fix(source-control): reap a torn-down worktree's project-scope plugin install records

[kyle-sexton]

Closes #3113

Summary

Removing a git worktree left behind every project-scope plugin install record that pointed into it, forever. Claude Code keys a project-scope install to a literal projectPath in ~/.claude/plugins/installed_plugins.json, and nothing reaps that record when the path goes away — so a directory tree this plugin's own babysit_worktree_root option calls ephemeral accumulates permanent state.

Measured on the author's machine: 108 project-scope records across 8 marketplaces, all 108 naming one worktree directory that no longer exists, and 1 distinct projectPath machine-wide — every project-scope record on that machine an orphan. D:\worktrees is exactly this plugin's configured worktree_root, so these are not configuration drift; they are normal lifecycle garbage from a directory this plugin itself created and destroyed. The worktree skill had zero awareness of install records: the cleanup path removed the directory and stopped.

Fix

cleanup reaps at teardown. New Step 4b runs scripts/reap-project-plugin-records.sh from inside the candidate, after the stranded-work and carried-ignored-file guards clear and before git worktree remove. It is ordered last of the three because it is the only one that cannot be undone: it must not fire for a worktree the guards are about to save.

The boundary is the teardown event, never path liveness. A project-scope record for a live repository on an unmounted network share or a detached external volume is indistinguishable from a dead worktree to a bare existence check. The helper refuses unless --worktree-path names the directory it is already standing in — the cwd constraint rendered in code rather than in prose, so it structurally cannot act on any other path.

Everything goes through the documented CLI. Enumeration via claude plugin list --json, removal via claude plugin uninstall <id> -s project. Never -s user — the CLI's own failure text for an id with no project record here reads Use --scope user to uninstall, and following that would uninstall the plugin fleet-wide. Never --prune (it reaches into shared auto-installed dependencies). installed_plugins.json is read, never written: it is Claude Code's internal state, not a published contract.

audit Step 2b reports pre-existing orphans and never reaps them (task-4 decision). Records left by worktrees removed before this step existed are unreachable by it, so audit makes them visible in four buckets — live here, live elsewhere, candidate orphan, other project records (information only, no remedy). Reaching a vanished path requires recreating a directory, which is precisely the mechanism most capable of the harm above; the audit emits the commands for the user and stops.

Two hazards found by verification, fixed in commits 2 and 3

Both are the same mistake — inferring deadness from a negative — and the fix's safety rests on them.

