# Multi-Site Config — Step 4: Implementation Summary

## Stage 1 - SiteProfileRegistry class
- Changes:
  - Added `src/ForumRewrite/SiteProfileRegistry.php`
    - `all(): array` — `zenmemes` and `chouse` entries, each with `name`, `defaultTheme`, `composerPrompt`
    - `active(): array` — resolves `getenv('FORUM_SITE_ID')`, defaults to `zenmemes` when unset/empty/unrecognized
  - Added `tests/SiteProfileRegistryTest.php` covering default resolution, known override, unknown-value fallback, and required-field presence
  - Registered the new test file in `tests/run.php`
- Verification:
  - `php tests/run.php` — full suite passes, including all 4 new `SiteProfileRegistryTest` cases
- Notes:
  - Both profiles currently carry identical `defaultTheme`/`composerPrompt` placeholder values; Stages 3-4 wire those fields through to rendering, at which point chouse's values can be revisited/diverged if desired

## Stage 2 - Wire SiteConfig::siteName()
- Changes:
  - `SiteConfig::SITE_NAME` constant replaced with `SiteConfig::siteName(): string`, delegating to `SiteProfileRegistry::active()['name']`
  - Updated call sites: `Application.php:966,997,2346,2422`, `Host/FrontController.php:265,278`, `View/TemplateRenderer.php:66`
  - `templates/pages/about.php` needed no change — it already reads `$siteName` from the template context these call sites populate
- Verification:
  - `php -l` on all four touched files — no syntax errors
  - `php tests/run.php` — full suite passes
  - Manual check: `SiteConfig::siteName()` returns `zenmemes` with `FORUM_SITE_ID` unset, `chouse` when set to `chouse`, and `zenmemes` for an unrecognized value
- Notes:
  - Searched for other hardcoded `zenmemes` literals outside the `SITE_NAME` call sites. Found and intentionally left untouched, as out of scope for this stage:
    - `FrontController.php:281` — a hardcoded "zenmemes is still baking" joke string in the busy-page copy (site-specific copy, not the site-name accessor; belongs to a future chouse-branding feature)
    - `templates/layout.php`, `public/assets/theme_toggle.js`, `public/assets/thread_density_toggle.js` — `localStorage` key names (`zenmemes-theme`, `zenmemes-thread-density`); internal storage keys, not user-facing branding, and functionally inert across sites since browsers scope `localStorage` per origin
    - `templates/pages/about.php:3` — a `data-about-section="zenmemes"` attribute used for CSS/JS targeting, not rendered text

## Stage 3 - Default theme wiring
- Changes:
  - `TemplateRenderer::renderLayout()` adds `'defaultTheme' => SiteProfileRegistry::active()['defaultTheme']` to the layout context
  - `templates/layout.php` renders it as `data-default-theme="..."` on the `<html>` root element
  - `public/assets/theme_toggle.js`: new `defaultTheme()` helper reads that attribute (validated against the known theme list, else `"auto"`); `readStoredTheme()`'s two `"auto"` fallbacks now call it instead
