OpenClaw Landable Bug Sweep

Was macht OpenClaw Landable Bug Sweep?

Autonomer Maintainer-Workflow zur Produktion eines angeforderten Batches landbarer OpenClaw-Bugfix-PR-URLs. Verwenden für breite Issue/PR-Sweeps, bei denen die Messlatte hoch ist und die Ausgabe PRs sind, nicht Notizen. Nicht verwenden für Plugin-SDK/API-Grenzarbeiten; diese erfordern eine separate Architekturüberprüfung.

Ziel

Verwende batch_size aus der Anfrage, Standardwert 5, maximiert bei 20. Gib bis zu dieser Anzahl qualifizierter PR-URLs zurück, jede mit:

• Bug-Zusammenfassung
• warum der Fix risikoarm ist
• Nachweis: rebasierter Head lokale/Testbox/live-Befehle oder Run-IDs
• Autoreview: sauberes Ergebnis auf dem exakten gezeigten Head
• CI grün auf dem exakt gepushten PR-Head
• Issue/Duplikat-Bereinigung erledigt oder noch ausstehend

Die URLs können bestehende PRs sein, die überprüft/repariert wurden, oder neue PRs, die aus Issues/Clustern erstellt wurden. Präsentiere dem Maintainer keine PR-URL, bevor sie nicht auf dem aktuellen main aktualisiert, links-getestet, autoreviewt sauber, gepusht und in der live GitHub CI als grün verifiziert wurde. Wenn Code, Tests, Changelog, PR-Body oder Branch-Basis nach dem Autoreview geändert werden, führe das Autoreview erneut durch, bevor du die URL zeigst. Fülle einen Batch nicht künstlich auf, wenn die begrenzte Suche weniger qualifizierte PRs ergibt.

Eingaben

• batch_size: angeforderte Anzahl landbarer PRs; Standard 5, Maximum 20.
• source_mode: discovery oder provided-prs; Standard discovery.
• provided_prs: explizite PR-Referenzen, wenn source_mode=provided-prs.

Im Modus provided-prs inspiziere nur die gelieferten PRs plus direkt verlinkte Duplikat/Kanon-Referenzen, es sei denn, eine breitere Suche ist erforderlich, um den besten Fix zu beweisen.

Begleit-Skills

Verwende $gitcrawl für Discovery/Clustering, $openclaw-pr-maintainer für live GitHub-Mutationsregeln, $github-author-context wenn das Vertrauen in Mitwirkende wichtig ist, $openclaw-testing für die Nachweiswahl, $autoreview vor dem Veröffentlichen/Landen und $crabbox für breite/E2E/live-Nachweise.

Kandidaten-Barriere

Akzeptiere nur, wenn alle zutreffen:

