Tidiness backlog: worktree fleet reconcile (93 registered) and six D:\ root strays

[kyle-sexton]

Durable record of two machine-tidiness items that need a human decision. Both are evidence-gathering-complete enough to act on; neither should be actioned by an agent unattended, because a prior cleanup lane was stopped mid-flight by the repo owner and a prior disk-hygiene session destroyed a deliverable another session needed.

1. Worktree fleet — 93 registered, 27 dirty

The criterion, which matters more than the list

Do not use git merge-base --is-ancestor origin/main <branch> to decide whether a worktree's work has landed. It is structurally broken for this repo and two blind verifiers confirmed it independently. The repo is squash-merge only (allow_squash_merge=true, allow_merge_commit=false, allow_rebase_merge=false), so a squash synthesizes a new single-parent commit and the branch's own commits are never ancestors of main. The criterion is unsatisfiable for exactly the population it selects — it reports "not merged" for every merged branch.

Use instead: a merged-PR record plus a git ls-remote SHA match, so the worktree is known to hold the work that landed rather than later unpushed work on top of it.

An audit using that criterion reached 31 SAFE candidates with a blind verifier mid-run before it was stopped. That list was not persisted and needs re-deriving.

Mandatory carve-outs

• D:/worktrees/_vfy/ — holds sabotage.sh plus a 9-case sab/ fixture matrix, untracked and unversioned, existing nowhere in git. The only item under D:/worktrees/ whose deletion would be unrecoverable. Note the commonly-recorded reason for holding it ("locked, lane active") is wrong — it is not a registered worktree and has no .git, so it cannot hold a lock. It is held for a better reason than the one usually written down.
• D:/worktrees/ccp-2840-fix — roughly 163 lines of uncommitted work orphaned by the fix: isolate test fixtures from the inherited git environment (#2840) #2876 merge: a heredoc-as-data exclusion, a TOPCLEAR distinction for clears nested in a function or subshell that are credited but never run at source time, and a declared vs isolated count split. Same soundness family as the findings that did land, unowned, and not covered by Widen the fixture-isolation credit signal to require GIT_CONFIG #2889 or Extend the fixture-isolation gate's logical-line join to the shell arm, and credit two correct clear idioms it rejects #2893. Salvage into an issue before anyone considers removing it.
• D:/worktrees/ccp-2840 — stale branch fix/2840-fixture-git-env-isolation, uncommitted work.
• D:/worktrees/silent-revert-markers — 335 lines uncommitted against base 5e5a91a48, a superseded pre-merge state of the fix(scripts): read revert subjects and assert the canary's replay attributions #2843 branch. Almost certainly the prototype of what shipped via feat(scripts): assert a recorded silent-revert incident's content came back #2873; confirm before discarding.
• fix/2648-tzdata-degradation — locked, lane active on another machine.
• ccp-2590-engine — merge conflict in progress (UU).
• fix-2618-belt-run-scoped-lifetime — dirty deliberately.
• Any *-main worktree — mislinked gitdir, sole holder of branch main.
• Any worktree whose branch has an open PR.

Five repo-level stashes exist, all from July, all predating current work — inspect before any prune, since a stash cannot be pushed and is invisible to a casual glance.

2. Six D:\ root strays

All six were created 2026-08-16 by session 67f27d86 ("Claude Code Proxy"), which is still running (PID 30028). The synthetic skeleton in them is claude-code-proxy; each lane is a git archive extract at a real commit. That session's own handoff records six PRs open and six verifier agents lost mid-run.

directory	finding	disposition
lane-j-mut-base	both independent checks: no unique data, 139 files ref-reachable in the ODB	owner's handoff calls it disposable — safe to delete
lane-j-mut-mainbase	same	safe to delete
lane-v157-ext	5 mutant files existed nowhere else; now captured durably (see below)	recoverable — prefer holding until PR #157 has a verdict
lane-v159-mut	no unique data, 139/139 in ODB	hold until PR #159 verified
lane-v159-repro	no unique data, 0 archive members missing from ODB	hold until PR #159 verified
spike	operator deliverable	do not delete

Two things worth knowing before any hygiene pass touches these:

• D:\spike\phase2-spike\venv was already destroyed once by an earlier disk-hygiene session and had to be rebuilt. The owning session's handoff explicitly forbids deleting it.
• The owning session tried to clean up lane-j-mut-* itself and the drive-root guard hook blocked it. The "abandoned artifact" appearance is blocked self-cleanup, not neglect — worth considering when tuning that guard, since it currently prevents sessions from tidying their own drive-root scratch.

lane-v157-ext's unique delta is captured at claude-code-proxy/.work/lane-v157-ext-mutant-diffs-capture.md, verified to round-trip: each patch applied to a fresh m0 base copy and cmp'd against the mutant, 5/5, then the fenced blocks re-extracted and confirmed byte-identical to those patches. Note one correction recorded there — m1 is not a one-line edit; it relocates a call block roughly 24 lines earlier.

Why this is filed rather than done

Removal is irreversible and this machine's history shows tidy-ups destroying live work twice. The evidence is assembled so the decision is a single pass rather than an investigation.

[kyle-sexton]

Adding two strays to this issue's inventory, both created and then only half-removed by the canary-lane session that ran 2026-08-17 through 2026-08-21. Recording them here so they are not knowledge that dies with that session.

Two deregistered worktree directories

git worktree remove deregistered both from the worktree list but failed to delete the directory, with error: failed to delete '<path>': Permission denied — a Windows file handle still held them at the time. The result is the exact shape this issue is about: a directory on D:\ that no longer appears in git worktree list, so a fleet audit keyed on the registry will not see it.

directory	branch	state
D:\worktrees\silent-revert-prose-fix	docs/2917-canary-prose-figures	clean; HEAD 184dba7c9 = merged head of #2930
D:\worktrees\ccp-2988-workflow-prose	fix/2988-canary-workflow-window-prose	clean; HEAD bd2c6350b = merged head of #3066

Both verified before removal was attempted: no uncommitted changes, no stashes, no ignored files (git status --porcelain --ignored empty), and local HEAD identical to the head sha of the PR that merged it. Both PRs are merged, so no unmerged work is held in either.

They can no longer be removed with git worktree remove — that now reports fatal: '<path>' is not a working tree. Clearing them is a plain directory delete, which is why this is being recorded for a human pass rather than actioned: a prior hygiene session destroyed a live deliverable on this volume, and the Permission denied suggests a process still held a handle, so a delete issued while that handle is live risks a partial delete.

Suggested action, once no process holds them: delete both directories directly, then confirm git worktree list is unchanged (they are already absent from it) — no git worktree prune (93 worktrees are registered and other machines' lanes are live in that list).

Two live worktrees with uncommitted, out-of-scope work

These are registered and dirty, so they are not strays yet — but they are unpushed and will die with the disk.

directory	branch	state
D:\worktrees\ccp-2920-miro-bump	work/2920-miro-changelog (never pushed)	dirty: plugins/miro/.claude-plugin/plugin.json, plugins/miro/CHANGELOG.md
D:\worktrees\ccp-3020-miro-bump	work/3020-miro-changelog (never pushed)	dirty: same two files

Both hold a draft version bump plus a CHANGELOG entry intended to clear changelog-parity-gate on a dependabot miro bump. The ccp-2920 draft is dead — PR #2920 was closed by dependabot on 2026-08-19 and superseded, and its entry names a dependency set that no longer matches. The ccp-3020 draft targets the live superseding PR but was written against the wrong dependency set too and needs re-deriving from that PR's actual diff.

Neither is worth preserving as-is. Both directories are safe to remove with git worktree remove --force once someone accepts losing the drafts, or the drafts can be redone from scratch against the current dependabot PR.

Note on the underlying gate

Any dependabot bump touching plugins/miro/ fails changelog-parity-gate with PUBLISHED VERSION REUSE, because dependabot cannot bump the plugin manifest or add a release entry. That is a recurring block on a bot PR, not a one-off; it may deserve its own issue.

[kyle-sexton]

AI-generated (autonomous triage lane): Claiming this item for triage evaluation this cycle. Will release the claim on completion or handoff.

[kyle-sexton]

This was generated by AI during triage.

Triage outcome: verified, human-gated (confirmed).

Redundancy check: no existing automated worktree-prune or drive-root-stray-cleanup mechanism found in this repo that already covers this scope; the item's own text records that a prior automated attempt at part of this (the lane-j-mut-* self-cleanup) was blocked by a drive-root guard hook, and that the correct merge-detection criterion (git ls-remote SHA match against a merged-PR record, not merge-base --is-ancestor, which is structurally broken for this squash-merge-only repo) has already been derived and verified by two independent checks. Not already implemented — the decision/action itself is still outstanding.

Confirming needs-human: the item's own "Why this is filed rather than done" section states removal is irreversible and this machine's history already shows two destructive incidents (a stopped mid-flight cleanup lane, a disk-hygiene session that destroyed a live deliverable). This is a genuine capability/trust-boundary block (irreversible action, prior harm on this exact class of operation), not an open design question with a safe reversible default — so it does not qualify for decision-defaulted either. Evidence-gathering is described as complete; what remains is a human go/no-go pass over the assembled candidate list (worktree fleet: re-derive/execute the 31 SAFE candidates using the corrected criterion, respecting the mandatory carve-outs; strays: delete lane-j-mut-mainbase/lane-j-mut-base per owner's own handoff, hold the PR-pending lanes, never touch spike).

Raw-intake marker (priority: needs-triage) cleared; needs-human retained. No work-class label (human-gated items don't carry one) and no brief rewrite — the body already is the complete decision record.

Releasing triage claim.

[kyle-sexton]

This was generated by AI during triage.

Already triaged; not re-triaged. One blocking condition has lapsed

This item was fully triaged on 2026-08-23 (verified, needs-human confirmed, raw marker cleared, claim released). That routing is correct and this pass does not disturb it: removal is irreversible, the volume is a Windows host no lane here can reach, and the machine's history includes two destructive incidents on this exact class of operation. Nothing about that has changed.

What this pass adds is a check the state machine does not cover: whether the item's own hold conditions still hold. Three of them do not.

Three "hold until PR verified" dispositions have resolved

The stray table gates three directories on pull requests in melodic-software/claude-code-proxy. Both are merged:

PR	State	Merged
#157 fix(tests): run the five never-green Pester tests…	merged	2026-08-17T14:49:00Z
#159 fix(ca): restore the FromConfig parameter set…	merged	2026-08-17T15:37:19Z

Applying that to the table:

directory	recorded disposition	status now
lane-j-mut-base	safe to delete	unchanged, safe
lane-j-mut-mainbase	safe to delete	unchanged, safe
lane-v157-ext	hold until #157 has a verdict	verdict reached, hold lapsed
lane-v159-mut	hold until #159 verified	verdict reached, hold lapsed
lane-v159-repro	hold until #159 verified	verdict reached, hold lapsed
spike	operator deliverable, do not delete	unchanged, protected

So the human pass is now five of six clearable and one protected, rather than two clearable and three pending. The spike carve-out is untouched and still absolute, including the venv beneath it that a prior hygiene session already destroyed once.

Worth noting why this was missed rather than stale: the issue was filed at 2026-08-17T14:45:53Z and #157 merged four minutes later, with #159 following inside the hour. The holds were live when written and had lapsed before the first triage pass looked at the item.

Two caveats on acting:

• lane-v157-ext's unique delta is the one thing here that existed nowhere else. The body records it as captured and round-trip verified into claude-code-proxy/.work/lane-v157-ext-mutant-diffs-capture.md. Confirm that capture file is present and readable before deleting that directory, since the merged PR does not itself preserve the mutant fixtures.
• These directories were created by session 67f27d86, recorded as still running (PID 30028). A merged PR says the work landed; it does not say the process released its handles. The two half-removed worktrees in the comment above failed to delete for exactly that reason.

Not checked, and still open

The worktree-fleet half (93 registered, the 31 SAFE candidates needing re-derivation under the corrected git ls-remote SHA-match criterion) is unchanged and unverifiable from here. Same for the five July stashes and the two never-pushed miro-bump worktrees.

Labels: unchanged. needs-human stays. No priority label applied, consistent with the prior pass, since the remaining action is a scheduled human go/no-go rather than queued work.

Triage claim released.

---

Generated by Claude Code