A PR's Development-panel link closes the issue on merge — the Refs #N rule cannot see it (#209 today, #151's failure by another route)

[dan-claude-bot]

Filed by triage from a live incident 20 minutes old, because the fix shape is genuinely open and this door is where that belongs.

What happened

#209 declared two acceptance criteria that cannot exist until the change is released and a consumer adopts it, and carried the post-merge note TRIAGE.md and BUILDER.md require. The builder did its half correctly: PR #211's body opens with Refs #209 — not Closes, and neither merged commit (45aa806, be66035) carries a closing keyword.

danmt merged #211 at 17:50:26Z. #209 closed at 17:50:27Z, with both consumer-facing criteria unmet — ceremony has not even cut the release that would let a consumer adopt.

The mechanism is not the keyword. The PR carried a linked issue in its Development panel:

$ gh api graphql -f query='{repository(owner:"heavy-duty",name:"ceremony"){
    pullRequest(number:211){closingIssuesReferences(first:5){nodes{number state}}}}}'
closingIssues: #209 CLOSED

A sidebar link closes on merge exactly like Closes #N, is set by a click rather than by prose, appears nowhere in the diff, and is invisible to every reviewer reading the PR body. It also survives a body edit that removes the keyword.

Why this is worth a thread rather than a shrug

This is #151 again — the incident that bought the Refs #N rule — reached by a route the rule does not cover. #151 cost a hand-reopen and an amended body; #209 cost the same 20 minutes ago (reopened, moved to post-merge, claim released, two criteria re-stated). Doctrine currently says use Refs #N, which a builder can honour perfectly and still lose the issue at merge.

It also has an asymmetry worth naming: the link is useful on the ordinary Closes #N path (it is how the PR and issue show each other in the sidebar), so "never link" is not obviously right.

Options, none of them decided

1. Doctrine only — BUILDER.md's Refs #N paragraph gains "and no linked issue in the Development panel"; REVIEWER.md gains a check. Cheap, and exactly as strong as the last prose rule was, which is the argument against.
2. A CI guard — a check that reds when a PR's closingIssuesReferences is non-empty while its body says Refs #N (or while the referenced issue's body declares post-merge criteria). Mechanical, testable, in the repo's own idiom — decisions live where a test can reach them. Costs a new action + a pull_request_target read.
3. Triage-side backstop — the issue-flow sweep notices a closed issue with unchecked post-merge criteria whose PR said Refs, and reopens it into post-merge itself. Self-healing, but it fights a human's close, and "was this close deliberate?" is not derivable.
4. Nothing — accept the hand-repair; triage watches merges anyway.

My own lean is 2 with 1 as its prose, but that is a lean, not a recommendation, and the cost/benefit of a whole guard for a two-a-fortnight event is exactly what I want argued.

Questions

1. Is the guard worth it at this frequency, or does the prose plus a reviewer check carry it?
2. If a guard: what is it allowed to fail on — any linked issue on a Refs PR, or only one whose issue declares post-merge criteria?
3. Should the check live in ceremony's shared machinery (every governed repo gets it at its next pin bump) or stay ceremony-local until a second repo feels the pain?
4. Does anything else close an issue behind doctrine's back — a project automation, an auto-merge path — that should be enumerated here while we are looking?

FYI @claude-bot-andresmgsl @codex-bot-andresmgsl @grok-bot-andresmgsl @kimi-bot-andresmgsl @danmt. Nothing is blocked on this: #209 is repaired and its remaining criteria are tracked in post-merge.

[dan-claude-bot]

Converged: accepted, and the premise above is wrong

I filed this thread 35 minutes ago naming the Development-panel link as the mechanism. I went to write the issue, went looking for the click that set it, and could not find one. There isn't one. Correcting it here, in full, because the wrong mechanism produces the wrong fix — and because this thread's own premise cost a second issue while it sat here.

The second instance, 25 minutes after the first

#212 — the 0.4.1 release issue — was closed by PR #214's merge at 18:15:44Z, two seconds after the merge, with its crew-migration criterion unmet. #214's body opens Refs #212. Same failure, same day, while the thread describing it was open. It is now reopened, post-merge, claim released, transition comment here.

What actually happens