- Verification:
  - `php -l` on touched PHP files, `node -c` on `theme_toggle.js` — no syntax errors
  - `php tests/run.php` — full suite passes
  - Manual check via `TemplateRenderer::renderLayout()`: `FORUM_SITE_ID` unset renders `data-default-theme="auto"` + `siteName=zenmemes`; `FORUM_SITE_ID=chouse` renders `data-default-theme="auto"` + `siteName=chouse` (both profiles currently share the `auto` default, so output differs only in site name until a profile's `defaultTheme` diverges)
- Notes:
  - The inline pre-hydration script in `layout.php` (head `<script>`, lines 7-34) still falls back to leaving no `data-theme` attribute when nothing is stored, rather than reading `data-default-theme` itself — for every profile today that resolves to the same visual result (`auto` via CSS `prefers-color-scheme`), since both profiles use `auto`. If a future profile sets a non-`auto` default theme, first-time visitors would see a brief flash of the system-preference theme before `theme_toggle.js` applies the real default on `DOMContentLoaded`. Left out of this stage's scope (the approved plan only called for wiring `TemplateRenderer` → attribute → `theme_toggle.js`); worth revisiting if/when a site profile actually diverges from `auto`.

## Stage 4 - Composer copy wiring
- Changes:
  - `TemplateRenderer::renderFile()` adds `'composerPrompt' => SiteProfileRegistry::active()['composerPrompt']` to the same default-merge block that already injects `unicodeAuthoredTextEnabled`/`emojiAuthoredTextEnabled` into every page/partial, so no per-route wiring was needed
  - `templates/pages/board.php`: the inline composer's `placeholder` and `aria-label` now read `$composerPrompt` (aria-label strips a trailing `.` for phrasing) instead of the literal `"Start a thread..."` / `"Start a thread"` strings
- Verification:
  - `php -l` on touched PHP files — no syntax errors
  - `php tests/run.php` — full suite passes
  - Manual render check via `TemplateRenderer::renderPageTemplate('board.php', ...)`: output textarea shows `placeholder="Start a thread..."` and `aria-label="Start a thread"`, identical to the pre-change literal, confirming no behavior change for zenmemes
  - Grepped `templates/` for other occurrences of `"Start a thread"` — none found, so no duplicate copy was missed
- Notes:
  - Both profiles still share the same `composerPrompt` value from Stage 1's placeholder data; chouse's copy can diverge later (e.g. in a future chouse-branding feature) by editing only `SiteProfileRegistry::all()`

## Stage 5 - Site-scoped local dev bootstrap
- Changes:
  - `LocalRepositoryBootstrap::defaultRepositoryRoot(string $projectRoot, string $siteId = 'zenmemes'): string` — new optional `$siteId` param; `zenmemes` (including the pre-existing default) resolves to the unchanged `state/local_repository` path, any other site ID resolves to a suffixed sibling directory (`state/local_repository_<siteId>`), auto-initialized from the same fixture the same way
  - `public/index.php` resolves `$siteId` via `SiteProfileRegistry::active()['name']` and applies the same suffix convention to the local defaults for `FORUM_REPOSITORY_ROOT`, `FORUM_DATABASE_PATH`, and `FORUM_STATIC_HTML_ROOT` (all three only take effect when the corresponding env var is unset — explicit env vars still win, unchanged)
  - All other `LocalRepositoryBootstrap::defaultRepositoryRoot()` call sites (various `scripts/*.php`, `tests/LocalAppSmokeTest.php`) are unaffected — the new parameter defaults to `'zenmemes'`, reproducing today's exact behavior
- Verification:
  - `php -l` on touched PHP files — no syntax errors
  - `php tests/run.php` — full suite passes
  - Manual check: `LocalRepositoryBootstrap::defaultRepositoryRoot($projectRoot)` (no site ID) still resolves to the pre-existing `state/local_repository`
  - Manual check: `LocalRepositoryBootstrap::defaultRepositoryRoot($projectRoot, 'chouse')` auto-initializes a distinct `state/local_repository_chouse` with its own `records/` and `.git`
  - Manual check of the `public/index.php` path-resolution logic: `FORUM_SITE_ID` unset yields the exact pre-existing database/static-html paths; `FORUM_SITE_ID=chouse` yields distinct `_chouse`-suffixed sibling paths
  - This directly delivers the dev-config ask: `FORUM_SITE_ID=chouse ./v3 start` alone (no other `FORUM_*` vars) now serves a fully separate, auto-initialized chouse sandbox — content, database, and static-artifact paths never overlap with the zenmemes checkout
- Notes:
  - `state/local_repository_chouse` is gitignored (same rule that covers `state/local_repository`), so exercising this locally leaves no untracked changes to commit

## Stage 6 - Docs and smoke-test coverage
- Changes:
  - `docs/examples/apache_vhost.conf`: added a commented `FORUM_SITE_ID` line alongside the existing `FORUM_*` path vars
  - `docs/examples/env.production.example`: same, as a commented optional var with its default noted
  - `docs/runbooks/production_deploy.md`: new "Site Profile" section — values, default, precedence/rollback matching the runbook's existing `FORUM_*` style, and the local/CLI `FORUM_SITE_ID=chouse ./v3 start` dev workflow from Stage 5
  - `tests/LocalAppSmokeTest.php`: added `testDefaultRepositoryBootstrapIsSiteScoped()` (zenmemes path unchanged, chouse resolves to a distinct auto-initialized sibling) and `testBoardPageRendersActiveSiteProfilePerFormSiteId()` (full `Application`-level render confirms site name and default theme both flip correctly between `FORUM_SITE_ID` unset and `chouse`, with proper `putenv` cleanup in `finally`)
- Verification:
  - `php -l` on all touched PHP files — no syntax errors
  - `php tests/run.php` — full suite passes, including both new `LocalAppSmokeTest` cases
- Notes:
  - While verifying this stage, `php tests/run.php` initially reported `testFrontControllerShowsBusyErrorForExecutionLockContention` failing. Root cause: an untracked `public/index.html` (gitignored static-artifact cache) had been written to disk as a side effect of this session's own earlier manual `Application`-level rendering checks in Stages 3-5. `FrontController` serves that cached file for `/` before ever reaching the lock/rebuild code path the test exercises, so the test short-circuited into a false failure — not a regression from this feature's changes. Confirmed by running the full suite on a clean `main` worktree (passed) and by inspecting `FrontController::resolveStaticArtifactPath()`, which checks `publicRoot/index.html` first. Fixed by deleting the stray gitignored file; the full suite is green afterward.