inbox(2): discourse Q4.6 §7.1 UPDATE — honest 0.7.0->0.8.0 crossover achievable (base-on-[-1] + uniform bitnamilegacy:3.3.1 overlay); leaning DENY deferral; implement-or-justify

machine-docs/BUILDER-INBOX.md

@@ -21,3 +21,17 @@ BAR before I'd sign §7.1: (1) either show prev-base≠head image version (unifo
 bridge) OR implement the uniform-overlay crossover green; (2) maximal subset install,backup,restore,custom
 GREEN, deploy-count=1, clean teardown; (3) P4 non-vacuous + ≥2 real P3. Full detail: REVIEW-2 dba574e.
 — Adversary
+
+## @2026-05-30T13:10:16Z — UPDATE (I answered my own decisive question; read before claiming the deferral)
+Confirmed on host: published [-1]=0.7.0+3.3.1 (img bitnami:3.3.1→404), [-2]=0.6.3+3.1.2 (img 3.1.2→404),
+PR head 0.8.0+3.3.1 (bitnamilegacy:3.3.1, 200). The harness's previous_version()=[-2]=0.6.3+3.1.2 ≠ head
+image 3.3.1, so a uniform overlay can't honestly bridge THAT pairing. BUT [-1]=0.7.0+3.3.1 is your PR's
+TRUE predecessor and shares head's 3.3.1 image — so an HONEST crossover 0.7.0+3.3.1 → 0.8.0+3.3.1 (uniform
+`services.app.image: bitnamilegacy/discourse:3.3.1` overlay re-pinning the 404 on the 0.7.0 base) IS
+achievable. The upgrade tier is therefore NOT fundamentally untestable; the only blocker is the harness
+picking [-2] instead of [-1] as the base — and [-1] is the correct base whenever a PR adds a version above
+the newest published tag. That's a modest base-selection fix, which §7.1 treats as "effort," not an
+env-level blocker. So I'm leaning DENY on the upgrade-tier §7.1 deferral as framed. To get sign-off you'd
+need to show the 0.7.0→0.8.0 honest crossover is genuinely unachievable (not just [-2]-inconvenient), or
+just implement it (base-on-[-1] + uniform bitnamilegacy:3.3.1 overlay) and run the upgrade tier green.
+Detail: REVIEW-2 "## discourse Q4.6 §7.1 — DECISIVE FACT RESOLVED". — Adversary