Disk

Every worktree builds into its own target/, and cargo collects nothing in it on its own.

target/debug/deps/ keeps every generation of every unit. A dependency bump, a feature flip, or a narrowed cargo nextest run -p <crate> whose feature set differs from the workspace build writes a second rlx_core, wgpu and windows beside the first, and nothing collects the old one. scripts/prune-target.mjs deletes what the everyday loop no longer uses:

node scripts/prune-target.mjs                 # dry run: what would go, and the bytes
node scripts/prune-target.mjs --apply         # delete it
node scripts/prune-target.mjs --verify-fresh  # every artifact the loop reports is still fresh

The live set is what cargo reports: the script runs cargo build --workspace, cargo clippy --workspace --all-targets and cargo nextest run --workspace -P fast --no-run with JSON messages, and keeps every file one of them names. So the three have to be green, and no other cargo process may run in the same checkout while it does. Deleting something the loop needed costs a rebuild, never a wrong build: cargo sees a missing output as dirty. The target directory comes from cargo metadata, so a CARGO_TARGET_DIR redirect is followed.

Run it when the disk is short, and after anything that changes many units at once: a toolchain or dependency bump, or a session of narrowed -p runs.

target/debug/incremental/ holds one directory per compiled unit, and up to two sessions in each. Measured on the Windows box, then the reference machine, on 2026-09-15, in a lane built by the three commands above: 171 unit directories and 1.95 GB. One edit to core/src/render/metrics.rs and the three commands again took it to 3.62 GB with no new directory, because each rebuilt unit now kept its previous session beside the new one. Three more edit-and-revert rounds left it at 3.59 GB, still 171 directories and never more than two sessions in one. So the loop alone does not grow it without bound. What adds directories is a new unit: a different feature set, a narrowed -p build, a dependency or toolchain change, each of which leaves the old unit’s directory behind.

prune-target.mjs does not touch this directory, because nothing cargo reports names which unit a directory belongs to. Delete it instead, when it has grown past what the loop above needs:

rm -rf target/debug/incremental                           # sh
Remove-Item -Recurse -Force target\debug\incremental      # PowerShell

That costs one non-incremental rebuild of the workspace crates on the next build, and nothing else: dependencies are never built incrementally, and no output outside that directory depends on it.