SiteWeaver_CMS/.decisions/architecture_decisions.yaml

decisions_log:
  - question: >
      Is a dedicated backend_architecture section needed (per the "e.g." placeholder
      comment above)?
    decision: >
      No — a separate backend_architecture section is not needed. Backend detail is
      already captured across the domain-specific sections (media_manager_architecture,
      plugins_architecture, themes_architecture, auth_requirements), which together
      provide sufficient depth on the backend.
    rationale: >
      Those sections already document the relevant backend concerns for their domain
      (storage abstraction, migrations, Service Providers, permissions, etc.), so a
      separate umbrella backend_architecture section would just duplicate them.
  - question: >
      Is a dedicated frontend_architecture section still needed to document how Vue
      Components are organized/bundled, and how they integrate with Fomantic UI and
      the templating engine?
    decision: >
      Yes — a `frontend_architecture` section has been added (see below), filled in
      with what could be gathered from the rest of this document, with its own
      `open_questions` for what couldn't be inferred.
    rationale: >
      Frontend integration (Vue Components + Fomantic UI + Laravel Blade templates) is enough of its own concern to warrant a dedicated section rather than
      being folded into `architecture` or `ui`.
  - question: >
      Given the previous "Multi-tenancy ready" note, should v1's schema/routing
      already carry a tenant identifier (even if unused), or should multi-tenancy be
      deferred entirely to a future major version with its own migration path?
    decision: >
      Multi-tenancy has been removed from consideration altogether — not deferred,
      not kept "ready for" — SiteWeaverCMS is a single-site, single-tenant CMS with
      no planned migration path toward multi-tenancy. The "Multi-tenancy ready" note
      has been removed from `notes` above, and the "Multi-tenancy" glossary term has
      been removed.
    rationale: >
      Avoids carrying unused tenant-identifier columns/routing complexity for a
      direction the project will not pursue.
  - question: How will plugin and theme loading be handled?
    decision: >
      Plugins and themes will be loaded through service providers that register their
      respective services. The plugin manager and theme manager will handle the
      discovery, loading, and unloading of these components at runtime.
    rationale: >
      Using service providers ensures proper dependency injection for plugins and
      themes, while also allowing for lazy loading and easy testing of individual
      components.
  - question: What approach will be used for routing?
    decision: >
      Laravel's routing system will handle all application and plugin routes. Plugins
      can define their own route files or use Route::group to register routes, leveraging
      middleware, named routes, and resource controllers provided by the framework.
    rationale: >
      Using Laravel’s built-in router provides a well-tested, feature-rich routing
      layer that supports middleware, route caching, and easy integration with
      authentication guards and API resources.
  - question: How will configuration be managed?
    decision: >
      Configuration will be handled through a service that loads from environment
      variables and .env files (if available), with support for runtime updates.
    rationale: >
      Using environment variables for configuration ensures secure handling of
      sensitive data while allowing for easy deployment to different environments.
  - question: How will services be registered?
    decision: >
      Services will be registered using Laravel’s service provider pattern. Core
      services go into core service providers, application-level services in
      AppServiceProvider, and plugin/theme-specific services into their own
      service providers.
    rationale: >
      This follows Laravel conventions, enabling lazy loading, caching of
      bindings, and integration with the framework's lifecycle events.
  - question: How will caching be implemented?
    decision: >
      A combination of in-memory caching (for frequently accessed data) and file-based
      caching (for larger content that doesn't need to be loaded on every request).
    rationale: >
      This hybrid approach ensures good performance for both frequently accessed
      data and larger content while maintaining a reasonable memory footprint.
  - question: How will security be implemented?
    decision: >
      Security will be implemented through a combination of input validation,
      authentication, authorization, and secure storage practices. Plugins will be
      subject to automated security audits during installation.
    rationale: >
      A layered security approach ensures that multiple attack vectors are covered,
      with special attention to preventing code injection and unauthorized access.
  - question: >
      `in_scope` and `out_of_scope` were both still empty. What is explicitly IN scope
      for v1 and what is explicitly OUT of scope for v1?
    decision: >
      `in_scope` and `out_of_scope` have been populated (see lists above): Page
      Builder, Role Based Auth, User Management, Blog plugin, Media Manager,
      Theme/Plugin Editor, i18n, Comments, Backup/Restore, and Search are in scope
      for v1; multi-tenant/SaaS deployment, a plugin marketplace, and native mobile
      apps are out of scope.
    rationale: >
      Gives a concrete, at-a-glance v1 boundary to plan milestones against instead of
      inferring scope from `features_overview.notes`.
  - question: What backup strategy is supported in v1?
    decision: Manual trigger only via Admin UI, no automatic or scheduled backups.
    rationale: >
      The feature notes specify that backups are not automated; they must be triggered
      manually by an admin action.