---
name: gate-worktree-target-disk
description: "Each gate worktree's target/ is ~17-22 GB — delete after the gate is certified or the 2TB host disk fills (LNK1180/LNK1318 link fails, timing flakes under 100% disk)"
metadata: 
  node_type: memory
  type: project
  originSessionId: fa4bae0f-ba28-4088-86d4-6708a0340f53
  modified: 2026-08-19T04:11:24.300Z
---

2026-07-10 (v0.30.6 endgame): host C: hit 3.8 GB free — five spt-core `.worktrees/*/target*` dirs held ~81 GB (17-22 GB each). Consequences observed the same day: doyle's full-suite gate flaked the brain_decouple money test under a 100%-full disk, and my swap-tree nextest build died mid-link (`LNK1180 insufficient disk space`, then cascading `LNK1318/LNK1140` PDB errors).

**Why:** every isolated-gate worktree gets a fresh full workspace build (iroh/ring/rustls heavy); nothing reclaims it when the gate finishes.

**How to apply:** after a gate/worktree's purpose is served (SHA certified, branch merged), delete its `target/`/`target-uwedge/` immediately even if the worktree itself stays; before launching a fresh full-workspace gate build, check `Get-PSDrive C` free space (want 25 GB+). Never delete another agent's ACTIVE worktree target (e.g. deployah's rel-* during a release). Kin: [[test-subagent-stalls-on-hanging-test]] (host-load test flakes), gravity-linux disk at 82%.

**⭐⭐ REPORT TWO NUMBERS, NOT ONE — free space is not a measurement of what you deleted.**
Measured 2026-08-05 (todlando, v0.55.0 post-land teardown; doyle named it the model): three lane
targets summed to **50.12 GB** by directory size, while the free-space delta across the same op was
**43.29 GB** (137710112 KB → 183100740 KB). Neither is wrong. The directory sum measures what you
removed; the free delta measures the BOX, which other agents were building and reaping into
throughout the window. Reconciling them into one confident number destroys the information — state
both and name the relationship. Corollary: a free-space figure quoted from earlier in the session is
stale the moment anyone else builds, so re-read it at the act (see
[[quoted-measurement-decays-when-you-mutate-the-subject]]).

**⭐⭐ A TEARDOWN BATCH IS NOT AN OWNERSHIP RECORD — and the batch note can be YOURS and still wrong.**
Measured 2026-08-19 (todlando, v0.56.0 post-publish teardown). My OWN commune listed four worktrees as
"my held batch, tear down post-ship". Two faces failed at the act: (1) `nameplate-asm` **did not exist**
— the real dir is `nameplate-asm-<sha>` (`NAMEPLATE-ASSEMBLY-JIT.md:22` establishes the naming), so a
delete keyed on the remembered name would have missed or, worse, matched by prefix; (2) `PUMP-FIX-JIT.md:13`
says **"doyle owns `nameplate-asm` + its warm pool — do not claim"** — the batch note was wrong about
OWNERSHIP, not about the dir, and the contradiction lived in a DIFFERENT doc than the one that listed it.
It was 70.35 GB. **Grep the project's own JIT/plan docs for the dir name before reaping it, even when your
own record says it is yours** — a note you wrote records what you INTENDED to reap, never who owns it.

**⭐⭐ BEFORE `git worktree remove`, READ THE DIRTY LINE — it can be the payload.** Same op: `pump-188`
showed `dirtyLines=1`, a single `??` on `crates/spt-daemon/tests/pump188_probe.rs` — 334 lines, doyle's
approved releases#188 carrier-quiet instrument with an ARM N negative control. It was in **no ref**
(`git log --all --diff-filter=A` empty) and in **exactly one copy on disk**. Plain `worktree remove`
refuses on untracked files, so the danger is entirely in the `--force` you reach for when it refuses:
that flag would have destroyed the only copy of an approved instrument. Preserve as a git OBJECT first
(committed unchanged to `diag/pump188-probe-instrument` @`021749d`, branch ref survives the worktree),
then remove. **"Clean" is a claim about tracked files; an instrument nobody committed is invisible to it.**

**Order that made the reap safe, same op:** classify OUTBOUND (`Get-Item -Force` — all three were
real dirs, not junctions) → sweep INBOUND for reparse points aimed at them (zero) and check
`CARGO_TARGET_DIR` (unset) → check holders by PATH (14 live `spt.exe`, all from
`AppData\Local\spt-core\bin`, none from a lane target) → `pool-release` BEFORE the reap → reap the
target SUBTREE → `git worktree remove` + prune. And when a worktree cannot be attributed to you,
hand it to its owner rather than guessing — 20 MB is never worth guessing about someone else's rig
(doyle confirmed the one I left was his, withdrawn, and authorized the reap himself).