fix(agent-actions): re-check the linked-issue hard rule on merge accept

[JSONbored]

What

decidePendingAgentAction (the approval-queue accept handler for a staged auto_with_approval action) re-validated only the head SHA before replaying a staged merge. The linked-issue hard rule (owner-assigned / missing-point-label / maintainer-only) is evaluated fresh on every planning pass and takes precedence over merge (planAgentMaintenanceActions never plans a merge when the rule is violated) — but a staged merge only replays the PLAN-TIME snapshot. If a maintainer relabels or reassigns the linked issue between staging and accept (head SHA unchanged, so the existing freshness check doesn't catch it), the stale merge decision would still execute, merging a PR that would now trip the deterministic hard-rule close if the planner were re-run.

Fix

decidePendingAgentAction (src/services/agent-approval-queue.ts) now re-runs resolveLinkedIssueHardRule for a staged merge action before executing it, denying/superseding the same way the existing head-moved check already does (same audit event type, agent.pending_action.superseded, outcome: "denied").

The recheck mirrors the planner's own closeEligible exemption: it's skipped entirely for an owner- or automation-authored PR (unless closeOwnerAuthors is on), since the hard rule never blocks those PRs in the planner either — without this, an owner's legitimate staged merge could be wrongly denied just because their own linked issue happens to match a rule pattern that was never meant to constrain them.

Scope note on the sibling CI-recheck deliverable: issue #2132 also asks to re-check live CI state at accept time. That's already covered by a separate, already-open PR for #2128 (executeAgentMaintenanceActions's step 6 CI re-verification), which applies to every merge-class action regardless of caller — decidePendingAgentAction's existing call into that executor will pick it up automatically once that PR merges, with zero additional changes needed here. This PR is deliberately scoped to just the linked-issue portion to stay small and avoid duplicating code already in flight; opening as "Advances" rather than "Closes" since full closure depends on that sibling PR landing too.

Tests

• New test: a staged merge is superseded when resolveLinkedIssueHardRule reports a violation between staging and accept (contributor PR).
• New test: a staged merge executes normally when the linked issue remains eligible.
• New test: an owner-authored staged merge executes normally even when the hard-rule resolver would report a violation, and confirms the resolver is never even called (the closeEligible exemption).
• New test: the supersede audit detail falls back to a generic reason when the hard-rule result omits one.
• New test: a slash-less repoFullName and a PR with no author login are tolerated (the two defensive fallbacks in the new repoOwner/authorLogin derivation).
• All 18 pre-existing tests in the file continue to pass unchanged, confirming non-merge action classes and the existing head-moved check are unaffected.
• npx tsc --noEmit clean.
• Scoped: agent-approval-queue.test.ts — 23 passed.
• Regression sweep: routes-agent-approval.test.ts, mcp-automation-state.test.ts, agent-action-executor.test.ts, agent-actions.test.ts, linked-issue-hard-rules.test.ts (the two direct importers of this module plus the hard-rule evaluator itself) — 215 passed.
• Diff-range coverage-gap check on src/services/agent-approval-queue.ts: fully covered.
• Full unsharded npm run test:coverage: 5605 passed, 4 skipped (pre-existing/unrelated), 0 failed.
• npm audit --audit-level=moderate: 0 vulnerabilities.

Advances #1936. Advances #2132.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-01 23:25:03 UTC}

2 files · 1 AI reviewer · no blockers · readiness 68/100 · CI green · clean

⏸️ Suggested Action - Manual Review

• Touches a guarded path — held for manual review

Review summary
The accept path now revalidates staged merge actions against the live linked-issue hard-rule state after precision-breaker downgrades, which is the right layer for preventing stale queued merges from bypassing deterministic planning rules. The visible implementation preserves the existing head/CI freshness checks, mirrors the planner's owner/automation exemption, and rejects only when the post-downgrade plan still contains a merge. The tests cover the main stale-rule path, the downgraded-hold path, fail-open token minting, owner exemption, and fallback audit detail.

Nits — 7 non-blocking

• nit: test/unit/agent-approval-queue.test.ts:368 queues a mocked hard-rule violation in a test that asserts the resolver is not called, so confirm the file's beforeEach resets mock implementations as well as call counts to avoid leaking that once-value into the next test.
• nit: src/services/agent-approval-queue.ts:149 adds a very long explanatory comment block in an already dense function; consider moving the planner-parity rationale into a small helper name or a shorter comment so the accept flow stays readable.
• nit: src/services/agent-approval-queue.ts:157 manually derives repoOwner from repoFullName; if the repo already has a shared parser/helper for full names, use that here to avoid a second subtly different owner extraction convention.
• In test/unit/agent-approval-queue.test.ts:368, remove the unused mockResolvedValueOnce from the no-call test or explicitly reset it before the next test so the assertion stays local to that case.
• In src/services/agent-approval-queue.ts:157, extract the linked-issue accept-time recheck into a private helper that takes the pending row, PR, settings, and plan; that would make the closeEligible parity easier to compare against the planner.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.
• Touches a guarded path — held for manual review — A maintainer must review and merge this change.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	⚠️ 3 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
Change scope	❌ 8/20	High review scope from cached public metadata (size label size:M; no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 65 registered-repo PR(s), 55 merged, 572 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 65 PR(s), 572 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 65 PR(s), 572 issue(s).
• Related work: Titles/paths share 8 meaningful terms. (issue #2132)
• Related work: Items reference the same linked issue fix(review): a nonexistent linked issue number satisfies the linked-issue hard rule #2136. (issue #2136, PR #2402)
• Related work: Open PR work references issue fix(review): a nonexistent linked issue number satisfies the linked-issue hard rule #2136. (issue #2136, PR #2402)

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Review top overlaps.
• Add a concise scope and risk note.
• Triage stale or unlinked PRs.
• No action.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.
• Check active issues and PRs before submitting.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.88%. Comparing base (6556a0f) to head (9fa37e7).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2388   +/-   ##
=======================================
  Coverage   95.88%   95.88%           
=======================================
  Files         224      224           
  Lines       25143    25158   +15     
  Branches     9143     9150    +7     
=======================================
+ Hits        24109    24124   +15     
  Misses        421      421           
  Partials      613      613           

Files with missing lines	Coverage Δ
src/services/agent-approval-queue.ts	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.