openclaw-landable-bug-sweep

OpenClaw 着地可能なバグ修正の一括処理

依頼された OpenClaw のバグ修正について、着地可能な PR URL をまとめて作成する自律型メンテナーワークフローです。 基準が高く、成果物としてメモではなく PR が求められる、広範な Issue／PR の一括処理に使用してください。 プラグイン SDK／API 境界に関する作業には使用しないでください。これらには個別のアーキテクチャレビューが必要です。

必須のオーケストレーション契約

• 制御プレーンとなるのは、ユーザーと直接やり取りするルート会話のみです。ルート会話は作業を分割し、Issue／PR／ファイルの担当範囲を明確に割り当て、範囲を限定した作業ワーカーと独立した検証担当者を直接起動し、安全性を調整し、完了状況を追跡して、ワーカーが実際に検証した最終結果を報告します。
• 委任された共同作業サブエージェントは、実作業を担う担当者であり、ユーザーと直接やり取りする別のルートオーケストレーターではありません。割り当てられた作業を直接実行します。この契約が再帰的にワーカーの行動を妨げてはなりません。ネストしたワーカーには、ルートによる明示的な承認と、ルートが追跡する処理能力、担当範囲、完了状況が必要です。Codex アプリで別のタスクやスレッドを作成しないでください。
• ワーカーは、すべての調査、ソース／依存関係／Codex の確認、再現、Issue／PR の調査、編集／リファクタリング、テスト／証明／CI、GitHub の読み取り／書き込み、コメント、クローズ、コミット、プッシュ、および別途許可された着地作業を実行します。Codex に関する判断を下す前に、実行するワーカー自身が依存関係の契約を検証し、隣接する ../codex を確認します。
• ルートはチェックアウト／ファイルの担当範囲を調整し、共有 Git／ref／index の変更と、競合するテスト／編集作業を直列化し、正確なヘッドを追跡するとともに、割り当てたワーカーを通じて許可、ソースの信頼性、セキュリティ、担当範囲、着地の各ゲートを徹底します。ワーカーの停滞、失敗、処理能力不足を理由に、ルートがオーケストレーションから実作業に切り替えてはなりません。範囲を限定した作業を別のワーカーに再割り当てしてください。

依頼された権限

• デフォルトの成果物は、マージ済み PR ではなく、検証済みの着地可能な PR URLです。明示的に依頼された修正・準備の一括処理では、依頼された範囲内での修正、リファクタリング、検証、コミット、プッシュ、PR の更新をワーカーに許可します。ただし、着地の明示的な依頼がない限り、着地は許可されません。
• review、triage、list、または landable-shortlist のみの依頼は、引き続き読み取り専用です。求められていないプッシュ、公開コメント、クローズ、置き換え PR、マージを行わないでください。
• 名前を指定した項目に対する自律的な process、resolve、または fix-and-land の明示的な依頼は、現在の main で修正済みと証明された項目をワーカーがクローズすること、および $openclaw-pr-maintainer とリポジトリ標準の scripts/pr ワークフローを通じて、検証済みの修正を着地させることも許可します。正確なヘッドと担当範囲の各ゲートを維持してください。
• 全権限での無人実行が明示的に依頼された場合、指定された一括処理の範囲内で、証拠に裏付けられたすべての作業に対する継続的な承認となります。これには、必要なタスク専用またはリポジトリ管理の PR ワークツリー、PR の適切な修正／置き換えとクレジット表記、証明コメント、正確なヘッドでの CI 修正、範囲を限定した公開、現在の main で修正済みと証明された項目のクローズ、依頼されたネイティブな着地作業が含まれます。定型的な承認確認を求めたり、無関係な未コミット変更に手を加えたりしないでください。ルートはオーケストレーションのみを行い、ワーカーが検証済みの完了まで実作業を担います。ソースの信頼性、実行するワーカー自身による Codex の確認、正確なヘッドでの必須 CI／セキュリティ／担当者ゲートを維持してください。クローズ／再オープンが 50 件を超える場合は、正確な件数と範囲について明示的な承認を得てください。
• 利用できないプロバイダー／チャネルの任意のライブ検証は、ユーザーが明示的に要件を緩和した場合に限り、失敗／成功する担当者境界の回帰テスト、プロデューサー／呼び出し元／隣接コード／依存関係ソースの直接的な証拠、独立したレビュー、正確なヘッドでの必須 CI 成功に置き換えられます。ライブ検証／ランク昇格の証明ができないことを開示してください。必須の外部 API、セキュリティ上重要なもの、リスク上必要なもの、または明示的に依頼されたライブ検証を省略してはなりません。

目標

リクエストの batch_size を使用します。指定がない場合は 5、上限は 20 です。 条件を満たす PR の URL を、次の内容とともに最大で指定数まで返します。

• バグの概要
• 修正のリスクが低い理由
• 証明：正確な head に対するローカル／Testbox／ライブのコマンドまたは実行 ID
• autoreview：表示する正確な head でクリーンな結果
• 正確なプッシュ済み PR head で CI がグリーンであること
• issue／重複の整理が完了しているか、未完了か

