OpenClaw Repair Sweep
Use for a multi-item repair campaign. Root AGENTS.md owns repair and safety
policy; $openclaw-pr-maintainer owns item review, GitHub writes, and landing.
The lead remains hands-on and delegates independent work where useful.
Scope and authority
- Explicit refs imply a bounded ref campaign. Otherwise discovery defaults to five qualified items (maximum twenty per batch); a whole-queue request means continuing through that queue. Do not pad low-confidence findings.
- Honor requested workers and focus. Ref/discovery campaigns normally use up to eight item owners; a queue campaign can assign up to sixty-four, but actual active proof workers must fit host/remote capacity. Start small and scale on observed resource health; assigned is not the same as running.
- An explicit autonomous fix-and-land/sweep invocation covers scoped investigation, repairs, commits, pushes, PRs, verified landings and proven closures. Review, triage, or list wording stays read-only; fix-only stops before publication. Never infer release, schema/config/protocol, credential, security, or product approval from campaign authority.
Use $gitcrawl for available archive discovery, $openclaw-testing for proof,
$autoreview for independent code review, and $crabbox when the proof requires
remote environment or untrusted-source isolation. Author-history research is
conditional on a concrete question, not a campaign prerequisite.
Coordinate ownership
Assign each item or shared root-cause cluster one owner, a checkout, frozen source SHA, authorized actions, and a useful stopping condition. Duplicate symptoms share an owner; repeated defect classes should be repaired in the canonical owner rather than by parallel near-identical patches.
Use isolated issue/PR worktrees and preserve unrelated files. Serialize shared fetch/ref/branch/worktree operations, PR preparation, and merges in short slots; never hold the slot across coding, tests, or a remote wait. Each remote lease has one owner and one active command. Pause only campaign-owned work under resource pressure, and preserve patches, claims, proof, and checkpoints before replacement. The lead may take over stalled work safely; it is not an orchestration-only role.
Read root and scoped guides before acting. Each verdict-bearing worker inspects its relevant dependency contracts directly, including the root's personal Codex source requirement. The lead verifies consequential results, not just summaries. Use independent challenge for nontrivial repairs and closure evidence; one independent autoreview is enough for the code-review requirement.
Investigate and repair
Search existing work before creating another fix: current body/comments, related
archive results, live state when it matters, and current source/history. Use bare
PATH gh with narrow JSON fields; reuse shared evidence and avoid unnecessary
pagination or repeated item fetches.
Prefer, in order:
- Prove the original behavior is already fixed on current main and close under the authorized scope with the canonical fix and evidence.
- Finish and verify an existing useful editable PR, preserving human credit.
- If that PR cannot safely be updated, create a credited replacement before closing it. Do not squash a contributor PR after replacing its ancestry.
- Implement a new high-confidence repair when no suitable fix exists.
- Record a concrete blocker or product/owner decision. A useful independent simplification may land under its own scope, but it does not close the bug.
A candidate needs a demonstrated current defect, an understood owner and bounded impact, relevant dependency proof, and feasible validation. Repairs requiring new dependencies/configuration, public-contract changes, security, persistence design, or product judgment require their root approvals before implementation or landing as applicable. Preserve useful investigation; do not work around the gate or count review-required work as an accepted fix.
Repair the invariant at its owner, cover relevant siblings, and remove connected
obsolete paths when justified. Do not add speculative fallback layers or hardcode
the reported example. Prefer simplicity without a LOC quota. Keep release-note
context and credit in the PR; CHANGELOG.md remains release-owned. Do not force a
second refactor PR after each completed item.
Proof and landing
Choose proportional proof through $openclaw-testing. Trusted development can
run locally; remote compute needs an environment or isolation reason. Untrusted
repository tooling never runs locally or on a credential-hydrated host. Preserve
explicit live requirements and never describe a mock, skipped test, old head, or
unfinished soak as live proof.
Run $autoreview on the completed nontrivial candidate and resolve verified
findings. Re-review substantive changes or unresolved concerns; do not multiply
reviews for mechanical head movement. Address actionable human/bot findings
without a separate Rank-up checklist or score-refresh gate.
Land through the native maintainer workflow only with current required CI and review evidence. Verify remote merge state and ancestry before counting success. A timed-out merge request may have succeeded; reconcile it before retrying. Refresh/rebase for conflicts, failed guards, explicit requests, or material stale base risk, not merely because main advanced. Delete only owned temporary state.
For broad campaigns, a shared-main failure may justify one separately scoped repair worker. Check for an existing fix first. Do not duplicate that repair in every PR or silently expand a bounded ref request to unrelated CI work.
Closure and reporting
Before closing, prove the reporter's primary outcome and affected surfaces are fixed, not merely mitigated or diagnosed. Check fix ancestry and containing tags when version claims matter; dates do not prove inclusion. Seek independent challenge for uncertain or consequential closure evidence. Disagreement, a still broken surface, or an owner hold means leave open. Product rejection is a maintainer decision, never an automatic cleanup conclusion.
Recheck live state before mutation and explain the fixed behavior, canonical commit/PR, known containing version, and useful proof. If a closure is challenged, pause the affected closure work and correct the evidence before resuming. No more than three workers should hold simultaneous closure duty; more than fifty close/reopen actions require the root's explicit count/scope approval.
Keep a resumable ledger of owner, source/head, outcome, proof/CI state, PR/merge, credit, blockers, and cleanup. Count verified outcomes, not planned or launched work. Report meaningful progress and each verified landing with links; summarize final behavior, proof, remaining limitations, and checkout state in natural prose.
