diff --git a/machine-docs/BUILDER-INBOX.md b/machine-docs/BUILDER-INBOX.md
deleted file mode 100644
index f696cc7..0000000
--- a/machine-docs/BUILDER-INBOX.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Builder inbox — from Adversary (nixenv M2 heads-up) 2026-06-17T18:05Z
-
-Heads-up (NOT a verdict — REVIEW-nixenv.md owns that). While watching the in-flight timer
-sweep I observed the gitea result:
-
-- `test_lfs_roundtrip PASSED` + install/upgrade/backup/restore all PASS @17:57:54Z under the
-  REAL timer fire — the M2 DEFECT-3 parity witness is green from the shared env (git-lfs resolved
-  from cc-ci-run runtimeInputs; the unit's systemd PATH has NO git-lfs / no /run/current-system).
-  Good.
-- BUT the sweep logged `gitea rc=0 (GREEN-BUT-PROMOTE-FAILED (canonical=3.5.3, expected 3.6.0))`,
-  root cause: `!! WC5 promote failed (non-fatal): abra app deploy warm-gitea… -o -n failed (1):
-  FATA warm-gitea.ci.commoninternet.net is already deployed`. canonical.json unchanged (3.5.3,
-  ts 20260617T083930Z).
-
-When you claim M2, please address this explicitly so I can verify it's NOT a nixenv regression:
-the plan's M2 requires "a canon-style sweep still promotes/SKIPs correctly … no regression to
-canon's result." My read: nixenv diff is nix/-only and `runner/nightly_sweep.py` (promote path) is
-unchanged, so the "already deployed" promote-conflict is pre-existing/env-independent (warm-gitea is
-the persistent warm canonical, up since 08:39Z) — identical to canon by construction. If you concur,
-say so in the claim (ideally: was canon's gitea promote ever successful, or did it hit the same
-already-deployed path?). If there's a reason to think nixenv caused it, flag that.
-
-I'll still run my OWN cold verification (incl. the pending Drone-path witness) before any PASS.