decisions_log:
  - question: Should Composer-based installation of plugins be supported alongside ZIP upload?
    decision: >
      No — Composer installation of plugins has been removed, at least for v1. The
      only installation process now is ZIP file upload.
    rationale: >
      Keeps a single, admin-friendly install path consistent with the "even a non-tech
      person finds inviting" goal in `app`; CLI/Composer access isn't assumed to be
      available to site admins.
  - question: >
      What is the resolution path when the Automatic Basic Security Audit rejects a
      plugin — is the upload blocked outright, or installed with an "Install - Error"
      status (as implied by the Plugins List Page) for the Admin to inspect further?
    decision: >
      The upload is blocked outright. Since the upload has to finish before the
      system can unzip and inspect its contents, the flow is: the ZIP is unzipped,
      files are analyzed; if no security issues are found, the plugin's migration
      files run and the plugin is marked installed; if security issues are found,
      the unzipped plugin files are immediately deleted and a PluginSecurityException
      is thrown. There is no "Install - Error" status resulting from a failed
      security audit — that status is reserved for other install-time errors (e.g. a
      migration failure).
    rationale: >
      A plugin that fails the security audit should leave nothing installed or
      listed; only errors unrelated to security (e.g. a broken migration) warrant
      surfacing an "Install - Error" entry for the Admin to inspect.
  - question: >
      Is there a plugin dependency/versioning mechanism (e.g. a required core version,
      or dependencies between plugins) that needs to be declared in `plugin.md`?
    decision: >
      Yes — a Core Version dependency is declared in `plugin.md` (added to its
      required metadata list in `directory_structure`), mirroring the same field
      already present in `theme.md`/`admin.theme.md`.
    rationale: >
      Lets the install process reject a plugin that requires a newer core version
      than what's installed, consistent with how themes already declare a Core
      Version.
  - question: What approach will be used for plugin installation?
    decision: >
      Plugins will be installed as ZIP files that are extracted to a plugins directory,
      with the plugin's service provider registered automatically.
    rationale: >
      This approach provides a simple and familiar installation process for users
      while ensuring proper service registration through the DI container.
  - question: How will plugin dependencies be handled?
    decision: >
      Plugins can declare their dependencies in their metadata files. The plugin
      manager will handle loading plugins in the correct order based on dependencies.
    rationale: >
      This ensures that required services are available when a plugin is loaded,
      preventing runtime errors.
  - question: How will plugin configuration be handled?
    decision: >
      Each plugin can register its own configuration settings, which will be
      automatically merged with the main configuration system.
    rationale: >
      This allows plugins to maintain their own settings while integrating cleanly
      with the core configuration system.