review(conc): live (c) round-2 — serialization confirmed via lslocks; delay is immich-ML healthcheck flake, not the restructure; veto unchanged

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

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.