mellions-issue-closurelisted

<!-- Mellions Engineer | LetA Tech Ltd. | leta@letatech.ca --> # Closing an issue One dangerous failure here is closing on somebody's word — the implementer's, a comment's, a green merge — with the proof local, the acceptance rule unread, or the authority assumed. ## Four events, never conflated ``` feature branch → base branch implementation merged base branch → release branch promoted release → running system deployed issue closed accepted ``` None of the first three implies the fourth. **Merging a pull request does not close its issue.** The issue is the audit trail and the pull request is one artifact on it, so the durable record is the proof comment — exactly what an auto-closing `Closes #NN` skips, and why a pull request body says `Refs` (`mellions-issue-remediation`). Arriving here to find the issue already closed by a merge means the proof was lost, not that the work is done: post it anyway and say what closed it, unless that body says the diff was the whole proof. ## The acceptance rule decides Read the issue's acceptance section — the whole sentence, not the first token — and honour the strictest rule it states. Rules compose: `merge` + `deployment` closes on the deploy, and a scan stopping at the first backticked word reads every compound rule as its weakest half, closing on an event that has not happened. | Rule | Closes when | |---|---| | `merge` | the implementation is merged into the base branch | | `promotion` | the change is on