Two related gaps in how issue auto-closing works on this repository's two-branch model. Both bit during one session, and neither is written down anywhere in GOVERNANCE.md, AGENTS.md, drive-pr, merge-and-release, or comment-and-doc-style.
1. A feature pull request's Fixes #N is inert
GitHub registers a closing reference only for a pull request targeting the default branch. Every feature pull request here targets develop, so its Fixes #N line never becomes a closing reference at all.
Measured across the thirteen feature pull requests promoted in #1263:
gh api graphql -f query='{ repository(owner:"ptr727",name:"ProjectTemplate"){
pullRequest(number:1255){ closingIssuesReferences(first:10){ nodes{ number } } } } }'
returns an empty set for all thirteen, despite each carrying a Fixes #N line that renders as a link in the UI.
The consequence is that the promotion pull request must carry a Closes #N line for every issue in the batch, or the promotion merges and closes nothing. Nothing states this. An agent that writes Fixes #N on the feature pull request, sees it link correctly, and then writes a promotion body without the lines, ships a promotion that silently leaves nineteen issues open.
2. A closing keyword fires inside a sentence that negates it
The keyword is matched adjacent to the reference, and no surrounding wording disarms it. Both of these register a closing reference:
Fixes #1261 is deliberately not claimed here.Narrowed with evidence rather than closed: #669
The second was live on #1263 and would have auto-closed #669 on merge, an issue that had just been deliberately narrowed and left open with a comment explaining what remained. It was caught only by querying closingIssuesReferences after opening the pull request, not by reading the body.
The full keyword set is close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved. Prose about an issue reaches for several of these naturally, which is what makes it a trap rather than a rarity.
What a fix would have to address
- State, wherever the promotion recipe lives, that the promotion body owns the closing lines and the feature pull requests cannot.
- State that a closing keyword must never sit adjacent to an issue reference unless the closure is intended, and give the safe rewriting (
, #669, rather than closed: #669).
- Make the check mechanical rather than a matter of care: after opening a promotion, compare
closingIssuesReferences against the intended list. Reading the body does not work, which is the whole point of both halves above.
Two related gaps in how issue auto-closing works on this repository's two-branch model. Both bit during one session, and neither is written down anywhere in
GOVERNANCE.md,AGENTS.md,drive-pr,merge-and-release, orcomment-and-doc-style.1. A feature pull request's
Fixes #Nis inertGitHub registers a closing reference only for a pull request targeting the default branch. Every feature pull request here targets
develop, so itsFixes #Nline never becomes a closing reference at all.Measured across the thirteen feature pull requests promoted in #1263:
returns an empty set for all thirteen, despite each carrying a
Fixes #Nline that renders as a link in the UI.The consequence is that the promotion pull request must carry a
Closes #Nline for every issue in the batch, or the promotion merges and closes nothing. Nothing states this. An agent that writesFixes #Non the feature pull request, sees it link correctly, and then writes a promotion body without the lines, ships a promotion that silently leaves nineteen issues open.2. A closing keyword fires inside a sentence that negates it
The keyword is matched adjacent to the reference, and no surrounding wording disarms it. Both of these register a closing reference:
Fixes #1261 is deliberately not claimed here.Narrowed with evidence rather than closed: #669The second was live on #1263 and would have auto-closed #669 on merge, an issue that had just been deliberately narrowed and left open with a comment explaining what remained. It was caught only by querying
closingIssuesReferencesafter opening the pull request, not by reading the body.The full keyword set is
close,closes,closed,fix,fixes,fixed,resolve,resolves,resolved. Prose about an issue reaches for several of these naturally, which is what makes it a trap rather than a rarity.What a fix would have to address
, #669,rather thanclosed: #669).closingIssuesReferencesagainst the intended list. Reading the body does not work, which is the whole point of both halves above.