review(2): discourse Q4.6 §7.1 pre-positioning — premise VERIFIED first-hand (all bitnami/discourse:{3.1.2,3.3.1,3.4.5}=404, bitnamilegacy=200, upstream newest 0.8.0+3.4.5); deferral NOT yet established (honest uniform-overlay crossover may make upgrade tier testable iff prev base==head image ver); decisive fact OPEN; bar set; not a verdict

machine-docs/REVIEW-2.md

@@ -2016,3 +2016,60 @@ window. So the forward-looking **Q5/DONE criterion still holds**: before I sign
 "a full green `!testme` run" + D7 results-UX), OR (b) an operator-blessed STATUS-2 statement that host
 `cc-ci-run` validation satisfies P1 (trigger recipe-agnostic, proven once in D10) and an empty live
 dashboard is acceptable for DONE. NOT a veto; not blocking in-progress work.
+
+## Break-it probe @2026-05-30T13:07:50Z — discourse Q4.6 §7.1 (upgrade-tier deferral) PRE-POSITIONING — premise VERIFIED; deferral NOT yet established (NOT a verdict; gate unclaimed)
+discourse Q4.6 is NOT formally claimed and no §7.1 sign-off is owed yet (Builder flagged the intent in
+STATUS-2 880ba78, not via my inbox). This is disbelieve-first pre-positioning so the bar is set before any claim.
+
+**VERIFIED FIRST-HAND (cc-ci host, Docker Hub registry v2 API; sanity debian:latest=200, token auth OK):**
+- `bitnami/discourse:3.1.2` → **404**, `:3.3.1` → **404**, `:3.4.5` → **404** (ALL removed).
+- `bitnamilegacy/discourse:3.1.2` → **200**, `:3.3.1` → **200**, `:3.4.5` → **200** (ALL served).
+- Upstream (`abra recipe fetch discourse`) newest published tag = **`0.8.0+3.4.5`** (newer than the
+  `0.7.0+3.3.1` the Builder's re-pin PR targets). Its compose also pins bitnami/discourse (→404).
+⇒ The Builder's **factual** premise is TRUE: every published discourse version pins a now-removed
+  `bitnami/discourse:*` image; the drop-in `bitnamilegacy/discourse:*` is served for every tag.
+
+**HARNESS MECHANISM (read first-hand: run_recipe_ci.py:725-729, lifecycle.py:200-263, 508-510):**
+- Upgrade tier base-deploys `base = previous_version(recipe) = recipe_versions()[-2]` (2nd-newest
+  PUBLISHED tag), via `deploy_app(version=prev)` → `abra recipe checkout <prev tag>` → deploy that
+  tag's compose. That compose pins `bitnami/discourse:<X>` (404) → base deploy fails. **The
+  cc-ci overlay (compose.ccci-health.yml) only raises healthcheck start_period; it does NOT re-pin the
+  image.** The HEAD re-pin lives in the PR-head compose, not the overlay.
+- COMPOSE_FILE/EXTRA_ENV overlay is "applied at EVERY deploy (install + upgrade's old_app)"
+  (lifecycle.py:77) — i.e. **version-UNIFORM**: one static overlay hits both the prev base deploy and
+  the chaos head redeploy identically.
+
+**DISBELIEVE-THE-"UNTESTABLE" ANALYSIS (the §7.1 crux — CONDITIONAL, one fact still to verify):**
+§7.1 says "needs effort / needs a workaround" is NOT a valid deferral; only a true environment-level
+blocker is. So the real question isn't "is the published image gone" (yes) but "can an HONEST upgrade
+crossover still be built." A static image-override overlay (`services.app.image: bitnamilegacy/discourse:<X>`)
+is version-uniform, so it pins the SAME image on BOTH base and head. Therefore:
+  • IF the harness's chosen prev base and the PR head target the **same** discourse image version
+    (Builder's PR is a pure namespace re-pin at 3.3.1: 0.7.0+3.3.1 → 0.8.0+3.3.1), then a uniform
+    `image: bitnamilegacy/discourse:3.3.1` overlay is CORRECT for both deploys → an **honest** crossover
+    (version-label/commit 0.7.0→head while running the identical, servable 3.3.1 image) → the upgrade
+    tier **IS testable with modest overlay effort** ⇒ deferral **NOT warranted**.
+  • IF the chosen prev base is a DIFFERENT discourse version than head (e.g. previous_version picks
+    0.6.3+**3.1.2** while head is **3.3.1**), a uniform overlay would force head onto 3.1.2 → a HOLLOW
+    "upgrade" (running the old image under the head version label) which §7.1 forbids; an honest
+    crossover would then require a version-AWARE overlay = a harness change (infra, out of Phase-2
+    scope) ⇒ deferral **more defensible**.
+
+**DECISIVE OPEN FACT (not yet verified first-hand — host output truncated):** which version does
+`recipe_versions(discourse)[-2]` resolve to **for this run** (mirror SRC=recipe-maintainers/discourse +
+REF=head), and does it share discourse's image version (3.3.1) with the PR head? That single fact
+decides sound-vs-unwarranted. I will resolve it before ruling.
+
+**Pre-positioned §7.1 bar (must ALL hold before I'd sign off the upgrade-tier deferral):**
+1. Builder demonstrates the prev base and PR head are **different** discourse image versions (so a
+   uniform overlay can't honestly bridge them), OR implements the honest uniform-overlay crossover and
+   runs the upgrade tier green. "All published images removed" alone is NOT sufficient — bitnamilegacy
+   is served, so servability is not the blocker; honest-crossover-impossibility is the bar.
+2. Maximal subset (install,backup,restore,custom on PR head) genuinely GREEN, deploy-count=1,
+   clean teardown.
+3. P4 backup/restore **non-vacuous** (seeded marker survives; negative control RED), ≥2 real P3
+   functional tests (create-topic round-trip etc., not health-only).
+NOT a veto, NOT a verdict — recorded so the §7.1 ruling is rigorous when the gate is claimed.
+
+(Harness caveat: tool-output garbled/duplicated lines this session; every VERIFIED fact above was
+re-confirmed and is consistent across duplicated outputs; the one truncated fact is explicitly marked OPEN.)