docs(issues): file the merged-PR re-fire defect in the PR mergeability check

docs/outstanding-issues-inbox/8dfc4aaf-c22f-45fd-a7f1-0edbd34bf569.json

@@ -0,0 +1,14 @@
+{
+ "version": 2,
+ "id": "8dfc4aaf-c22f-45fd-a7f1-0edbd34bf569",
+ "createdOn": "2026-08-21",
+ "action": "add",
+ "payload": {
+ "pri": "P2",
+ "type": "issue",
+ "summary": "PR mergeability re-fires on merged/closed PRs and always fails: the mergeability job has no PR-state filter, and a merged PR's mergeable_state is permanently 'unknown'",
+ "detail": "MECHANISM (confirmed end to end on PR #2229, 2026-08-21). .github/workflows/pr-mergeability.yml listens on pull_request_target with types [opened, synchronize, reopened, ready_for_review, edited]. GitHub fires 'edited' on CLOSED and MERGED pull requests, and this repo has a bot that reliably edits PR descriptions (the PR #2229 body carries a '## Summary by CodeRabbit' section). The 'mergeability' job is gated only by `if: github.event_name == 'pull_request_target'` — there is NO filter on pull_request.state, pull_request.merged, or head-ref existence. Its 'Signal real merge conflicts' step calls github.rest.pulls.get and feeds the result to classifyMergeability() in scripts/pr-mergeability.mjs. For a merged PR the API returns mergeable: null and mergeable_state: 'unknown' PERMANENTLY, which is exactly the classifier's 'retry' branch, so all 5 attempts retry and the step ends in core.setFailed('GitHub did not finish computing mergeability for PR #<n> after 5 attempts.'). The failure is therefore deterministic, not flaky: any pull_request_target event on a merged or closed PR fails this required check.\n\nEVIDENCE. PR #2229 merged 2026-08-21T13:52:54Z (merge commit 68bcb38d031cb9c355d81d809c535a2ea3e2f9c6), head branch claude/ledger-reconcile-0821b deleted by the merge. At 13:54:31Z — 97 seconds after the merge — workflow run 32489311892 (.github/workflows/pr-mergeability.yml, event pull_request_target, triggering_actor coderabbitai[bot]) started; job 96792973908 'Refresh PR mergeability after base push' correctly skipped, and job 96792972554 'PR mergeability' failed at 13:54:51.99Z with exactly that setFailed message. A live pulls.get on #2229 today still returns state 'closed', merged true, mergeable_state 'unknown' — so the check would fail identically on every future edit event.\n\nMISSING FILTER, AND THE PROOF IT WAS AN OVERSIGHT. The sibling job in the same file, 'refresh-after-base-push', already scopes its work with github.rest.pulls.list({ state: 'open' }). The state filter was applied to the push path and omitted from the pull_request_target path.\n\nSMALLEST FIX (not applied; .github/workflows/** is operational-risk scope). Add a closed/merged branch to classifyMergeability() in scripts/pr-mergeability.mjs, ahead of the existing draft branch, returning { ok: true, action: 'skip', reason: 'merged' } when merged === true or state === 'closed', and pass state: latestPr.state / merged: latestPr.merged from both call sites in pr-mergeability.yml. This mirrors the existing draft skip path exactly, keeps the check reporting rather than silently skipping the job, and is provable offline with 'node scripts/pr-mergeability.mjs --self-test' plus a new assertion there. Do NOT fix this by dropping the 'edited' trigger type: 'edited' is what catches a base-branch change on an OPEN PR, which genuinely alters mergeability. Any change to this file must respect the deliberate cancel-in-progress asymmetry pinned by tests/ci-cache-safety.test.ts, which this fix does not touch.\n\nCORRECTION TO THE ORIGINAL REPORT — the co-reported symptoms were NOT part of this defect. The clarifying comment on #2229 (issuecomment-5371138259) attributed failing 'PR required' and 'Static PR checks' to the merge as well. That is wrong. ci.yml's pull_request types do not include 'edited', and the run list confirms it: every ci.yml run on claude/ledger-reconcile-0821b is pre-merge, and the last one (32489042816, 13:51:34-13:52:52Z, head 754cbfcb) was SUCCESS three seconds before the merge. The six earlier failures were genuine, diff-attributable failures on earlier heads — e.g. run 32488292727 at 13:44Z, where 'Static PR checks' exited 1 on its own step and 'PR required' logged 'static-pr result was failure' — and were fixed before merge. What made them look post-merge is that ci-triage.yml edits ONE comment in place: comment 5369760686 was created 12:23:46Z and last updated 13:44:36Z, both pre-merge, but still sat on the page after the merge naming those two jobs. So the ci-triage comment is stale-by-design, not re-fired; only 'PR mergeability' actually re-fired post-merge. Worth knowing before diagnosing the next one.\n\nRELATED, NOT DUPLICATE. #TF6TPJ is the cancellation-driven false red on OPEN PR branches ('PR required' red with zero failing jobs after repeated main-merges); different trigger, different job, different failure text. #HSSHRG (closed 2026-08-21) is the in-flight CI push guard in scripts/guard-push.mjs. Neither covers a required check re-firing against an already-merged PR. pr-policy.yml carries the same pull_request_target 'edited' exposure but is not defective — its post-merge run 32489311920 at 13:54:33Z passed.\n\nSCOPE NOT MEASURED. GitHub reads for this investigation were authorised only for PR #2229, so how often this fires repo-wide is unquantified. It should recur on any PR whose description a bot edits after merge, which is the normal CodeRabbit pattern here.",
+ "source": "PR #2229; run 32489311892 job 96792972554 (2026-08-21T13:54:51Z); .github/workflows/pr-mergeability.yml; scripts/pr-mergeability.mjs; https://github.com/BigSimmo/Database/pull/2229#issuecomment-5371138259",
+ "issueUlid": "01M0JD82S0HDYCQP5CCPCS4C3Z"
+ }
+}