1 Commits
Author SHA1 Message Date
yhh 88925b5caa feat(ci): ask reporters to verify on the release that carries their fix
A PR writing "Fixes #N" auto-closes its issue on merge. One writing "Refs",
"Related" or "Addresses" does not, so the report stays open waiting for a
follow-up after the release that nobody sends. Auditing the last 400 merged
PRs found 33 open issues referenced by shipped work; only three could be
closed on the evidence, and most of the rest were blocked on nothing but an
unanswered "please re-test".

On every published release this now diffs against the previous tag in the
same series, collects the issues those PRs referenced, and asks each still-open
reporter to verify. It never closes anything — deciding a report is resolved
stays human.

Two traps the audit hit are pinned by tests rather than left to be rediscovered:

- "owner/repo#123" is an upstream reference. Matching it once pulled a
  wailsapp/wails issue number in as if it were ours.
- GitHub's issues API answers for pull requests too, so a consolidation PR
  listing "PR #5576 by @x" reads as a perfectly good open issue. A dry run
  against desktop-v1.18.0 showed 26 of 40 references were pull requests; without
  the check the bot would have asked their authors to re-test.

The PR template now says where to put the keyword, since a "- Fixes #123" list
item is exactly the silent no-op that produced this backlog.
2026-07-29 22:23:57 -07:00