ClawSweeper 0.2.0 adds guarded PR repair and automerge loops

• openclaw's 0.2.0 announcement says ClawSweeper now runs a full maintenance loop from issue triage to fix/build, guarded PR creation, review, repair, re-review, and automerge.
• According to steipete's launch post, the bot is open source, runs on Codex, and is meant to be forked for other repositories instead of staying OpenClaw-only.
• The official ClawSweeper docs describe four separate lanes, Review, Apply, Repair, and Commit Review, plus one durable marker-backed comment per issue or PR.
• The repair docs at ClawSweeper Repair say the re-review loop is bounded, skips stale heads, and caps automatic repairs at ten per PR and one per head SHA.

You can browse the project repo, read the Work Lane docs on how an issue graduates into queue_fix_pr, and dig into the operations page, which draws a hard line between narrow bug fixes that can open PRs and security or broad findings that stay audit-only. steipete's Crabboxes validation screenshot also shows the bot validating a macOS-only launchd bug through a fresh remote test target, which is a nice tell for the kind of bug backlog this thing is aiming at.

The big change in 0.2.0 is that ClawSweeper is no longer just a reviewer or closer. openclaw's 0.2.0 announcement frames it as an issue-to-PR loop, and the official Work Lane docs show the gate that makes that possible: reviews can mark an item as queue_fix_pr only when the report looks valid, narrow, and safe for a single repair PR.

That queue is still manual promotion, not free-running autonomy. The docs list explicit work-candidate fields like reproduction status, confidence, likely files, and whether the fix would require a new feature or config option, which keeps product decisions out of the auto-repair path.

The official homepage describes ClawSweeper as four separate operational lanes:

• Review: proposal-only analysis that writes one markdown record per item.
• Apply: comment sync and high-confidence close actions.
• Repair: bounded fixes for trusted needs-changes findings.
• Commit Review: scans commit-level findings and can escalate narrow regressions.

The same page also spells out the close policy. ClawSweeper only proposes closing items that are implemented, unreproducible, duplicate, incoherent, clearly stale, or better handled outside core, and maintainer-authored items stay open.

The Repair docs add the mechanics tweet 0 only hints at. Maintainers can opt an existing PR into /clawsweeper autofix for repair-only handling or /clawsweeper automerge for a bounded merge loop, and the loop is marker-driven so only comments with clawsweeper-action:fix-required trigger another pass.

The operations page narrows the blast radius further. ClawSweeper will open a PR only for ordinary, narrow bug or regression candidates, while security, privacy, supply-chain, and other broad findings are kept audit-only.

Steipete's macOS screenshot shows why the project bothers with this extra machinery. The validation log runs Go tests, plugin checks, and a launchd test suite through a Crabbox-hosted macOS SSH target, then records 46 unit tests and 4 real launchd integration tests passing.

That is a more interesting target than generic issue triage. It suggests ClawSweeper is being wired into reproducibility-heavy maintenance work where a fresh environment matters, not just comment drafting and duplicate closure.

One piece of maintainer lore surfaced in a retweeted reply thread: early versions had no PR limit and flooded maintainers, then moved to a 10-open-PR cap. That lines up with the product's whole posture, conservative automation first, throughput second.

The repair docs add two more concrete caps: automatic repairs stop at ten per PR, and ClawSweeper only attempts one repair per PR head SHA before waiting for a new state. Combined with the public PR cap, 0.2.0 looks less like a bot that learned to code and more like a bot that learned to queue.