## @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