merge_pr should refuse when a commit message carries a closing keyword the PR body does not nf-x2wh ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/537 by tools/beads/import_github.py's reconcile pass.

Filed unclaimed. Found on #527, where it was one merge away from silently closing an issue that had been deliberately left open.

The asymmetry

The PR body is the reviewed artifact. The commit messages are not — and only the commit messages reach main.

merge_pr.py merges with gh pr merge <n> --squash --delete-branch and passes no --subject/--body (tools/nflib/gh.py), so GitHub's repo-default squash message applies. On this repo that is the bullet list of the branch's commit messages, verbatim. Confirmed against main:

``` $ git log -1 --format=%B 1ae30df | head -3 f5.py: port the F5 sync, and warn when the build is stale (design 001 piece 8) (#509)

* f5.py: faithful port, pinned by a 15-scenario oracle (design 001 piece 8) ```

A closing keyword in any constituent commit therefore closes its issue on merge, whatever the PR body says.

The live case

#527 originally said Closes #524. Review established that it closes only one of #524's two consequences, so the PR body was corrected to Refs #524 and a status comment was posted on the issue explaining which half landed. All visible, all reviewed.

The commit message still said Closes #524. Merging would have closed the issue and buried the half the correction existed to protect — and it would have failed silently: the issue just quietly closes and nobody looks at it again. Caught by ninefold-reviewer as F6, not by any gate.

Worth noting the divergence is detectable and rare: no squash body in the last 40 commits on main carries a bare Closes #n, so this is not a widespread pattern — which is exactly why nobody would think to check.

Shape

A preflight in merge_pr.py, next to the feedback ledger and the presubmit gate:

• Extract closing keywords (clos(e|es|ed), fix(es|ed), resolve(s|d) + #n) from every commit on the branch and from the PR body.
• Refuse if a commit closes an issue the body does not. That is the direction that loses information silently.
• The reverse — body closes, commits do not — is harmless: GitHub honours the PR body too, and the issue closes either way.

Escape hatch in the house style: SKIP_LINKAGE=1, loud, exact-string "1", matching SKIP_LEDGER / SKIP_PRESUBMIT.

Worth considering instead, or as well

• Pass an explicit squash body. merge_pr.py could build the body from the PR description rather than letting GitHub concatenate commits — which fixes the class outright instead of detecting it. Bigger change, and it makes the merge commit match the reviewed artifact by construction, so probably the better long-term answer.
• Document it in CLAUDE.md. The PR-body conventions section says nothing about commit-message linkage, and the mental model most sessions carry is "the PR body is the record". It is not, on merge.

Related: #470 (merge_pr gates), design 001 §5.1.