fix(automation): stop mention sweep on already-exceeded rate limits

[cursor]

Why this PR exists

#1012 correctly stops the mention sweep after an exact API rate limit exceeded string. That needle misses GitHub's API rate limit already exceeded wording, does not reproduce the repository-listing path that produced 116 isolated failures, and lets the scheduled CLI crash with a traceback instead of telling the operator the next action.

What to do after this lands

Merge this head instead of, or immediately after, #1012. After merge, wait for the next scheduled Review Agent Mention Router run. If that run prints ::error:: and rate limit, wait for the installation REST budget to reset. Do not re-run the sweep immediately.

Test-first repair

• RED: API rate limit already exceeded was not classified; the incident-path listing test expected ::error:: and a wait instruction; main() re-raised SweepRateLimitExhausted.
• GREEN: classification now requires rate limit plus exceeded/exhausted, or secondary rate limit; repository-listing and dispatch-time exhaustion stop before later work; main() returns 1 with an operator next action.
• Doctoring, ARCHITECTURE, and CHANGELOG record the boundary and APA 7th GitHub REST/App/GraphQL/best-practice citations.

Boundary

No retry, sleep, credential rotation, permission widening, reviewer-identity change, invocation-key change, or ledger weakening. Ordinary candidate-local failures stay isolated.

Verification

coverage run over the mention-sweep suite is 100% statements/branches on scripts/ci/agent_mention_sweep.py. interrogate on that module is 100%.

  

[seonghobae]

Rebased the four-commit mention-sweep rate-limit fail-fast series onto current origin/main c47bee5.

Current HEAD: 97f99fb

Validation on this HEAD:

• pytest -q tests/test_agent_mention_rate_limit.py tests/test_agent_mention_sweep.py: 13 passed
• interrogate: 100%
• compileall and git diff --check passed

@OpenCode review this exact HEAD after the rebase.

[seonghobae]

Exact-current-head repair loop: rebased onto protected main 2cce96f, preserved fail-closed rate-limit classification and operator next action. Current head 2cd701f. Focused rate-limit tests (5) passed; interrogate, compileall, and diff-check passed. Hosted Checks are regenerating; keep Draft and review this exact head only.

[seonghobae]

Exact-head audit — WAIT_AND_REMEDIATE

• Exact head: 7b1c5c54e6b3d7e481fcbc9ff05019d161a5b0c8
• Exact base: 6a79f075d62b5f8dcfef6145960f1c42c147f273
• PR remains Draft; no merge or bypass is authorized.
• The current tree includes the rate-limit fail-fast repair and a normal merge of the current protected main.
• Focused regression/contract suite: 141 passed.
• git diff --check: passed.
• Local actionlint 1.7.12 reports concurrency.queue as unexpected, but current GitHub Actions documentation defines queue: max (up to 100 pending runs). The workflow is intentionally retained; this is a local validator-version mismatch, not a source failure: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency
• Hosted required Checks must complete for this exact head, and an independent substantive approval is still absent.

Decision: WAIT_AND_REMEDIATE. Do not force merge.

[seonghobae]

Exact-head audit — WAIT_AND_REMEDIATE

• Exact head: eaee0aa80501d797439a8eeb90bf33de0d2c7a70
• Exact base: 6a79f075d62b5f8dcfef6145960f1c42c147f273
• Fixed the observed exact-head-path-policy failure: the rate-limit repair branch's Strix contract assertions now match the live scheduler concurrency expressions.
• Local validation: 141 passed, shell syntax passed, and git diff --check passed.
• The PR remains Draft; hosted required Checks must rerun against this exact head and an independent approval is absent.
• The local queue: max warning remains a validator-version mismatch; it is supported by current GitHub Actions syntax and was not weakened.

Decision: WAIT_AND_REMEDIATE.

[seonghobae]

Exact-head audit update\n\nObserved hosted pip-audit failure on the prior head: PYSEC-2026-3721 through pip 26.1.2.\nRoot-cause fix: refreshed the hash-locked CI dependency to pip 26.2.1 with both package hashes.\n\nExact head: df86ac4\nExact base: 6a79f07\nLocal verification: pip-audit clean; 22 mention-rate-limit/sweep regression tests passed; diff checks passed.\nGitHub currently reports the branch behind and still draft; required checks and exact-head approval remain pending. Decision remains WAIT_AND_REMEDIATE.

[seonghobae]

Triage (2026-09-02): base history is orphaned, not a resolvable merge conflict

This PR's base commit 0156282022134484ea9d7541d5ba0730ba14fd96 is not an ancestor of current main:

$ git merge-base --is-ancestor 0156282022134484ea9d7541d5ba0730ba14fd96 origin/main && echo yes || echo no
no
$ git merge origin/main --no-edit
fatal: refusing to merge unrelated histories

origin/main now has multiple historical roots (a restructuring/history-splice happened after this branch was cut from an older main), so there is no common ancestor for an ordinary 3-way merge. Forcing --allow-unrelated-histories would diff every shared file against an empty tree and manufacture spurious conflicts across the whole tree — not a real fix, and not something to push through mechanically.

The mergeable_state: dirty GitHub reports here reflects that structural gap, not a normal content conflict this session's usual merge-main-and-resolve recipe can repair.

Next action (needs a human/design call): either (a) reimplement the intent of this PR as a fresh branch cut from current main — the historical commits can't be replayed as-is — or (b) verify whether the underlying gap (mention-sweep rate-limit classification) is already closed on current main, since predecessor #1012 was itself closed unmerged around the same time this history diverged, and close this as superseded if so. Not closing this myself since I haven't verified a live successor covers it. Leaving open pending that decision.

---

Generated by Claude Code

[seonghobae]

Retraction — the "main history splice" diagnosis was wrong.

An earlier comment on this PR claimed main's history was spliced onto new roots around 2026-08-20/21, that this PR's base predates the boundary, and that an ordinary merge would fail with fatal: refusing to merge unrelated histories requiring a from-scratch re-implementation. That diagnosis is incorrect — please disregard it entirely.

Root cause: the analysis was run from a shallow git clone in the analysis sandbox (git rev-parse --is-shallow-repository → true). A shallow clone's truncation boundary commits look exactly like disjoint history roots, and git merge from inside a shallow checkout genuinely does throw fatal: refusing to merge unrelated histories even when the real, full history is perfectly linear and connected. After git fetch --unshallow, origin/main has exactly one root commit, and this PR's base is a completely normal ancestor of current main.

This PR should be triaged the ordinary way: fetch a full (non-shallow) clone, git fetch origin main && git merge origin/main --no-edit, resolve any real content conflicts, run the repo's gates, and push. There is no history-splice blocker and no need to abandon or re-implement this PR's work.

Apologies for the incorrect guidance. See #1722 for the corrected writeup.

---

Generated by Claude Code