status(2): discourse upgrade-tier blocked — ALL prev published versions pin removed bitnami images (3.1.2+3.3.1 gone); plan maximal subset install,backup,restore,custom + §7.1 sign-off for upgrade tier

machine-docs/STATUS-2.md

@@ -1088,3 +1088,18 @@ Drone re-tests the *trigger*, not the *recipe tests* (which is what Phase 2 is a
 OPERATOR decision, so this is flagged for operator input (not self-grantable). Alternatively a single
 representative Phase-2 recipe driven through real `!testme` would satisfy (a) at low cost — candidate
 once the current recipe-PR work settles. **OPEN — operator pick (a) vs (b) before DONE.**
+
+### discourse Q4.6 — UPGRADE TIER blocked by upstream image removal of PREV versions @2026-05-30
+FULL run (`/root/ccci-discourse-full.log`, STAGES=install,upgrade,backup,restore,custom) install tier
+FAILED at 2400s. CAUSE: with `upgrade` in STAGES, the install base-deploys the PREVIOUS published
+version (0.6.3+3.1.2) so upgrade can go prev→head — but that prev version's compose pins
+`bitnami/discourse:3.1.2`, which Docker Hub ALSO removed (same emptying as 3.3.1). Every published
+discourse tag (0.6.3+3.1.2, 0.7.0+3.3.1) references a now-removed bitnami image, so NO prev version is
+deployable → the HC1 upgrade-crossover tier cannot run. (install+custom passed in pr5 because that mode
+base-deploys the PR HEAD directly = re-pinned bitnamilegacy/discourse:3.3.1.) Re-pinning a published
+*tag* would mean rewriting published mirror history — not appropriate.
+**PLAN (maximal subset, §7.1 pattern like drone/plausible):** run `STAGES=install,backup,restore,custom`
+on PR head → gives P1 (install serving) + P4 (backup/restore data-integrity) + P3 (create-topic/site) +
+P2 N/A. Document the **upgrade tier** as a genuine upstream-image-removal constraint (all prev published
+images gone) and request Adversary §7.1 sign-off for that one tier. NOT a weakened test — the upgrade
+machinery is fine; there is simply no servable prev image to upgrade FROM.