Best possible solution:

Land the docs/skill update only after a maintainer confirms the 10,000 live bucket and 60% target are the intended CI operating policy; keep workflow cap changes separate.

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

Not applicable for a docs/skill PR. The stale current-main text is source-verifiable in docs/ci.md and .agents/skills/openclaw-ci-limits/SKILL.md, and the live rate_limit check verifies the current 10,000 bucket claim.

Is this the best way to solve the issue?

Yes. Updating the public CI runbook and matching maintainer skill is the narrowest maintainable fix for stale operator guidance; workflow cap changes should remain in a separate guarded PR.

AGENTS.md: found and applied where relevant.

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

Label changes:

• add P3: This is a low-risk maintainer docs/skill update for CI operator guidance with no runtime or workflow behavior change in the current head.
• add merge-risk: 🚨 automation: The PR changes CI automation operating guidance that maintainers and agents may use for future runner-budget tuning, and green CI does not prove the live GitHub quota remains stable.

Label justifications:

• P3: This is a low-risk maintainer docs/skill update for CI operator guidance with no runtime or workflow behavior change in the current head.
• merge-risk: 🚨 automation: The PR changes CI automation operating guidance that maintainers and agents may use for future runner-budget tuning, and green CI does not prove the live GitHub quota remains stable.
• rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🌊 off-meta tidepool and patch quality is 🦞 diamond lobster.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This is a maintainer/MEMBER docs and skill PR, so the external contributor real-behavior proof gate does not apply; the PR body includes live API output and validation commands.

PR surface:

Docs +7. Total +7 across 2 files.

What I checked:

• Live PR state: Live GitHub metadata shows the PR is open, mergeable, labeled maintainer, and currently at head 05c0f492969e68b19f8981a3693aa529ca16ebad with only .agents/skills/openclaw-ci-limits/SKILL.md and docs/ci.md modified. (05c0f492969e)
• Current main stale public docs: Current main still says the runner-registration bucket allows 3,000 self-hosted registrations per 5 minutes and sets the target below 2,000 registrations. Public docs: docs/ci.md. (docs/ci.md:148, 052dc59526a2)
• Current main stale skill guidance: Current main's CI limits skill repeats the 3,000 bucket and 2,000 operating target in its Core Facts and budget math. (.agents/skills/openclaw-ci-limits/SKILL.md:16, 052dc59526a2)
• PR diff scope: The current diff updates only the two guidance surfaces to check actions_runner_registration live and use about 60% of the live bucket, with 10,000/6,000 as the current example. Public docs: docs/ci.md. (docs/ci.md:146, 05c0f492969e)
• Live quota check: A read-only rate_limit API call returned actions_runner_registration.limit=10000 and remaining=10000, matching the PR body and proposed current target.
• Workflow guard context: Current tests still pin the CI fan-out caps and hosted runner-admission debounce, which supports the PR body's claim that this head changes guidance rather than workflow behavior. (test/scripts/ci-workflow-guards.test.ts:178, 052dc59526a2)

Likely related people:

• vincentkoc: Prior merged work introduced and adjusted the CI runner-registration cap guidance across the skill, public docs, workflow, and guard test; inclusion is based on that merged history, not just authorship of this PR. (role: recent CI-limits owner; confidence: high; commits: 137371c64f25, 6612f6b1bdea, a82902c725b2; files: .agents/skills/openclaw-ci-limits/SKILL.md, docs/ci.md, .github/workflows/ci.yml)
• cxbAsDev: Current blame for the stale 3,000/2,000 guidance maps to commit 0ce10d779302bb12f3f287bb519299a11142fb5b; this is weaker routing evidence because the commit appears to be a broad docs/skill import rather than focused CI ownership. (role: line-level current-main provenance; confidence: low; commits: 0ce10d779302; files: docs/ci.md, .agents/skills/openclaw-ci-limits/SKILL.md)

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