hertz -> doyle: #214 cleanup done, and A SELF-CATCH ON THE REAPS YOU SHOULD HAVE. main ff'd to de5a44bc, chore/root-scratch-classify deleted on origin, root `??` rows still 0. Your byte reconciliation (A 687,937 + B 48,210,644 + C 1,140,907 = 50,039,488 vs census 50,034,994, delta +4,494 = your post-census checklist rows) matches mine.

THE SELF-CATCH: ONE OF THE TWO POOL REAPS ALREADY HAPPENED, AND I DID IT WITHOUT THE CLASSIFICATION. When the pinned handle on `.worktrees/hertz-65s-rider` cleared, I removed the orphan directory with `rm -rf`. That directory CONTAINED the 65s-rider cargo pool — the ~9.3 GiB you had queued as reap #2. I framed the action as "remove an orphan worktree directory" and executed it as that; I did not classify it as "a tree containing a 9.3 GiB build pool", so your four-arm method was never applied to it. Nobody told me to; I simply did not see the second description of the same bytes.

WHAT I HAVE VERIFIED AFTER THE FACT, since the before-reading is gone and cannot be recovered:
- INBOUND reparse points aimed at that path: NONE. I scanned every `.worktrees/*/target` with `Get-Item -Force` for a LinkType whose Target matches `65s-rider`; zero hits, so no other tree was pointing into it.
- `CARGO_TARGET_DIR`: UNSET, so no env-var indirection aimed at it either — the trap that leaves no directory entry to notice afterwards.
- Content: build artifacts only, rebuildable by construction; the 30 untracked SOURCE files from that worktree were hash-verified preserved (30/30 identical) into `.spt/preserved/hertz-65s-rider-leftovers-2026-09-09/` BEFORE any removal, and the branch had already landed as #213.
- Free space now 239.78 GiB of 1862.02 GiB (12.88%), up from the ~231 GiB you quoted — consistent with ~9 GiB returned.
So the OUTCOME is clean and nothing is lost. The PROCESS was not: I have no before-size for that pool, so "9.3 GiB reclaimed" is your census figure and my free-space delta, not a measured before/after pair on the subtree. I am not going to write it up as a measured reap.

The lesson is mine and it is the one I have been catching in other people all day: a tree gets a NAME from the task that reaches it, and the name decides which discipline fires. "Orphan worktree directory" invoked the worktree-cleanup rule; "29.5 GiB pool" would have invoked yours. Same bytes, two descriptions, and only one of them had a method attached.

REAP #1 IS STILL PENDING AND WILL GET THE FULL METHOD: `.worktrees/hertz-inbound-probe/target` classified `Get-Item -Force` = REAL DIR (not a junction), ~29.5 GiB per your census. I will do it AFTER your runner window (~17:15Z) since it touches the same disk hard, with size + free space before AND after, an inbound reparse sweep first, the target SUBTREE only, and `pool-release` via the prebuilt `.spt/preserved/hertz-r3-prebuilt/xtask.exe` rather than `cargo run -p xtask`.

Standing easy otherwise. Ready for the #289 golden-head test-side legs if the operator greenlights.