1. The worktree root is shared. create places worktrees at <root>/<owner>-<repo>-<slug>, one root serving every repository on the machine, so "under the root and not in this repository's git worktree list" is true of every other repository's live worktree. Registration is scoped to one repository; liveness is not. audit gained the live elsewhere bucket keyed on git -C <path> rev-parse --is-inside-work-tree, plus a precondition that stops the whole step when the resolved root itself does not resolve — the detached-volume case that would otherwise make every path under it qualify on identical evidence.
2. The orphaned-directory candidate was the weak edge. It is the only candidate class with no stranded-work row to read — the engine enumerates strictly from git worktree list, so an unregistered directory produces no row, and the stranded guard's closed-list rule covers an unrecognized value, never an absent one. A live worktree of another repository whose main clone has been moved, deleted, or unmounted still carries its .git file while rev-parse fails, so one negative test called it an empty husk and reaped plus rm -rf'd it. It now must pass all three of not a work tree, no .git entry, and empty — the middle test being load-bearing, and the third the only positive evidence in the set (and what the presentation row's (empty, no git ref) always claimed and never checked). cleanup also gained the unresolvable-root precondition, and Step 2's layout list now names the configured external root where create actually places every worktree.

0.55.0 is a deliberate minor bump: cleanup gains a new side effect on an existing action — additive behaviour, not a repair.

Verification

The load-bearing measurement. claude plugin uninstall <id> -s project has no path flag and resolves strictly against the resolved absolute current directory:

Arm	Result
install -s project in a plain non-git directory	writes a record with projectPath = resolved native absolute cwd (backslash-spelled on Windows). 108 → 111
plugin list --json from two unrelated cwds	identical project-scope record set (same cksum) — enumeration is cwd-independent
uninstall -s project from a different cwd	exit 1, count unchanged. It cannot reach another path's record
uninstall -s project from the recorded directory	exit 0, record removed
directory deleted, then recreated empty at the same path	record outlives the directory; uninstall from the recreated one exits 0 and removes it
no record here	exit 1, no-op — same message as the wrong-path case, and it suggests --scope user

Six arms in throwaway $TEMP directories with the record store read but never written by the probe, plus a full end-to-end run of the shipped helper: 108 → 110 → 111 → refuse (unchanged) → dry-run (unchanged) → 109 → 108, wrong-cwd refusal, other-path record untouched, idempotent zero case. The record store was returned to exactly its 108-record baseline; no real record was touched. Claude Code 2.1.240, re-run unchanged on 2.1.241, Windows/Git Bash. Recorded with its as-of stamp and recheck trigger in skills/worktree/fixtures/README.md; re-runnable as fixtures/project-scope-reap-probe.sh.

Three fresh-context opus verifications, none by the author. Passes 1 and 2 each returned FAIL on the hazards above; commits 2 and 3 are those verdicts acted on. Pass 3 over the final state is running as this is written — any further finding lands as another commit on this branch, and this PR is not to be merged before it reports.

Pass 2's break attempts against audit, none of which got through: live worktree of another repo, bare repo, submodule, plain non-git directory, mounted-but-slow share, unmounted share, detached volume, symlinked/junctioned root, dangling symlink, path-is-a-file.

Test plan

• plugins/source-control/scripts/reap-project-plugin-records.test.sh — 32/32, new. Stubs the claude CLI to reproduce the measured contract; pins the cwd-equality refusal (a refused run makes zero CLI calls), that only this directory's records are removed while another path's survive, that -s user and --prune never appear in any invocation, that a CLI no-op is reported and never escalated, that --dry-run mutates nothing, and that a degrade is visible (exit 3). One case caught a real Windows-only defect: @tsv escapes backslashes and the ${p//\\//} parameter expansion does not replace them, so the matcher silently matched nothing on the only platform where projectPath is backslash-spelled.
• skills/worktree/nesting-invariant-ssot.test.sh — 18/18.
• scripts/validate-plugin-contracts.mjs — clean (48 setup skills, 2805 files).
• shellcheck -x --rcfile .shellcheckrc on all three new .sh — silent.
• scripts/check-changelog-parity.sh --check, check-orphaned-fixtures.sh, check-silent-skips.sh, check-shell-portability.sh, check-skill-portability.sh, check-drive-root-litter.sh, sync-plugin-options-docs.py --check, generate-cheatsheet.mjs --check — all clean.
• CHECK_SKILL_SKIP_MARKDOWNLINT=1 scripts/check-changed-skills.sh origin/main — PASS, 0 errors (2 pre-existing warnings). markdownlint-cli2 — 0 issues.
• Pre-existing on this Windows host, confirmed by stashing the change and re-running against the pristine base: worktree-root-doctor.test.sh fails 9 and worktree-add-containment-gate.test.sh fails 2, both from POSIX-vs-native path form and includeIf gitdir matching. Unrelated to this change.

Related

• Closes fix(source-control): worktree teardown leaves project-scope plugin install records forever #3113 — worktree teardown leaves project-scope plugin install records behind forever.
• Refs fix(claude-ops): remediate the plugins:sync audit findings #3112 — claude-ops:plugins classifies and reports these stale project records instead of routing them to a converge that cannot run. That is the reporting half; this is the half that stops them accumulating at the source. claude-ops deliberately does not reach into another plugin's userConfig to decide what is ephemeral, and does not own the lifecycle — source-control creates the worktree, knows worktree_root, and destroys the directory.
• Refs fix(plugins): correct the unstamped --config reconfiguration claim (#3111) #3115 — open and green, and it owns plugins/source-control/skills/setup/ plus a version bump on this plugin's .claude-plugin/plugin.json and CHANGELOG.md. A rebase conflict on exactly those two files is expected. Resolve by taking the higher version and keeping BOTH CHANGELOG entries — never by dropping either side's. No other file overlaps: this PR never touches skills/setup/.

🤖 Generated with Claude Code

[claude]

Claude finished @kyle-sexton's task in 3m 40s —— View job

---

Claude finished the code review

• Gather context (PR body, changed files)
• Run /review:code-review procedure
• Post findings

Summary

Reviewed the diff against origin/main — the new reap-project-plugin-records.sh/.test.sh, the cleanup.md/audit.md procedure updates, SKILL.md, plugin.json, CHANGELOG.md, and the fixtures. This is an unusually well-substantiated change: the cwd-equality boundary, the never--s user/never---prune rules, and the shared-worktree-root "live elsewhere" classification are all backed by measured probes and a 32-case unit suite, and the second commit already fixed a real hole (shared-root liveness) that an independent verifier caught pre-merge.

One finding posted inline — plugins/source-control/scripts/reap-project-plugin-records.sh:247-262:

The pre-reap enumeration failure (line 201) correctly degrades — warn: + exit 3 — per the script's own "a degrade is reported, not swallowed" principle. The post-reap verification enumeration (line 247) reuses collect_matches but swallows a failure into an empty string (survivors="$(collect_matches)" || survivors=""), so a transient claude plugin list --json/jq hiccup on that second call falls through to ok: every … is gone with exit 0 — reporting a fully-verified reap when the verification pass never actually completed. This is inconsistent with the identical failure mode a few lines earlier and isn't covered by the test suite (which exercises the first enumeration failure via the exit-3 case, but not a failure on the second/verification call).

No other high-signal issues found — the CLI-boundary logic, path normalization (backslash/case/CRLF handling), the ordering of guards before the reap in cleanup.md, and the four-bucket classification in audit.md all held up under review.

[claude]

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

---

Claude finished the security review

• Gather context (PR diff, description, changed files)
• Run /review:security-review per custom instructions
• Post findings

Security review — no issues found

This PR touches genuinely security-relevant surface (new shell scripts that call rm -rf, git worktree remove, and claude plugin uninstall), so I read the full diff rather than skipping. Focus was plugins/source-control/scripts/reap-project-plugin-records.sh (new, blob) and the destructive command sequences it's wired into via context/cleanup.md and context/audit.md.

Checked for, and did not find:

• Command/argument injection — every variable that flows into a claude/git/rm invocation is quoted ("$id", "$worktree_path", "$path" etc.); no eval, no unquoted expansions that could split into extra arguments.
• Path-confusion / TOCTOU on the cwd guard — reap-project-plugin-records.sh resolves both the current directory and --worktree-path via cd ... && pwd -P/pwd -W before comparing (reap-project-plugin-records.sh:96-155), so symlinks and relative-path tricks collapse to the same real path rather than bypassing the equality check.
• Scope escalation — the script structurally never passes -s user or --prune (both would reach far past the current directory's records), and never writes installed_plugins.json directly; every mutation goes through the documented claude plugin uninstall CLI. This matches the intent explained in the PR body and is enforced, not just documented.
• Destructive-path misclassification — the second commit's fix (shared worktree root → live elsewhere bucket in audit.md, plus the is-inside-work-tree gate before cleanup's orphaned-directory rm -rf) closes the hole where another repository's live worktree under the same shared root could be misread as dead and handed a destructive remedy. The remaining rm -rf sites are all gated behind that liveness check plus explicit user confirmation.
• Heredoc/quoting edge cases — the <<EOF … $matches … EOF pattern in the reap script is a single parameter expansion (not re-evaluated shell text), so record IDs containing shell metacharacters can't inject commands there.
• CI/Actions surface — this PR doesn't touch any workflow files, so no pull_request_target/permissions/supply-chain surface to assess.

Nothing here rises to CRITICAL/IMPORTANT/SUGGESTION. The destructive operations (rm -rf, plugin uninstall, worktree removal) are consistently gated behind cwd-equality checks, liveness tests, and &&-chained fail-closed sequences, matching what the PR description claims.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ba17c8f87f

ℹ️ 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".

[github-actions]

Last security-reviewed head: e7c39b0357b0d03ecc49c89d704c95490394dca9. On the next push, the relevance gate compares only the commits since this SHA; delete this comment to force a full re-review.

[github-actions]

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

[claude]

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

---

Security review (/review:security-review)

• Gather context (PR diff since last reviewed head, changed files)
• Run /review:security-review procedure
• Post findings

Skip-gate check: the last security review covered head ba17c8f. This run's relevance window is only the commits pushed since then — one new commit, d1e96a9 ("hold the acting path to the reporting path's evidence bar").

What changed since the last review

d1e96a9 touches only documentation/skill-procedure files — cleanup.md, audit.md, SKILL.md, CHANGELOG.md — no shell script content changed (reap-project-plugin-records.sh and its test file are untouched, already reviewed at ba17c8f).

The change tightens the guard in front of the destructive path, rather than loosening anything:

• The "orphaned directory" classification that gates cleanup's rm -rf (Step 4b) previously required only a single negative test (git -C <path> rev-parse --is-inside-work-tree ≠ true). This commit found and closed a real hole: another repository's live worktree whose main clone was moved/deleted/unmounted also fails that same test while still holding real work — so the old single test could misclassify it as an empty husk and destroy it.
• It now requires all three: not a work tree, no .git entry (file or directory — closing exactly the miss above), and directory actually empty. audit.md gets the matching precondition (stop scanning a worktree root that doesn't resolve, so a detached volume doesn't make every path under it look orphaned).
• The audit's pasted remedy now substitutes a resolved absolute path for the helper script instead of ${CLAUDE_PLUGIN_ROOT} (unset in a user's own shell) — a correctness fix, not a security-relevant one; the &&-chained fail-closed structure and quoting are unchanged.

Result: no security issues found

Reviewed against the same criteria as the prior pass (injection surfaces, scope escalation, destructive-path misclassification, trust boundaries) — this commit only narrows the conditions under which the destructive rm -rf / reap path fires. No new command construction, no new variable interpolation into git/claude/rm invocations, no permission or scope changes. Nothing here rises to CRITICAL/IMPORTANT/SUGGESTION.

[claude]

Claude finished @kyle-sexton's task in 3m 18s —— View job

---

Claude finished the code review

• Gather context (PR body, changed files, prior review comments)
• Run /review:code-review procedure
• Post findings

Summary

Skip-gate check: HEAD has advanced from ba17c8f (last reviewed by this lane) to d1e96a9, so the prior review no longer applies as-is — re-ran the review scoped to what changed since then.

The new commit, d1e96a9 ("hold the acting path to the reporting path's evidence bar"), is documentation-only — CHANGELOG.md, SKILL.md, audit.md, cleanup.md. No shell scripts changed. It tightens cleanup.md's orphaned-directory qualification from one test (rev-parse --is-inside-work-tree) to three (not a work tree, no .git entry, empty), adds a precondition that stops scanning an unresolvable worktree root, and fixes a ${CLAUDE_PLUGIN_ROOT}-in-a-user-pasted-command bug in audit.md's remedy. I checked the new three-test qualification for internal consistency (it correctly closes the exact gap its own commit message describes — a live worktree whose main clone was moved/unmounted still has a .git file even though rev-parse fails on it) and didn't find a correctness problem in the added prose or its example commands.

I also checked whether audit.md's Step 2b candidate orphan bucket (line 56) should have picked up the same third test — it's still only two — but that row's text is untouched by this commit (pre-existing, and the bucket already carries an explicit caveat that two negatives aren't proof of death and requires per-path user confirmation before any remedy runs), so it's out of scope for this incremental pass rather than a new issue.

No new high-signal findings in this commit.

Status of the previously-flagged issue: reap-project-plugin-records.sh:247 — the post-reap verification's survivors="$(collect_matches)" || survivors="" still swallows an enumeration failure into "0 survivors" instead of degrading like the identical pre-reap check at line 201 does — is unchanged by this commit (the script wasn't touched) and was already posted inline by both this lane's prior pass and Codex. Not re-posting a duplicate; it still applies at current HEAD.
· branch fix/3113-worktree-teardown-plugin-records

