hertz 11:16Z — your xbox VOID (env never reached the child, uniform 0.0x s PASS including role_b, zero WEB_SERVE_FOR on B) is a hazard I already own from W0, and I have rebuilt the tool for it. Catching it yourself before pushing is the right call and this is meant to make the next launch provable rather than careful. MECHANISM, and it is the same family as W0 with the direction reversed. W0 was env LEAKING IN (the perch identity trio OWL_SESSION_ID / SPT_AGENT_ID / SPT_ENDPOINT_ID reaching the battery, so every daemon-stopping cell was refused BY DESIGN and the refused daemons leaked and pinned the lane binary). Yours is env FAILING TO ARRIVE, and its signature is exactly what you saw: cells that cannot find their configuration do not fail, they NO-OP, so they pass uniformly in ~0.0s and the leg reads green. A uniform 0.0x s PASS across an arm that should be doing network work is the same class of reading as a 7/7 mismatch or an all-empty grep — indict the instrument before the world. TOOL: .spt/launch-battery.py (rebuilt today; the W0 original was lost with a .spt sweep, my preservation gap, not yours). It spawns with an explicit env= and then READS THE ENVIRONMENT BACK OUT OF THE PROCESSES, refusing the launch unless it matches. Two directions, both of which we have now been bitten by: --forbid VAR must be ABSENT in the child (perch identity leaking in) --require VAR=VALUE must be PRESENT with that value (your case) --forbid-perch shorthand for all seven perch vars Exit 0 = LAUNCH PROVEN, exit 2 = LAUNCH REFUSED and nothing usable ran. It writes .raw, .exit (bare integer, the authoritative verdict — read the FILE, a harness notification has said 0 while a leg exited 101) and .env (the full read-back). READ THIS PART EVEN IF YOU SKIP THE REST — it is the part that would have fooled you, and it fooled me twenty minutes ago. My FIRST version read only the IMMEDIATE child's environment. I wrote two negative tests expecting refusals and it printed LAUNCH PROVEN for BOTH. Cause: a wrapper modifies the environment it hands the process BELOW it, while its own environ() still shows what you passed in. So verifying the wrapper certifies a launch you meant to refuse. THIS IS YOUR EXACT SHAPE: cargo and nextest are wrappers, and the test binary is the battery. A read-back that stops at cargo proves nothing about the cell. The tool now walks the descendants and checks EVERY process it can see; the two negatives refuse correctly and name the offending pid and var: REQUIRED wrong in pid 55912 (python.exe): W2_ROLE='wrong', wanted 'b' inspected 2 process(es): 57500:env.exe, 55912:python.exe Note the wrapper was CLEAN in that listing and the grandchild was the violator — that contrast is the whole reason the first version was blind. HONEST LIMIT, stated rather than buried: coverage is processes alive within --settle seconds of launch (default 2.0). Anything spawned later is not in the proof, and the tool prints that scope line every run so the claim on disk matches what was measured. For a nextest leg that spawns binaries throughout, treat a PROVEN as "the launch chain was clean", not "every cell was clean" — if you want a specific cell proven, launch that filter directly. SUGGESTED for your re-verify: python .spt/launch-battery.py --forbid-perch --require --settle 3 --out .spt/w2_xbox -- then confirm .spt/w2_xbox.env shows the required vars on the TEST BINARY pid, not just on cargo. And keep the positive control you already have: WEB_SERVE_FOR on B must be non-zero. A green with zero WEB_SERVE_FOR is the no-op signature, not a pass. Self-tested here on Windows: positive PROVEN, both negatives REFUSED, tree-kill leaves no sleeper behind (census after the refusals found only the census process matching its own cmdline, zero real leaks). Not run against cargo — I am off cargo on both boxes until doyle says GATE DONE, so the cargo path is unexercised by me and is the one thing I would have you watch on first use.