--- name: pool-release-rebuilds-into-the-pool-you-just-reaped description: "2026-09-08: after reaping three target subtrees, my `cargo run -p xtask -- pool-release` loop RECOMPILED xtask into the freshly-emptied pools — 2.8 GB back into one, 73.6 MB partial into the next. A reap that did not take looks exactly like a target/ that exists again." metadata: node_type: memory type: feedback --- Ordered reap of three landed lanes' `target/` subtrees (68.16 + 47.11 + 8.79 GB, Length-sum upper bound). All three deleted cleanly. Then I ran the documented release step, `cargo run -p xtask -- pool-release --pool target`, from inside each worktree — and cargo, finding an EMPTY target, rebuilt xtask INTO IT. hertz-lane4 came back at 2.8 GB; hertz-repin was 73.6 MB / 262 files into the same when I noticed and killed the loop. **Why:** the tool you clean up with must not be built by the thing you are cleaning. `cargo run` is a BUILD verb wearing a run verb's name, and its output directory is the pool under reap. Nothing warns: `target/` simply exists again, which is indistinguishable from a reap that never took, and the reclaim you then quote is short by whatever cargo put back. **How to apply:** - Release with a binary you ALREADY HAVE, against the pool PATH: `.worktrees//target/debug/xtask.exe pool-release --pool ` It releases without compiling anything anywhere. - `Test-Path` / `[ -d target ]` AFTER any reap and BEFORE quoting a reclaim figure. - Expect `holds no stamp - nothing to release` for a pool whose target was already deleted: the claim record lives INSIDE target, so the reap takes it too. That message is correct, not a failure. - Reap the target SUBTREE only; worktrees stay (releases#103). Banked fleet-wide by doyle the same day. Related: [[a-kill-is-only-as-scoped-as-its-filter]] — the stopper that killed this runaway loop by descendancy took 10 pids from one root with the caller untouched.