OpenClaw ランディング可能バグスイープ

OpenClaw ランディング可能バグスイープ は何をしますか？

自律メンテナー向けワークフロー。要求されたバッチ数の、ランディング可能な OpenClaw バグ修正 PR URL を生成します。 幅広い Issue/PR スイープに使用し、基準は高く、出力はメモではなく PR です。 プラグイン SDK/API 境界の作業には使用しないでください。それらは別途アーキテクチャレビューが必要です。

目標

リクエストから batch_size を使用し、デフォルトは 5、上限は 20 とします。 最大でその数の、条件を満たした PR URL を返します。各 URL には以下を含めます。

• バグ概要
• 修正が低リスクである理由
• 証拠: rebase 後のヘッドでのローカル/Testbox/実働 コマンドまたは実行 ID
• 自動レビュー: 表示している正確なヘッドでのクリーンな結果
• プッシュされた正確な PR ヘッドでの CI グリーン
• Issue/重複のクリーンアップが完了済みか保留中か

URL はレビュー/修正済みの既存 PR でも、Issue/クラスタから新規作成した PR でも構いません。 メンテナーに PR URL を提示する前に、必ず現在の main でリフレッシュし、左テストを実施し、自動レビューがクリーンで、プッシュし、GitHub CI でグリーンが確認されている必要があります。 自動レビュー後にコード、テスト、CHANGELOG、PR 本文、ブランチベースが変更された場合は、再度自動レビューを実行してから URL を提示してください。 制限された検索で条件を満たす 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、公開/ランディング前には $autoreview、広範囲/E2E/実働証明には $crabbox を使用します。

候補基準

以下のすべてが真である場合のみ受け入れます。

• バグまたはペーパーカットであり、機能/製品/サポート/ドキュメントのみではない
• 根本原因が現在のコードで証明されている
• 依存関係の動作が関連する場合、アップストリームのドキュメント/ソース/型で確認されている
• プロダクション/ランタイムの diff が小さいこと。理想的には 500 LOC よりもはるかに小さく、常に 500 LOC 未満
• テストは大きくても良いが、焦点が絞られていること
• 新しい依存関係がないこと
• 新しい設定オプションがないこと
• 後方互換性のない動作がないこと
• セキュリティ/製品/オーナー境界の判断が必要ないこと
• プラグイン SDK、公開プラグイン API、または src/plugin-sdk/** 境界の変更がないこと
• 広範なリファクタリングの臭いがないこと
• 焦点を絞った証明が実行可能であること
• ブランチを rebase/リフレッシュしてプッシュできる、または代替 PR を作成できること

良い例:

• プロバイダーパラメータの不一致が依存関係/API 契約に照らして証明されている
• CLI コマンドが隣接するコマンドの動作から逸脱している
• 狭いランタイム状態/シリアル化のバグで、失敗するテストがある
• 既に現在の main で修正済みの Issue で、証拠があり、クローズ可能な重複がある

拒否するもの:

• 機能リクエスト、新しい設定項目、マイグレーション、リリース作業、ワークフローポリシー、サポート
• プラグイン SDK/API 境界の変更（互換性シム、新しい SDK メソッド、SDK エクスポート、プラグイン向けチャネル/プロバイダーシームを含む）
• 明示的にアサインされていない限り、認証/セキュリティ境界の変更
• 利用可能なライブ認証情報を必要とするバグ
• CI が赤い PR（修正、rebase、プッシュ、グリーンを再確認しない限り）
• ローカルでレビューしただけで、リフレッシュ/プッシュ/ライブ確認をしていない PR
• 最終ヘッドが $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、close-fixed-on-main、close-duplicate、または reject
4. パッチ前に証明:
   • 失敗するテスト、焦点を絞った再現、ログ/ソース証明、または依存関係契約の証明
   • main で既に修正済みの場合は、現在のソース/テスト/コミットで証明し、親切にクローズ
5. パッチ:
   • 既存の PR が良好で書き込み可能な場合はそれを優先
   • 書き込み不可または形状が不適切な場合は、独自の PR を作成し、有用なコントリビュータークレジットを保持
   • PR が存在しない場合は作成
   • 適合する場合は回帰テストを追加
   • ユーザー向け修正の場合は、PR 本文またはコミットメッセージにリリースノートのコンテキストを含め、既知の人間の報告者/コントリビューターにクレジットを付与
6. レビュー、リフレッシュ、公開:
   • PR ブランチを現在の origin/main に rebase またはその他の方法でリフレッシュ
   • 新たに露呈した CI 障害を含むドリフトを解決し、PR を準備完了としてカウントしない
   • 通常のスイープ PR 中に CHANGELOG.md を追加しない。リリース自動化が PR とコミットから生成する
   • rebase 後のヘッドを、バグを証明する最小限の意味のあるローカル/Testbox/実働コマンドで左テスト
   • $autoreview を、受け入れられた/実行可能な所見がなくなるまで実行してから、PR URL を作成、更新、または提示
   • 実際の本文と証拠フィールドを備えた PR を作成/更新
   • レビュー済みの正確なヘッドをプッシュ
   • プッシュされたそのヘッドに対して GitHub CI がグリーンであることを確認。保留中、赤、ダーティ、競合、外部ブロック中の PR をカウントしない
7. 衛生管理:
   • スイープ中に気づいた重複や main で修正済みの Issue/PR は、証拠とともにすぐにクローズ
   • 明示的な確認なしに、1 つのクラスタ内で 5 を超える関連アイテムを決して変更しない
   • コメントは親切で具体的であり、証拠/PR/コミットリンクを含めること
8. batch_size のランディング可能な PR URL が準備できるか、制限付きの適格キューが尽きるまで繰り返します。

PR 本文の証拠

リポジトリの PR テンプレートを使用します。著者による ## What Problem This Solves と ## Evidence セクションを含めます。本文は意図と最も有用な検証証拠に焦点を当てます。正確性を判断する前にコード、テスト、CI を検査します。

既存 PR のルール

• diff を超えたコードパスをレビューしてから信頼する。
• PR が良好な場合: 現在の main に rebase/リフレッシュし、小さな問題を修正し、左テストし、自動レビューをクリーンにし、プッシュし、CI がグリーンになってから表示またはカウントする。
• PR が良好でないが有用なアイデアがある場合: ローカルで再作成し、必要に応じて共著者とし、感謝と説明とともに元の PR をクローズ。
• PR が重複または main で修正済みの場合: 証拠とともにコメントし、クローズ。
• メンテナーがコントリビューターブランチにプッシュできない場合: 独自のブランチ/PR を作成し、有用なコミットまたはクレジットを保持。
• ローカル証明後に CI が赤くなった場合、それを通常の作業として扱う: 失敗したジョブを調査し、修正または拒否し、再実行し、PR がグリーンになってからカウントする。

出力台帳

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

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:

最終回答:

• 要求された数の受け入れられた PR URL、または探索尽くしの理由とともに少ない適格数
• PR ごとに 2～4 文の説明
• PR ごとの証拠/CI 状態
• クローズされた重複/main で修正済みの参照
• 現在のブランチ/ステータス