Was macht OpenClaw-Korrektur kleiner Fehler?
Batch-Workflow für eingefügte OpenClaw-Issue/PR-Referenzen. Ausführen, nicht zusammenfassen. Triage-Überprüfungen, Nachweise und Patches erfolgen lokal; Veröffentlichung wartet auf Peters manuelle Überprüfung.
Peter-Überprüfungs-Gate
Peter möchte den Code vor Commits immer überprüfen. Standardablauf:
- Jede Issue gründlich überprüfen, um das aktuelle Verhalten und die Ursache nachzuweisen.
- Nur einfache, hochsichere Fehler mit begrenztem Umfang und fokussiertem Nachweis beheben.
- Mit der Zusammenfassung des Dirty-Diffs, der betroffenen Dateien und der Test/Gate-Ausgabe für Peters manuelle Überprüfung aufhören.
- Nachdem Peter die Auslieferung genehmigt hat, einen Commit pro akzeptiertem Fix mit einem Changelog-Eintrag für jeden benutzersichtbaren Fix erstellen.
- Pull/Rebase, Push, dann die behobenen oder explizit triagierten/geschlossenen Issues kommentieren und schließen.
Keine themenfremden Issue-Fixes in einen Commit bündeln. Während der Überprüfungs-/Nachweisphase nicht pushen, PRs erstellen, kommentieren, schließen, labeln, landen, mergen oder anderweitig veröffentlichen.
Begleit-Skills
Zuerst $gitcrawl verwenden, dann $openclaw-pr-maintainer für die Live-GitHub-Pflege, $github-deep-review für die Quellenverfolgung und $openclaw-testing für den Nachweis.
Schleife
Für jede Referenz:
- Live-Ziel mit
ghlesen. - Mit
gitcrawlnach verwandten, doppelten, geschlossenen oder bereits behobenen Threads suchen. - Body, Kommentare, verlinkte Referenzen, geänderte Dateien, aktuellen Code, angrenzende Tests und bei Bedarf Abhängigkeitsverträge lesen.
- Den tatsächlichen Laufzeit-Pfad verfolgen.
- Bei Issues: Nur lokal beheben, wenn es sich um einen Bug handelt, der aktuelle Code die Ursache belegt, der betroffene Pfad klar ist und ein schmaler Patch sauberer als ein Refactoring ist.
- Bei PRs: Entscheiden
ready-to-merge,needs-fixupoderskip; PR-Branches nicht ändern, es sei denn, es wird explizit darum gebeten. - Fokussierten Regressionsnachweis hinzufügen, wenn dies für lokale Issue-Fixes oder PR-Bereitschaftsprüfungen praktikabel ist.
- Das kleinste sinnvolle Gate ausführen.
- Fortfahren, bis jede eingefügte Referenz behoben oder klassifiziert ist.
Keine Unteragenten, es sei denn, es wird explizit angefordert.
Überspringen, wenn
- kein Bug
- Konfigurations-/Dokumentations-/Workflow-/Release-/Support-/Abhängigkeits-/Produktarbeit
- Reproduktion oder Ursache unsicher
- größeres Refactoring oder Änderung der Besitzergrenze sauberer
- bereits auf aktuellem
mainbehoben - Abhängigkeitsverhalten wird vermutet
- kein fokussierter Nachweis möglich
Mit knapper Begründung überspringen. Nicht mit unsicheren Fixes aufblähen.
Fix-Regeln
- zuerst das Besitzermodul; generische Naht nur bei Bedarf
- bestehende Muster/Helper/Typen verwenden
- keine unwesentlichen Refactorings
- Tests in der Nähe der fehlerhaften Oberfläche
- Docs nur bei geändertem öffentlichem Verhalten
- kein Commit während der Überprüfungs-/Nachweisphase
- nach Peters Genehmigung zum Ausliefern: ein Commit plus Changelog pro akzeptiertem benutzersichtbarem Fix
- kein Push/PR-Erstellen/Kommentieren/Schließen/Labeln/Landen/Mergen bis Peter nach Überprüfung die Auslieferung genehmigt
PR-Regeln
ready-to-merge: Code ist gut, aktueller Head geprüft, erforderlicher Nachweis ist grün oder hängt nur noch von externer CI ab; für Maintainer-Merge oder@clawsweeper automergeauflistenneeds-fixup: kleiner Bug ist klar, aber PR-Branch benötigt Änderungen; genaue Dateien/Tests auflisten und auf explizite Fix-/Push-/Automerge-Anweisung wartenskip: breit, veraltet, spekulativ, Konfigurations-/Produkt-/Sicherheits-/Release-Arbeit, Besitzergrenze oder Refactoring-Größe- wenn der Quell-PR nicht vertrauenswürdig/nicht bearbeitbar ist, während des Sweeps keinen Ersatz-PR erstellen
Ausgabeformat
Ledger: fixed-local, ready-to-merge, needs-fixup, skipped, needs-human.
Abschluss: Issue-Dateien auf der Platte belassen, PRs bereit für Merge/Automerge, Tests/Gates, Überspringungsgründe.