• Bug oder Papierschnitt, kein Feature/Produkt/Support/nur-Dokumentation
• Grundursache ist im aktuellen Code nachgewiesen
• Abhängigkeitsverhalten über Upstream-Dokumentation/Quelle/Typen und relevant geprüft
• Produktions-/Laufzeit-Diff ist klein, idealerweise viel kleiner als 500 LOC und immer unter 500 LOC
• Tests können größer sein, aber fokussiert
• keine neue Abhängigkeit
• keine neue Konfigurationsoption
• kein rückwärtsinkompatibles Verhalten
• keine Sicherheits-/Produkt-/Owner-Grenzentscheidung erforderlich
• keine Plugin-SDK-, öffentliche Plugin-API- oder src/plugin-sdk/**-Grenzänderung
• kein breiter Refaktor-Geruch
• fokussierter Nachweis ist durchführbar
• Branch kann rebased/refresh und gepusht werden, oder ein Ersatz-PR kann erstellt werden

Gute Beispiele:

• Provider-Parameter-Fehlanpassung nachgewiesen gegen Abhängigkeits-/API-Vertrag
• CLI-Befehl weicht vom angrenzenden Befehlsverhalten ab
• schmaler Laufzeit-Zustands-/Serialisierungs-Bug mit fehlschlagendem Test
• Issue bereits auf aktuellem main behoben, mit Nachweis und schließbaren Duplikaten

Ablehnen:

• Feature-Anfragen, neue Stellschrauben, Migrationen, Release-Arbeit, Workflow-Policy, Support
• Plugin-SDK/API-Grenzänderungen, einschließlich Kompatibilitäts-Shims, neue SDK-Methoden, SDK-Exporte oder Plugin-zugewandte Kanal-/Provider-Nähte
• Auth-/Sicherheitsgrenzänderungen, es sei denn, explizit zugewiesen
• Bugs, die live-Zugangsdaten benötigen, die nicht verfügbar sind
• PRs mit roter CI, es sei denn, du reparierst, rebasierst, pushst und überprüfst sie grün
• PRs, die du nur lokal überprüft, aber nicht refreshed/gepusht/live überprüft hast
• PRs, deren finaler Head nicht $autoreview bestanden hat
• Fixes, deren saubere Form ein größerer Architekturzug ist
• spekulative Berichte ohne reproduzierbare/nachweisbare Ursache
• UI/UX-Änderungen, die Produkturteile erfordern

Sweep-Schleife

1. Sauber starten:
   • git status -sb
   • git pull --ff-only
   • überprüfen, ob der Branch erwartet wird, normalerweise main
2. Kandidatencluster bauen:
   • gitcrawl offene Issues/PRs, Nachbarn und Suche
   • live gh issue/pr view
   • PRs einbeziehen, die von Issues und Duplikaten verlinkt sind
3. Für jeden Cluster:
   • Issue/PR-Body, Kommentare, Labels, verlinkte Referenzen, aktuellen Quellcode, angrenzende Tests lesen
   • PRs von Maintainern mit umfassendem Zugriff ausschließen, bis created_at mindestens 14 Tage alt ist; nur ein benannter PR oder eine explizite Maintainer-Arbeitsanfrage überschreibt dies
   • Opener/Autor identifizieren und Credits wahren
   • Entscheiden: repair-existing-pr, create-new-pr, close-fixed-on-main, close-duplicate oder reject
4. Vor dem Patchen beweisen:
   • fehlschlagenden Test, fokussierten Reproducer, Log-/Quellcode-Nachweis oder Abhängigkeitsvertrag-Nachweis
   • falls bereits auf main behoben, mit aktuellem Quellcode/Test/Commit beweisen und freundlich schließen
5. Patchen:
   • bestehenden PR bevorzugen, wenn gut und beschreibbar
   • wenn unbeschreibbar oder falsche Form, eigenen PR erstellen und nützliche Credits von Mitwirkenden wahren
   • wenn kein PR existiert, einen erstellen
   • Regressionstest hinzufügen, wenn es passt
   • Release-Notiz-Kontext für benutzersichtbare Fixes im PR-Body oder Commit-Nachricht; menschlichen Reporter/Mitwirkenden erwähnen, wenn bekannt
6. Überprüfen, Aktualisieren und Veröffentlichen:
   • PR-Branch auf aktuellen origin/main rebasen oder anderweitig aktualisieren
   • Abweichungen auflösen, einschließlich neu aufgetretener CI-Fehler, anstatt den PR als bereit zu zählen
   • CHANGELOG.md während normaler Sweep-PRs nicht hinzufügen; Release-Automatisierung generiert es aus PRs und Commits
   • den rebasierten Head mit dem kleinsten sinnvollen lokalen/Testbox/live-Befehl, der den Bug beweist, links-testen
   • $autoreview ausführen, bis keine akzeptierten/umsetzbaren Befunde mehr übrig sind, bevor eine PR-URL erstellt, aktualisiert oder präsentiert wird
   • PR mit echtem Body und Nachweisfeldern erstellen/aktualisieren
   • den exakt überprüften Head pushen
   • überprüfen, dass die live GitHub CI für diesen gepushten Head grün ist; ausstehende, rote, schmutzige, konfliktbehaftete oder extern blockierte PRs nicht in die fünf zählen
7. Hygiene:
   • Duplikate und auf main behobene Issues/PRs mit Nachweis schließen, sobald du sie während des Sweeps bemerkst
   • nie mehr als fünf zugehörige Elemente in einem Cluster ohne explizite Bestätigung mutieren
   • Kommentare müssen freundlich, konkret sein und Nachweis-/PR-/Commit-Links enthalten
8. Wiederholen, bis batch_size landbare PR-URLs bereit sind oder die begrenzte qualifizierte Warteschlange erschöpft ist.

PR-Body-Nachweis

Verwende die PR-Vorlage des Repos. Füge die Abschnitte ## What Problem This Solves und ## Evidence hinzu. Halte den Body fokussiert auf die Absicht und die nützlichsten Validierungsnachweise; inspiziere Code, Tests und CI, bevor du die Korrektheit beurteilst.

Bestehende PR-Regeln

• Code-Pfad jenseits des Diffs überprüfen, bevor du ihm vertraust.
• Wenn PR gut ist: auf aktuellem main rebasen/aktualisieren, kleine Probleme beheben, links-testen, autoreview sauber, pushen und CI grün bekommen, bevor du ihn zeigst oder zählst.
• Wenn PR nicht gut ist, aber eine nützliche Idee hat: lokal neu erstellen, Co-Autor, wenn angebracht, Original mit Dank und Erklärung schließen.
• Wenn PR ein Duplikat ist oder auf main behoben wurde: Nachweis kommentieren, schließen.
• Wenn Maintainer nicht in den Contributor-Branch pushen kann: eigenen Branch/PR erstellen, nützliche Commits oder Credits wahren.
• Wenn CI nach lokalem Nachweis rot wird, behandle das als normale Arbeit: fehlschlagenden Job inspizieren, reparieren oder ablehnen, erneut ausführen und den PR erst zählen, wenn er grün ist.

Ausgabe-Ledger

Führe ein fortlaufendes Ledger:

accepted:
- PR URL:
  source refs:
  bug:
  root cause:
  fix:
  risk:
  rebase/head:
  left-test:
  autoreview:
  CI:
  credit/thanks:
  cleanup:

rejected:
- ref:
  reason:

closed:
- ref:
  reason:
  proof/comment:

Finale Antwort:

• die angeforderte Anzahl akzeptierter PR-URLs oder die kleinere qualifizierte Anzahl mit dem Grund der erschöpften Suche
• 2-4 Satz-Erklärung pro PR
• Nachweis/CI-Status pro PR
• geschlossene Duplikate/auf-main-behobene Referenzen
• aktueller Branch/Status