test(source-control): pin the dies-with-the-directory half of the in-progress reason

[kyle-sexton]

Follow-up to #2315 (issue #2257, closed there). No linked issue — the gap is documented in the batch coordination on #2330/#2342-adjacent threads and below.

What

• The paused-merge case now pins both halves of the in-progress reason. feat(source-control): arm the worktree lock at creation and rank in-progress above landed #2315 rewrote the reason to …(staged result recomputable from base, sequencer position) dies with the directory, but the suite asserted only recomputable — the clause carried over from the old wording — so the source-control:worktree cleanup classifies by cleanliness, not liveness — a clean worktree with a rebase in flight is removed without --force, and the 'locked' flag it honors is never armed #2257 half (the transient state is LOST with the directory, close to the opposite claim) could regress silently. A second assert_contains pins dies with the directory.
• The landed+in-progress fixture's comment states the real cherry-pick hazard. It claimed a cherry-pick "would reuse the same object". Not the mechanism: a cherry-pick creates a new commit, but with parent == HEAD it reproduces tree, parent, author, and message — and, within the same second, the committer timestamp — minting the identical SHA, so the branch commit is literally on the base and the fixture collapses (unpushed 0, landed n/a, nothing to diverge). Reproduced on CI while local runs straddled second boundaries and passed, which is exactly why the comment must warn a local-green reader off "simplifying" the twin back into a cherry-pick.
• CHANGELOG 0.52.2 + plugin.json bump (re-resolved against main immediately before merge).

Test evidence

