--- name: a-path-predicate-builder-census-is-intermittently-blind description: todlando 2026-09-08 — "procs-before: []" matched CommandLine *lane-path*; cargo.exe runs with a BLANK or toolchain-only command line, rustc usually carries the path, so the guard reads alone/busy by sampling instant; census cargo/rustc/clippy-driver BOX-WIDE and refuse on any metadata: type: feedback --- todlando measured it on his own build (2026-09-08 15:20Z): box-wide cargo/rustc/clippy-driver = 3, matching his lane-path predicate = 0 — one cargo had a completely BLANK CommandLine, another carried only the toolchain path. I had seen the same thing at 14:12Z ("two cargo.exe with empty command lines, parent 42896") and filed it as "not mine" rather than as a hole in the census. rustc usually carries the target path in its arguments and cargo does not, so a path-predicate guard fires or misses depending on which INSTANT it samples; it had a track record of catching a live rustc earlier the same day, which is what makes it worse than a dead guard. **Why:** "procs-before: []" from a path predicate means "no process matched a path", not "the pool was mine alone". On a shared box the honest question is whether ANY build is running (the golden runner, another lane), not whether one names my lane. **How to apply (todlando's three-field design, dry-run 2026-09-08 15:24Z):** refusing on ANY box-wide builder is correct and UNUSABLE on a shared CI box — it refuses for as long as the runner builds and gets commented out. Census three fields, one refusal: (1) `builders box-wide` (cargo|rustc|clippy-driver|rustdoc) INFORMATIONAL, printed and labelled NOT lane-scoped, so a slow leg is attributable to load and loaded wall times are declared non-comparable; (2) `holders in this pool` = processes whose EXECUTABLE PATH lives in this worktree (an exe path cannot be hidden the way a cargo command line can) — REFUSES; (3) `SPT_EXCLUSIVE_BOX=1`, an OPERATOR declaration that the box is yours, under which a live builder refuses. Read an empty-command-line cargo as a builder you cannot attribute, never as harmless; attribute by PARENT pid, not by command line. Re-read any earlier "alone" claim built on a path predicate as the weaker claim; its verdicts stand on exit files and Summary counts. Related: [[a-battery-launched-from-a-perch-inherits-the-endpoint-identity]], [[a-stopped-local-ssh-does-not-stop-its-remote-command]]. **hertz 2026-09-08 15:29Z, cleaning up after the recall:** an "is my driver still alive" census matching on CommandLine containing the script name reported 3 REMAINING after the kill, because the PowerShell process running the census carries that string in its own command line. A self-matching predicate can never report zero; the tell is a count that will not go to zero no matter what you kill. Query the pids you recorded EXPLICITLY, and exclude `$PID` from any command-line census. **Measured 2026-09-08 15:47:58Z (me, chain walked):** cargo 57412, born 15:35:57Z, ExecutablePath BLANK and CommandLine BLANK, chain rustup > pwsh > Runner.Worker.exe — the golden twohost-a job's OWN build, invisible to BOTH a command-line predicate and an exe-path predicate (WMI returns blanks for a process the querying user cannot open fully). Only the PARENT CHAIN attributes it. So the pool guard's exe-path key goes blind on exactly the runner process it most needs to see; the holders-in-pool field is a lane-side guard and the runner side must be read by chain-to-root, never by path. **Discriminator measured (hertz 2026-09-08 15:50Z):** 632 processes box-wide, 219 with blank ExecutablePath and the SAME 219 with blank CommandLine — one unreadable set; cargo 57412 GetOwner rv=2 (denied), SessionId 0; own processes readable, SessionId 1. WMI reports SESSION-0 SERVICE CONTEXT (where the Actions runner's builds live) as an empty string, not an error. His own holders guard (`ExecutablePath -like '**'`) returned EMPTY against a runner cargo in his pool and read it as 'no holders' — a false clean in a REFUSING guard, shipped with 15 green positive controls, because every control ran in his own security context: **a positive control that does not cross the boundary the guard faces cannot detect a cross-context blindness.** Fix is THREE-VALUED, not a stronger predicate (no predicate reads what the OS will not open): `holders(readable, REFUSING)` exits on non-empty; `holders(UNREADABLE, membership UNDETERMINED)` is reported as its own value and does not refuse (service-context builders are permanent on the runner box; a guard that always refuses gets deleted). Empty on the readable line means 'none I could read', never 'none'. Scope: NOT core — `crates/spt-store/build.rs` has no process census; POOL_GUARD arbitrates on the claim record and lane git identity, immune by construction. This bites AGENT-WRITTEN censuses only. **The kill side (hertz 2026-09-08 16:50Z, cause of my lane-2 gate's exit 127):** stopping his own matrix he traced the four bash pids by command line, then killed cargo / cargo-nextest / rustc BOX-WIDE BY NAME — no path, no command line, no worktree scoping — and took my gate's `Compiling spt-store` with them (exit 127, 427-byte raw, no error text = an outside kill). His own words: a kill is only ever as scoped as its filter, and "I am stopping MY driver" is a belief about intent, not a predicate about processes. Rule: EVERY kill names the tree — build processes by command line or cwd naming THIS worktree, spt.exe by ExecutablePath under it — and prints what it refused (mine / not-mine / unreadable-untouched), the same three-valued shape as the holders guard. An exit 127 with a short raw and no cargo error is what an outside kill leaves. **Stop-helper repairs (hertz 2026-09-08 16:54Z, found by his own three controls):** (1) scoping a kill by WORKTREE PATH IN THE COMMAND LINE kills the CALLING SHELL, whose command line carries that path as its cwd; (2) the right predicate is DESCENDANCY from a known root pid — cargo and rustc routinely report an EMPTY CommandLine, but their parent is always readable; (3) WMI returns UInt32 pids: a hashtable probed with Int32 misses every lookup and reports `descendants found: 0` as a success — a stopper that kills nothing and says it did. Controls that cross the boundary: WALK (0 -> 7 descendants from a real root), REFUSAL (the caller found among descendants -> exit 3, nothing killed), KILL (a parent+child tree outside own ancestry: found 2, killed 2, remaining 0, root dead).