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