[claude]

Claude finished @kyle-sexton's task in 4m 35s —— View job

---

Claude finished the code review

• Gather context (PR body, prior reviews, changed files)
• Run /review:code-review procedure (scoped to commit 17621ac, the delta since this lane's last reviewed head d1e96a9)
• Post findings

Summary

Skip-gate check: this lane's last review covered d1e96a9. HEAD has advanced to 17621ac ("unbreak the machine-specific-paths gate and close verification pass 3"), so I reviewed that delta — CHANGELOG.md, reap-project-plugin-records.sh (comments only, no behavior change), SKILL.md, audit.md, cleanup.md, fixtures/README.md.

This commit adds a fourth qualifying test — not a symlink — to the orphaned-directory candidate check, closing a real hole: find <path> -mindepth 1 doesn't descend into a symlinked start point, so a symlink pointing at a busy directory would read as empty and pass the old three-test bar. I checked this fix for internal consistency across cleanup.md, audit.md, SKILL.md, and CHANGELOG.md — the numbering (0–3), the "negatives vs. the one positive" framing, and audit's candidate orphan bucket guidance all line up correctly with the new test.

One finding posted inline — plugins/source-control/skills/worktree/context/cleanup.md:167:

The new test -L "<path>" guard can itself be defeated by a trailing slash on <path> — POSIX pathname resolution follows a symlink-to-directory when the path ends in /, so test -L "link/" reports false even though link is a symlink. Nothing upstream in this doc guarantees the candidate path string is slash-free, and this is exactly the same class of "looks empty/not-a-symlink because of how the test was phrased" gap this commit set out to close for the find-doesn't-descend-symlinks case.

Status of the previously-flagged issue: reap-project-plugin-records.sh:250 — the post-reap verification's survivors="$(collect_matches)" || survivors="" still swallows an enumeration failure into "0 survivors" instead of degrading like the identical pre-reap check at line 201/204 does — is unchanged by this commit (the script's logic wasn't touched, only comments were). Already flagged inline by this lane, Codex, and the security lane on earlier heads; not re-posting a duplicate, but it still applies at current HEAD.

No other issues found in this delta — the CHANGELOG wording matches the code/doc changes, and the symlink-comment edits to the script are comment-only with no functional change.
· branch fix/3113-worktree-teardown-plugin-records

[claude]

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

---

Security review (/review:security-review)

• Gather context (PR diff since last reviewed head, changed files)
• Run /review:security-review procedure
• Post findings

Skip-gate check: the last security review covered head d1e96a9. This run's relevance window is the one new commit pushed since then, 17621ac ("unbreak the machine-specific-paths gate and close verification pass 3").

What changed since the last review

Six files, no new logic paths — this commit tightens an existing guard and clarifies comments; nothing loosens anything:

• reap-project-plugin-records.sh (native_pwd comment, norm_path comment) — comment-only changes, no executable-line diff. They document two edge cases more precisely (an 8.3-short path component, not just a whole-path form; a UNC-path corner of the backslash-squeeze) and explicitly note the cwd guard still confines any action regardless of what the matcher returns. I checked the UNC claim: //server/share/x and /server/share/x could theoretically collide after the squeeze, but no valid Windows path spells the un-prefixed form, and — as the comment says — a false match here can only ever produce a reported no-op, never a wrong-path mutation, because the actual removal is still gated by the separate cwd-equality check earlier in the script. Confirmed, not a new surface.
• cleanup.md / audit.md (orphaned-directory qualification) — adds a fourth test, "not a symlink" (cleanup.md:167, rule explained at cleanup.md:174-177). This closes a real gap: find <path> -mindepth 1 doesn't descend through a symlinked start point, so a symlink to a busy live directory previously reported "empty" and could pass the old three-test bar, while the reap step resolves pwd through the link and would act on the target directory's records. This is a genuine destructive-path hardening (it sits directly in front of rm -rf <path> and the reap script invocation), and I verified it closes the gap it claims to: the new test -L "<path>" runs before the other three and disqualifies the candidate outright. audit.md's parallel confirmation checklist (audit.md:76) picks up the same three checks; the fourth (not-a-work-tree) is already embedded in how a row reaches the candidate orphan bucket in the first place (audit.md:41-44), so no test is silently dropped between the two files.
• CHANGELOG.md, SKILL.md, fixtures/README.md — prose-only propagation of the same three-test → four-test change and a wording fix to the 8.3-short-form example. No behavioral surface.

Result: no security issues found

This commit only narrows the conditions under which the destructive rm -rf / reap path fires, and the one substantive change (the symlink test) is itself a fix for a symlink-following misclassification risk — verified sound rather than just asserted. No new command construction, no new variable interpolation into git/claude/rm invocations, no scope or permission changes.

The pre-existing correctness finding on the post-reap verification swallow (reap-project-plugin-records.sh:247, survivors="$(collect_matches)" || survivors="") is unchanged by this commit — that file's only edits here are comments — and is a reporting-accuracy issue, not a security one, so it's out of scope for this lane (already tracked via the code-review lane and Codex's review).
· branch fix/3113-worktree-teardown-plugin-records

[claude]

Claude finished @kyle-sexton's task in 2m 16s —— View job

---

Security review (/review:security-review)

• Gather context (PR diff since last reviewed head, changed files)
• Run /review:security-review procedure
• Post findings

Skip-gate check: the last security review covered head 17621ac. This run's relevance window is the one new commit pushed since then, e7c39b0 ("an unverified reap must not report a clean one") — the commit responding to this PR's three open review threads.

What changed since the last review

• Threads 1 & 2 (the post-reap verification swallow) — fixed correctly. reap-project-plugin-records.sh:250-268 replaces survivors="$(collect_matches)" || survivors="" with an explicit if ! survivors=...; then branch that prints surviving UNKNOWN, states the pass is UNVERIFIED, reports the reaped/no-op counts, and exits 3 — now symmetric with the pre-reap degrade at line 207. I traced the call site in cleanup.md (Step 4 report language, cleanup.md:263) and the exit-code contract comment (reap-project-plugin-records.sh:41-46) — both now correctly treat exit 3 as covering either enumeration, and the caller never deletes the directory on the strength of an unverified pass. This closes the most dangerous failure mode in the script (false "fully reaped" report used to justify a subsequent rm -rf/git worktree remove).

• Thread 3 (trailing-separator defeats the symlink test) — fixed for the case it measures, but the shown fix is incomplete. cleanup.md:159-190 adds a normalization step ahead of the four orphaned-directory qualifying tests, with the header claiming it strips "every trailing separator." The only code shown is:

  path="${path%/}"        # and again for a Windows-style trailing backslash

  This line strips a trailing / only. The comment says to run it "again" for a trailing \, but no second line is shown, and this file is prose an executing agent follows literally (there is no compiled script backing Step 4b — audit.md:82 just says "check it the way cleanup does"). An agent that copies the one bash line shown, as the surrounding text otherwise encourages, leaves a trailing backslash unstripped. That reopens exactly the hazard this commit exists to close, on the platform this whole PR is measured against (Git Bash/Windows, where dir/Explorer-pasted paths commonly carry a trailing \): a symlink to a busy directory named with a trailing backslash would still read test -L "<path>\" as false and find as empty, sailing through all four tests into rm -rf. It's also untested — the new fixture in reap-project-plugin-records.test.sh only exercises a real symlink with a trailing /, never a trailing \.

  Suggest making the shown snippet actually strip both, e.g. path="${path%[/\\]}" (repeated if multiple trailing separators are possible), rather than leaving the second half as an unexecuted comment — and mirroring the corrected snippet in audit.md's "check it the way cleanup does" pointer.

  Fix this →

Result

One SUGGESTION-level finding (doc-completeness gap in a destructive-path guard's own fix, not an active exploit in shipped script code — the actual executable script, reap-project-plugin-records.sh, is untouched here and was already reviewed clean). No CRITICAL/IMPORTANT findings. The two previously-flagged issues (post-reap swallow, trailing-slash symlink bypass) are both substantively fixed by this commit; the residual gap above is in how completely the trailing-backslash half of the fix is spelled out for the agent that has to execute it, not a reintroduction of the original defect.
· branch fix/3113-worktree-teardown-plugin-records

[claude]

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

---

Claude finished the code review

• Gather context (PR body, prior reviews, changed files)
• Run /review:code-review procedure (scoped to commit e7c39b0, the delta since this lane's last reviewed head 17621ac)
• Post findings

Summary

Skip-gate check: this lane's last review covered 17621ac. HEAD has advanced to e7c39b0 ("an unverified reap must not report a clean one"), so I reviewed that delta — CHANGELOG.md, reap-project-plugin-records.sh, reap-project-plugin-records.test.sh, audit.md, cleanup.md.

This commit is explicitly a fix-up for the three open threads on this PR (this lane's, Codex's, and this lane's trailing-slash finding). I verified each fix rather than restating the author's claims:

1. Post-reap enumeration swallow (reap-project-plugin-records.sh:259-266) — previously survivors="$(collect_matches)" || survivors="" absorbed a post-reap claude plugin list failure into "0 survivors" and reported a clean reap (exit 0). Now a failure short-circuits before survivor_count is ever computed, prints surviving UNKNOWN / UNVERIFIED, names how many uninstall calls reported success vs. no-op, and exits 3 — matching the pre-reap enumeration failure's degrade path exactly (line 207-211). The script's header comment (lines 41-47) was updated to state exit 3 now covers both enumerations. This closes the finding both this lane and Codex raised, and does so correctly: the ok: every … is gone line is now unreachable on this path.
2. Trailing-slash defeats the symlink test (cleanup.md:162-190, mirrored in audit.md:82-86) — the doc now normalizes <path> (strips trailing separator) before all four qualifying tests, not just the symlink one, and explains why a trailing slash resolves test -L through the link. This closes the finding I raised on 17621ac.
3. Test coverage — reap-project-plugin-records.test.sh gained a stub-driven case pinning the post-reap degrade (call 1 succeeds, call 2 fails → exit 3, UNVERIFIED, surviving UNKNOWN, never the clean-reap line) and a real-symlink fixture pinning the three trailing-slash assertions (test -L link → true, test -L "link/" → false, find link -mindepth 1 → empty), with an honest skip_case on platforms that can't create a symlink. Both fixtures match the mechanism they claim to test.

I did not find a new issue in this delta. One low-signal observation, below the bar for this lane (not filed as a finding): the illustrative snippet at cleanup.md:171-173 shows only path="${path%/}" with a comment to "do it again" for a backslash, and a single application of %/ only strips one trailing separator (a path ending in // would keep one) — but this is prose an agent executes, not code that runs unattended, git worktree paths don't carry doubled trailing separators in practice, and the surrounding text already tells the reader to normalize both separator styles.

No new findings — no inline comments posted. Both previously-flagged threads (the post-reap swallow and the trailing-slash symlink gap) are now fixed and covered by tests I read and traced by hand.
· branch fix/3113-worktree-teardown-plugin-records