Merge preview revives a closed child; doctor misses an absent locked worktree

Start with dist/cli.js: read changeForLink (around line 27418) and the repair path (around line 27898) for how missing open PRs are planned, then inspect the worktree parser (26754–26788) and doctor (28128–28155). Reproduce the two cases with the described disposable repositories and fake gh response; done means closed children are not silently planned as new PRs, and doctor and merge give actionable diagnostics for a registered absent locked worktree.

Two behaviors reproduced with the installed @kitlangton/[email protected] CLI (dist/cli.js SHA-256 48656d77524cf36b1a6e3f42c56443bf6c7f7743bf26e99d96773524d5ade899), invoked through Bun. These observations use real disposable local Git repositories/worktrees and a deterministic read-only fake gh response. No real GitHub request, remote operation, --apply, PR creation or rebase was performed. This is actual CLI behavior under that isolated input boundary, not a report of a real PR being reopened.

The fixture has main→A→B with separate commits. Stack v1 state tracks A/PR #101 under main and B/PR #102 under A, each with its factual parent anchor. origin is an owned local bare repository, with origin/main seeded locally. The fake transport permits only the CLI's exact open-PR query:

gh api repos/{owner}/{repo}/pulls?state=open&per_page=100 --paginate --slurp

All other gh calls and all preview Git writes/network commands are rejected; repository files/modes remain unchanged in all three observations below.

1. Closed, unmerged child is planned as a new PR

PR #101/A is OPEN. The fixture's PR #102/B is CLOSED and unmerged, so its fake open-list response omits #102 while the existing Stack link remains. Running stack merge A without --apply exits 0 and includes:

would merge #101 (A)
would reparent B: A -> main
would rebase B onto main
would push B
would create pr for B -> main
next root: B

Desired behavior: an explicitly closed/superseded child should not automatically be planned as a new PR. A closed-child distinction or a clear refusal/manual decision would avoid accidental revival. The open-only response is sufficient for the observed plan but does not establish whether B is closed, merged, missing or inaccessible; the current preview does not request the recorded child's state.

Source inspection agrees with the observation: changeForLink (dist/cli.js:27418) selects from the open list, and the repair path can emit createPull when that list lacks the tracked child (:27898). This finding concerns the dry-run plan; apply behavior was deliberately not exercised.

2. Doctor does not diagnose a registered absent locked worktree

In a separate fixture, both PRs are OPEN. Git creates a B worktree, locks it with a reason, and its directory is then removed while the real common-Git registration and lock remain. Recorded git worktree list --porcelain -z still contains the absent locked path.

stack doctor exits 0 and reports:

ok current branch: main
ok worktree clean
ok trunk branch: main
ok open PRs visible: 2
ok stack metadata: 2 link(s)
ok undo journal: none

It makes no worktree-list request and gives no missing/locked-worktree warning. In the same fixture, stack merge A exits 1:

git status --short failed (1)
PlatformError: NotFound: FileSystem.access (<fixture>/missing-locked/locked-B)

Desired behavior: doctor should identify the registered absent locked path, and merge should provide an actionable worktree-specific diagnostic before attempting to inspect it. No automatic prune, unlock or branch repair is requested. The current parser handles prunable but does not retain locked (dist/cli.js:26754–26788); doctor does not enumerate worktrees (:28128–28155).

Qualified evidence and remaining limit

The closed-child preview, missing-locked doctor and missing-locked merge observations each have zero denied process requests, zero repository file/mode drift and no timeout. Their full stdout/stderr, actual child arguments, Stack link inputs, fake open-list inputs and raw worktree porcelain are preserved. No conclusion about interruption recovery or lock-aware apply safety is made.

An initial surviving-locked control read the real B worktree and its status, but then failed a separate head-repository mapping guard: PR #102 head is fixture/stack-regression, but no local git remote points to that repository. That original control remains unqualified and preserved.

A separate fresh one-case control, with both PRs OPEN and PR #102's supported head.repo: null input, completed stack merge A with exit 0. It read the real surviving locked-B status and planned would retarget #102 (B) to main before merge, with no create-PR action. The null-head branch selects the owned local origin; this is not a normally attributed remote GitHub PR. There were zero denied calls, repository file/mode drift, input drift or timeouts. The three earlier observations were not rerun or replaced. Root verified no remaining owned child processes and removed both exact marked temporary roots after preserving the evidence. This confirms a complete dry-run control for a present locked path; it does not establish lock-aware apply safety or real GitHub behavior.