A nested worktree belonging to a different repository

[blooop]

Question

A nested worktree belonging to a different repository: what should the sweep do with it?

Raised by the keystone decision on #445. Under the site-subtree unit this case is now reported rather than silently deleted, which is the important half and already better than the status quo. But it is unclassifiable by the sweep, so it stands forever and pins its parent standing with it, and the only reclaim path is --force-worktrees.

That is principle 1 behaving correctly and principle 2 going unserved, which is the trade this map is meant to make deliberately rather than by omission. So: is standing forever the right answer, or should devlaunch do more?

The facts that bear on it, from #448's findings: a nested worktree of another repository has its admin directory under that repository, its gitfile points there, and the containing clone cannot see its registration at all — so no prune in the containing clone ever reclaims it, and the containing repository has no way to ask about its state.

Candidates:

1. Stands, reported, and that is the documented answer. Cheapest. Principle 2 is partly served by the report: the bytes are named even though nothing reclaims them.
2. Read its gitfile and ask that repository about its cleanliness and reachability, then treat the answer as the verdict. Strictly more capable, and the cost is that the sweep now reaches outside the clone it was scoped to, which R1 in the map's Notes exists to prevent. Weigh whether "the repository this worktree names" is a legitimate widening of a scan domain or the first step of the thing R1 forbids.
3. Treat the parent as uncollectable and say so once, rather than re-reporting a permanent condition on every run. Noise has a cost when the whole point is that somebody reads the output and acts.

Note the interaction with the container question on the sibling ticket: inside a container, the other repository's worktree may be perfectly readable, so the answer may differ by where --prune runs. Say so if it does.

How the answer gets tested: a fixture with a worktree of a second repository nested inside the first, asserting the verdict and that the parent's fate follows from it.

[blooop]

agent-decided (principle 1, no data loss): a nested worktree belonging to a different repository stands, is reported, and is never probed. Candidate 1, with candidate 3's concern adopted and its mechanism refused. It lands in #446's existing CouldNotProve(NotThisClonesToAccountFor) arm and needs no new arm, exactly as #446 §9 predicted. Candidate 2 is refused on its merits, not on its availability, which is what #462 required of me: the verdict does not move if P1 is ever weakened.

But the ticket's premise is false in the direction that matters, and I measured that before deciding anything. This case is not "now reported rather than silently deleted." It is deleted today, unopposed, with no flag typed, and the reason printed for it is a false claim. So the trade this ticket exists to make deliberately is not principle 1 against principle 2 — it is a live principle 1 defect that the site-subtree unit closes only if one more thing is true, and that thing is not true yet.

Everything below is measured on git 2.51.1 and on this tree's dl at 449cae2. Scratch cache, scratch DEVPOD_HOME, a scripted devpod list. Nothing was written to the repo.

1. What dl --prune does with this case today

Fixture: a devlaunch clone under a scratch cache_dir, referenced by a live workspace so the agent-worktree sweep runs; a second, unrelated repository with a worktree at <clone>/.claude/worktrees/nested2 on branch feat, holding UNSAVED.txt. Nothing about it is stale: the other repository lists it, no prunable line, and it is the checkout of a live branch.

Agent git worktrees inside the clones above -- 12.0 KiB:

  …/repos/blooop/demo/demo-wt:
    - removing …/demo-wt/.claude/worktrees/nested2 (12.0 KiB): git has already forgotten it

Are you sure? [y/N] y
Removed 1 agent worktree(s) -- 12.0 KiB.

UNSAVED.txt is gone. No objection, no --force-worktrees, no unsaved figure, and "git has already forgotten it" is false: the repository that registered it has forgotten nothing. The path through the code is short and has no guard in it. linked_worktree_name (agent_worktrees.rs:270) reads only the gitfile's …/.git/worktrees/<name> tail and ignores the prefix by design, so a foreign worktree yields Some("nested2"); this clone's listing joins nothing to it and this clone has no admin directory of that name, so worktree_status's (None, None) arm at :632 returns Forgotten { holds: NothingToLose }; decide at :745 finds no objections and returns Remove { promotion: Unopposed }.

And it also disappears from its parent's dirty answer. is_only_nested_worktrees (:538) drops an untracked entry when holds_only_worktrees (:575) says everything under it is a confirmed linked worktree — and that confirmation is the same tail-only read. So the foreign worktree is subtracted from the parent's Q2 and deleted in its own right. Both halves of the module treat "shaped like a worktree" as "one of ours."