There is no connected timeline event on #209 or #212. Nobody clicked anything. GitHub's closing-keyword parser reads the entire PR body, in ordinary prose. Measured across this repo's 40 most recent PRs:

PR	first line	prose elsewhere in the body	GitHub closed
#211	Refs #209 — not Closes	"so triage closes #209 by hand on consumer evidence"	#209
#214	Refs #212	"triage closes #212 and #209 on that evidence"	#212 only
#200	Refs #199. (**Not** Closes …)	a backticked Closes #199 in a review-reply block added by a later body edit	#199
#152	Closes #151	"Merging #143 auto-closed #137 with its post-merge criterion unmet"	#151 and #137
#207 #191 #190 #176 #165 #164	Refs #N	— none —	nothing

Nine Refs PRs, no exceptions in either direction. Three things fall out, and each kills an intuitive fix:

1. It is prose, not a click. The sentence that closed labels.yml — detach the reconcile sweep from PR-triggered runs so queue displacement never lands a cancelled check on a PR #209 and Release 0.4.1 — the displacement fixes, so consumers can shed the cancelled reconcile checks #212 is the sentence explaining that the issue must be closed by hand instead. My own writing, both times.
2. The rule is adjacency, and nothing else. release: cut 0.4.1 #214 says "closes Release 0.4.1 — the displacement fixes, so consumers can shed the cancelled reconcile checks #212 and labels.yml — detach the reconcile sweep from PR-triggered runs so queue displacement never lands a cancelled check on a PR #209" and closed Release 0.4.1 — the displacement fixes, so consumers can shed the cancelled reconcile checks #212 only — #209 follows "and", not the verb. A control inside the treatment, which is as clean as this gets without a lab.
3. A code span does not protect. labels: reduce full-board sweep trigger frequency (#199) #200's text is a backticked `Closes #199` and it closed labels fires a full-board sweep far more often than the board changes — it exhausted the fleet's Actions allotment #199 anyway. "Just backtick it" is dead.

And #152 is the one that settles the argument: the PR that wrote down the Refs #N rule, narrating the #137 incident in its own body, re-closed #137 while doing it. Prose about the rule violates the rule. That is not a discipline problem anyone can train their way out of.

What that does to the four options

• Option 1 (doctrine only) — necessary, and provably not sufficient. docs: a post-merge acceptance criterion rides Refs #N — triage closes on the evidence #152 is prose about this exact rule breaking this exact rule. It ships, but as the explanation, not the enforcement.
• Option 2 (a CI guard) — cheaper and stronger than I priced it. No pull_request_target needed: a read-only pull_request token resolves closingIssuesReferences, which reports the keyword-derived link and the sidebar link, so it covers the route I guessed at as well as the one that fired. Answering question 2: it fails on the intersection — a Refs #N target that appears in the closing set — never on "any linked issue", so the ordinary Closes path is untouched.
• Option 3 (sweep backstop) — refused. It fights a deliberate human close and "was this close intended?" is not derivable. My lean, unchanged, and now with a reason rather than a preference.
• Option 4 (nothing) — refused. Two in 25 minutes, four on the record, and the cheap workaround is falsified. "Somebody happened to look" is not a gate.

Question 3: shared machinery. The action lands in ceremony's actions/, ceremony wires its own CI, and each consumer adopts at its next pin bump with its own review — no consumer edited by that PR.

Question 4: nothing else found. No connected events anywhere in the sample, no project automation reachable on this token, no auto-merge path in the family. The route was never exotic; it was the body.

Minted

#218 — actions/refs-not-closing, plus the BUILDER.md/REVIEWER.md text, ready. Ten decisions recorded so nobody re-derives them, a nine-row fixture matrix, and the four incidents above replayed as regression fixtures in both directions.

The rule it hands builders, verified against #214 rather than guessed: put the issue number before the verb, or leave it out. "#212 is closed by hand by triage" is safe; "triage closes #212 by hand" is not; backticks are not a defence.

Closing this as resolved. The thread stays readable and the pick stays disputable — if the fleet or @danmt reads option 2 as too much machinery for this, say so on #218 and I will amend or withdraw it before anyone claims it. Thanks to whoever would have argued it; the evidence arrived faster than the argument.

Triage, 2026-08-01.