review(2): ACK new anti-compose-overlay policy + SCOPED VETO on DONE — discourse/ghost start_period must migrate to env PR (ghost Q4.4 + mumble Q4.2 passes now CONDITIONAL); REVERSE discourse Q4.6 §7.1 (now GRANT upgrade-from-removed-image-base deferral per policy pt2); drift evidence = overlay-merge YAML dup-key fail

machine-docs/REVIEW-2.md

@@ -2103,3 +2103,57 @@ servable prev image" is false — bitnamilegacy:3.3.1 is served, and the 0.7.0
 and achievable). NOT a final verdict: discourse Q4.6 is unclaimed. If the Builder claims the deferral, the
 bar is: show the 0.7.0→0.8.0 honest crossover is genuinely unachievable (not just `[-2]`-inconvenient), or
 implement it green. I'll re-run cold either way before ruling.
+
+## POLICY ACK + RECALIBRATION @2026-05-30T14:23:42Z — plan-prefer-env-over-compose-overlay.md (cc-ci compose overlays = drift); SCOPED VETO on DONE
+Orchestrator shipped a new ACTIVE §9 guardrail (`/srv/cc-ci/cc-ci-plan/plan-prefer-env-over-compose-overlay.md`,
+4942 B): cc-ci-authored `tests/<recipe>/compose.*.yml` overlays are test-environment DRIFT (recipe-as-tested
+≠ recipe-as-published) → can mask defects / weaken tests. Policy: (1) prefer an UPSTREAM env-var recipe PR
+(e.g. `APP_START_PERIOD=${APP_START_PERIOD:-5m}`) set via .env/EXTRA_ENV; (2) prefer DECLARING an old base
+UNTESTABLE (§7.1 Adversary-signed) over a custom compose to make a removed-image base deployable;
+(3) overlays are LAST RESORT — each must be Adversary-justified in REVIEW + paired with the obsoleting env PR
++ tracked in DECISIONS. Retroactive: existing overlays (discourse/ghost/mumble) must migrate OR get a
+last-resort record before the owning gate may pass/stay-passed; "a green run that depends on an unjustified
+overlay is NOT a valid pass."
+
+**I am POLICING this now. Current cc-ci overlay surface (verified on disk @HEAD 0002f9c):**
+- `tests/discourse/compose.ccci-health.yml` — app healthcheck `start_period: 1200s` (on-disk content is
+  start_period-only; NO image re-pin present despite an earlier Builder note — re-confirm if it reappears).
+- `tests/ghost/compose.ccci-health.yml` — same class (start_period bump).
+- `tests/mumble/host-ports.yml` — host-port publishing for the mumble-web sidecar (NOT a start_period).
+
+**Per-overlay assessment vs policy:**
+- discourse start_period → **MIGRATE to env PR** (policy ex. `APP_START_PERIOD`). NOT last-resort (env can
+  express it). The Builder already has recipe PR recipe-maintainers/discourse#1 open — fold APP_START_PERIOD
+  (default 5m) into it; cc-ci sets EXTRA_ENV; delete the overlay.
+- ghost start_period → **MIGRATE to env PR** (same). ⇒ **ghost Q4.4 PASS is now CONDITIONAL** — its green
+  run depended on this overlay; per policy it is not a valid stay-pass until migrated-or-justified.
+- mumble host-ports → **JUSTIFY-or-migrate.** Host-mode/published-port topology may not be env-expressible;
+  could be a genuine last resort — but it needs an explicit Adversary-justified last-resort RECORD
+  (+ DECISIONS) which does not yet exist. ⇒ **mumble Q4.2 PASS is now CONDITIONAL** pending that record.
+
+**RECALIBRATION — discourse Q4.6 §7.1 (I am REVERSING my prior leaning, and saying so plainly):**
+Earlier (REVIEW-2 dba574e/1d83beb) I argued the upgrade tier is testable via a uniform image-re-pin overlay
+→ "leaning DENY the §7.1 deferral", and pushed the Builder to implement it. **The new policy supersedes that.**
+All published discourse prev bases pin REMOVED `bitnami/discourse:*` images (verified: 0.6.3+3.1.2→404,
+0.7.0+3.3.1→404; bitnamilegacy served), so the ONLY way to deploy a prev base is a cc-ci re-pin overlay —
+which policy point 2 explicitly says to AVOID in favor of declaring that base untestable. So my position is
+now: **the discourse upgrade-from-removed-image-base IS a legitimate §7.1 environment-level blocker, and I
+will GRANT that sign-off** when claimed with (a) a DECISIONS note naming the removed-image constraint, and
+(b) the maximal subset install,backup,restore,custom GREEN on the re-pinned PR head (the recipe PR's
+bitnami→bitnamilegacy is an UPSTREAM recipe change, legitimate, not a cc-ci overlay), with start_period via
+env PR not overlay, P4 non-vacuous, ≥2 real P3, deploy-count=1, clean teardown. (UPGRADE_BASE_VERSION the
+Builder added is a harness env knob, not a compose overlay — fine to keep; it's just moot if upgrade is
+deferred.) I own the churn this reversal causes; the policy is correct (the overlay would test a recipe no
+user runs).
+
+**Corroborating drift evidence (first-hand):** the last full run /root/ccci-discourse-maxsub.log failed at
+the BASE deploy with `yaml: unmarshal errors: line 139: mapping key "file" already defined at line 138` —
+i.e. the COMPOSE_FILE overlay merge itself produced invalid YAML. Concrete instance of the fragility the
+policy warns about.
+
+## VETO (scoped to Phase-2 DONE) @2026-05-30T14:23:42Z
+**No Phase-2 `## DONE` until every cc-ci `tests/<recipe>/compose.*.yml` overlay is EITHER migrated to the
+upstream env-var pattern OR carries an Adversary-justified last-resort record (+ DECISIONS), per
+plan-prefer-env-over-compose-overlay.md.** Currently unresolved: discourse (migrate), ghost (migrate, Q4.4
+pass now conditional), mumble (justify-or-migrate, Q4.2 pass now conditional). This VETO does NOT block any
+in-progress recipe work — only the DONE flip. I close it when all three are resolved and re-verified.