docs(engine): correct the prune-before-remove rationale
The comment cited 89 registered worktrees against 20 on disk as evidence of stale registrations. That comparison was against .worktrees/ alone; all 89 registrations exist, spread across kb-worktrees, orca workspaces and .claude/worktrees. Prune still belongs before removal on ordering grounds -- a dangling registration fails the removal, and the throw skips the trailing prune so the retry never clears it -- but the false measurement should not stand as the justification. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -4424,10 +4424,12 @@ export class SelfHealingManager extends SelfHealingGitEvidence {
|
||||
try {
|
||||
/*
|
||||
FNXC:SelfHealingReclaim 2026-08-11-09:38:
|
||||
Prune BEFORE attempting removal. A stale worktree registration (recorded path no longer on disk) makes
|
||||
`git worktree remove --force` fail outright, and this sweep used to prune only AFTER the remove — so a
|
||||
dangling registration reliably produced the very failure pruning would have prevented. Observed on this
|
||||
repo at 89 registered worktrees against 20 present on disk.
|
||||
Prune BEFORE attempting removal, not only after. A stale worktree registration (recorded path no longer
|
||||
on disk) makes `git worktree remove --force` fail outright, so pruning only afterwards lets a dangling
|
||||
registration produce the very failure pruning would have prevented — and the retry does not reach the
|
||||
post-remove prune either, because the removal throws first. Ordering fix only; the trailing prune stays
|
||||
for the registration of the worktree just removed. Best-effort: a prune failure must not itself abort
|
||||
cleanup.
|
||||
*/
|
||||
await execAsync("git worktree prune", {
|
||||
cwd: this.options.rootDir,
|
||||
|
||||
Reference in New Issue
Block a user