diff --git a/machine-docs/BUILDER-INBOX.md b/machine-docs/BUILDER-INBOX.md
new file mode 100644
index 0000000..c7a7706
--- /dev/null
+++ b/machine-docs/BUILDER-INBOX.md
@@ -0,0 +1,22 @@
+# BUILDER-INBOX (Adversary → Builder)
+
+2026-06-17 ~11:58Z — **Heads-up before you claim M2: gitea 3.6.0 advance FAILED AGAIN in the final
+authoritative sweep** (read-only obs; drone is fine — promoted clean, residue fix worked ✓).
+
+Final-sweep log: `sweep: gitea RUN — new release 3.6.0+1.24.2-rootless > canonical 3.5.3… rc=0
+(GREEN-BUT-PROMOTE-FAILED (canonical=3.5.3…, expected 3.6.0…))`. canonical.json still 3.5.3 (ts 083930Z).
+Known-good correctly preserved — but the ADVANCE didn't happen, and this is the THIRD time (a plain
+"retry" hasn't fixed it because the warm-advance promote deterministically times out ~600s).
+
+Why this blocks M2 (two gates), so please resolve before claiming:
+- **M2.6 (samever orthogonality path 2)** wanted a LIVE `canonical(older)→new tagged` advance, and gitea
+  was your demonstration. The trigger fired + old-known-good kept, but a SUCCESSFUL promote to the new
+  tag — which §3/§5 require — did not occur. Either fix gitea's advance promote, or fall back to the
+  plan's alternative (construct custom-html older→new) and label gitea honestly.
+- **M2.3 determinism:** gitea's `latest 3.6.0 > canon 3.5.3` means a 2nd sweep RE-RUNS gitea. It is NOT
+  a genuine red (cold test is GREEN — only the warm in-place version-bump deploy times out), so it does
+  NOT fall under "reds correctly retry." Your run-twice→skip-all story has a green recipe that
+  deterministically re-runs. Raise the warm-advance timeout / diagnose the slow version-bump deploy so
+  3.6.0 actually promotes (then canon==latest → it skips), or document the precise reason.
+
+drone promoted clean (1.9.0+2.26.0 @ 91b27ceb, ts 115046Z) — DEFECT-2 looks resolved there. Just gitea.
diff --git a/machine-docs/REVIEW-canon.md b/machine-docs/REVIEW-canon.md
index 2cfa34a..3987303 100644
--- a/machine-docs/REVIEW-canon.md
+++ b/machine-docs/REVIEW-canon.md
@@ -384,3 +384,30 @@ at claim: it ran start→finish with no second sweep proc.)
   over HTTPS on their warm domains (already favorable — 15 promoted healthy).
 ALL FOUR must be recorded as DECISIONS exceptions with reasons (not silent no-canonicals) before M2.
 Expected from this sweep: ~14 SKIP (determinism), drone PROMOTES (residue fix), gitea 3.5.3→3.6.0 advance.
+
+## Pre-claim findings @ 2026-06-17T11:58Z — final sweep crux outcomes (drone ✓, gitea advance ✗)
+
+Cold-read from cc-ci (raw canonical.json, my own check). 16 canonical recipes on disk: cryptpad,
+custom-html, custom-html-tiny, drone, ghost, gitea, hedgedoc, immich, lasuite-{docs,drive,meet}, mailu,
+matrix-synapse, n8n, plausible, uptime-kuma. 16 promoted + 4 documented reds (discourse, mattermost-lts,
+mumble, bluesky-pds) = 20 enrolled. Clean accounting.
+- **drone — PROMOTED CLEAN ✓ (favorable, DEFECT-2 closing evidence).** `/var/lib/ci-warm/drone/
+  canonical.json` = `{version 1.9.0+2.26.0, commit 91b27ceb…, status idle, ts 20260617T115046Z}` —
+  fresh, from THIS final post-fix sweep; log `sweep: drone rc=0 (PASS (promoted 1.9.0+2.26.0))`. The
+  fresh-seed-teardown residue fix (ca89d44) resolved the once-failed-promote secret residue. (At the
+  formal claim I'll re-derive that commit == the 1.9.0+2.26.0 tag's commit, and confirm warm reattach.)
+- **gitea — ADVANCE FAILED AGAIN ✗ (CLAIM-BLOCKER for M2.6 + M2.3).** Log: `sweep: gitea RUN — new
+  release 3.6.0+1.24.2-rootless > canonical 3.5.3+1.24.2-rootless … rc=0 (GREEN-BUT-PROMOTE-FAILED
+  (canonical=3.5.3…, expected 3.6.0…))`. canonical.json still `3.5.3+1.24.2-rootless` (ts 083930Z, OLD)
+  — known-good correctly PRESERVED on the failed advance, but the advance did NOT happen. Impact:
+  1. **M2.6 not demonstrated:** gitea was the live new-tag→`canonical(older)→new` advance proof. The
+     trigger fired (RUN on the newer tag) and old-known-good was kept, but a SUCCESSFUL promote to the
+     new tagged version — which §3/§5 M2.6 requires — did not occur. Needs a real fix or the plan's
+     alternative (construct custom-html older→new).
+  2. **M2.3 determinism dirtied:** on a 2nd sweep `sweep_decision(gitea, 3.6.0, 3.5.3) → RUN`, so gitea
+     re-runs — and it is NOT a genuine red (cold test is GREEN; only the warm advance promote times
+     out ~600s). So it is NOT covered by "reds correctly retry"; it is a green recipe whose promote
+     deterministically fails, which both wastes a CI rerun AND breaks "run-twice → skip-all". A plain
+     retry won't fix a deterministic timeout — needs the warm-advance timeout raised / the in-place
+     version-bump deploy diagnosed, OR gitea documented like the reds (but it's green, so that's weaker).
+  Sending the Builder a heads-up so they don't claim M2 with this open.