Context
A maintainer review-stack × Autonomous Miner System (AMS) integration audit (2026-07-09) found that the only cross-repo defense against one identity opening PRs across many gated repos at once is off by default and has no awareness of the confirmed_miner role that already exists elsewhere in the codebase.
Evidence
src/queue/processors.ts:2946-2996 — the per-repo contributorOpenPrCap enforcement counts only listOtherOpenPullRequestsForAuthor(env, repoFullName, ...), i.e. single-repo scope.src/settings/global-contributor-cap.ts — resolveGlobalContributorOpenItemCap returns null (no cap at all) whenever GLOBAL_CONTRIBUTOR_OPEN_ITEM_CAP is unset/invalid; its own comments describe it as "cross-repo-within-one-install only (no federation, no cross-instance)."src/settings/command-authorization.ts — the confirmed_miner actor tier is real and live for @gittensory command authorization, but is never consulted by either PR cap.- The only exemption mechanism for both caps is the flat, manually curated
autoCloseExemptLogins allowlist (src/settings/auto-close-exempt.ts) — no role-based exemption exists.
Why this matters for the Autonomous Miner System
Once the Miner Wave 3 orchestration loop (#2333, #2336, #2337) starts opening PRs autonomously, a legitimate miner fleet arriving at scale would need an operator to have proactively turned this cap on and individually allowlisted every miner login beforehand — otherwise it gets throttled identically to a farming attack on day one. This complements the miner's own self-throttling in the Governor epic (#2341 kill-switch, #2344 rate-limit) — that's the miner policing itself; this is the review stack's own admission-time defense, which currently has no sane default posture for a known-good fleet.
Deliverables
Surfaced by a maintainer review-stack × AMS integration audit (2026-07-09). Related: #2341, #2344 (miner-side Governor throttling), #2270/#2562 (the existing per-repo/install-wide caps this issue extends).
Context
A maintainer review-stack × Autonomous Miner System (AMS) integration audit (2026-07-09) found that the only cross-repo defense against one identity opening PRs across many gated repos at once is off by default and has no awareness of the
confirmed_minerrole that already exists elsewhere in the codebase.Evidence
src/queue/processors.ts:2946-2996— the per-repocontributorOpenPrCapenforcement counts onlylistOtherOpenPullRequestsForAuthor(env, repoFullName, ...), i.e. single-repo scope.src/settings/global-contributor-cap.ts—resolveGlobalContributorOpenItemCapreturnsnull(no cap at all) wheneverGLOBAL_CONTRIBUTOR_OPEN_ITEM_CAPis unset/invalid; its own comments describe it as "cross-repo-within-one-install only (no federation, no cross-instance)."src/settings/command-authorization.ts— theconfirmed_mineractor tier is real and live for@gittensorycommand authorization, but is never consulted by either PR cap.autoCloseExemptLoginsallowlist (src/settings/auto-close-exempt.ts) — no role-based exemption exists.Why this matters for the Autonomous Miner System
Once the Miner Wave 3 orchestration loop (#2333, #2336, #2337) starts opening PRs autonomously, a legitimate miner fleet arriving at scale would need an operator to have proactively turned this cap on and individually allowlisted every miner login beforehand — otherwise it gets throttled identically to a farming attack on day one. This complements the miner's own self-throttling in the Governor epic (#2341 kill-switch, #2344 rate-limit) — that's the miner policing itself; this is the review stack's own admission-time defense, which currently has no sane default posture for a known-good fleet.
Deliverables
GLOBAL_CONTRIBUTOR_OPEN_ITEM_CAPa real default when unset (instead of "no cap"), sized for realistic fleet cadenceconfirmed_miner-aware exemption/allowance path (distinct from the flat login allowlist) so a verified miner identity gets a fleet-appropriate cap instead of either "no cap" or the plain human-contributor default.gittensory.yml/ env var reference updateSurfaced by a maintainer review-stack × AMS integration audit (2026-07-09). Related: #2341, #2344 (miner-side Governor throttling), #2270/#2562 (the existing per-repo/install-wide caps this issue extends).