One correction to the keystone, in the direction of worse. #445's resolution says of the three unaccountable shapes: "today sweep_clone does continue — not reported, not descended into, and deleted with its parent." True of a plain directory and of an unreadable gitfile, which really do hit the continue at :1131. Not true of a cross-repository worktree, which passes the confirmation and is removed in its own right, without its parent going anywhere. This is the one of the three that never reached the continue, and it is the one the ticket is about.

The doc comment two lines above the defect already names it: the tail is "what says 'a git worktree, registered under some repository's admin directory'" (:268). Some repository. The module writes down the ambiguity and then reads the value as unambiguous.

2. What git's unforceable refusal covers, and what it does not

#462 §4 established the one safety fact git contributes and asked me to establish its exact edges, because this ticket is its subject. Re-measured:

invocation	result
git -C r1 worktree remove <path of r2's nested worktree>	fatal: '<path>' is not a working tree, 128
same with -f -f	identical refusal, 128; UNSAVED.txt intact
git -C r1 worktree remove <r1's outer worktree containing it>	exit 0, silent. UNSAVED.txt destroyed

So the refusal covers a forget by name whose argument resolves outside the asking repository, and it is unforceable. What it does not cover is everything that reaches this ticket's case:

1. It attaches to an invocation devlaunch never makes. The refusal only ever fires on a recorded path, and under What unit does the agent-worktree sweep reason about #445 a recorded path exists only because this clone's listing printed it. r1's listing never mentions the foreign worktree. There is no call for the refusal to protect.
2. It says nothing about the byte operation. The removal is remove_tree_as_far_as_it_goes, a filesystem walk with no git in it. Row 3 above shows even git's own careful command destroying the nested tree exit 0; devlaunch's is strictly less careful. The refusal guards the operation that cannot reach this case and is absent from the one that can.
3. Its message is scoped, not descriptive. is not a working tree is r1's answer about a path that is a working tree, of r2. The refusal is r1 declining to recognise, not git recognising a foreign owner and protecting it. Nothing in it generalises to "git protects other repositories' worktrees."

Therefore git contributes exactly zero to this case. The whole of the protection is #445's conjunction plus #446's predicate, and that sentence belongs in the module prose so nobody later simplifies by leaning on the refusal. It is the same conclusion #462 §3 reached for the container case by a different route, and it should now be stated once for both.

3. Candidate 2, refused on its merits

Read the gitfile, ask that repository, treat the answer as the verdict. Under P1 the prefix is a path in a namespace one level in and does not resolve where the pass runs, so the probe is dead wherever --prune legitimately runs. #462 told me not to rest on that, and I do not need to. Three independent legs, none of which mentions availability:

(a) It selects a git target from file content, which is the one thing this module's discipline forbids. linked_worktree_name already refuses a . or .. tail because "file content is not trusted to be a name" (#442 review S6), and #445 rejected prefix-derived containment edges for "computing the most safety-critical relation in the design from the least trustworthy data in it." Candidate 2 is that same move promoted from an edge to a --git-dir: devlaunch would run git against a repository chosen by a file inside a directory it is about to delete. A name can at least be checked against a listing devlaunch owns. A prefix can be checked against nothing.

(b) A clean answer would still not license the removal, because devlaunch cannot finish the operation. This is the leg that kills it. Suppose the probe answers perfectly: clean tree, every commit reachable from a ref. The act is still rm -rf of a subtree, and the registration lives in a listing devlaunch does not own, so #445 forbids naming it and nothing devlaunch may invoke can forget it. Measured, the wreckage:

$ git -C other worktree list --porcelain
worktree …/demo-wt/.claude/worktrees/nested2
branch refs/heads/feat
prunable gitdir file points to non-existent location

$ git -C other checkout feat
fatal: 'feat' is already used by worktree at '…/demo-wt/.claude/worktrees/nested2'   # 128

The other repository is left holding a stale registration and cannot check out its own branch until somebody prunes it. So candidate 2 buys a proof about principle 1 by committing a principle 2 violation one namespace over, in a namespace devlaunch has no reclaim path into, and by breaking a working repository. What is missing is not knowledge, it is capability: knowing the tree is clean does not give devlaunch the second half of the operation. A probe that cannot be followed by a complete act is a probe with nothing to answer.

(c) Shipping it would be a deleting path that is dead everywhere CI or a real invocation reaches. Under P1 it never resolves on either real surface, so its only live use is the case P1 says cannot happen. #462 §6 refused the container detector partly because the in-container path has zero coverage on every CI leg; this is the same argument with the polarity that matters more, since the untested path is the one that enables a removal.

4. Candidate 3, split

