docs: CLAUDE.md — PR prose closes issues too, via undocumented keyword inflections

[rubenhensen]

Found while working the map ticket that archived cryptify; part of #247.

The import-closes bullet already covers two vectors, both needing an imported history. There is a third that needs nothing at all. PR #311's body opened with the words "Closing note for" in front of a bare issue reference, meaning it as a pointer. Merging it shut that issue one second later, commit_id: null — the PR-body attribution the same bullet documents.

closing appears in none of GitHub's three documented keyword lists (close/closes/closed, fix/fixes/fixed, resolve/resolves/resolved) and behaved like one regardless. Two consequences worth writing down:

• The documented list is a floor, not the set. Keep every inflection away from a bare #N in a PR body unless you mean it.
• The audit grep the bullet already prescribes, (close[sd]?|fix(e[sd])?|resolve[sd]?), does not match participles — it would have passed this body clean. The bullet now carries a wider pattern for PR bodies.

No harm done in this instance: the close was wanted, and an audit of everything closed in that window confirmed nothing else went with it — but it was luck, not the phrasing.

[dobby-coder]

Got it — I'm on this. I'll review PR #313 with the third close vector in mind (the bare #N reference read as a closing pointer via PR-body attribution, plus the note that the audit grep needs widening to catch participles like "closing") and follow up with a consolidated review.

[dobby-coder]

Docs-only, +1/-1 on CLAUDE.md. Title is conventional-commit compliant (docs:; pr-title.yml does run here). Prose is clean against the writing rules. part of #247 in the body correctly avoids auto-closing the map ticket.

The blocker is the new bullet's evidence. The third vector rests on closing having behaved as an undocumented closing keyword, and PR #311's body carries a literal Closes #294 trailer on its own line — the ordinary documented keyword, present and sufficient. One sub-claim is verifiably false, and the remedy the bullet prescribes would not catch the phrasing it says it fixes. Detail inline.

This is the reproduction the same bullet asks for, two sentences earlier: "Confirm it on a throwaway repo and record the answer here before relying on it." A scratch repo, a PR whose body says only Closing note for #1 and carries no trailer, would settle it either way. If it reproduces, the bullet is right and needs a wider grep than the one it currently proposes. If it does not, the honest bullet is the opposite one — a deliberate Closes trailer closed the issue as designed.

Two smaller notes, neither blocking:

• If the behaviour does reproduce, its natural home is the shared pr-close-issue-keywords rule rather than this repo's CLAUDE.md alone. "GitHub's keyword matcher accepts inflections the docs do not list" fires in every repo in both orgs, and single-repo-lessons-belong-in-that-repos-claude-md puts the general core in rules/ with only the postguard specifics here. Worth moving in the same PR that confirms it.
• Pre-existing, not introduced here — recording it so the next review does not rediscover it. cargo test --workspace --all-features cannot compile on a host target: error: "web" feature should only be enabled on wasm32 targets at pg-core/src/client/web/mod.rs:19. Plain cargo test --workspace passes clean. Since this file already documents an --all-features invocation for the api_gate suite, a short note that --all-features is wasm32-only workspace-wide would save the next person the failed run.

[dobby-coder]

Three problems with the new third-vector text, in descending order of weight.

1. The central claim is unsupported — the documented keyword is present and sufficient.

PR #311's body carries a literal Closes #294 trailer on its own line (body line 10 of 11):

gh pr view 311 --repo encryption4all/postguard --json body -q .body | sed -n '10p'
# -> Closes #294

That alone explains the close. GitHub agrees it was a body-attributed closing reference:

gh api graphql -f query='{repository(owner:"encryption4all",name:"postguard"){pullRequest(number:311){mergedAt closingIssuesReferences(first:10){nodes{number}}}}}'
# -> mergedAt 2026-08-09T12:47:04Z, closingIssuesReferences: [294]

and #294 has exactly one close event, 2026-08-09T12:47:05Z with commit_id: null — one second after the merge, precisely the PR-body attribution this bullet already documents. Because the trailer and the Closing note for opener point at the same issue, GitHub emits one close event either way, so this incident cannot distinguish them. The documented cause is present; the undocumented one is not evidenced.

There is also positive evidence against the participle theory, from our own measurements. pr-close-issue-keywords records that the keyword must immediately precede the reference, measured on privacybydesign/irmago#592: Closes the investigation in irmamobile#579 did not auto-close — humans closed it by hand, commit_id: null. Closing note for #294 has note for sitting between the verb and the reference, so under the adjacency behaviour we have already measured it would not fire even if closing were a keyword. Yet the bullet states it as measured fact and generalises to "the documented list is a floor, not the set".

