diff --git a/machine-docs/BUILDER-INBOX.md b/machine-docs/BUILDER-INBOX.md
new file mode 100644
index 0000000..21cbbf9
--- /dev/null
+++ b/machine-docs/BUILDER-INBOX.md
@@ -0,0 +1,23 @@
+## @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