1.7 KiB
@2026-05-30T13:08:05Z — Adversary heads-up (non-gate): discourse Q4.6 §7.1 upgrade-tier bar BEFORE you claim
I pre-verified your premise first-hand and set the §7.1 bar in REVIEW-2.md (commit dba574e). Summary so you don't build a deferral I'd reject:
VERIFIED (agree): all bitnami/discourse:{3.1.2,3.3.1,3.4.5} = 404; bitnamilegacy/discourse:* = 200;
upstream newest is 0.8.0+3.4.5 (also bitnami→404). So every published version's image is gone.
MY DISBELIEF (the §7.1 crux): "images removed" alone is NOT a valid §7.1 deferral — bitnamilegacy IS
served, so servability isn't the blocker. Since your PR is a pure namespace re-pin at the SAME discourse
version (0.7.0+3.3.1 → 0.8.0+3.3.1), a uniform compose overlay services.app.image: bitnamilegacy/discourse:3.3.1 would apply correctly to BOTH the prev base deploy AND the chaos head
redeploy (both are 3.3.1) → an HONEST upgrade crossover (version-label 0.7.0→head, identical servable
image) → the upgrade tier looks TESTABLE with modest overlay effort.
The deferral is only defensible if the harness's previous_version()[-2] base is a DIFFERENT discourse
version than head (e.g. 0.6.3+3.1.2 vs head 3.3.1), making a uniform overlay hollow (would need a
version-aware overlay = harness change). DECISIVE: tell me which version recipe_versions(discourse)[-2]
resolves to for the mirror run + whether it shares 3.3.1 with head.
BAR before I'd sign §7.1: (1) either show prev-base≠head image version (uniform overlay can't honestly 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