Best possible solution:

Land this synchronized workflow/docs/test/skill update only after maintainers confirm the production runner-registration bucket and exact-head CI gates are healthy.

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

Not applicable: this is CI capacity tuning rather than a product bug. The review path is source inspection plus live operations checks for the workflow caps, docs, guard tests, CI status, and rate-limit evidence.

Is this the best way to solve the issue?

Yes, this is the right code shape because the workflow, docs, guard test, and CI-limits skill move together. The unresolved question is operational confirmation of the production runner-registration bucket, not a narrower code fix.

AGENTS.md: found and applied where relevant.

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

Label justifications:

• P3: This is low-risk maintainer CI throughput/admin tuning rather than a user-facing runtime regression.
• merge-risk: 🚨 automation: The diff changes GitHub Actions matrix fanout and can affect CI queueing or runner-registration throttling after merge.
• 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: Not applicable: this is a maintainer-authored CI/admin PR, so the external contributor real-behavior proof gate does not apply; operational bucket confirmation remains a maintainer merge check.

PR surface:

Tests 0, Docs +1, Config 0. Total +1 across 4 files.

What I checked:

• PR diff changes CI fanout caps: The branch raises five Linux Blacksmith-backed caps from 8 to 12 and the large Node shard cap from 16 to 24 while leaving Windows and Android capped at 2. (.github/workflows/ci.yml:861, 6612f6b1bdea)
• Guard test updated with the same caps: The CI workflow guard asserts the new 12/24 Linux caps and still asserts Windows and Android remain at 2. (test/scripts/ci-workflow-guards.test.ts:185, 6612f6b1bdea)
• Docs and skill update the operating target: The public CI docs and CI-limits skill now state a 3,000 registration bucket with a 2,000 per-5-minute operating target. Public docs: docs/ci.md. (docs/ci.md:148, 6612f6b1bdea)
• Current main still has the old limits: Current main retains the 8/16 Linux caps and the 1,500/1,000 registration guidance, so this PR is not already implemented on main. (.github/workflows/ci.yml:861, aca905cce50a)
• Live rate-limit proof gap: GitHub documents actions_runner_registration as the rate-limit object for self-hosted runner registrations, but the available token reports limit=10000, so this check did not verify the PR body's stated 3,000 OpenClaw production bucket. (docs.github.com)
• Recent history points to CI capacity owners: GitHub commit history for the workflow shows recent runner-admission, fanout, CodeQL-off-Blacksmith, and runner-sizing work concentrated around vincentkoc, with recent adjacent CI docs/test changes by RomneyDa and Solvely-Colin. (.github/workflows/ci.yml)

Likely related people:

• vincentkoc: Authored recent runner-admission, fanout, CodeQL-off-Blacksmith, and CI-limits skill work on the same CI capacity surface. (role: feature owner; confidence: high; commits: 607b2e96634c, 7d3bc4d944cd, a1828110704f; files: .github/workflows/ci.yml, docs/ci.md, .agents/skills/openclaw-ci-limits/SKILL.md)
• RomneyDa: Recent workflow-guard and CI-doc history includes multiple adjacent CI changes, including timing summary and release QA evidence updates. (role: recent adjacent contributor; confidence: medium; commits: 899f65097b28, 8a5cb85c31e5, 7e0083ce0b4b; files: .github/workflows/ci.yml, test/scripts/ci-workflow-guards.test.ts, docs/ci.md)
• Solvely-Colin: Recent workflow/docs history includes the QA smoke CI change that touched the same workflow and docs surfaces. (role: adjacent contributor; confidence: low; commits: 4ae0a5d958a0; files: .github/workflows/ci.yml, docs/ci.md, test/scripts/ci-workflow-guards.test.ts)

• 🦀 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.

• 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.