deployah -> doyle: SEVEN-CRITERIA READOUT, run 34310511612 attempt 1, headSha f6110c2a12df0dd50b87dfb60a2ec4120b5cf98d (re-read from the API, matches). VERDICT: RED. Not shippable. Triage is yours; below is measurement plus ONE falsifiable hypothesis, flagged as such. Nothing rerun, nothing tagged, counter 104 still unconsumed. FIRST, A DEFECT IN MY OWN READER — disclosed before its output. accept-r3.sh used the `jq` binary, which is NOT installed on this box. Every jq-backed criterion printed `FAIL` when the true state was VOID: it reported "FAIL job count < 9" and "FAIL no Windows Docs drift STEP found at all" purely because jq was absent. Both were wrong. This is the extractor-exit-code trap in my own instrument, one arc after I banked it. I re-read everything below with gh's BUILT-IN -q (no jq binary) and the raw jobs endpoint. Treat the first accept-r3.sh output as void, not as evidence. JOB SET: NINE jobs, all materialized (twohost legs and notify included), EXACTLY ONE red. success changes · success traceability · success n1-gate Linux · success n1-gate Windows success test Linux · success twohost-a · success twohost-b · success notify FAILURE test (self-hosted, Windows, hfenduleam) C1 FLOOR_DOCS PASS -> NOT MET, and not for a docs reason. The only FLOOR_DOCS in the whole run is the LINUX one: `FLOOR_DOCS job=test runner=Linux free_bytes=146577657856 floor_bytes=34359738368 verdict=PASS`. The Windows "DISK docs floor (Windows)" step never ran (SKIPPED) because the Windows job died at step 21 and everything after it skipped. By the same rule you set for the drift gate, a green Linux floor is not Windows evidence. Recorded as NOT MET, not as PASS. C2 Windows "Docs drift gate" STEP -> NOT MET. Step 38 "Docs drift gate (CLI ref + llms links) — windows" conclusion = SKIPPED. That is its SIXTH consecutive skip, and a skip is not a pass. It is downstream of the step-21 failure, so this criterion CANNOT be assessed on this run at all — even a clean rerun of everything else would have to re-earn it. C3 FLOOR_END PASS -> MET, on every job including both Windows ones: test Windows free_bytes=87339024384 (81.3 GiB) verdict=PASS · n1-gate Windows 148463468544 PASS test Linux 143042285568 PASS · n1-gate Linux 222092566528 PASS · twohost-a 141980196864 PASS twohost-b 216761896960 PASS · changes 226339926016 PASS · traceability 226313785344 PASS C4 "Summary lines == 2" -> MEASURED 4, and I am calling the CRITERION mis-specified rather than claiming a pass or a red. The four are 2 legs x 2 PHASES: Win Phase A Summary [ 641.931s] 3346 run: 3346 passed (4 slow, 4 leaky), 1 skipped Win Phase B Summary [1164.007s] 234 run: 233 passed (1 slow), 1 FAILED, 0 skipped Lin Phase A Summary [ 41.701s] 3325 run: 3325 passed (2 leaky), 1 skipped Lin Phase B Summary [1152.093s] 219 run: 219 passed (1 slow), 0 skipped This is NOT the doubled-run signature (which is what "==2" was written to catch): each leg has exactly ONE Phase A and ONE Phase B summary, and the FAIL attribution is therefore sound. The invariant that actually holds under the A/B split is 2 per leg / 4 total. Your call whether to amend the criterion; I did not amend it myself. C5 role_a green on A -> MET. twohost-a job success; two_host_web_helper_role_a ... ok, plus deny/fetch/range role_a ok, two_host_ladder_role_a ok, gated_cli_role_a ok. C6 role_b green on B FROM B'S OWN SERVED COUNT -> MET, and read the way you specified — B's own emission, never A's poll. From the twohost-b job: TWOHOST OK: role B serving open.md + locked.md (waiting for 5 served cells) TWOHOST-WEB role B: served cell 1/5 ... 2/5 ... 3/5 ... 4/5 ... 5/5 TWOHOST OK: role B served all 5 requester cells test two_host_web_role_b ... ok (test result: ok. 5 passed; 0 failed) C7 run terminal, EVERY job green, expect NINE -> terminal YES (completed/failure), NINE YES, every-job-green NO (1 of 9). So C7 fails on the green clause alone. THE RED, at source. Windows Phase B, test 69/234: FAIL [ 71.881s] spt::resident_service_e2e a_declared_service_rises_with_the_daemon_and_reaches_the_cli panicked at crates/spt/tests/resident_service_e2e.rs:670:5 "teardown LEAKED — these processes outlived the test that started them, and no per-pid check could name them: [(25596, ...\.tmpAHRrrZ\srcs\svcboot\svcmock.exe)]" "settle: went_clean=false after 60.6070532s of a 60s budget" CRITICAL SHAPE: the test's FUNCTIONAL assertions ALL PASSED. Its own instrumentation line reads daemon_up=true boot_alive=true boot_pid=Some(53100) rel_started=true rel_pid=Some(25012) broker_survived=true rel_online=true dir_online=true survived_teardown=true spooled=[(1,"cli@HFENDULEAM","a supervised service reporting in")] The feature under test worked. The failure is entirely in TEARDOWN HYGIENE. MY HYPOTHESIS — falsifiable, NOT a ruling, yours to accept or kill: the rig reaps the SUPERVISED CHILDREN BEFORE THE SUPERVISOR. Reap order in the log is boot(53100, srcs\svcboot\svcmock.exe) -> rel(25012, srcs\relshell\svcmock.exe) -> brain(42716) LAST, all three verdict=KILLED cleanly. The survivor 25596 is THE SAME IMAGE as the already-killed 53100 (srcs\svcboot\svcmock.exe). A resident-service supervisor doing its job would restart the service it saw die, minting 25596 in the window between the boot kill and the brain kill. If that is the mechanism it is a RIG TEARDOWN-ORDERING RACE and the product behaviour is CORRECT supervision — which would make this neither a #272 defect nor a product regression. HOW TO KILL THE HYPOTHESIS: the rig records started_at for every pid it reaps but NOT for the survivor. Capture the survivor's start time; if it is AFTER the boot kill, the respawn is proven and the fix is ordering (kill the supervisor first, or stop supervision before reaping children). If it is BEFORE, my hypothesis is dead and it is a genuine unreaped child. ONE COUNTER-INDICATION I OWE YOU, against my own hypothesis: the settle went the FULL 60.607s of a 60s budget. The rig's own message says a wait far SHORTER than the budget with survivors listed means they appeared after a clean sweep — a different defect. Going the full budget means it NEVER read clean, which fits "alive the whole time" at least as well as "respawned early". I have not separated those two. #272'S OWN PRODUCT IS GREEN ON WINDOWS — the red is outside the milestone's surface: PASS [ 16.022s] (77/234) spt::webserve_attachment_e2e an_attachment_is_snapshot_served_fetched_back_and_named_by_its_message ^ THE EXACT CELL RIDER 5 FIXED. The structural fix held on the box that was 26.7% flaky. PASS [ 26.317s] (78/234) spt::webserve_cross_node_e2e a_peers_url_is_served_by_its_owner_through_the_local_listener plus both twohost web legs green with B's own served count (C5/C6 above). ONE LINE FLAGGED AS A QUESTION, NOT A FINDING: inside the failing test's stderr, during its "add (no daemon)" phase: ADAPTER_WEB_PENDING: serving registry reconciliation failed: The system cannot find the file specified. (os error 2); retry at the next daemon start It is the only webserve-shaped line anywhere in the red test, and it sits in a no-daemon phase where a pending state looks expected by design. I do NOT claim it is a defect and I have not chased it — raising it only because it is webserve vocabulary inside the one red test in a WEBSERVE milestone, and you should decide rather than discover it later. PRESERVED, in .spt/preserved/golden-272-r3-drive/ (manifest rebuilt + re-verified from the repo root): r3-run-34310511612.log full run log, 12,076,773 bytes r3-jobs-34310511612.json raw jobs endpoint, paginated r3-watch.log 67 status samples, 04:22:04Z queued -> 05:29:57Z completed/failure accept-r3.sh the reader, jq defect and all — preserved as-run, not silently fixed msg-doyle-28.txt this readout STANDING BY. Not rerunning; the same-sha rerun decision is yours. hertz + todlando still off cargo as far as I am concerned — say the word and I will tell them the box is free, since my watch is done.