URL は、レビュー／修正済みの既存 PR でも、issue／クラスターから作成した新しい PR でもかまいません。 正確な公開済み head がテスト済みで、autoreview がクリーンに完了し、ライブの GitHub CI がグリーンであることを確認するまで、PR の URL を提示しないでください。 PR ブランチを更新するのは、実際の競合、正確な head のチェックまたはリポジトリ固有のガードの失敗、ユーザーからの明示的な依頼、またはベースの陳腐化による重大なリスクが立証された場合に限ります。main が進んだだけの理由でリベースしてはいけません。 autoreview の後に本番コード、テスト、またはレビュー済みの head が変更された場合は、URL を提示する前に autoreview を再実行してください。 検索範囲を限定した結果、条件を満たす PR が指定数より少ない場合、件数を水増ししないでください。

入力

• batch_size：対象となる PR の希望数。デフォルトは 5、最大は 20 です。
• source_mode：discovery または provided-prs。デフォルトは discovery です。
• provided_prs：source_mode=provided-prs の場合に指定する PR 参照。

provided-prs モードでは、最適な修正を立証するためにより広範な探索が必要な場合を除き、指定された PR と、直接リンクされた重複／正規の参照のみを調査してください。

関連スキル

探索／クラスター化には $gitcrawl、ライブの GitHub 変更ルールには $openclaw-pr-maintainer、コントリビューターの信頼性が重要な場合は $github-author-context、証明方法の選択には $openclaw-testing、広範なテスト／E2E／ライブでの証明には $crabbox を使用してください。 公開／マージの前に $autoreview を実行してください。

候補の基準

以下をすべて満たす場合に限り、候補として採用してください。

