diff --git a/REVIEW-conc.md b/REVIEW-conc.md
index 423c097..623c45d 100644
--- a/REVIEW-conc.md
+++ b/REVIEW-conc.md
@@ -332,3 +332,28 @@ leakage, and (4) (a)/(b)/(d) re-confirmed on the fixed harness, still require th
 evidence (in flight). The code fix strongly predicts a (c) pass but M2 is a LIVE gate — I will
 re-verify the (c) double-!testme cold from the Drone API once the Builder posts the M2 claim, and
 only then clear the veto.
+
+## 2026-06-10T08:43Z — live (c) round-2 (builds 290+291): serialization CONFIRMED via lslocks; delay is an immich-ML flake, NOT the restructure (not a verdict)
+
+(b)+(d) re-passed on the fixed harness (builds 287 immich#2 + 288 plausible#3, parallel, both
+success — I'll re-confirm at the M2 claim). (c) round 2 = builds 290+291 (both custom PR=2 immich,
+same domain immi-ad3e33), started 08:22:30Z. I inspected the LIVE host state cold (my own ssh):
+
+- **CORE INVARIANT DIRECTLY OBSERVED in the kernel lock table** — strongest possible proof of the
+  double-!testme serialization:
+  `lslocks`: pid 739163 (build 290) holds `WRITE` on cc-ci-app-immi-ad3e33….lock; pid 739341
+  (build 291) is blocked `WRITE*` on the SAME lock. Exactly one holder, one waiter, one inode.
+- 290 (holder) is sleeping in `services_converged()` poll (hrtimer_nanosleep, no abra child) because
+  `immich-machine-learning` is stuck 0/1: its container repeatedly fails the healthcheck
+  (`non-zero exit (143): dockerexec: unhealthy container`, swarm restarting every 1–6 min). Current
+  attempt (08:43) has gunicorn up, health `starting` — slow/flaky ML readiness, not a deploy break.
+- NOT caused by the restructure / teardown: 290's immich volumes (model-cache/postgres/uploads) +
+  .env are all from 290's OWN fresh deploy (08:23), not inherited from the earlier same-domain run
+  287. ML image present (1.36GB, no pull), host healthy (5.2Gi mem free, 65G disk). So this is an
+  immich-ML healthcheck flake, orthogonal to concurrency.
+
+Bearing on M2(c): the SERIALIZATION mechanism under test is verified working live. The "both GREEN"
+half of condition (3) is not yet demonstrated only because 290 is flake-blocked on immich-ML; if 290
+REDs on deploy-timeout, (c) needs a clean re-run (flake, not a code fault). VETO unchanged — I still
+require one clean (c) where both same-domain builds go GREEN with the block line + zero leakage.
+Continuing to watch 290/291 to terminal.
diff --git a/machine-docs/BUILDER-INBOX.md b/machine-docs/BUILDER-INBOX.md
new file mode 100644
index 0000000..cd22057
--- /dev/null
+++ b/machine-docs/BUILDER-INBOX.md
@@ -0,0 +1,22 @@
+# Adversary → Builder — 2026-06-10 ~08:44Z
+
+Heads-up on (c) round-2 (builds 290+291), NOT a gate verdict — context so you don't misdiagnose:
+
+- **Serialization is working** — I confirmed it directly in the kernel lock table while both runs
+  are live: `lslocks` shows pid 739163 (build 290) holding WRITE on the immi-ad3e33 app lock and
+  pid 739341 (build 291) blocked WRITE* on the SAME lock. One holder, one waiter. The (c) mechanism
+  is good.
+- **The delay is an immich-machine-learning healthcheck flake, NOT concurrency.** 290 (the holder)
+  is parked in services_converged() because the ML service is stuck 0/1 — its container repeatedly
+  fails the healthcheck (`non-zero exit (143): dockerexec: unhealthy container`, swarm restarting
+  every 1–6 min). ML image is present (1.36GB), host is healthy (5.2Gi mem free, 65G disk), and
+  290's volumes/.env are from its OWN fresh deploy (08:23), not inherited from 287 — so it's not a
+  teardown/state-leak issue. immich-ML is just slow/flaky to pass its healthcheck.
+- Likely outcome: 290 REDs on the deploy timeout (immich-ML never converges), tears down, releases
+  the lock, 291 then runs (and may hit the same ML flake). If so, **(c) needs a clean re-run** once
+  immich deploys healthily — this is environmental, not a code fault in the restructure.
+
+My VETO stays until one clean (c) shows BOTH same-domain builds GREEN + the block line + zero
+leakage. CONC-A1 code fix itself is already cold-verified + mutation-proven on my side (see
+REVIEW-conc) — only the live (c) both-green remains. No action needed from you on the code; just
+re-trigger (c) when the ML flake clears.