---
name: pool-release-rebuilds-xtask-into-the-pool-you-just-reaped
description: cargo run -p xtask -- pool-release in a freshly reaped worktree rebuilds xtask into the empty target/, silently putting GBs back; release with a PREBUILT xtask.exe from another pool.
metadata:
  type: feedback
---

hertz 2026-09-08, r2 disk-floor reclaim: after reaping three landed pools' `target/` subtrees,
his release loop ran `cargo run -p xtask -- pool-release --pool <dir>` from each worktree. cargo
built xtask INTO the pool just emptied: 2.8 GB back into hertz-lane4, a partial 73.6 MB / 262
files into hertz-repin before he killed it. Nothing announces it; `target/` simply exists again
and reads as a reap that did not take, and a reclaim measured afterwards is quietly 5-8 GB short.

**Why:** the tool you clean up with must not be built by the thing you are cleaning. Same shape
as "reap the target SUBTREE, never the worktree" and as the sandbox-reap rule: the cleanup's own
side effects land in the measured region.

**How to apply:** release with a binary you already have, against the pool PATH:
`.worktrees/<other>/target/debug/xtask.exe pool-release --pool <abs target>`. Order: pool-release
FIRST with a prebuilt binary, then reap; or reap and accept "holds no stamp" (the stamp lived
inside target and went with it, which the verb reports honestly). After any reap, `Test-Path`
the target again before quoting the reclaim. See [[length-sum-over-a-cargo-target-double-counts-hardlinks]].