Refused as a mechanism. "Say it once" across runs needs memory of what was already said, which is new persistent state whose failure mode is silence, and #446 §4's last row is the standing instruction against it: "a parent reported as 'kept' with the child unnamed is the invisible straggler." Worse, the report is the only service principle 2 gets here (the ticket says so itself), so suppressing it spends the one thing that was working to buy quiet. And suppression is wrong even when it works: a foreign site whose bytes grow tenfold, or a second one appearing beside it, would be a repeat of a remembered condition.

Adopted as wording and count, which is where the noise actually lives.

• One line per standing site per run, not one per pinned ancestor. What proves an agent worktree safe to remove, and what if it cannot be proved #446 already gives this: reasons accumulate but each names its own Inside, and a parent's line names the child. A three-deep chain pinned by one foreign site prints that site once. The count of printed lines is the number of standing sites, not the number of things they pin.
• The line says the condition is permanent from devlaunch's side and names who can end it. A repeated line that tells you what to do is a to-do; a repeated line that tells you nothing is noise. Frequency was never the variable.

5. Standing is not principle 2 unserved, and three of the four reasons are already settled law

The ticket frames this as principle 2 going unserved. Sharpened, it mostly is not.

Principle 2's subject does not include this. It reads "nothing devlaunch causes to exist should accumulate unreclaimed." Devlaunch causes clones, and the harness causes worktrees of those clones. A worktree registered by a repository devlaunch never touched is not devlaunch-caused, and reclaiming it is not devlaunch's obligation. What principle 2 does cover is the parent it pins, which is devlaunch-caused.

The named third party is the correct owner. This map already satisfies principle 2 by naming a reclaimer rather than becoming one: git gc's worktree prune --expire in #445, buildkit's own GC in #450. Here the reclaimer is better than either, because it is the party that created the thing and the only one that can complete the operation: git -C <that repository> worktree remove <path>, or deleting it from inside the container where the path resolves. That is a row for #455 with a name in it, not silence.

#468 already reclaims the part that is worth bytes, and already decided this exact row. Its claimant fold names CouldNotProve(NotThisClonesToAccountFor) explicitly as a non-claimant: "another repository's env, tagged, with its own lock beside it, is still derivable, and whose repository it is was never part of the argument." So a foreign site's tagged .pixi/envs/default goes, and so does the pinned parent's, because the standing reason is git's account of content rather than a claimant's claim. That is the ~94.5 GB of the measured 104.5 GB, reaching into the very sites this ticket worried would stand forever holding everything. I checked this rather than assuming it, and I am not reopening it: it is consistent with what I decide here, and it is the reason "stands forever" costs far less than the ticket's framing implies.

And the disposition matches the one #446 already took, out loud. #446 §5(b) accepted roughly 33 of 72 directories standing behind a flag, "named with their bytes, so principle 2 is served by visibility where it is not served by reclamation." This is the same trade on a smaller and rarer population, and consistency with the route already walked is the tie-break the map asks for where the principles are silent.

So the residue after all four is: the parent's non-derivative bytes stand until a human types --force-worktrees or the owning repository takes its worktree back. That is principle 1 beating principle 2, and per the map's instruction the run says so out loud.

One completeness note, since the ticket asks what the parent's fate follows from. Standing propagates to ancestors, never to descendants. A worktree of this clone nested inside a foreign one is still joined to this clone's listing, so it is still ours and still collectable on its own proof, and removing it is removing our own subtree from inside untracked content of a repository that never tracked it. The foreign site pins what contains it and nothing it contains.

6. Constructive modeling: one type moves, and it is not the verdict

Ran /constructive-modeling. #446's Verdict does not move, which is the composition test #446 §9 set for this ticket, passed a second time. What moves is #445's SiteKind, and the finding is the sharpest kind the skill names: one value with two meanings, and a comment explaining which.

linked_worktree_name's Option<String> is today the whole of the confirmation, and Some("nested2") means both a worktree of this clone and a worktree of some repository. Its own doc says "some repository's admin directory." Prose carrying the invariant the type was supposed to carry.

Two findings, and both are about the positive space rather than a new guard:

1. SiteKind::OursHere must be unconstructible without a registration from this clone's own listing. In What unit does the agent-worktree sweep reason about #445's shape, Site carries registered: Vec<Recorded> beside kind, so OursHere with an empty vector is constructible and means "ours on the strength of a gitfile" — tag plus parallel fields, and the arm that deletes. OursHere should carry the join witness (a NonEmpty<Recorded>, or the Recorded it joined on) and derive admin inside its constructor from that name, never take it as an independent Option<PathBuf>. Ownership is then a positive answer from a listing devlaunch owns, Recorded's only constructor already parses that listing, and the gitfile drops back to what it is honestly evidence of: that this place is a site at all, rather than whose.
2. An admin directory is a channel, never ownership evidence. This is the collision case, and it is the one thing this ticket adds that no other ticket covers. A foreign worktree whose leaf name happens to match a name this clone has an admin directory for reaches worktree_status's (None, Some(admin)) arm and gets probed through this clone's index, which is What proves an agent worktree safe to remove, and what if it cannot be proved #446 §8's suffix-join hazard and What --prune should do inside a container, where recorded paths resolve #462 §4's boundary case arriving from a third direction. What proves an agent worktree safe to remove, and what if it cannot be proved #446 says it fails safe because a borrowed index reports the whole directory as changed. That is a behaviour of git's diff, not a property, and it is the wrong thing to rest on: two worktrees cut from the same commit with no edits are a clean Q2. Deriving admin from the joined registration makes the borrow unconstructible, so the property stops depending on what a borrowed index happens to say.

Unaccountable needs a named arm for a linked worktree registered somewhere that is not this clone, distinct from an unreadable gitfile and from a plain directory, because the report's words and the named reclaimer differ and only this arm has one. #468's Reason::subject() is a wildcard-free match, so the arm forces its §6 question to be answered — and #468 answered it already, in the row quoted above. No Verdict change, no fourth Blank, no new flag.

Restraint check, since the skill demands one. The NonEmpty<Recorded> earns itself: what it prevents is not a panic but the unopposed removal measured in §1. It is not a newtype speed bump; it is the discriminator between two filesystem namespaces. And it changes no outcome for the population #446 already decided: a site of ours whose registration was expired by gc's worktree prune --expire loses the same argument it already lost under NothingToAskThrough, so the arm is different and the verdict is not.

7. What this adds to #454

Net additions, all small, and one of them is a shipped data-loss fix independent of everything else on this map.

1. Ownership is a registration join, never a gitfile tail. SiteKind::OursHere carries the joined Recorded and derives admin from it; linked_worktree_name stays tail-only and stays the site test rather than the ownership test. This is the fix for §1 and it is the whole of my answer's build cost.
2. A named Unaccountable arm for a linked worktree registered outside this clone, its Reason::subject() row already given by May a standing site's re-fetchable subtrees be reclaimed #468.
3. An absence to pin: no git invocation in this module ever takes a repository path derived from file content. Today admin_dir builds from clone plus a name, so the property holds by accident of construction; the test makes it deliberate. This is candidate 2 refused structurally rather than merely unimplemented.
4. The report's shape: one line per standing site, attributed to the site, stating that devlaunch will never reclaim it and naming the owning repository and --force-worktrees. No cross-run memory of what was reported.
5. The test the ticket asks for, and one row of it is the important one. A worktree of a second repository nested inside the first, holding uncommitted work, asserting: the site stands with the foreign-registration reason; every ancestor stands and the printed line names the child; nothing under it is removed with no flag typed; no git invocation devlaunch makes ever names the foreign registration; and the second repository is untouched, still listing its worktree with no prunable line and still able to check out its branch. Add the collision row from §6.2: the same fixture with the foreign leaf renamed to collide with a name this clone has an admin directory for, asserting the probe is not made through this clone's index.
6. A false claim to correct, the sixth this map has found in this module, and the only one that is a live deletion rather than stale prose: agent_worktrees.rs:268-269's "some repository's admin directory," read as this clone's. Alongside it, correct What unit does the agent-worktree sweep reason about #445's own "does continue" description of this case per §1.
7. Module prose: git contributes nothing to this case, with §2's three edges. The same sentence What --prune should do inside a container, where recorded paths resolve #462 §3 needed for the container case, stated once for both.

Net removals: none. Nothing on #454's list gets easier, and nothing gets deleted.

8. Fog

• The .claude/worktrees/ place is not devlaunch's to define, and nothing owns that. Every shape in this module keys on a directory the harness chose, which means a foreign worktree can land there by nothing more than a cd and a git worktree add. Whether devlaunch should mark the place it reasons about with something of its own is a real question, and it is the same shape as Orphaned volumes with no surviving record #451's per-workspace marker. Not ticketed: it changes no verdict here, and May a standing site's re-fetchable subtrees be reclaimed #468's CACHEDIR.TAG gate is the precedent for reading a published marker rather than minting one.
• A worktree of the sibling .bare nested in a clone is the near-miss of this case that I did not measure, because P1 keeps the bare unmounted in the container and nothing devlaunch does creates one. It would join to no listing this pass reads and land in the same arm, which is the right answer, but the reason string would say "another repository" about a repository that is arguably the same one. Wording, not a verdict, and worth a look when Rebuild the agent-worktree sweep on the decided unit #454 writes the line.