WARM-LANE READINESS RECEIPT, 85f84d73. No checkout changed, no pool claimed, no cargo launched. All figures below are read-only measurements taken just now on HFENDULEAM. HEADLINE: THE WARM LANE DOES NOT EXIST -- the warmest pool on the box is the one holding the attested executable, and every other pool refuses this lane by identity. What is ready is a COLD lane.

1. TARGET OWNERSHIP. Owning worktree is .worktrees/repr-fix-53d625cd, HEAD 85f84d73, branch test/304-w2-enforcement-codes, working tree CLEAN. 96080953 verified as an ancestor of 85f84d73, one commit ahead. THAT WORKTREE HAS NO target DIRECTORY: it owns no pool, so a build there creates a fresh cold one. CARGO_TARGET_DIR is unset in my environment.

2. FREEZE HELD, verified rather than trusted. All seven diff hunks between 96080953 and 85f84d73 fall at line 1083 or later, and mod tests opens at line 991 -- so the whole 91-insert/14-delete change is test-side. Proof rather than inference: sha256 of lines 1..990 of windows.rs is 1dd5a6a60cc1d5c5 at BOTH commits, byte-identical. Production is untouched by hertz's commit.

3. ATTESTED EXECUTABLE -- LOCATED, HASHED, AND IT IS THE PROBLEM. It is .worktrees/304-w2-repr/target/release/spt.exe, sha256 prefix edd3d8e0, confirmed by hashing it just now. That same pool is THE WARMEST ON THE BOX: newest artifact 1.0h old, versus 33-41h for every other pool. So the pool that would give a genuine warm build is exactly the pool whose release/spt.exe a build would overwrite, destroying the attestation. I rule it out rather than propose guarding it -- a build into that pool cannot be made safe by care.

4. WHY NO OTHER POOL IS WARM FOR THIS LANE. Seven pools carry POOL-OWNER.json. Four name a lane, and every named lane branch is UNLANDED against main: test/304-premise-lines +1, test/304-remote-friction +47, test/304-w2-enforcement-codes +64, test/304-w2-observed-spelling-cells +61. Unlanded work refuses takeover. All five holder pids (37824, 35760, 14288, 35516, 40248) are DEAD, and I am NOT treating that as authorization -- a dead holder is advisory, a cleared session is not a finished lane. Two pools (main's own target, and 304-w2-repr's) carry only owner_tree and written_by with NO lane identity. Per IR-42 I do not predict enforcement from claim records: those arms live in the build and speak at the next build, not in pool-claim. So the prediction I will stand behind is only this -- no pool is available to this lane by rule, and the expected shape is a fresh cold pool in the owning worktree.

5. CAPACITY. C: 121GB free of 1.9TB, against the 32GB golden floor. Measured pool sizes: 304-product 18.8GB, 304-w2-repr 10.1GB, 304-w2-bootstrap-tcp 10.0GB, asm-304 8.3GB, main 4.2GB (two smaller pools still measuring). A fresh pool of the ~10GB class lands free space near 111GB, roughly 79GB above the floor. Capacity is not the constraint.

6. AVAILABILITY, BOTH AXES.
   Axis 1, CI runner: Runner.Listener alive at pid 22712; NO Runner.Worker process. The runner is online and NOT executing a job. Caveat I will not drop: a merge-push re-occupies this box's runner automatically, so this axis can change without anyone scheduling it.
   Axis 2, local build contention: ZERO cargo, rustc or linker processes on the box. No build is in flight anywhere. The box is populated but not building -- 22 spt, 14 claude-spt, 8 claude, 3 omp-spt, 38 node; CPU 47%, 24.6GB free RAM of 63.1GB.

7. ESTIMATE -- AND I CANNOT GROUND IT. You asked for an estimate from prior warm-build evidence. I do not hold a measured LOCAL build duration for this workspace, and I found none I would cite in docs. The nearest evidence is runner-side: the last 8 CI runs on spt-bs-core ran 11.0 to 19.1 minutes wall, all success. That is a whole-CI leg on a warm runner pool over docs-weight commits, so converting it into a local cold cargo build+test figure for this lane would be exactly the scope-widening I keep getting corrected for. The honest sources for a real number are a prior local record I do not have, or the build itself.

WHAT ADMISSION WOULD ACTUALLY BUY: a cold pool created in .worktrees/repr-fix-53d625cd, claimed from that worktree so the identity it writes is the lane's, at a cost I can bound in disk (~10GB) but not in time. Hertz's other ask -- the extraction-boundary read-only powershell -- is seconds and contends with nothing; they reported it to you directly as unrun.

Standing: no window sought or held, nothing claimed, nothing built.