Parent: #1936
Problem
decidePendingAgentAction, the accept-handler for a staged auto_with_approval action, re-checks only stagedHead !== pr.headSha before replaying the planned action. It never re-fetches CI state or re-runs resolveLinkedIssueHardRule — both of which are computed exclusively inside the live-sweep planner path (src/queue/processors.ts) and never touched again by the approval-queue accept path. AgentPendingActionParams doesn't even carry these fields, so there's no stale data being (mis)trusted — the concept is simply absent from the replay path.
Failure scenario: a repo sets merge: auto_with_approval and has one or more linked-issue hard rules (ownerAssignedClose, missingPointLabelClose, maintainerOnlyLabelClose) enabled. A PR passes gate+CI and is staged for merge. Before a maintainer accepts, another maintainer relabels the linked issue maintainer-only or reassigns it to the owner. The head SHA never changes, so the freshness check passes and the stale merge decision executes — merging a PR that would now trip the deterministic hard-rule close if the planner were re-run. (This is separate from and lower-severity than the sibling CI/mergeable-state gap already filed for this same accept path, since it's config-gated behind hard rules that are off by default.)
Requirements
- Accepting a staged merge must re-validate the linked-issue hard rule and CI state against current data, not just head SHA.
Deliverables
- For
actionClass === "merge" in decidePendingAgentAction, re-run resolveLinkedIssueHardRule against the PR's current linked issues/labels and deny/supersede on violation, using the same pattern as the existing head-moved rejection.
- Re-check live CI state (or at minimum the required-status-contexts aggregate) the same way, denying if CI is no longer green.
- Prefer collapsing this into the broader fix tracked in the sibling issue (re-running the full plan at accept time), since both gaps share the same root cause.
- Add a regression test in
test/unit/agent-approval-queue.test.ts (currently no test file exists for this scenario) covering: linked issue becomes ineligible between staging and accept — assert deny rather than execute.
Acceptance criteria
- A staged merge whose linked issue becomes hard-rule-ineligible between staging and accept is denied on accept.
- A staged merge whose linked issue remains eligible executes normally.
Expected outcome
An operator who enables linked-issue hard rules can trust they're enforced at the moment of actuation, not just at staging time — closing the gap between "this looked eligible when staged" and "this is still eligible now."
Parent: #1936
Problem
decidePendingAgentAction, the accept-handler for a stagedauto_with_approvalaction, re-checks onlystagedHead !== pr.headShabefore replaying the planned action. It never re-fetches CI state or re-runsresolveLinkedIssueHardRule— both of which are computed exclusively inside the live-sweep planner path (src/queue/processors.ts) and never touched again by the approval-queue accept path.AgentPendingActionParamsdoesn't even carry these fields, so there's no stale data being (mis)trusted — the concept is simply absent from the replay path.Failure scenario: a repo sets
merge: auto_with_approvaland has one or more linked-issue hard rules (ownerAssignedClose,missingPointLabelClose,maintainerOnlyLabelClose) enabled. A PR passes gate+CI and is staged for merge. Before a maintainer accepts, another maintainer relabels the linked issuemaintainer-onlyor reassigns it to the owner. The head SHA never changes, so the freshness check passes and the stale merge decision executes — merging a PR that would now trip the deterministic hard-rule close if the planner were re-run. (This is separate from and lower-severity than the sibling CI/mergeable-state gap already filed for this same accept path, since it's config-gated behind hard rules that are off by default.)Requirements
Deliverables
actionClass === "merge"indecidePendingAgentAction, re-runresolveLinkedIssueHardRuleagainst the PR's current linked issues/labels and deny/supersede on violation, using the same pattern as the existing head-moved rejection.test/unit/agent-approval-queue.test.ts(currently no test file exists for this scenario) covering: linked issue becomes ineligible between staging and accept — assert deny rather than execute.Acceptance criteria
Expected outcome
An operator who enables linked-issue hard rules can trust they're enforced at the moment of actuation, not just at staging time — closing the gap between "this looked eligible when staged" and "this is still eligible now."