What proves an agent worktree safe to remove, and what if it cannot be proved

[blooop]

Question

What exactly proves an agent worktree safe to remove, and what is the answer when the proof cannot be obtained?

Principle 1 says fail towards keeping. This ticket turns that into one predicate somebody can read, because right now the answer is spread across a reachability check, a dirty check with a pathspec exclusion, a lock check, and an arm that had no probe at all.

The cases, each needing a stated verdict:

• Unpushed commits; branch absent from the remote entirely; branch present but local ahead.
• Detached HEAD, where there is no branch for a branch-keyed check to find and the admin dir's HEAD is the only thing reaching the commit.
• Dirty working tree; staged-but-uncommitted index; untracked files.
• Untracked content that is not a worktree under a worktree's own .claude/worktrees/, which review finding S4 established is currently excluded from the dirty check and skipped by the sweep, so it is neither reported nor protected.
• git worktree locked, which dl --prune cannot reclaim agent worktrees inside live workspaces' clones (104 GB measured) #426 Ask 2 says is never removed implicitly.
• Stashes: refs/stash lives in the shared repository, so it survives the directory. Confirm and write it down so nobody re-checks it.

And the cases where the check itself cannot run, which is where principle 1 actually bites:

• Remote-tracking refs that are stale or absent, because the clone is cut from the sibling .bare and repointed at the forge with no fetch of its own. Asking the clone alone reports pushed-and-merged branches as unpushed; asking the bare gives an answer as of the last fetch. Neither is live, and --prune must not start doing network I/O.
• A registered path that is a container path and does not resolve on the host.
• A gitfile tail that does not normalise to a name under <clone>/.git/worktrees/ (traversal, doubled or trailing separators, absolute vs relative, a tail naming a different worktree's admin dir).

Decide whether the honest answer is a boolean, or a value that distinguishes proved safe, proved unsafe, and could not be proved — the third being the one principle 1 cares about, and the one a boolean has to lie about. Whatever it is, the output has to be able to say which case a kept worktree fell in, because "kept" with no reason is what makes a straggler invisible.

Run /constructive-modeling.

How the answer gets tested: one table-driven test with a row per case above, including the unprovable ones, each asserting the verdict and the reason string.

[blooop]

constraint from the keystone, not an answer to this ticket. #445 is resolved: the unit is a nesting site plus everything nested inside it, one subtree decided bottom-up. Three things that follow for the predicate this ticket owns.

The verdict has to compose conjunctively over a subtree, so it has to be foldable rather than a bare boolean or a bare enum consumed at one site. A parent is collectable only when it and every site nested inside it are, which is what makes the T1 losses unconstructible rather than guarded. That is an argument for the value this ticket picks, and it points the same way this ticket's own question already does: proved safe / proved unsafe / could not be proved, with the third folding like the second.

One case needs a verdict this ticket does not list yet, and it can only be stands: a directory in the worktrees place that this clone cannot account for. A worktree of a different repository nested inside one of ours, a plain directory, a gitfile that reads but names an admin directory that is not in this clone. Review S4 found the smaller half of this; the unit makes it a site, so it needs a verdict, and nothing about it is provable from here.

And a measurement the "could not be proved" arm has to survive. git worktree remove <a container path> applies no dirty check at all — the cleanliness check sits inside if (file_exists(wt->path)) and a container path does not resolve — so it drops the registration of a worktree whose host directory holds uncommitted work, exit 0, silently. Measured on git 2.51.1 and 2.43.0. The metadata operation therefore contributes no safety of its own, and this ticket's predicate is the entirety of what stands between a registration and somebody's afternoon. Nothing may lean on git refusing.

[blooop]

breadcrumb: scope addition from #459, which resolved and argued both of these belong here because this ticket owns the predicate and it should be decided once for every reader.

The existing clone-level unsaved guard is structurally blind to nested agent worktrees, in both halves. .claude/worktrees/ is gitignored so status --porcelain returns empty, and the unpushed probe names one branch rather than --all. Reproduced on real git. A clone-only count would therefore have printed "0 clones hold work that exists nowhere else" over the 72 worktrees and 104.5 GB that started #426. This outranks the ticket it was found on: dl <ws> rm and --prune's orphan arm both rely on that guard and both have a per-item keep, so they carry a check that lies, where --purge merely has none.

Second, independent of worktrees: dl's unpushed answer is log --oneline <branch> --not --remotes everywhere, so commits on any other local branch are invisible. Commit on wip, switch to main, let dl delete the clone, and those commits are gone with NothingToLose printed. Live in shipped code. --all is one word and also catches the nested-worktree commit half of the first finding.

So this ticket's answer needs to cover what the clone-level answer must reach, not only what proves a single worktree safe. Both are principle 1, which outranks everything else on this map.

[blooop]

agent-decided (principle 1, no data loss): not a boolean, and not a flat trichotomy either. A two-armed verdict whose standing arm carries a non-empty list of reasons, and a reason is either proved unsafe or could not be proved. The three values the ticket asks about are all there; what is refuted is putting them in three flat arms, because a subtree can be both at once and any three-arm fold has to answer Refused ∧ Unproved by discarding half the report. The collectable arm carries a proof, a private-field witness minted only by a probe that answered, so "nothing objected" and "nothing was asked" stop being the same value. That is the whole of the answer: Safe is not the fallthrough of a filter, it is a thing you have to be handed.

Everything below is measured on git 2.51.1 unless it says otherwise. Probe scripts were throwaway; nothing was written to the repo.

1. Four questions, and their scopes are not the same

The ticket's case list collapses to four questions once you ask what each one can be put to.

	question	what answers it	its natural scope
Q1	what is at this site at all?	the walk, plus the site's own gitfile	one site
Q2	does the working tree hold anything that exists nowhere else?	status --porcelain through --git-dir=<admin> --work-tree=<at>	one working tree
Q3	do the commits reachable from here exist somewhere else?	the sibling bare first, then the clone	one repository
Q4	does a third party assert a claim on it?	locked in the listing	one site

Q1 is prior: its answer decides which of the rest are askable at all. And the scope column is the finding, because the shipped code has both middle rows backwards. It asks Q2 once per clone (so it misses every nested working tree, since a working tree is the only thing that has an index and there are as many indexes as worktrees) and Q3 once per branch (so it misses every other ref in the repository, since refs are shared). Both halves of #459's §4 are that one transposition. Dirt is per working tree. Reachability is per repository. One sentence, two live data-loss paths closed.

Three cases the ticket lists are not separate questions and should stop being treated as such. Dirty tree, staged-but-uncommitted index and untracked files are one Q2 — one porcelain read reports all three, and splitting them into three probes is three chances to have two of them agree and one not. Branch-absent-from-remote, branch-ahead and detached HEAD are one Q3, because Q3 is asked about the commit and not about the branch name; the existing two-arm WorktreeHead already gets this right and it is the reason it must not become an Option<branch>.

Stashes are not a question, confirmed so nobody re-checks it. Measured: a git stash push from inside a linked worktree writes <clone>/.git/refs/stash, is listed by git stash list in the main worktree, and is reached by rev-list --all. It is in the shared ref store, it survives the directory, and --prune never removes the shared store. No probe. Into the module doc.

2. Why the lock is an unproved and not a loss

#448 established that git documents a lock as "this worktree may be on a portable device or network share which is not always mounted" and says nothing else, and that no git command consults it except the ones that name the locked worktree. So a lock is evidence about nothing on disk: a locked worktree with a clean tree and pushed commits is, as far as the bytes go, proved safe, and #426 Ask 2 still says it must not be removed implicitly.

Under a boolean that is an unexplained special case. Under this verdict it is not a special case at all: a lock is a claim over the site by a party this pass cannot interrogate, which is precisely could not be proved. That is why Ask 2's answer is the same flag as everything else rather than a separate mechanism, and it means Reason::Holds never carries a lock — reporting a lock as a loss would be inventing work that may not exist, which is the mirror image of the lie the ticket is about.

3. The verdict, and the two traps

/// What this pass established about one site.
pub enum Verdict {
    /// Every question that bears on this site was put, and answered clear.
    Collectable(Proof),
    /// At least one reason it stands, and reasons accumulate up the subtree.
    Stands(Standing),
}

/// Proved unsafe, or could not be proved. Each names the site it came from,
/// which is what makes a parent's refusal report the *child* that caused it.
pub enum Reason {
    Holds { site: Inside, losses: Losses },
    CouldNotProve { site: Inside, blank: Blank },
}

pub enum Blank {
    /// No admin directory and no registration. Q2 cannot be put at all.
    NothingToAskThrough,
    /// A probe ran and refused. Carries git's words.
    GitWouldNotSay(CouldNotTell),
    /// `locked`, with its reason where git printed one.
    ThirdPartyClaim(Option<String>),
    /// Q1 said this is not this clone's to account for.
    NotThisClonesToAccountFor(Unaccountable),
    /// The probe was skipped rather than run, because the repository lock was
    /// held and this pass does not queue. #459's `run_if_lock_free`.
    CouldNotTakeTheLock,
}

Standing is a private-field non-empty list; and_also is conjunction, Stands absorbs, and two Stands concatenate their reasons. Verdict::nothing_nested() is the fold's identity, named for the fact about the world it asserts so that it cannot be reached for as a default.

Proof has no public fields, no Default, and exactly two constructors, each taking witnesses that only a probe mints:

Proof::everything_asked(clean: Clean, elsewhere: Elsewhere, unclaimed: Unclaimed)
Proof::holds_nothing(empty: NoBytes, elsewhere: Elsewhere)

Each witness constructor takes the raw GitAnswer<String> and returns Result<Witness, Blank>, so a witness cannot exist without an answer in hand inside the module either, not only outside it.

Compiled both directions from a downstream crate. Forging fails:

Verdict::Collectable(Proof { how: .. })   error[E0451]: field `how` of struct `Proof` is private
Clean { asked_through: .. }               error[E0451]: field `asked_through` … is private
Unclaimed { _p: () }                      error[E0451]: field `_p` … is private
Proof::default()                          error[E0277]: the trait bound `Proof: Default` is not satisfied
Standing { first: .., rest: vec![] }      error[E0451]: fields `first` and `rest` … are private

and the legitimate uses compile: the identity, reading reasons, and folding two Stands into one that keeps both.

That closes the two traps this run already paid for. The forgeable-payload one is closed the way #445's is, by structs rather than variant fields. N4 is closed structurally rather than by reaching for NonEmpty::one. Losses::of([one]) resolving its dead arm towards NothingToLose was a symptom: the disease is that NothingToLose is a unit arm reachable by falling through a filter, so every fold in the module has an edge that reads as a licence to delete, and NonEmpty::one fixes two of them and leaves the shape. With Collectable(Proof) there is no fallthrough to fall through to. The same move retires unsaved_in's early return could_not_tell, which today discards losses it had already found — 40 uncommitted changes plus a refused reachability probe report as CouldNotTell and the 40 go unmentioned. Both arms keep, so nothing was lost, but the person deciding was told half the truth, and #459 §6 requires exactly that this cannot collapse.

4. Every case, with its verdict

case	verdict	reason carried
unpushed commits; branch absent from the remote; branch present but local ahead	proved unsafe	Holds(Unpushed) — Q3 answered, and the answer was commits
detached HEAD, commit nowhere else	proved unsafe	same; Q3 is asked about the commit, so no branch is needed
detached HEAD, commit reached by a ref the bare holds	proved safe on Q3	as of the last fetch, and the report says so
dirty tree / staged index / untracked files	proved unsafe	Holds(Uncommitted), one Q2 for all three
untracked non-worktree content under the site's own .claude/worktrees/	proved unsafe	an untracked entry is dropped from Q2's answer only when everything under it is a site the child forest accounts for. Exclude by what a thing is, not where it sits (#442 S4)
git worktree locked	could not be proved	ThirdPartyClaim. §2
stashes	not a question	measured shared; no probe, and a doc line so none is added
bare reached the commit	proved safe on Q3	proof names the bare and the fetch time
bare could not be asked, clone lists commits	proved unsafe	Holds(Unpushed). Note this is also where absent remote-tracking refs land: --not --remotes with no remotes excludes nothing, so the clone lists every commit and the site stands. The stale-ref trap fails towards keeping on its own
bare could not be asked, clone lists none	proved safe on Q3	and the proof states its own limit: a remote-tracking ref in this clone reaches it, as of clone time. Standing here reclaims nothing, ever, which is the failure mode the sharpened spec warns about
bare could not be asked, clone refused	could not be proved	GitWouldNotSay
a registered path that is a container path	not a blank at all	the recorded path is never resolved, and the walk reads the same bytes through the bind mount. This is what every worktree an agent made carries, so treating it as an unknown stands everything forever
gitfile tail that does not normalise: .., ., traversal, doubled or trailing separators, a tail naming another worktree's admin dir	could not be proved	NotThisClonesToAccountFor, via Q1. Not a guard on a deleting arm — there is no path from that Q1 answer to a Proof
a plain directory, an unreadable gitfile, a symlink, a worktree of another repository	could not be proved	same. Stands, pins every parent. #463 owns whether to do better
registered, nothing at the site (container path or deleted)	proved safe only if Q3 also answers	see §5. Not safe on emptiness alone
nothing to ask through, and bytes at the site	could not be proved	NothingToAskThrough. See §5
nothing to ask through, and no bytes once the child forest is subtracted	proved safe	bounded walk, no git, holds_nothing
any site with a standing child	stands	the child's reasons, unmodified, so the printed line names the child's path and not the parent's

The last row is what turns T1 from a silent deletion into a printed line, and it is why the reason carries Inside. A parent reported as "kept" with the child unnamed is the invisible straggler the ticket warns about, one level in.

5. Three verdicts that differ from shipped behaviour

(a) "Registered, nothing here" is not free, and the reason is measured. RegistrationsWithNothingHere's doc says it is "the one category with no bytes behind it", so worktree prune "is the whole of the work". True about bytes, false about work. Measured: a registration is the last ref reaching a detached worktree's commits. rev-list --all --not --remotes in the clone reaches a nested detached worktree's HEAD; forget the registration and it stops reaching it, so the next gc collects the commits. A branch site is not exposed this way, because the branch ref lives in the shared store and survives — which is exactly why WorktreeHead's two arms are load-bearing rather than tidy. So Q3 applies to every registration whether or not there are bytes at its site, and the emptiness proof alone never carries a registered site. This is review T4 generalised and promoted from nit to rule.

(b) #426's category 1 changes verdict, and the population is manufactured. The ticket calls unregistered leftovers "safe to delete outright", roughly 33 of the 72 directories on the reference host. Under this predicate a site with nothing to ask through and bytes in it stands, needing --force-worktrees. Before deciding that I went looking for where that population comes from, and it is not abandonment:

worktree /workspaces/ws-abc/.claude/worktrees/agent-a
prunable gitdir file points to non-existent location

A container-path registration lands on the one prune arm --expire gates, git gc calls worktree prune --expire with gc.worktreePruneExpire (three months by default, clocked on the admin index), and I reproduced the whole sequence: backdate the index, prune --expire=3.months.ago, and the admin directory is gone while the site still holds notes.md, the gitfile still reads gitdir: /workspaces/…, and the branch survives. So "git has forgotten it" on a host is mostly what a routine git gc does to every container-registered worktree older than three months. It is not evidence of abandonment, it is evidence that three months passed. Deleting on that reading is deleting on a clock nobody set for this purpose.

This is principle 1 beating principle 2, and per the map's instruction the run says so out loud: on the reference host this predicate reclaims the registered directories and leaves roughly 33 of 72 standing behind a flag. Two things make that less bad than it reads. They are named with their bytes, so principle 2 is served by visibility where it is not served by reclamation. And the fog item in §8 is a route to their gigabytes that does not touch principle 1 at all.

(c) prunable is never read, and Held goes. Of worktree list --porcelain's fields the predicate reads worktree (the join key, and the argument to remove), HEAD/branch (Q3), and locked (Q4). It never reads prunable, because #448 §5 established that prunable is git's claim about whether <path>/.git exists as a filesystem entry — a fact about a path this module's whole discipline is to not resolve. Reading it is resolving by proxy. So WorktreeStatus::Held disappears, which withdraws an accidental cover and does not replace it: Held never fires on a host, and in a container it is the only thing stopping a live worktree being collected. That is #462's hazard, and making the accident visible rather than quietly inheriting it is the right composition — but it means #454 must not ship this predicate with nothing in that place. See §7.

6. What the clone-level answer must reach (#459)

#459 handed this ticket two live defects and was right that they are one decision. Both are §1's transposition, and both are fixed by the same fold rather than by two mechanisms.

The clone is the root of the same forest, not a different question. A clone's verdict is its own Q2 and Q3 conjoined with the verdict of every top-level site inside it. That closes the dl <ws> rm and --prune-orphan holes with the rule that already exists one level down, and it means there is one predicate with one set of readers rather than a clone predicate and a worktree predicate that can disagree — which is the shape this map has punished three times.

The two recursions are not the same recursion, and conflating them is what made the hole. #442's rule "do not descend into a directory that is going, or the bytes are counted twice" is correct about bytes and was silently also a decision about safety. So: the byte recursion stops at the outermost thing that goes, unchanged; the verdict recursion descends into everything, including sites that are going and clones that are going. Stated apart, they stop trading against each other.

Q3 at clone scope is --all, and that is decided here for every reader. Measured in a clone with a nested worktree on a branch, a second nested worktree on a detached HEAD, and a stray local wip branch:

status --porcelain                       (empty — .claude/worktrees/ is gitignored)
log --oneline main --not --remotes        (empty — the shipped probe)
log --oneline --all --not --remotes       0a27789 work nowhere else
                                          fe42665 detached commit nowhere else

--all reaches every local branch, every tag, refs/stash, and every worktree's HEAD including detached ones — the last confirmed by removing the registration and watching the commit stop being reached. So one word covers #459's wip-branch loss path, the nested-worktree commit half of its §4, and the detached-nested case, all at once. --single-worktree is documented to turn the cross-worktree reach off; it must never be passed. This does not change the site-level probe, which stays keyed on that site's own revision because that is what attributes a loss to a directory in the report.

The dirt half is not fixable this way and must not be attempted. Removing the .gitignore line makes the clone's status say ?? .claude/, and --ignored makes it say !! .claude/worktrees/: both are the right answer for the wrong reason and neither says what is inside. A nested working tree has its own index, and only its own admin directory can be asked. So the fold is the mechanism, and #459's cheaper candidate (b) is adopted for Q3 and refused for Q2.

#459's two constraints are met without new machinery. The figure is not a usize: it is this verdict folded, so nothing at risk and could not weigh are different values by construction and "some at risk and some unknown" is a Standing holding both kinds of Reason — which is the case Unsaved cannot represent today. And run_if_lock_free composes for free: a repository whose lock was held reads CouldNotProve(CouldNotTakeTheLock), which stands. The third value pays for itself in a place the ticket did not anticipate.

One consequence for Unsaved. It cannot carry this: three flat arms, NothingToLose reachable by fallthrough, and no way to say both. So Verdict becomes the internal answer and Unsaved survives as the flattening at the JSON edge — the constructive-modeling skill's own prescription, fix the internal type and confine the lossy re-encoding to one function. Loss, Losses and CouldNotTell are reused unchanged; this is a new answer type, not a new loss vocabulary. The wire rule for the new case: a Standing holding both kinds emits both wouldLose and couldNotTell, additively, so no reader keyed on key presence breaks and no answer is dropped to fit the shape.

7. What has no representation now

1. A collectable site whose subtree holds a standing one. Conjunction plus a derived verdict (What unit does the agent-worktree sweep reason about #445), so T1's three probes are unconstructible. With no flag typed, a locked nested worktree cannot be inside anything that goes.
2. A proof that no probe produced. No Default, no unit arm, no public constructor, and every witness minted from a GitAnswer. Reclaim the agent git worktrees stranded inside live workspace clones #442's S1 and S6 both reduce to reaching a deleting arm on git's silence; there is now no such arm to reach. This is the absence What unit does the agent-worktree sweep reason about #445 and Rebuild the agent-worktree sweep on the decided unit #454 want asserted as a public-api.rest.txt row that does not exist, rather than as a guard firing.
3. A verdict that reports one reason when there were two. Standing accumulates, so the dirty-and-refused case can no longer print half of itself.
4. A clone answer that does not account for what is nested in it. The clone is the forest root; there is no clone-level predicate to be blind separately.
5. An unpushed answer scoped to one branch. --all at clone scope, and Q3's scope is stated as the repository so a per-branch call reads as a category error rather than as a reasonable narrowing.
6. A registration forgotten while anything still needs it. The forget is a consequence of a completed subtree removal (What unit does the agent-worktree sweep reason about #445), and by §5(a) Q3 must have answered for that registration too.

8. Rejected, and fog

• A boolean. Has to call could not be proved either safe or unsafe. Safe is Reclaim the agent git worktrees stranded inside live workspace clones #442's S1 and S6; unsafe reclaims nothing and the flag becomes the only route to anything.
• Three flat arms. Refuted by the fold rather than by taste: a subtree can be both proved unsafe and unproved, so Refused ∧ Unproved needs a fourth arm or discards reasons. Two arms with an accumulating payload is forced.
• A fourth arm for the lock. §2. It is an unproved, and calling it a loss invents work.
• Unsaved with a fourth arm. Tag-plus-parallel-fields, and it leaves NothingToLose reachable by fallthrough, which is the actual defect.
• Fixing N4 with NonEmpty::one. Correct at both sites and leaves the shape that produced them.
• Reading prunable. §5(c).
• Removing the .gitignore line, or status --ignored, to make the clone see nested dirt. §6.
• Content-based proof for a site with nothing to ask through — hashing files and asking whether the clone's object store already holds them. "Content-identical to something committed" is not "this file is saved", and it is an O(bytes) walk to earn a wrong answer.
• Fetching to make Q3 live. Settled already: --prune stays local, and the answer says "as of the last fetch".

Fog now worth its own tickets:

• May a standing site's re-fetchable subtrees be reclaimed anyway? This is the one route to the measured 104.5 GB that does not weaken principle 1, and it is the direct consequence of §5(b). 18 of 72 directories carry a whole .pixi/envs/default, which is why dl --prune cannot reclaim agent worktrees inside live workspaces' clones (104 GB measured) #426 is 104 GB and not ~10, and an installed env is derivable from pixi.lock plus the download cache. Principle 2's stated exception is re-fetchable content. But it is a different unit from the site the keystone just chose, so it is a decision and not a build detail, and it needs its own argument about whether a hand-patched env or an editable install makes it unsafe.
• An expired registration leaves an orphan local branch that nothing reclaims. Measured in §5(b): refs/heads/agent/a survives the prune, and Confirm the bare object stores are bounded #453 established --prune only removes heads whose upstream branch was deleted, so a branch that was never pushed is never pruned. It is a straggler (principle 2) that is simultaneously the thing keeping its commits alive (principle 1), so it must not be reclaimed while its site stands. A Write the reclaim contract into docs/cleanup.md #455 row at minimum, and possibly a decision.
• The suffix join can pair a registration with a directory that is not its working tree. Two container mounts can produce two registrations whose inside keys collide on one site. It fails safe today for a reason worth pinning rather than trusting: the borrowed index reports the whole directory as changed, so Q2 objects. A test, not a ticket.

9. Handoffs

#454's scope changes again, and this time it grows. Net additions: the predicate replaces Unsaved as the internal answer with Unsaved flattening at the wire (blast radius: dl <ws> rm, --prune's orphan arm, --ls --json's pinned goldens, and #461's purge figure); the clone-level guard and dl <ws> rm's refusal come into scope, because they are readers of one predicate and are the two paths #459 showed have a check that lies; --all --not --remotes replaces the single-branch probe at clone scope, which is a shipped data-loss fix independent of worktrees; the verdict recursion and the byte recursion are stated as two recursions; prunable stops being read and Held is deleted; and RegistrationsWithNothingHere's "no bytes, so the prune is the whole of the work" is corrected per §5(a). Net removals: N4 needs no per-site fix, T4 is absorbed into §5(a) as a rule, and the Forgotten arm's careful "asked wherever there is anything to ask through" prose becomes a type instead of a comment.

#454 now depends on #462 in ordering, and this is the one thing on this ticket that could be shipped wrong. Deleting Held withdraws the accidental in-container cover (§5(c)). #454 must not carry this predicate with nothing in its place: either #462 resolves first, or #454 ships a stated refusal to prune inside a container as an interim, which #462 may then replace with something better. I am not deciding #462 — refusing is its own candidate 1 and it may well lose — only that the accident must not be the mechanism and the gap must not be silent.

Composes with #462 and #463 either way. #462 is a question about where the pass runs, which reaches this predicate only through Q1's answer and the site's kind; nothing in the verdict type changes if a container's recorded paths resolve, because the predicate never resolves them. #463 is a question about one Blank value: NotThisClonesToAccountFor stands today, and if #463 decides to read the other repository's gitfile and ask it, that reason arm becomes a genuine probe with a genuine answer and the type does not move. That is the composition test, and both pass.

For #455's contract table, the "what proves removal safe" column has one vocabulary for every row now, and one clarification it should state plainly: "exists somewhere else" means reachable from a ref in a repository this pass does not remove, which includes the sibling bare, and not "is on the forge". #453 established that the bare's tags are monotone, so a commit the forge has deleted can still read proved safe on the strength of the bare holding it. That is honest and it is the right call, since --prune does not remove the bare — but it is the exact scope of the proof and the table should not overstate it.