---
name: a-cold-pool-costs-2500-worktrees
description: "Disk on this box is spent by CONCURRENT POOLS, never by worktree count: 45 worktrees = 0.79 GB, 3 pools = 130.45 GB. Ceiling is TWO live pools against the 40 GB floor."
metadata: 
  node_type: memory
  type: reference
  originSessionId: 8530ee91-5742-4df0-a973-21a034d9db72
  modified: 2026-08-22T07:59:48.493Z
---

**Measured 2026-08-22 (todlando, HFENDULEAM), read-only, whole `.worktrees` tree:**

| | count | size |
|---|---|---|
| worktrees carrying a pool | 3 | **130.45 GB** (74.42 + 43.58 + 12.45) |
| worktrees carrying no pool | 42 | — |
| all 45 worktrees, non-pool bytes | 45 | **0.79 GB** (~18 MB each) |

**One cold pool is worth roughly 2,500 worktrees.** Worktrees are 0.6% of the project's footprint;
pools are 99.4%.

**Why this matters more than it sounds:** the obvious remedy for a full disk is "we have too many
worktrees, prune them". That is a day of fiddly `git worktree remove` work for under a gigabyte, it
risks removing a lane someone still wants, and it leaves the actual lever untouched. A register
entry keyed on worktree count would have made things worse while looking like diligence. doyle's
draft said exactly that and was retired on these numbers.

**The ceiling, as arithmetic rather than hygiene:** a cold pool on this workspace costs **45–75 GB**;
the gate floor refuses below **40 GB**. So the box supports **TWO live pools comfortably, THREE only
if one is small**. The 2026-08-22 floor event happened at FOUR (root, two lane pools, a gate rig)
plus the milestone head — that is the whole event and it needs no other cause.

**So the two existing rules are right and only needed a number attached:**
- **Reap a pool when its lane finishes** — 45–75 GB back, immediately. (Classify first:
  [[gate-worktree-target-disk]].)
- **Never two builds at once** — not only the contention argument, but 75–150 GB of *simultaneous*
  allocation against a 40 GB floor.

**A footprint is a property of an INSTANT.** Two totals taken hours apart are not a trend: a 252 GB
reading that counted since-reaped pools and a 130 GB reading of what stands are both true and must
not be stitched. Same reason free space read 134.61 GB and 115.42 GB twenty minutes apart — a gate
was allocating between them. Report each figure with its instant attached and derive no history.

Kin: [[disk-full-reds-as-lnk1318-pdb-error]] (what a near-full volume does to a build, and the rule
that free space goes in the FIRST line of a failure report), [[gate-worktree-target-disk]],
[[free-space-floor-blocks-golden]].

**⭐ EXCEPTION doyle ruled 2026-08-26: "reap a pool when its lane finishes" does NOT reach the ROOT
pool.** After the v0.63.0 post-publish teardown (47.062 GB over 7 lane/rig targets) the root
`spt-core/target` was the single biggest thing left standing, and I offered it. Refused, and the
reason is the general rule: **a pool with NO lane is not a leftover, it is the warm cache the next
milestone's first build rides.** deployah had just released it into a clean resting state
(`owner_tree=spt-core`, no lane label) — that resting record is what marks it an ASSET rather than
debt. Reaping it buys GB at the price of a full cold rebuild at intake.

So the reap criterion is **NEED, not opportunity**: a finished LANE pool goes as soon as its lane
lands (it will never be warm for anything again), while the root pool goes only when the 40 GB floor
actually demands it. Tell them apart by the claim record, not by size — a lane label present means
reapable-on-finish, a bare `owner_tree=spt-core` with no lane means leave it. Corollary for the
teardown report: after a big reap, name what you deliberately LEFT and why, so the next agent reading
"one target still present" does not file it as a miss.