diff --git a/machine-docs/ADVERSARY-INBOX.md b/machine-docs/ADVERSARY-INBOX.md
deleted file mode 100644
index 95a6bb9..0000000
--- a/machine-docs/ADVERSARY-INBOX.md
+++ /dev/null
@@ -1,29 +0,0 @@
-# Builder → Adversary (2026-06-18T06:11Z) — M2 verify heads-up (non-gate)
-
-Two things that affect your in-progress M2 verification (your 06:08Z entry shows `/tmp/adv-m2` @
-**b96b8a4** — that's STALE; please re-fetch):
-
-1. **Harness branch `redfix-m2-harness` was reset to `07fc6d4` at 05:53Z (BEFORE the claim).** The
-   bluesky `exec-into-pds` commit **b96b8a4 was DROPPED** — origin tip is now `07fc6d4` = mumble
-   `07fc6d4` + keycloak `61211db` ONLY. Your `/tmp/adv-m2` is at b96b8a4 (cloned just before my
-   force-push). Re-fetch / reset it to origin/redfix-m2-harness `07fc6d4`, else its stale
-   `service="pds"` exec-refs will spuriously fail bluesky's cold custom tier.
-
-2. **bluesky fix CHANGED per operator directive (2026-06-18): NOT the rename.** It is now
-   recipe-PR-ONLY: caddy resolves `${STACK_NAME}_app` via `{$APP_HOST}` (compose env on the caddy
-   service), service stays named `app`, so **NO cc-ci harness change** (that's why b96b8a4 was
-   dropped). PR #4 `ci/warm-routing-alias` @**4987ba9** (force-replaced the rename).
-
-**Verification approach for the two recipe-PR fixes whose failure is warm-promote-only (gitea PR #2,
-bluesky PR #4): use the DIRECT chaos-deploy procedure in STATUS-redfix.md "HOW" — NOT a full harness
-cold run + WC5 promote.** Reason (documented in STATUS NOTE + JOURNAL): the WC5 promote does
-recipe_checkout(published-tag)+non-chaos deploy, and BOTH `run_recipe_ci.py:373` AND abra force-fetch
-`refs/tags/*` from upstream, so a local tag-move to the fix is reverted to the PUBLISHED commit (which
-pre-merge lacks the fix). I confirmed this empirically — a full gitea harness run's WC5 promote
-deployed `357926f` and crash-looped exactly like M1. Chaos deploys the working-tree checkout (= the PR
-fix), so the direct chaos-deploy reproduces the EXACT M1 failing scenario and proves the fix; the
-canonical-registry advance follows once the operator merges (the phase's "nothing merged" constraint).
-Evidence logs on cc-ci: `/tmp/redfix-gitea-m2-directproof.log`, `/tmp/redfix-bluesky-m2-directproof.log`.
-
-(mattermost-lts PR #1 / discourse PR #4 are COLD-tier fixes — verifiable by !testme on the PR head as
-usual: runs #901 / #849.)
diff --git a/machine-docs/REVIEW-redfix.md b/machine-docs/REVIEW-redfix.md
index af585b7..5c1062f 100644
--- a/machine-docs/REVIEW-redfix.md
+++ b/machine-docs/REVIEW-redfix.md
@@ -182,3 +182,21 @@ test-disabling.
   before/during/after. The data-warm canonical (warm-canon-keycloak) and live-warm provider
   (warm-keycloak) are fully separate deployments that never touched. Builder's keycloak fix CORRECT +
   non-weakening; the §2.B de-enrollment is now structurally resolved. (1/6)
+
+- 2026-06-18T06:15Z — **mumble component VERIFIED (2/6)** by my OWN cold harness run
+  (`/tmp/adv-mumble-m2.log`, RECIPE=mumble from /tmp/adv-m2, recipe tag 1.0.0+v1.6.870-0). RUN SUMMARY:
+  deploy-count=1, **all 5 cold tiers pass**. The stabilized custom test
+  `test_handshake_completes_with_channel_presence` **PASSED** (junit failures=0, time=10.3s). The
+  handshake completing in ~10s confirms M1's **load/timing-FLAKE** classification (fast in isolation,
+  nowhere near even the OLD 60s budget) and that the fix — widening 12->36 attempts (60s->180s) — is
+  pure headroom: the asserts are UNCHANGED, so a genuinely dead server still exhausts all 36 retries
+  and FAILs. **Non-weakening.** WC5 promote: `/var/lib/ci-warm/mumble/canonical.json` version
+  1.0.0+v1.6.870-0, idle, ts 20260618T061114Z (THIS run). Builder's mumble fix CORRECT. (2/6)
+
+  NOTE on branch state: I cloned /tmp/adv-m2 at tip `b96b8a4` just before the Builder force-reset
+  `redfix-m2-harness` to `07fc6d4` (dropping a bluesky exec-into-pds commit). Confirmed
+  `git diff 07fc6d4 b96b8a4` = ONLY `tests/bluesky-pds/_p4.py` + `test_account_and_post.py` (2 lines,
+  bluesky-only) → keycloak (61211db) and mumble (07fc6d4) code are BYTE-IDENTICAL between b96b8a4 and
+  the claimed tip 07fc6d4, so my keycloak+mumble PASSES hold at the claimed state. bluesky is verified
+  separately via recipe chaos-deploy (PR #4 @4987ba9, now recipe-PR-only per operator directive), so
+  the harness-checkout staleness does not touch it.