decisions_log:
  - question: >
      Should the same Automatic Basic Security Audit that applies to Plugins also
      apply to uploaded Themes and to any file saved via the in-place Theme Editor,
      given that `theme.md`/`layout.php`/partials can contain arbitrary PHP?
    decision: >
      Yes — the same security audit used for Plugins (no eval, no exec, no remote
      code execution) also applies to Themes, both on ZIP upload and on files saved
      via the in-place Theme Editor. The only difference from the plugin flow is that
      a failed audit throws a `ThemeSecurityException` instead of a
      `PluginSecurityException`.
    rationale: >
      Themes can contain just as much arbitrary PHP as Plugins (`theme.md`,
      `layout.php`, partials), so leaving them unaudited would be an inconsistent
      security gap.
  - question: >
      Should theme files be versioned/backed up before each save through the Theme
      Editor, so an accidental bad edit can be reverted without needing the full Site
      Restore feature?
    decision: >
      Yes — versioning is implemented on each Theme Editor save (see the "Theme
      Editor File Versioning" note above).
    rationale: >
      Gives a lightweight, per-file undo path for editor mistakes instead of forcing
      a full Site Restore for a single bad save.
  - question: How will theme assets be handled?
    decision: >
      Theme assets (CSS, JS, images) will be served directly by the web server,
      with support for versioning to prevent caching issues.
    rationale: >
      Direct serving of assets provides better performance than PHP-based serving
      while still allowing for proper version management.
  - question: How will theme customization be implemented?
    decision: >
      Themes will include a built-in editor that allows direct modification of
      template files through the admin interface.
    rationale: >
      This provides an easy way for users to customize their themes without needing
      to modify files directly on the server.