• バグまたは小さな使い勝手の問題であり、機能追加／プロダクト／サポート／ドキュメントのみの変更ではない
• 現在のコードで根本原因が立証されている
• 該当する場合、依存関係の挙動を上流のドキュメント／ソース／型定義で確認している
• 本番コードの差分が小さく、理想的には 500 LOC を大幅に下回り、必ず 500 LOC 未満である
• 可能な場合、本番コードの LOC が差し引きゼロまたは減少している。本番コードが増加する場合は、その理由を説明している
• テストはより大きくてもかまいませんが、対象が絞られている
• 新しい依存関係を追加しない
• 新しい設定オプションを追加しない
• 後方互換性のない挙動を導入しない
• セキュリティ／プロダクト／所有者境界に関する判断を必要としない
• プラグイン SDK、公開プラグイン API、または src/plugin-sdk/** の境界を変更しない
• リファクタリングが立証済みの根本原因、所有者境界、小規模変更のリスク制限内に収まっている
• 対象を絞った証明が可能である
• 必要に応じて既存ブランチを安全に更新できるか、承認済みの代替ブランチ作成が妥当である

良い例：

• 依存関係／API の契約との照合で立証された、プロバイダーのパラメーター不一致
• CLI コマンドの挙動が隣接するコマンドと異なる
• 失敗するテストを伴う、限定的なランタイム状態／シリアライズのバグ
• 現在の main ではすでに修正済みの issue で、証明があり、重複 issue をクローズできるもの

却下するもの：

• 機能要望、新しい設定項目、移行、リリース作業、ワークフローポリシー、サポート
• 互換性シム、新しい SDK メソッド、SDK エクスポート、プラグイン向けのチャネル／プロバイダー境界の追加を含む、プラグイン SDK／API 境界の変更
• 明示的に割り当てられていない認証／セキュリティ境界の変更
• 必須の外部 API、セキュリティ、リスク上必要、または明示的に依頼されたライブ検証に必要な認証情報を利用できないために修正できないバグ
• CI が赤の PR。ただし修正し、必要に応じて head を更新してプッシュし、再確認してグリーンにした場合を除く
• 変更後の head がプッシュされていない PR、または正確な head の CI がライブで確認されていない PR
• 最終 head で $autoreview に合格していない PR
• 対象範囲外のプロダクト、アーキテクチャ、または所有権に関する判断が必要な修正
• 再現できる／立証可能な原因のない推測的な報告
• プロダクトの判断が必要な UI／UX の変更

スイープループ

1. クリーンな状態から開始します：
   • git status -sb
   • 必要な場合に限り、ルート権限があり、専有しているクリーンなベースチェックアウトを git pull --ff-only で更新します
   • 兄弟ワーカーが作業中の場合、共有チェックアウトのプル、ブランチ切り替え、変更は行いません
   • 通常は main など、想定どおりのブランチであることを確認します
2. 候補クラスターを作成します：
   • gitcrawl でオープン中の Issue／PR、関連項目、検索結果を確認します
   • gh issue/pr view で最新情報を確認します
   • Issue からリンクされている PR と重複項目を含めます
3. 各クラスターについて：
   • Issue／PR の本文、コメント、ラベル、リンク先の参照、現在のソース、関連するテストを読みます
   • 広範なアクセス権を持つメンテナーが作成した PR は、created_at から少なくとも 14 日経過するまで除外します。名前を指定した PR またはメンテナーの作業依頼が明示されている場合のみ、この制限を適用しません
   • 起票者／作成者を特定し、貢献を適切にクレジットします
   • repair-existing-pr、create-new-pr、fixed-on-main、duplicate、reject のいずれかを判断します。クローズするのは権限がある場合に限ります
4. パッチを適用する前に立証します：
   • 失敗するテスト、対象を絞った再現、ログ／ソースによる証拠、または依存関係の契約に関する証拠を用意します
   • すでに main で修正済みの場合は、現在のソース／テスト／コミットで立証します。権限がある場合に限り、丁寧にクローズします
5. パッチを適用します：
   • 既存の編集可能な PR は、最初に正しい責務境界に沿った修正へ書き直す／リファクタリングします。元の実装方針が適切でない場合も同様です
   • 元のブランチが編集できない、または安全に更新できない場合に限り、権限のある代替 PR を作成します。貢献者のクレジットを保持し、代替 PR が存在し、かつクローズの権限がある場合に限り、元の PR をクローズします
   • PR が存在しない場合、公開の権限がある場合に限り作成します
   • 適切であれば回帰テストを追加します
   • ユーザー向けの修正では、PR 本文またはコミットメッセージにリリースノート用の情報を記載します。人間の報告者／貢献者が判明している場合はクレジットします
6. レビュー、検証、公開を行います：
   • 実際のコンフリクト、厳密なヘッドチェックまたはラッパーガードの失敗、明示的な依頼、あるいはベースが古いことによる重大なリスクが実証された場合に限り、PR ブランチを更新します
   • PR を準備完了として扱うのではなく、実際のコンフリクトや CI の失敗を解決します
   • 通常のスイープ PR では CHANGELOG.md を追加しません。リリース自動化によって PR とコミットから生成されます
   • バグを立証できる、最小限かつ有意義なローカル／Testbox／ライブコマンドで、候補となる正確なヘッドをテストします
   • PR の URL を作成、更新、提示する前に、対応可能な指摘がなくなるまで $autoreview を実行します
   • 権限がある場合、具体的な本文と証拠の項目を含めて PR を作成／更新します
   • 権限のある変更の公開に必要な場合に限り、レビュー済みの正確なヘッドをプッシュします
   • プッシュしたヘッドに対する GitHub CI が成功していることを確認します。保留中、失敗、未コミットの変更あり、コンフリクト中、または外部要因でブロックされた PR は、5 件の中に数えません
7. 整理します：
   • 証拠を添えて重複項目と main で修正済みの Issue／PR をクローズします。クローズの権限がない場合は、証拠を報告します
   • 明示的に許可された範囲に含まれる場合に限り、1 つのクラスター内で関連項目を 5 件より多く変更します。ただし、クローズ／再オープンが 50 件を超える場合は、引き続き件数と範囲を明示した別途の承認が必要です
   • コメントは丁寧かつ具体的な内容にし、証拠／PR／コミットへのリンクを含めます
8. batch_size 件のマージ可能な PR URL が準備できるか、範囲が限定された適格なキューを処理しきるまで繰り返します。

PR 本文に記載する証拠

リポジトリの PR テンプレートを使用します。作成者が記入する ## What Problem This Solves と ## Evidence のセクションを含めます。本文は意図と、最も有用な検証証拠に絞ります。 正しさを判断する前に、コード、テスト、CI を確認します。

既存の PR ルール

• 信頼する前に、差分の範囲を超えてコードパスをレビューします。
• PR が適切な場合：具体的な問題を修正し、対象の最新コミットをローカルでテストして自動レビューし、許可された変更を公開してから、対象の最新コミットの CI が成功したことを確認して提示します。
• PR が未完成、または適切でないレイヤーにあるものの編集可能な場合：根本原因を扱う担当箇所で既存の PR を書き換え／リファクタリングし、作成者のクレジットを保持して、修正後の最新コミットを検証します。
• PR が重複している、または現在の main で修正済みの場合：根拠をコメントし、クローズが許可されている場合にのみクローズします。許可されていない場合は、根拠を報告します。
• ソースブランチが編集できない、または安全に更新できない場合：許可されている場合にのみ置き換えを作成し、有用なコミット／クレジットを保持します。置き換えが存在し、かつクローズが許可された後にのみ、元の PR をクローズします。
• ローカルで確認した後に CI が失敗した場合は、通常の作業として扱います。失敗したジョブを調査して修正または却下し、再実行します。CI が成功した場合にのみ PR をカウントします。

出力台帳

進行中の台帳を維持します。

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

rejected:
- ref:
  reason:

closed:
- ref:
  reason:
  proof/comment:

最終回答：

• 指定された件数の採用 PR の URL。該当する PR が少ない場合は、検索を終了した理由とともに、条件を満たした件数を提示します。
• 各 PR について 2～4 文の説明
• 各 PR の検証／CI の状態
• クローズした重複 PR／main で修正済みの PR の参照
• 現在のブランチ／状態