---
name: the-name-you-give-a-tree-selects-which-discipline-fires
description: "The same bytes have several true descriptions, and the one the task hands you decides which rule you apply — I rm -rf'd an 'orphan worktree directory' that was also a 9.3 GiB cargo pool with a binding reap method attached"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 9a42c7a1-71f1-47b6-8341-adf7b3dbae7d
  modified: 2026-09-09T16:55:32.936Z
---

**Measured 2026-09-09, mine, reported to doyle before he could find it.** A worktree directory had
refused `git worktree remove` on a pinned handle. Later the handle cleared and I removed the orphan
with `rm -rf`. That directory **contained the `hertz-65s-rider` cargo pool — ~9.3 GiB**, which doyle
had queued as a reap with a binding four-arm method (`Get-Item -Force` outbound classification,
inbound reparse sweep, `CARGO_TARGET_DIR` check, size and free space before AND after, subtree only).

**None of that fired.** Not because I disagreed with it, and not because anyone rushed me — because
I never saw the second description. The task reached me as *"the orphan worktree directory you could
not remove earlier"*, so it selected the worktree-cleanup rule and completed cleanly by that rule's
standard. The pool inside it had no name in that frame.

Two rule lines were crossed by one command (doyle's audit): **"never delete a `target/` you have not
classified"** and **"reap the target SUBTREE, never the worktree directory around it."**

**Outcome was clean, and that is not the point.** After the fact I could still show: no inbound
reparse point aimed at the path, `CARGO_TARGET_DIR` unset, contents rebuildable by construction, the
30 untracked source files hash-verified preserved *before* removal, branch already landed. Free space
239.78 GiB vs the ~231 quoted earlier. But the before-size is gone forever, so the reclaim is a
free-space delta and **not a measured reap** — recorded that way deliberately, and no register line
claims the figure.

**Why this is worth a file:** it is the same shape as the census failure I had caught in a peer the
same hour ([[a-tracked-only-corpus-cannot-answer-tracked-or-not]] — a file's PATH supplying an answer
its corpus could not), and as the directory-ignore trap ([[ignoring-a-directory-buries-what-the-repo-cites-in-it]]).
In all three, a *description* stands in for a *property*. Catching it in someone else's work is much
easier than catching it in the sentence that arrived as your own next task.

**How to apply:**
1. **Before any destructive act, ask what the target CONTAINS, not only what it IS called.** A
   `Get-ChildItem -Force` one level down would have printed `target` and renamed the whole action.
2. **When a rule exists for a thing, the rule fires on the THING, not on the task title.** If the
   tree holds a `target/`, the pool method applies even when the ticket says "worktree cleanup".
3. **A refusal that later clears is still the same object.** The deferred retry inherits every
   discipline the first attempt owed; nothing is discharged by waiting.
4. **Report the process failure even when the outcome is clean** — and refuse to dress the result up
   as a measurement you did not take. "~9 GiB by free-space delta, not a subtree before/after" is the
   honest record; "9.3 GiB reclaimed" would have been a fabricated measurement.

Kin: [[reap-subtree-not-session-dir]], [[preservation-is-its-own-step-before-any-reap-broadcast]],
[[a-length-sum-census-overstates-a-cargo-pool]], [[a-tracked-only-corpus-cannot-answer-tracked-or-not]].