Parent: #1936
Problem
processGitHubWebhook has no branch for eventName === "issues" (confirmed absent despite the event being subscribed and delivered) — so labeling/unlabeling maintainer-only or a point-bearing label on the linked ISSUE, or assigning/unassigning the repo owner on it, never re-triggers resolveLinkedIssueHardRule for PRs that link it. That check only runs when the PR itself receives a webhook, or via the periodic sweep. selectRegateCandidates (src/settings/agent-sweep.ts:46) caps at SWEEP_MAX_PRS = 3 per repo per ~2-minute tick with no priority signal for "a linked issue's label just changed."
Failure scenario: a maintainer adds maintainer-only to an issue after a contributor already opened a linking PR (or removes it to unblock a wrongly-flagged PR). The PR keeps whatever verdict it had until either a new push happens on it or the staleness-ordered sweep eventually reaches it — on a repo with more than a few open PRs, this can lag for many sweep cycles. A should-now-be-closeable PR can still auto-merge in the meantime, or a should-now-be-mergeable PR stays wrongly held/closed.
Requirements
- A label/assignment change on a linked issue should converge the linking PR's hard-rule disposition promptly, not only on the next PR-side webhook or the slow staleness sweep.
Deliverables
- Add an
eventName === "issues" branch to processGitHubWebhook for labeled/unlabeled/assigned/unassigned actions: look up PRs that link this issue number and re-trigger resolveLinkedIssueHardRule (and the standard maintenance re-evaluation) for each.
- Alternatively/additionally, give the sweep a priority boost for PRs whose linked issue changed recently, ahead of pure staleness ordering.
- Add a regression test: an issue linked by an open PR gets
maintainer-only added — assert the PR's hard-rule re-evaluation fires promptly (webhook-driven, not sweep-only).
Acceptance criteria
- A label/assignment change on a linked issue triggers re-evaluation of every PR that links it, without waiting for a PR-side event or the full sweep cycle.
Expected outcome
Hard-rule enforcement reflects the current state of a linked issue promptly, closing a real convergence-lag window a maintainer would reasonably expect not to exist.
Parent: #1936
Problem
processGitHubWebhookhas no branch foreventName === "issues"(confirmed absent despite the event being subscribed and delivered) — so labeling/unlabelingmaintainer-onlyor a point-bearing label on the linked ISSUE, or assigning/unassigning the repo owner on it, never re-triggersresolveLinkedIssueHardRulefor PRs that link it. That check only runs when the PR itself receives a webhook, or via the periodic sweep.selectRegateCandidates(src/settings/agent-sweep.ts:46) caps atSWEEP_MAX_PRS = 3per repo per ~2-minute tick with no priority signal for "a linked issue's label just changed."Failure scenario: a maintainer adds
maintainer-onlyto an issue after a contributor already opened a linking PR (or removes it to unblock a wrongly-flagged PR). The PR keeps whatever verdict it had until either a new push happens on it or the staleness-ordered sweep eventually reaches it — on a repo with more than a few open PRs, this can lag for many sweep cycles. A should-now-be-closeable PR can still auto-merge in the meantime, or a should-now-be-mergeable PR stays wrongly held/closed.Requirements
Deliverables
eventName === "issues"branch toprocessGitHubWebhookforlabeled/unlabeled/assigned/unassignedactions: look up PRs that link this issue number and re-triggerresolveLinkedIssueHardRule(and the standard maintenance re-evaluation) for each.maintainer-onlyadded — assert the PR's hard-rule re-evaluation fires promptly (webhook-driven, not sweep-only).Acceptance criteria
Expected outcome
Hard-rule enforcement reflects the current state of a linked issue promptly, closing a real convergence-lag window a maintainer would reasonably expect not to exist.