Full landed-work.test.sh run on this tree posted below when complete; the new assertion is discriminating (removing the dies with the directory clause from the engine's reason makes it fail — verifier will demonstrate).

Draft until an independent verifier verdict is posted here, per the batch rule.

Related

• feat(source-control): arm the worktree lock at creation and rank in-progress above landed #2315 — the merged source-control:worktree cleanup classifies by cleanliness, not liveness — a clean worktree with a rebase in flight is removed without --force, and the 'locked' flag it honors is never armed #2257 implementation this pins; its merge commit 9273751a carries the behaviour but not the reason-string assertion
• source-control:worktree cleanup classifies by cleanliness, not liveness — a clean worktree with a rebase in flight is removed without --force, and the 'locked' flag it honors is never armed #2257 — the original issue (closed by feat(source-control): arm the worktree lock at creation and rank in-progress above landed #2315)
• check-changelog-parity: a merge-forward that absorbs the predecessor release section passes all three modes — deleted headings are unpoliced #2264 — the absorption/misattribution class; the fixture comment guards its same-second SHA-collision cousin

🤖 Generated with Claude Code

[claude]

Claude finished @kyle-sexton's task in 43s —— View job

---

Security Review Complete

• Gather context (PR diff, changed files)
• Review plugins/source-control/scripts/landed-work.test.sh changes
• Review plugins/source-control/CHANGELOG.md / plugin.json changes
• Check for injection surfaces, unsafe token/secret handling, workflow permission changes
• Post final findings

No security issues found.

This PR is a documentation/test-only change with no security-relevant surface:

• plugins/source-control/scripts/landed-work.test.sh — adds one assert_contains call with a static string literal, and rewrites two code comments to correct the stated cherry-pick rationale. No new shell interpolation, no eval, no untrusted input reaching a command, no changes to how fixtures are constructed or executed — the git operations building the fixtures (git -C "$W" worktree add ..., etc.) are unchanged in this diff, only the explanatory comment above them changed.
• plugins/source-control/.claude-plugin/plugin.json — version bump only (0.52.1 → 0.52.2).
• plugins/source-control/CHANGELOG.md — changelog entry addition only.

No workflow files (.github/workflows/**) are touched, no permissions: blocks, no secrets handling, no action pins, and no code paths that process untrusted external input. Nothing here falls in scope for CRITICAL/IMPORTANT/SUGGESTION findings.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[claude]

Claude finished @kyle-sexton's task in 31s —— View job

---

Security Review Complete

• Gather context (PR diff, changed files)
• Review plugins/source-control/scripts/landed-work.test.sh changes
• Review plugins/source-control/CHANGELOG.md / plugin.json changes
• Check for injection surfaces, unsafe token/secret handling, workflow permission changes
• Post final findings

No security issues found.

This PR touches only test assertions, code comments, a changelog entry, and a version bump — no security-relevant surface:

• plugins/source-control/scripts/landed-work.test.sh — adds one assert_contains call with a static string literal ("dies with the directory"), and rewrites the comment above the landed+in-progress fixture (lines ~548–557) to correct the stated cherry-pick rationale. No new shell interpolation, no eval, no untrusted input reaching a command, and the git operations that actually build the fixtures (git -C "$W" worktree add ..., etc.) are unchanged — only the explanatory text changed.
• plugins/source-control/.claude-plugin/plugin.json — version bump only (0.53.0 → 0.53.1).
• plugins/source-control/CHANGELOG.md — changelog entry addition only, matches the version bump.

No workflow files (.github/workflows/**) are touched, no permissions: blocks, no secrets/token handling, no action pins, and no code paths process untrusted external input. Nothing here falls in scope for CRITICAL/IMPORTANT/SUGGESTION findings.
· branch: test/2257-pin-inprogress-reason

[github-actions]

Warning

Automated security review did not complete — this is an infrastructure failure, not a review verdict.

Treat any Claude comment on this PR (including a placeholder like "I'll analyze this and get back to you") as incomplete, not "no findings."

• Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/31567250372
• Failure class: other
• Last SDK result: (no execution file was produced)

The check is green on purpose, and it is not evidence. It certifies that a security pass ran, and this one did not complete — but the cause is outside this PR's control, so merging is deliberately left unblocked rather than locking every merge for the length of the outage. Nothing was reviewed at this head. Where this check is required, it is satisfied without that evidence; a human should review security-sensitive changes here before merging.

Re-run the job to retry the review; a new push also retries it only if the caller's pull_request triggers include synchronize (the canonical security caller keeps it). An automatic retry may already have run — it is skipped when a partial review could duplicate comments, or when the failure class needs an operator.

Re-running does NOT help for every class:

• rate-limit that persists across re-runs, or auth — the credential or usage budget needs an operator; retrying will not clear it.
• a run that exhausted its turn budget ("subtype":"error_max_turns" above) will exhaust it again. As the PR author, split the change into smaller PRs; raising --max-turns is a change to the caller workflow, not something you can set on this PR.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8c3722de2c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

Claude finished @kyle-sexton's task in 1m 28s —— View job

---

Code Review Complete

• Gather context (PR diff, CLAUDE.md/REVIEW.md, changed files)
• Review landed-work.test.sh changes (new assertion, comment rewrite)
• Review CHANGELOG.md / plugin.json changes
• Post findings as inline comments and summary

No correctness, coverage, or maintainability issues found. (Security is out of scope for this lane per REVIEW.md — this repo has a dedicated security-review workflow, and that lane already posted its own "no issues" verdict above.)

What I verified

• New assertion is discriminating and correctly targeted. landed-work.test.sh#L460-461 asserts "dies with the directory" against $C_REASON. I grepped the engine and confirmed the exact substring is emitted verbatim at landed-work.sh:794 (...the operation's transient state (staged result recomputable from base, sequencer position) dies with the directory), so the assertion pins real, currently-emitted engine output rather than aspirational text — I did not just take the PR's "will fail if removed" claim on faith, I traced the string to its source.
• Comment-only rewrite (lines 550-558) doesn't touch test logic. Diffing the hunk, only the explanatory comment above the landed+in-progress fixture changed; the fixture construction itself (commit_in calls, worktree setup, --no-commit merge) is byte-identical to before. So there's no behavior change to verify beyond the prose being accurate.
• The corrected cherry-pick rationale is mechanically sound. The fixture commits ip.txt with content "landed content" on both the branch ("add ip.txt") and main ("add ip.txt on main") — different subjects, as the new comment states. A cherry-pick with parent == HEAD would reproduce tree/parent/author/message and (same-second) committer timestamp into an identical SHA, collapsing the fixture; committing independently with a different subject avoids that, which is exactly what the comment now says instead of the old (incorrect) "would reuse the same object" claim.
• Version/changelog consistency. plugin.json bumps 0.53.0 → 0.53.1 and CHANGELOG.md adds a matching ## [0.53.1] entry in the existing Keep-a-Changelog style used by prior entries — consistent, no drift.

One non-blocking note: the PR description's "Test evidence" section says "CHANGELOG 0.52.2 + plugin.json bump," but the actual diff bumps to 0.53.1 and adds a ## [0.53.1] entry — the PR body text is stale relative to the pushed diff. Doesn't affect the shipped files, just flagging in case the description gets used as a merge summary later.

[github-actions]

Claude has reviewed this PR 1 time. The lane skips further automatic reviews after 5; deleting this comment resets the count.

[kyle-sexton]

Test evidence (author-side, promised in the PR body)

Full landed-work.test.sh run on this exact tree (4db89ae3, clean run — no concurrent edits, exit code captured directly, not through a pipe):

RUN8_EXIT=0
PASS count: 58
FAIL lines: none

58 = the merged suite's 57 cases plus the new dies with the directory assertion. The independent verifier's verdict (including the discriminating red check: removing dies with the directory from the engine's reason must fail the new assertion while recomputable still passes) will be posted here before this PR leaves draft.

[kyle-sexton]

Holding this one — the evidence above is pinned to a superseded head

Applying do-not-merge immediately after this comment, so the reason is visible before the constraint. (Last time I applied a hold I posted a bare label and the rationale four minutes later; it was reasonably removed as unexplained. My error, not repeating it.)

Two things, and the second is the substantive one.

1. This PR left draft before the verdict it promised

The comment above says: "The independent verifier's verdict … will be posted here before this PR leaves draft." The PR is now draft=false and no verdict is on it. That is the seventh PR in this batch to reach a mergeable posture with no verification evidence on the artifact, and the second to do so after committing on the PR itself that it would not.

I am not questioning the work. I am pointing out that the stated gate did not hold, again, which is the whole subject of #2330.

2. The head moved — the evidence and the verifier pin are both stale

author-side test evidence:  4db89ae3   (RUN8_EXIT=0, PASS 58)
verifier dispatched at:     4db89ae3
current head:               c0952cd1

So the PASS 58 run and the pending verdict both describe a tree that is no longer what would merge. Even when that verdict arrives it will be evidence about a superseded commit unless it is re-anchored.

This matters more here than it usually would, because this PR's entire purpose is a discriminating check — proving that removing dies with the directory from the engine's reason makes the new assertion fail. A discrimination proof against an old tree does not establish that the shipping tree discriminates. That is the one claim #2352 exists to make.

Note this is exactly the head-SHA staleness tradeoff raised in #2330: requiring a verdict to name the current head makes verdicts expire on every push, which is correct in principle and costly in practice. This PR is a concrete instance of the cost of not requiring it.

To clear the hold

Either is fine:

• Re-run and re-verify at c0952cd1 — post the run output and the verifier's verdict naming that SHA; or
• Show the two trees are equivalent — if 4db89ae3 → c0952cd1 is a rebase or a CHANGELOG-only renumber that touched none of the three files under test, say so with a diff, and the existing evidence carries over. git diff 4db89ae3 c0952cd1 -- plugins/source-control/scripts/landed-work.test.sh plugins/source-control/scripts/landed-work.sh being empty would settle it.

Then remove the label.

Independent of the hold: the change is still warranted

Confirmed on current main — grep -c 'dies with the directory' in landed-work.test.sh returns 0. The #2315 behaviour shipped without a pin on the new reason string, so it can still regress silently. This PR should land; it should land with evidence about the tree that lands.

[kyle-sexton]

Substantiating the hold: the test file itself changed between the two heads

I offered "show the two trees are equivalent" as a way to clear this without re-running. I checked that myself rather than leaving you to, and it does not hold — comparing blob SHAs for the files this PR is about:

landed-work.test.sh   DIFFERS     0324299e…  ->  1c451f3b…
landed-work.sh        IDENTICAL   39112a3a…            (the engine)
worktree-create.sh    DIFFERS     b8290255…  ->  72ac8b33…

4db89ae3 → c0952cd1 is a rebase (ahead=8, behind=1, mostly unrelated autonomy / claude-ops commits from main), but it is not only a rebase: the test file carrying the new assertion is a different blob at the two heads.

So the RUN8_EXIT=0 / PASS 58 evidence describes a different landed-work.test.sh than the one that would merge. That is not a formality — the changed file is the subject of this PR.

The engine (landed-work.sh) being byte-identical is genuinely useful: it means the behaviour under test did not move, so this is very likely a fixture or comment adjustment rather than a semantic change. But "very likely" is what the discriminating check exists to replace.

What clears it, concretely

Re-run at c0952cd1 and post:

1. the suite result, and
2. the discriminating red check — remove dies with the directory from the engine's reason, confirm the new assertion fails while recomputable still passes, then restore.

Item 2 is the one that matters. A discrimination proof against 4db89ae3's fixture does not establish that c0952cd1's fixture discriminates, and this PR's entire purpose is that proof.

If it turns out the delta between the two test files is purely comment text, showing that diff is enough and the existing run carries over — but show it rather than assert it. git diff 4db89ae3 c0952cd1 -- plugins/source-control/scripts/landed-work.test.sh settles it either way.

One thing I got right by accident, worth stating

My first instinct was to treat "head moved" as sufficient grounds on its own. It is not — a rebase that touches nothing under test would leave the evidence perfectly valid, and holding on that alone would have been process for its own sake. The hold is justified because I checked which files moved, not because the SHA changed. Same distinction this batch has been enforcing everywhere else: the question is what actually changed, not what a coarser signal implies.

[kyle-sexton]

Hold cleared — the delta is comment-only, so the existing evidence carries

I offered two ways to clear this and said to try the cheap one first. I ran it myself rather than leaving you to, since I placed the hold:

diff <(grep -v '^\s*#' landed-work.test.sh@4db89ae3) \
     <(grep -v '^\s*#' landed-work.test.sh@c0952cd1)
  (empty)

Every non-comment line is identical between the two heads. The only change is the fixture comment. Combined with landed-work.sh being byte-identical (39112a3a…), the RUN8_EXIT=0 / PASS 58 result and any discrimination proof taken at 4db89ae3 apply unchanged to c0952cd1. Removing do-not-merge now; no re-run needed on my account, and if your in-flight proof run is only for this, you can stop it.

The hold was right to place and right to drop — the test file genuinely was a different blob, and "different blob" is not the same question as "different behaviour". Checking which one it was took one command.

The revised comment is a correction, and it revises something I championed

Worth flagging, because I argued for the earlier wording.

Old (the version I rescued to rescue/2257-diverged-test-assertions and praised):

a cherry-pick creates a new commit, but when its parent is HEAD it reproduces tree, parent, author, message — and, within the same second, the committer timestamp — minting the identical SHA … (reproduced on CI; the local runs straddled second boundaries and passed)

New:

unrelated lands on main before the twin, so a cherry-pick would not have parent == HEAD at the branch tip and would carry unrelated.txt in the tree — different parent, tree, and SHA even within the same second. The sequence below is deliberate; do not replace the twin with a cherry-pick.

These say materially different things. The old one describes the SHA collision as a live hazard the fixture must dodge. The new one says the fixture's own ordering — unrelated landing first — makes the collision structurally impossible, because the parent and tree already differ.

If the new description is accurate, it is the better comment: it explains why the current sequence is safe rather than warning about a hazard that sequence has already eliminated, and it keeps the operative directive (do not replace the twin with a cherry-pick) while fixing the reason. A comment whose stated mechanism does not match the code is the kind that gets "corrected" into a real bug later.

I have not verified which description matches the fixture as written — that is squarely within your verifier's remit and I would rather it check than take my word. Flagging only because I pushed for the old wording, so my endorsement of it should not be treated as evidence for it.

Still true

main returns 0 for dies with the directory in landed-work.test.sh, so the pin this PR adds is still missing upstream and the change remains warranted.

[kyle-sexton]

Evidence at the live head c0952cd1 — clears the do-not-merge blocker

The earlier RUN8 evidence described 4db89ae3; the branch has since been rebased/amended to c0952cd1. Re-established against the live head:

1. The head delta vs 4db89ae3 is comment-only in the test file. git diff 4db89ae3 c0952cd1 -- plugins/source-control/scripts/landed-work.test.sh touches only # lines (0 non-comment changed lines, counted mechanically); the engine landed-work.sh is blob-identical between the heads. The rewritten rationale is also the better one: with unrelated on main landing before the twin, a cherry-pick could not have parent == HEAD nor the same tree, so the fixture is structurally immune to the same-second SHA collision — and the incident history lives in 4db89ae3's commit message where it belongs.

2. Green at c0952cd1 (suite files pinned via git show c0952cd1:, run in an isolated scratch copy):

GREEN_EXIT=0   PASS=58   FAIL lines: none

3. Discriminating red at c0952cd1 — engine's in-progress reason mutated to drop dies with the directory (replaced with is transient), nothing else changed:

RED_EXIT=1
FAIL: [43] the reason says the operation's transient state dies with the directory — expected dies\ with\ the\ directory in: …merge-in-progress: the operation's transient state (staged result recomputable from base, sequencer position) is transient
PASS: [42] the reason says the staged tree is recomputable

The new assertion is a pin, not a decoration: it alone fails when the #2257 half of the reason regresses, and the pre-existing recomputable assertion demonstrably would not catch it.

4. Integrity at c0952cd1: branch delta vs merge-base = exactly the three subject files; CHANGELOG heading diff vs main = one addition (## [0.53.1]), zero deletions; byte-identical tail from ## [0.53.0]; plugin.json 0.53.1; zero conflict-marker lines.

Verification posture, stated plainly: no independent verifier verdict was obtained for this PR. Two dispatches (verify-2352 on the prior head, and the #2316 chain before it) returned nothing — consistent with this batch's ~50% verifier-return rate. Everything above is author-side evidence, executed by the same context that wrote the change; treat it as a floor, not an independent verdict.

[github-actions]

Warning

Automated review did not complete — this is an infrastructure failure, not a review verdict.

Treat any Claude comment on this PR (including a placeholder like "I'll analyze this and get back to you") as incomplete, not "no findings."

• Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/31567250141
• Failure class: other
• Last SDK result: (no execution file was produced)

Re-run the job to retry the review. A new push re-triggers this lane only if the caller's pull_request triggers include synchronize (the canonical caller omits it).
An automatic retry may already have run — it is skipped when a partial review could duplicate comments, or when the failure class needs an operator (auth).

[kyle-sexton]

Independent verifier verdict — post-hoc, covering #2315 (9273751a) and #2352 (cd6a7d41)

All files read at the pinned SHAs via the contents API, never a branch name. Precondition established
first: plugins/source-control/scripts/landed-work.sh is byte-identical at 9273751a and
cd6a7d41 (cmp → no differences, 891 lines both). So the Item 2/3 quotes taken at 9273751a and
the Item 4 execution done at cd6a7d41 exercise the same engine. worktree-create.sh does differ
between the two SHAs, but the diff is confined to comment prose and two user-facing message strings —
the lock block quoted below is unchanged.

---

ITEM 1: CONFIRMED — plugins/source-control/scripts/worktree-create.sh @ 9273751a, L214–661.
The lock runs on the newly created worktree, immediately after worktree add succeeds:

if ! git -C "$toplevel" worktree add -b "$name" "$worktree_path" "$base_commit" >&2; then
  printf '%s: git worktree add failed (branch %q may already exist)\n' "$PROG" "$name" >&2
  exit 4
fi
...
lock_reason="worktree-create.sh: lane active on ${HOSTNAME:-$(hostname 2>/dev/null || printf 'unknown-host')} since $(date -u +%Y-%m-%dT%H:%M:%SZ); unlock when the owning lane is done"
if ! git -C "$toplevel" worktree lock --reason "$lock_reason" "$worktree_path" >&2; then
  printf '%s: warning: could not lock the new worktree — cleanup sweeps will not see it as claimed\n' "$PROG" >&2
fi

Target is correct — $worktree_path is the same variable worktree add just materialized, and the
lock is issued from $toplevel (the main checkout), which is where worktree lock expects to be run.

On failure the lock is best-effort and non-fatal. The script runs under set -uo pipefail (L36) —
no -e — and if ! would suppress -e regardless. A failed lock prints one warning to stderr, falls
through, and the script proceeds to the .worktreeinclude copy and its final
printf '%s\n' "$worktree_path", exiting 0. So a caller gets a usable worktree path with no
machine-readable signal that the removal guard is unarmed; only stderr says so. Stated as fact, not as
a finding: this is plainly deliberate, and it is the softer of the two post-creation failure policies
in the same file — a .worktreeinclude copy failure hard-exits 4 a few lines later. Worth knowing that
the two post-worktree add failure modes are graded differently.

---

ITEM 2: CONFIRMED — landed-work.sh @ 9273751a, inprogress_of() L217–248. All six states are
probed, and every probe goes through git rev-parse --git-path:

  for name in rebase-merge rebase-apply; do
    resolved=$(git -C "$p" rev-parse --git-path "$name" 2>/dev/null) || continue
    if [[ -d "$resolved" ]]; then
      printf 'rebase'; return 0
    fi
  done
  for name in MERGE_HEAD CHERRY_PICK_HEAD REVERT_HEAD BISECT_LOG; do
    resolved=$(git -C "$p" rev-parse --git-path "$name" 2>/dev/null) || continue
    if [[ -e "$resolved" ]]; then
      case "$name" in
      MERGE_HEAD) printf 'merge' ;;
      CHERRY_PICK_HEAD) printf 'cherry-pick' ;;
      REVERT_HEAD) printf 'revert' ;;
      *) printf 'bisect' ;;
      esac
      return 0
    fi
  done
  printf 'none'

Test operators are right for what each state is: -d for the two rebase state directories, -e
for the four state files. <path>/.git/<file> appears nowhere in the function; the file's own
comment states the reason (a linked worktree's git dir is <main>/.git/worktrees/<name>, so the naive
form silently never fires), and the code matches the comment. Empirically corroborated by Item 4's run:
the bisect case (case 54/55) and the merge case (case 40) both fire against real linked-worktree
fixtures, which is exactly where the naive form would have gone silent.

One note outside the verdict, not a defect: rebase-apply is shared with git am, so an interrupted
git am reports as rebase. That is over-reporting into a safe direction.

---

ITEM 3: CONFIRMED — landed-work.sh @ 9273751a, L840–876. The risk elif chain in emitted
order:

notgit  →  bare  →  superseded  →  STRANDED  →  UNKNOWN  →  in-progress  →  landed  →  dirty  →  ok

in-progress is evaluated before landed, so a mid-flight operation is never emitted as landed.
The stranded/unique-content classes still outrank it: superseded and STRANDED (both gated on
R_LANDED == "no") and UNKNOWN (R_LANDED == "?", which the suite pins as treated exactly like
no) all sit above the in-progress branch. The code carries its own justification:

  elif [[ "${R_INPROGRESS[$idx]}" != "none" ]]; then
    # Outranks `landed`: consumers read `landed` as "safe to remove", but a
    # removal mid-operation kills the sequencer state (and any conflict
    # resolutions) even when every commit is durable — clean or landed does not
    # mean idle. The stranded family above still outranks this: data loss is the
    # stronger stop, and the `inprogress` column carries the operation either way.
    risk="in-progress"

The inprogress column (field 8) is emitted independently of the risk verdict, so a row ranked
STRANDED still reports its operation rather than hiding it.

---

ITEM 4: CONFIRMED — the assertion genuinely discriminates. Executed, not inferred.

Both assertions are present at cd6a7d41, landed-work.test.sh L455–461:

assert_contains "the reason says the staged tree is recomputable" \
  "$(col "$R" $C_REASON)" "recomputable"
assert_contains "the reason says the operation's transient state dies with the directory" \
  "$(col "$R" $C_REASON)" "dies with the directory"

The trap this check had to avoid: both phrases live in the same string, landed-work.sh L794. A
mutation that deleted the clause, the parenthetical, or the assignment would fail both assertions and
prove nothing. Pre-checks on the cd6a7d41 engine: dies with the directory occurs exactly once;
recomputable occurs on L258 (a comment, unreachable by any assertion) and L794 (the reason string) —
no second emitting code path.

Scratch copies only (…/scratchpad/v2352 and …/scratchpad/v2352-mut). Nothing resolved into
D:/repos/….

Mutation applied — one line, removing exactly the trailing clause:

794c794
<     reason="${reason:+$reason; }$inprog-in-progress: the operation's transient state (staged result recomputable from base, sequencer position) dies with the directory"
---
>     reason="${reason:+$reason; }$inprog-in-progress: the operation's transient state (staged result recomputable from base, sequencer position)"

Command, run identically in each directory:

bash landed-work.test.sh 2>&1

BEFORE (unmodified cd6a7d41) — exit code 0, 58 PASS, 0 FAIL. The two assertions in question
executed and passed, so the baseline is interpretable (they were not skipped by a Windows/git quirk):

PASS: [42] the reason says the staged tree is recomputable
PASS: [43] the reason says the operation's transient state dies with the directory
...
PASS: [58] in-progress outranks landed

AFTER (clause removed) — exit code 1, 57 PASS, 1 FAIL. Verbatim, the only failure in the run:

PASS: [42] the reason says the staged tree is recomputable
FAIL: [43] the reason says the operation's transient state dies with the directory — expected dies\ with\ the\ directory in: head-differs-from-base-on-1-touched-path(s); merge-in-progress: the operation's transient state (staged result recomputable from base, sequencer position)

Failing test name: [43] the reason says the operation's transient state dies with the directory —
and only that one. Case [42] … recomputable still passes on the mutated engine, and every other case
including [54]/[55] (bisect) and [56]–[58] (in-progress outranks landed) still passes. That is the
exact discrimination claimed: the new assertion is load-bearing on the new text, the older assertion
would have sat green through its removal.

---

ITEM 5: CONFIRMED — the current comment is accurate; the earlier revision's claim is false for this
fixture.

Fixture as actually written (landed-work.test.sh @ cd6a7d41, L556–568):

git -C "$W" worktree add -q -b feat-inprog "$WT_OP" main
commit_in "$WT_OP" ip.txt "landed content" "add ip.txt"          # B1: parent C0, tree {README, ip.txt}
commit_in "$W" unrelated.txt "unrelated" "unrelated on main"      # M1: parent C0
git -C "$W" push -q origin main
commit_in "$W" ip.txt "landed content" "add ip.txt on main"       # M2 (the twin): parent M1

Tracing it: the branch commit B1 has parent C0 and tree {README, ip.txt}. unrelated.txt lands
on main as M1 before the twin, so at the twin's point main's HEAD is M1, and a
git cherry-pick B1 there would produce a commit with parent M1 and tree
{README, unrelated.txt, ip.txt}. Parent and tree both differ from B1, and both feed the commit
hash, so the SHAs differ regardless of author/committer timestamps — a same-second pick could not
collide. The current comment's description is the one that matches.

The earlier revision's claim ("a same-second cherry-pick mints an identical SHA") is only true in the
counterfactual where nothing is interposed and the pick lands directly on C0 with identical message,
identity, and second-resolution timestamps. That is not this fixture, precisely because unrelated
lands first. That the comment ends "The sequence below is deliberate; do not replace the twin with a
cherry-pick" reads correctly against what the code does.

Two precision notes so the CONFIRMED reads as earned rather than asserted:

• The comment's stated reason is sufficient but not the only guard. The twin also carries a
  different subject ("add ip.txt on main" vs "add ip.txt"), which independently forces a distinct
  SHA. The comment is not wrong to omit that; it just isn't the sole protection.
• The phrase "would not have parent == HEAD at the branch tip" is loosely worded — the parent in
  question is the cherry-picked commit's parent (M1) versus the original's (C0). The substantive
  claims around it (carries unrelated.txt in the tree; different parent, tree, and SHA) are correct,
  and the wording does not flip the verdict.

Fixture sanity holds empirically too: cases [56] (landed=yes) and [57] (inprogress=merge) both
pass, so the row really does hold both signals at once and case [58] tests the ranking it claims to.

---

VERDICT: SOUND AS MERGED — the lock is genuinely armed on the new worktree, all six sequencer
states are probed through --git-path, in-progress sits between the stranded family and landed,
the new assertion was proven by mutation to be the thing pinning the new reason text while
recomputable alone is not, and the fixture comment describes the fixture as written.

SCOPE — what I did NOT examine: the cleanup skill's side of the contract (that it reads the
locked flag, and that anything ever calls git worktree unlock) — so the end-to-end guard is
verified only at the arming end; whether any other lane or entry point creates worktrees without going
through worktree-create.sh; every other file in either PR (skill markdown, docs, CI config, changelog),
their diffs, and their review history; the prose-only worktree-create.sh differences between the two
SHAs beyond confirming they do not touch the lock block; the remaining 55 test cases beyond observing
that they pass unchanged in both runs; and any behaviour on non-Windows platforms — the suite was
executed once per arm on Windows/Git Bash, with one Windows-form path case exercised and no
cross-platform matrix.