overlay policy (content): §9 guardrail rewrite + plan-ccci-compose-overlay-policy.md

The prior commit only captured the file deletion (git add aborted on the
already-removed pathspec). This adds the actual content: the reworked §9
guardrail (justified ccci overlays OK; abra can't env start_period; always test
upgrade-to-latest, from-version custom tests skippable) and the new policy doc.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

cc-ci-plan/plan.md

@@ -830,20 +830,25 @@ Each default stands until the Adversary or reality forces a change; record the c
   a real app-level check — that **RAISES on actual non-readiness**, never a no-op that masks a failed
   deploy. **Prove it has teeth** (a negative test that fails on stuck convergence, e.g. F2-12's
   P7-negative). The Adversary treats a custom probe as a potential test-weakening until cold-verified.
-- **Don't fork the recipe's compose — parameterize upstream, tune via env.** A cc-ci-authored compose
-  file/overlay (an extra `compose.*.yml` layered via `COMPOSE_FILE`) is **avoided wherever possible**:
-  it risks **silent drift** from the recipe actually shipped, so you'd no longer be testing what users
-  get. When a recipe needs a value tuned for cc-ci's environment (e.g. a longer healthcheck
-  `start_period` for the slower single node), the **preferred fix is an upstream recipe PR** that
-  exposes it as an **env var** (e.g. `APP_START_PERIOD`) with the **current value as the default in
-  `env.sample`** — then CI just sets that env in the app `.env`, no new compose. The env knob also
-  helps real operators on slow hosts. **Old-version testability:** if making the **upgrade tier** work
-  from an older base version would need a custom compose (a since-removed image tag, or an overlay the
-  old version predates), **prefer DECLARING that older version not-testable under this CI env** (note
-  it + skip that crossover) over authoring a custom compose for it. A cc-ci compose overlay is a
-  **last resort** only when neither path is possible — Adversary-confirmed non-drifting and paired with
-  the upstream-env PR that will obsolete it. (The existing ghost/discourse `compose.ccci-health.yml`
-  start_period overlays + discourse's image re-pin are exactly this debt — migrate per
-  `plan-prefer-env-over-compose-overlay.md`.)
+- **Custom cc-ci compose overlays — avoid where possible, justify each, prefer upstream.** A
+  cc-ci-authored compose overlay (an extra `compose.*.yml` layered via `COMPOSE_FILE`) risks **drift**
+  from the recipe users actually run, so **avoid it where possible and justify each use**. In most
+  cases the cleaner fix is an **upstream recipe PR** — either a genuine robustness fix, or exposing a
+  knob the recipe should expose. **But a uniform, optional `compose.ccci-*.yml` overlay file per
+  recipe is an acceptable fallback** — especially for a value abra/compose can't take from an env var.
+  **Known limitation (builder, 2026-05-30): abra does NOT support an env value for a healthcheck
+  `start_period`.** So the ghost/discourse `start_period` bumps legitimately **need** the overlay (an
+  env-var PR is not possible for that field) — these overlays **stay**, justified. When you do use an
+  overlay: keep it **minimal + single-purpose**, **document WHY in the file header** (the exact abra/
+  upstream limitation that forces it), have the **Adversary confirm it doesn't weaken a test or mask a
+  recipe defect**, and **file the upstream PR where the fix genuinely belongs** (e.g. if a recipe's
+  `start_period` is too tight for any slow host, propose raising it upstream too).
+- **Upgrade tier: always test the upgrade to the LATEST version.** Don't drop the upgrade test just
+  because the *from* (older) version is awkward. If an older from-version can't be fully deployed/tested
+  (its image tag was pulled from the registry, or it predates an overlay/feature), you do **NOT** need
+  that older version's **custom tests** to run — deploy it minimally (a justified overlay is fine) or
+  pick the nearest deployable prior, then **upgrade to latest and run the full assertions on the
+  latest**. Skipping a from-version's custom tests is an honest, recorded outcome; skipping the
+  upgrade-to-latest is not. (See `plan-ccci-compose-overlay-policy.md` for the per-recipe disposition.)
 - **Honest reporting.** If a stage is skipped or a check failed, say so in `STATUS.md`/`JOURNAL.md`
   with the output. The loop's value depends entirely on the ledgers being true.