decisions_log:
  - question: What language and minimum version should the app target?
    decision: PHP 8.4+
    rationale: >
      8.4 is as far back in PHP versions as we want to support; targeting a recent
      minimum keeps the codebase modern instead of carrying compatibility baggage
      for older, less-supported PHP versions.
  - question: Should the backend use an existing framework (e.g. Laravel, Symfony) or a custom/home-brewed codebase?
    decision: Laravel 13.x
    rationale: >
      Leveraging Laravel 13.x provides robust routing, authentication, service container,
      and ecosystem packages that accelerate development and reduce maintenance burden.
  - question: Which CSS framework should the UI be built on?
    decision: Fomantic UI
    rationale: >
      Fomantic UI is an actively maintained fork of Semantic UI (which is no longer
      maintained), and semantic class names are strongly preferred over
      structural/utility class names for CSS.
  - question: Which JavaScript approach/framework should the frontend use?
    decision: >
      Vue — but used specifically via its Components feature only (similar in spirit
      to how Svelte components are used), not as a full-fledged SPA framework.
    rationale: >
      General preference for Vue over React or Angular. Svelte would also have been an
      acceptable choice for a components-only approach, but Vue was the one picked.
  - question: Which tool should manage PHP dependencies?
    decision: Composer
    rationale: Composer is the de facto standard package manager for PHP.
  - question: >
      Is SiteWeaverCMS intended to be self-hosted only for v1, or should the
      "Multi-tenancy ready" note under `architecture` mean a hosted/SaaS offering
      is also on the roadmap?
    decision: >
      Self-hosted only. Multi-tenancy has been removed from consideration entirely
      (see `architecture.decisions_log`), so there is no hosted/SaaS offering on the
      roadmap and no tenant-isolation/billing concerns to capture.
    rationale: >
      Once multi-tenancy was ruled out as an architectural direction, a hosted/SaaS
      offering (which would require it) is ruled out along with it.
  - question: >
      When the "Automatic Basic Security Audits for Plugins" check fails (eval/exec/
      remote code execution detected), what happens — is the ZIP upload rejected
      outright, or is the plugin installed with an "Install - Error" status (as
      implied by the Plugins List Page in `plugins_architecture`) for an Admin to
      review?
    decision: >
      The upload is rejected outright, not installed with an "Install - Error" status.
      Flow: the ZIP is unzipped, files are analyzed; if no security issues are found,
      the plugin's migrations run and it is marked installed; if security issues are
      found, the unzipped plugin files are immediately deleted and a
      PluginSecurityException is thrown. The same audit and rejection flow applies to
      Themes (throwing a ThemeSecurityException instead) — see
      `plugins_architecture.decisions_log` and `themes_architecture.decisions_log`.
    rationale: >
      Files must be unzipped before they can be scanned, so a full "Install - Error"
      list entry is unnecessary — a failed audit is treated as a hard rejection with
      no trace left on disk.
  - question: How will dependency injection be implemented in the app?
    decision: >
      Laravel's built-in service container will be used, following the framework’s
      service provider pattern. This provides robust DI, lazy loading, and integration
      with Eloquent, routing, and other core services.
    rationale: >
      Leveraging Laravel's container eliminates the need for a custom DI solution,
      reduces boilerplate, and aligns with the ecosystem's conventions.
  - question: What license (if any) will SiteWeaverCMS be released under (e.g. MIT, GPL, proprietary)?
    decision: >
      No public license for now — SiteWeaverCMS stays sole-ownership/proprietary. It
      is being used to build client websites, with the clients themselves administering
      the sites built for them; a public release/license may be revisited later.
    rationale: >
      Matches the current usage model (agency-built client sites) rather than a
      publicly redistributable product, so there is no need to pick a license yet.
  - question: >
      Should a target audience/deployment size be stated up front, since it
      influences caching, storage backend, and search decisions made later in the
      spec?
    decision: >
      Yes — the initial target audience is self-employed business owners, small
      craft makers, and small new bloggers, with room to grow toward larger sites
      and capabilities over time.
    rationale: >
      Gives later caching/storage/search decisions a concrete initial scale to design
      against, while leaving room to grow.