OpenClaw 小さなバグ修正スイープ
貼り付けられたOpenClaw Issue/PR参照に対するバッチワークフロー。 実行のみ行い、要約はしない。 トリアージ、レビュー、証明、ローカル修正のパッチ適用を先に行い、公開はPeterの手動レビューを待つ。
Peter レビューゲート
Peterは常にコミット前にコードをレビューしたい。 デフォルトの流れ：
- 各Issueを、現在の動作と根本原因を証明できるほど深くレビューする。
- 所有権が狭く、焦点を絞った証明が可能な、簡単で信頼性の高いバグのみを修正する。
- Peterの手動レビューのために、ダーティな差分サマリー、変更ファイル、テスト/ゲート出力で停止する。
- Peterが出荷を承認したら、承認された修正ごとに1つのコミットと、ユーザー向けの修正ごとに変更履歴エントリを作成する。
- プル/リベース、プッシュ、その後、修正されたか明示的にトリアージ・クローズされたIssueのみをコメントしてクローズする。
無関係なIssue修正を1つのコミットにまとめないこと。レビュー/証明フェーズ中にプッシュ、PR作成、コメント、クローズ、ラベル付け、ランディング、マージ、その他の公開を行わないこと。
コンパニオンスキル
最初に$gitcrawl、ライブなGitHubハイジーンには$openclaw-pr-maintainer、ソーストレーシングには$github-deep-reviewの姿勢、証明には$openclaw-testingを使用する。
ループ
各参照について：
ghでライブターゲットを読む。gitcrawlで関連、重複、クローズ、または既に修正されたスレッドを確認する。- 本文、コメント、リンクされた参照、変更ファイル、現在のコード、隣接するテスト、関連する場合は依存関係契約を読む。
- 実際の実行パスをトレースする。
- Issueの場合：これがバグであり、現在のコードが根本原因を証明し、関係するパスが明確で、狭いパッチがリファクタリングよりクリーンである場合にのみローカルで修正する。
- PRの場合：
ready-to-merge、needs-fixup、skipのいずれかを判定する。明示的に依頼されない限り、PRブランチを変更しない。 - ローカルのIssue修正やPR準備状態確認において、実用的な場合に焦点を絞った回帰テストを追加する。
- 最小限の意味のあるゲートを実行する。
- 貼り付けられたすべての参照が修正されるか分類されるまで続ける。
明示的に要求されない限り、サブエージェントは使用しない。
スキップ条件
- バグではない場合
- 設定/ドキュメント/ワークフロー/リリース/サポート/依存関係/製品関連の作業の場合
- 再現または根本原因が不確かな場合
- より大規模なリファクタリングや所有者境界を越える変更の方がクリーンな場合
- 現在の
mainで既に修正済みの場合 - 依存関係の動作が推測によるものの場合
- 焦点を絞った証明が実行不可能な場合
簡潔な理由を添えてスキップする。信頼性の低い修正で埋めないこと。
修正ルール
- 最初に所有者モジュール内で行う。必要な場合のみジェネリックなシームを使用する。
- 既存のパターン/ヘルパー/型を使用する。
- ついでリファクタリングを行わない。
- 障害発生箇所の近くにテストを配置する。
- 変更された公開動作についてのみドキュメントを追加する。
- レビュー/証明フェーズ中はコミットしない。
- Peterが出荷を承認した後、承認されたユーザー向け修正ごとに1つのコミットと変更履歴エントリを作成する。
- Peterがレビュー後に出荷を承認するまで、プッシュ/PR作成/コメント/クローズ/ラベル付け/ランディング/マージを行わない。
PRルール
ready-to-merge: コードは良好、現在のヘッドを確認済み、必要な証明は成功しているか、外部CIのみが明らかに保留中。メンテナーによるマージ、または@clawsweeper automergeのためにリストアップする。needs-fixup: 小さなバグは明確だが、PRブランチに変更が必要。正確なファイルとテストをリストアップし、明示的な修正/プッシュ/自動マージ指示を待つ。skip: 広範囲、古い、推測的、設定/製品/セキュリティ/リリース関連、所有者境界を越える、またはリファクタリング規模のもの。- 元のPRが信頼できない/編集不可能な場合、スイープ中に代替PRを作成しないこと。
出力形式
台帳： fixed-local、ready-to-merge、needs-fixup、skipped、needs-human。
最終結果： Issueファイルはディスク上に残り、PRはマージ/自動マージ準備完了、テスト/ゲート、スキップ理由。