FIELD-ADMISSION READINESS, read-only preflight. ONE HARD REFUSAL AND ONE UNMEASURED NUMBER; everything else is ready. No product invocation, no build, no firewall action, nothing elevated. 1. THE BOX GATE WOULD REFUSE RIGHT NOW. I ran the FROZEN helper itself rather than reasoning about it: RUNNER_CENSUS tag=preflight-readiness utc=2026-09-12T10:05:50Z procs=599 self_seen=True candidates=6 cargo_build=0 runner_descended=0 analyzer=4 shim_unresolved=2 runner_procs=0 listener_procs=1 RUNNER_WORKER=ABSENT valid=YES box_gate dies on any nonzero shim_unresolved, so that row is a REFUSAL. The two are rustup shims whose command line resolves to rust-analyzer: pid 39260 rustup.exe chain rustup.exe<-claude.exe(5988)<-claude-spt.exe(38632)<-spt.exe(4732) cmd [C:\Users\decid\.cargo\bin\rust-analyzer.exe] pid 43280 rustup.exe chain rustup.exe<-claude.exe(38220)<-claude-spt.exe(44512)<-spt.exe(4732) cmd [C:\Users\decid\.cargo\bin\rust-analyzer.exe] They are IDE language servers under OTHER live agent sessions, not builds and not runner work. The classification is your own fail-closed arm working exactly as specified: name is not rust-analyzer*, ancestry has no Runner.Worker, and the command line matches no producer verb, so it lands in shim_unresolved. NOTE THE DISTINCTION - the instrument is HEALTHY (valid=YES, exit 0); it is the GATE VERDICT that refuses. Two ways out and both are yours: those sessions' own owners stop their analyzers (I will not reap another agent's processes), or you rule on whether a rustup shim resolving to rust-analyzer classifies as analyzer rather than unresolved. I have changed nothing and proposed no edit to a frozen helper. 2. CAPACITY: MEASURED, PASSES, and the headroom is the number to watch. free=122.09 GiB used=1739.93 total=1862.02 on C:. Driver constants: FLOOR_GIB=96 producer-admission floor, HARD_STOP_GIB=32. So it passes both, with 26.09 GiB of headroom above the FLOOR. 16 logical CPUs; RAM 63.1 GiB total, 29.2 GiB free; processor queue length sampled at 2 (one sample, not a load profile). THE RISK, stated with its number: the release build is COLD (see 3) and its footprint is UNMEASURED. If it consumes more than 26.09 GiB the capacity gate fails MID-RUN, at the next gate rather than at admission. For scale, the lane's existing debug tree is 8.7 GiB - which is evidence about debug, not release. 3. RELEASE-BUILD ESTIMATE: I can bound the CI workflow, NOT a local build, and I am not going to convert one into the other. The driver's EXE is .worktrees/304-w2-repr/target/release/spt.exe. It DOES NOT EXIST. target/ is a real directory (not a junction), 8.7 GiB, and contains NO release/ subdir at all - so this is a COLD release build; the debug artifacts do not help it. Available evidence, release.yml wall clocks: 13m51s (v0.69.0, 2026-09-11), 15m49s (v0.67.0, 2026-08-30), 14m06s (2026-08-29), plus one 46m49s outlier on a CI-budget change. Recent ci.yml runs sit at 11-19 minutes. Those are WORKFLOW wall clocks on a runner, not a local debug-rollout --build-current on this box, and I have no measured local release build to offer. A local number needs one measured build, which is not authorized. I would rather hand you a labelled gap than a converted guess. Pool state is clean for this: target/POOL-OWNER.json names owner_tree = the lane's own worktree (written_by spt-poolguard), so the build would run in the tree that owns the pool - no foreign-pool refusal expected. One discrepancy worth knowing: that record carries ONLY owner_tree and written_by - no branch, no base sha, no holder - which is not the richer claim shape AGENTS.md describes. I am reporting the bytes I read, not the documented shape. The lane branch test/304-w2-observed-spelling-cells at 53d625cd is NOT merged into main, so the lane reads as unlanded work, which is correct for a live lane. 4. TWO-AXIS RUNNER AVAILABILITY, measured on the helper's own two axes: Runner.Listener.exe PRESENT (listener_procs=1) so the runner is registered and online; Runner.Worker.exe ABSENT (runner_procs=0, RUNNER_WORKER=ABSENT) so it is executing no job. Both axes are FREE. Caveat from my own record: the ff-push that concludes a golden re-occupies this box for minutes afterwards via the post-merge run, so "free now" is a sample and not a reservation. The box is also shared - 17 spt processes and 2 daemons are live, including the sessions owning the two analyzers in item 1. 5. THE EXACT FROZEN SET, re-measured just now, not quoted from memory: fp-driver-v9.sh a9510e1ec86a71266b7f421b90a6a02c5c0f7586f96803c6843133b5b2b0bb12 fp-bin/census.ps1 7a50b14e2ea0bf93a310ca14c0ba4f06faf82f6905a9bc764c692b0f913d413b fp-bin/cpubracket.ps1 fc10031d25eb551daa88ba84b1cb13da4b90baa45ddc5dde3986fbd1abe90e73 fp-bin/portfields.ps1 283386e7e1cac9df5e8e3c7e8283faea224ad3d12f4da30185a9b342b9a1da85 fp-bin/runner-census.ps1 0d8b67edf980f852aa120fa3a88c51b00916566611753aba3bb843da608984f9 fp-bin/d1_render.py 3b9844932696286b83342b831a90407e4505cf1a16665bc936c71f2d99cca596 All six unchanged since the v9 pin. Path: the 291081e5 session scratchpad (fp-driver-v9.sh at its root, helpers in fp-bin/). 6. ELEVATED SETUP AND CLEANUP: ASKED, NOT ANSWERED YET. liam is the only route this driver has for the elevated reconcile and the elevated teardown, and both are otherwise blocking. I have asked liam for an availability picture only - can they take an elevated handoff in the next window, what turnaround between request and receipt, when are they definitely unavailable, and whether any condition on their side would make the handoff refuse. I explicitly told them nothing is granted and asked them to run nothing. Their answer is outstanding and I will relay it verbatim. Why I pushed on this rather than just noting it: the cleanup wait is bounded at 300s and a timeout there leaves bootstrap-owned firewall rules POSSIBLY IN PLACE with the state marker deliberately left set. An unavailable liam does not merely stall the run, it makes the expensive outcome reachable. SUMMARY: admission blocked on item 1 (a gate verdict, yours to rule or another agent's to clear), exposed on item 2 by an unmeasured cold-build footprint against 26.09 GiB of headroom, waiting on item 6. Capacity, runner axes and the frozen set are ready. #300 continues independently: perri's assessment preserved VERBATIM with its provenance at .spt/preserved/todlando-300-adapter-assessments/perri-claude-spt-2026-09-12.txt, sha256 233056d84541c0b545d2813366bf76915b89df2609bc0a46f0d477a1facf19d7, labels intact as perri's own. Your reframe is taken: authorship of the characters is not the question, the submitter expresses the request, so pasted and recalled text is not a defect - which retires perri's co-authorship objection as a blocker rather than answering it. I have NOT adopted the previous-commit interval as proof, have not implemented anything, and have not asked perri to run the operator-assisted measurements. enqueue-versus-dequeue stays explicitly UNRESOLVED. emphasys is still offline and outstanding. No contract expansion: the draft is untouched at 24069979, unpushed.