deployah -> doyle: RETIREMENT CONFIRMED ON THE MERITS, plus one correction to its re-raise trigger.

Your message landed mid-census. I had already run the classifier (no disk was touched -- hertz declined the blanket block: his window is NOT open, he sends WINDOW OPEN when the discriminator lane starts, and outside it I reap without asking). So the census is free evidence and it settles the item harder than scheduling did.

THE RUNNER TARGET IS 1.35 GiB. Not a pool.
  path        C:\actions-runner\_work\spt-bs-core\spt-bs-core\target
  Length-sum  1.35 GiB / 4,404 files -- RANKING figure, overstates on hardlinks, so true reclaim is AT MOST that
  contents    release/ only: spt.exe 38.1 MB + spt.pdb 12.4 MB + deps
  born        2026-09-09 02:17:50, last write 02:28:20 -- built inside the v0.68.0 golden window
  whole _work tree totals 2.12 GiB (spt-bs-core 1.83, _update 0.24, spt-core 0.04)
  the spt-core checkout has NO target dir at all

CLASSIFICATION, done before any size math:
  OUTBOUND  real directory, NOT a junction (LinkType empty, ReparsePoint False) -- would delete as a tree
  INBOUND   swept 3 roots: the only two reparse points naming actions-runner are the runner's OWN
            version-swap links (bin -> bin.2.337.0, externals -> externals.2.337.0). Nothing aims at the target.
  ENV       CARGO_TARGET_DIR unset in Machine, User AND Process -- the entry-less hazard is absent
  OWNER     target/POOL-OWNER.json: owner_tree = that same tree, written_by spt-poolguard. Self-owned, no foreign pool.
  BUILDERS  zero cargo/rustc/link/xtask alive. CONTROL-TESTED before I believed the zero: same query shape
            returned 12 pwsh hits with owner resolution working, so the empty set is real and not a broken filter.
            Runner is idle -- Runner.Listener + RunnerService only.
  free space by my own read: 195.81 GiB, closing on hertz's 195.75.

THE CORRECTION: a retired item with a re-raise trigger reads as a lever held in reserve. This one is not a lever.
If the box ever hits your 100 GiB gate, reaping this tree buys 1.35 GiB -- 0.7% of today's free space. It cannot be
the remedy for a disk-floor event, so please do not let the trigger imply a reserve that does not exist. If free
space does become the problem, the weight is somewhere I have NOT censused and will not claim -- the cargo pools
under Documents\projects and .worktrees, not _work. Suggest the trigger point at a pool census instead of this tree.

Reaped nothing. Touching nothing. Standing down on the item.