fix(ci): cap ClawSweeper worker bursts

[vincentkoc]

Summary

• lower the shared ClawSweeper worker budget from 128 to 64 and reduce background/repair/exact-review ceilings
• reduce scheduled sweep fan-out and enforce an 8-slot durable exact-review queue
• synchronize dashboard, workflow, docs, changelog, and capacity tests

Verification

• pnpm run build
• pnpm run build:repair plus 563 repair tests passing
• pnpm run build:dashboard plus 46 dashboard tests passing
• pnpm run check:limits
• pnpm run format:check
• git diff --check
• branch autoreview clean

The change is intentionally conservative around GitHub secondary-rate-limit pressure: scheduled/repair lanes yield to priority work and the exact-review queue cannot exceed 8 concurrent leases.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed June 22, 2026, 12:30 AM ET / 04:30 UTC.

Summary
This PR lowers shared ClawSweeper worker and exact-review queue limits across automation config, the sweep workflow, dashboard Worker defaults, docs, changelog, and capacity tests.

Reproducibility: not applicable. this is an automation capacity-tuning PR rather than a user-facing bug report. I checked the source limit derivation and PR diff instead of reproducing a runtime failure.

Review metrics: 3 noteworthy metrics.

• PR surface: 16 files, +87/-85. The change is broad enough across workflow, Worker config, docs, and tests that maintainers should review consistency before merge.
• Global worker budget: 128 -> 64. This is the main operational capacity reduction and controls several derived lane defaults.
• Exact-review queue cap: config 32 -> 8; dashboard default 40 -> 8. Exact-review admission is the most latency-sensitive cap changed by the PR.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P2] Let pnpm check finish before merge and refresh the PR body if validation changes.

Risk before merge

• [P1] Merging intentionally halves the global worker budget and caps exact-review admission at 8, so review, repair, and implementation backlog latency can rise if the lower cap is too conservative.
• [P1] The dashboard Worker runtime must pick up the changed WORKER_BUDGET and EXACT_REVIEW_QUEUE_MAX_CONCURRENT values, or live admission/status can diverge from the checked-in docs and config.

Maintainer options:

1. Land with operational monitoring
   Maintainers can accept the lower caps and watch exact-review queue depth, backfill age, and repair latency after deployment.
2. Tune caps before merge
   If the expected backlog impact is too high, adjust workers.max or the exact-review queue cap in this PR before landing.
3. Pause until capacity data is clear
   If the rate-limit incident data is not enough to justify the throughput reduction, keep the draft open until live metrics support the new budget.

Next step before merge

• [P2] Keep this draft MEMBER-authored automation-capacity PR in maintainer review; there is no narrow repair finding for ClawSweeper to queue.

Security
Cleared: The diff only changes numeric workflow/dashboard capacity defaults plus docs/tests; it adds no action refs, permissions, secrets handling, dependencies, or downloaded code execution.

Review details

Best possible solution:

Land the coordinated lower-cap defaults only after maintainers accept the automation-throughput tradeoff and CI confirms the updated capacity matrix.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is an automation capacity-tuning PR rather than a user-facing bug report. I checked the source limit derivation and PR diff instead of reproducing a runtime failure.

Is this the best way to solve the issue?

Yes, the implementation uses the existing central config-derived limit model and synchronizes workflow, dashboard, docs, and tests. The remaining question is the maintainer policy choice around lower throughput versus rate-limit relief.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 855cffa7c7ae.

Label changes

Label changes:

• add P2: This is a normal-priority automation reliability improvement with meaningful but bounded operational impact.
• add merge-risk: 🚨 automation: The diff changes workflow and dashboard capacity controls, so merging can alter review/repair dispatch behavior even when tests pass.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The external-contributor proof gate does not apply because this is a MEMBER-authored draft; the PR body lists build, dashboard, repair, limits, format, and diff-check validation.

Label justifications:

• P2: This is a normal-priority automation reliability improvement with meaningful but bounded operational impact.
• merge-risk: 🚨 automation: The diff changes workflow and dashboard capacity controls, so merging can alter review/repair dispatch behavior even when tests pass.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The external-contributor proof gate does not apply because this is a MEMBER-authored draft; the PR body lists build, dashboard, repair, limits, format, and diff-check validation.

Evidence reviewed

What I checked:

• AGENTS policy read: Target AGENTS.md was read fully; its automation-safety, protected maintainer-authored item, and throughput/default tuning guidance apply to this review. (AGENTS.md:1, 855cffa7c7ae)
• Current limit derivation: Current main derives review, commit, repair, hard-cap, and issue-implementation defaults from config.workers.max, so the config change is the central runtime knob rather than a missed parallel source constant. (src/repair/limits.ts:76, 855cffa7c7ae)
• Workflow scheduler path: Current sweep.yml reads derived limits through the workflow utility and caps broad shard_count to lane and hard caps, which matches the PR's workflow/default-cap surface. (.github/workflows/sweep.yml:1009, 855cffa7c7ae)
• PR diff surface: The PR changes 16 files with numeric capacity/default updates in workflow, config, dashboard Worker settings, docs, changelog, and two focused tests; it does not add dependencies, permissions, or new third-party execution. (config/automation-limits.json:1, 23a3fc82cbd9)
• PR metadata and workflow state: GitHub reports this PR as draft, authored by vincentkoc, mergeable but unstable, with pnpm check still pending at review time and no human review comments yet. (23a3fc82cbd9)
• Adjacent prior work: Merged fix(ci): reduce ClawSweeper GitHub API pressure #343 reduced GitHub API pressure in nearby workflow/code paths, but it did not replace this worker-burst cap PR. (1566ad6a0a5b)

Likely related people:

• vincentkoc: Recently landed adjacent GitHub API-pressure work touching sweep workflow and src/clawsweeper.ts, and that merged history is directly adjacent to this capacity-cap change. (role: recent area contributor; confidence: high; commits: 1566ad6a0a5b; files: .github/workflows/sweep.yml, src/clawsweeper.ts)
• Peter Steinberger: Blame and log show the central worker config, derived limits, workflow scheduler path, and exact-review queue expansion primarily date to Peter's release and queue-capacity commits. (role: feature introducer and adjacent owner; confidence: high; commits: dc824915bb6c, 30163dfd667b; files: config/automation-limits.json, src/repair/limits.ts, .github/workflows/sweep.yml)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.