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:
gsxdsm
2026-08-11 02:49:01 -07:00
parent 2b228383d5
commit cb4d94104a

View File

@@ -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,