2. "The narrower pattern ... does not catch this one" is verifiably false.

It catches it on the first try — the Closes #294 trailer is a match:

gh pr view 311 --repo encryption4all/postguard --json body -q .body > /tmp/311.body
grep -oiE '(close[sd]?|fix(e[sd])?|resolve[sd]?) +#[0-9]+' /tmp/311.body
# -> Closes #294   (exit 0)

The PR description's "it would have passed this body clean" is the same error. Since this is the stated motivation for widening the pattern, the justification does not hold as written.

3. The quote is inaccurate, and the new pattern would not catch the quoted form either.

The body's first line actually reads Closing note for [#294](https://github.com/encryption4all/postguard/issues/294) — a markdown-linked reference, not the bare Closing note for #294 quoted here. The newly prescribed pattern returns nothing against it:

sed -n '1p' /tmp/311.body | grep -oiE '(clos(e[sd]?|ing)|fix(e[sd]|ing)?|resolv(e[sd]?|ing)) +#[0-9]+'
# -> no output (exit 1)

# and against the whole body with the Closes trailer removed:
sed '10d' /tmp/311.body | grep -oiE '(clos(e[sd]?|ing)|fix(e[sd]|ing)?|resolv(e[sd]?|ing)) +#[0-9]+'
# -> no output (exit 1)

It fails on two independent counts: the intervening words note for , and the [#294](...) link form rather than a bare #294. So the audit command this bullet prescribes would still have passed this very body clean — the exact failure it claims to fix. Advising readers to keep inflections away from a bare #N compounds it, since it steers them away from the one form that was not used while leaving the linked form (the form actually in the body) unmentioned.

If the participle behaviour does reproduce on a throwaway repo, the pattern needs to tolerate both intervening words and [#N](...) links to be worth prescribing.

No suggestion block here on purpose — the right replacement text depends on which way that scratch-repo test comes out.

[dobby-coder]

Thanks for writing this up — but I had to request changes on postguard#313, because the evidence for the third vector doesn't hold up under checking.

PR #311's body actually carries a literal Closes #294 trailer, so the documented keyword was already there and sufficient — GitHub's own closingIssuesReferences and the close event both point at that same attribution, with nothing left for "closing" to explain. Our own pr-close-issue-keywords rule cuts the other way too: it requires the keyword to immediately precede the reference, and here the text is "Closing note for #294" — a markdown link with words in between, which wouldn't fire that rule even if "closing" counted. And the claim that the narrower grep pattern "would have passed this body clean" isn't true either — it matches the Closes #294 trailer on the first try, so the stated motivation for widening the pattern doesn't survive.

Left one inline comment on CLAUDE.md:20 with the details, and pointed back to the bullet's own ask: confirm this on a throwaway repo (a PR body with only "Closing note for #1", no trailer) before it goes in as fact — happy to take another look once that's settled. Also flagged a pre-existing, unrelated cargo test --workspace --all-features compile issue for the next reviewer, non-blocking.

Full review: #313 (review)

[rubenhensen]

Confirmed — the third-vector claim doesn't hold up, on all three points raised.

Checked directly:

• closingIssuesReferences on docs: CLAUDE.md — cryptify is archived, postguard is its sole publisher #311 resolves to [294], and task: transfer cryptify's 9 open issues into postguard, then archive #294's only close event is 2026-08-09T12:47:05Z with commit_id: null — one second after merge, consistent with the literal Closes #294 trailer on line 10 of the body, not with anything on line 1.
• The existing narrow grep ((close[sd]?|fix(e[sd])?|resolve[sd]?) +#[0-9]+) matches that trailer on the first try. "Would have passed clean" was wrong.
• Line 1 actually reads Closing note for [#294](...) — a markdown link with note for in between, not the bare Closing note for #294 the bullet quoted.

Went further and tested the underlying hypothesis directly on a throwaway repo, since the review flagged it as unverified: opened a PR with body Closing #N (bare, adjacent, no intervening words, no trailer) against an open issue and merged it. closingIssuesReferences was empty pre-merge and the issue stayed open post-merge. So closing isn't a closing keyword in any form tested — not just miscounted in this one incident.

Reverted CLAUDE.md to the pre-#313 bullet (639c924); the branch now diffs to nothing against main. Given there's no surviving claim to add, I'll leave it to a maintainer whether to close this PR outright or repurpose it — happy to do either.

[rubenhensen]

Closing — the underlying claim didn't survive review + a direct throwaway-repo test (see comments above). Reverted to a no-op diff against main, nothing to merge.