Severity: CRITICAL
Location: src/settings/agent-actions.ts:746
Found via a full-system adversarial audit of the ORB review/scoring engine (2026-07-15) — 2 independent skeptic passes, both had to vote "confirmed" for this to survive.
Failure scenario
Repo sets contributorOpenPrCap (or the install-wide GLOBAL_CONTRIBUTOR_OPEN_ITEM_CAP) with autonomy.close = "auto_with_approval" (a real, supported, tested AutonomyLevel — see src/types.ts:1450). Contributor 'farmer99' has PR #10 open and opens PR #11, going over cap. planAgentMaintenanceActions (src/settings/agent-actions.ts:741-758) builds a closeKind:"contributor_cap" close action with requiresApproval:true, but — unlike the sibling blacklist (line 730), review_nag (line 779), copycat (line 804) and screenshot_table (line 829) blocks — it never spreads ...(input.pr.headSha ? { expectedHeadSha: input.pr.headSha } : {}) onto the action. The action is staged into the approval queue (stageForApproval -> actionParams, src/services/agent-action-executor.ts:955-967), so the persisted pending row's params.expectedHeadSha is always undefined for this closeKind. When the maintainer clicks 'Accept', decidePendingAgentAction (src/services/agent-approval-queue.ts:66) reads stagedHead = pending.params.expectedHeadSha = undefined, then evaluates isUnpinnedRatifyingAction (lines 93-95): !stagedHead && (... || pending.actionClass === "close") is unconditionally true for this row. The function immediately marks the row 'rejected' and returns executionOutcome:"unpinned_legacy_action" (lines 96-107) BEFORE ever reaching the actual close execution at line 399. PR #11 is never closed; the maintainer's accept is silently discarded every single time, and a fresh regate sweep just re-stages the identical unpinned action, producing an infinite accept-then-supersede loop.
Impact
The entire per-contributor and install-wide open-item cap anti-abuse mechanism (#2270/#2562) is non-functional for any repo that chooses the human-in-the-loop close policy (auto_with_approval) — arguably the more conservative, security-conscious choice a maintainer would pick for an auto-close feature. A contributor or a farming Gittensor miner can accumulate unlimited open PRs/issues past the configured cap with total impunity: the close can never execute regardless of maintainer intent. Confirmed via git history that this is a genuine regression, not an intentional design gap: commit de8bf57 (#2477/#2452, 2026-07-02 00:12) introduced expectedHeadSha pinning + the isUnpinnedRatifyingAction guard for the three closeKinds that existed at the time (blacklist/linked-issue-hard-rule/heuristic); commit 62d51be added contributor_cap ~1 hour later WITHOUT the pin; commit 1092bf3 added review_nag only 44 minutes after that and correctly included the pin — proving the convention was already established and simply missed for contributor_cap. No test in test/unit/agent-actions.test.ts's 'per-contributor open-item cap short-circuit' describe block (lines 2036-2112) or test/unit/agent-approval-queue.test.ts asserts expectedHeadSha for a contributor_cap close, unlike every other closeKind, which independently confirms the gap was never caught.
Severity: CRITICAL
Location:
src/settings/agent-actions.ts:746Found via a full-system adversarial audit of the ORB review/scoring engine (2026-07-15) — 2 independent skeptic passes, both had to vote "confirmed" for this to survive.
Failure scenario
Repo sets contributorOpenPrCap (or the install-wide GLOBAL_CONTRIBUTOR_OPEN_ITEM_CAP) with autonomy.close = "auto_with_approval" (a real, supported, tested AutonomyLevel — see src/types.ts:1450). Contributor 'farmer99' has PR #10 open and opens PR #11, going over cap. planAgentMaintenanceActions (src/settings/agent-actions.ts:741-758) builds a closeKind:"contributor_cap" close action with requiresApproval:true, but — unlike the sibling blacklist (line 730), review_nag (line 779), copycat (line 804) and screenshot_table (line 829) blocks — it never spreads
...(input.pr.headSha ? { expectedHeadSha: input.pr.headSha } : {})onto the action. The action is staged into the approval queue (stageForApproval -> actionParams, src/services/agent-action-executor.ts:955-967), so the persisted pending row's params.expectedHeadSha is always undefined for this closeKind. When the maintainer clicks 'Accept', decidePendingAgentAction (src/services/agent-approval-queue.ts:66) reads stagedHead = pending.params.expectedHeadSha = undefined, then evaluates isUnpinnedRatifyingAction (lines 93-95):!stagedHead && (... || pending.actionClass === "close")is unconditionally true for this row. The function immediately marks the row 'rejected' and returns executionOutcome:"unpinned_legacy_action" (lines 96-107) BEFORE ever reaching the actual close execution at line 399. PR #11 is never closed; the maintainer's accept is silently discarded every single time, and a fresh regate sweep just re-stages the identical unpinned action, producing an infinite accept-then-supersede loop.Impact
The entire per-contributor and install-wide open-item cap anti-abuse mechanism (#2270/#2562) is non-functional for any repo that chooses the human-in-the-loop close policy (auto_with_approval) — arguably the more conservative, security-conscious choice a maintainer would pick for an auto-close feature. A contributor or a farming Gittensor miner can accumulate unlimited open PRs/issues past the configured cap with total impunity: the close can never execute regardless of maintainer intent. Confirmed via git history that this is a genuine regression, not an intentional design gap: commit de8bf57 (#2477/#2452, 2026-07-02 00:12) introduced expectedHeadSha pinning + the isUnpinnedRatifyingAction guard for the three closeKinds that existed at the time (blacklist/linked-issue-hard-rule/heuristic); commit 62d51be added contributor_cap ~1 hour later WITHOUT the pin; commit 1092bf3 added review_nag only 44 minutes after that and correctly included the pin — proving the convention was already established and simply missed for contributor_cap. No test in test/unit/agent-actions.test.ts's 'per-contributor open-item cap short-circuit' describe block (lines 2036-2112) or test/unit/agent-approval-queue.test.ts asserts expectedHeadSha for a contributor_cap close, unlike every other closeKind, which independently confirms the gap was never caught.