resolve-review

コードレビューへの対応

すべてのレビュー項目について、証拠に基づいた処置と確認済みの返信を行うか、それができない理由を報告してください。懸念点をコードと意図された変更に照らして評価してください。レビュー担当者が妥当な問題を指摘していても、提案された修正方法が適切とは限りません。作業に合った調査、実装、検証の方法を選んでください。公開前に何を確認する必要があるかは、以下の要件で定めています。

この作業の実行は、プルリクエストの既存のヘッドブランチへのコミットとプッシュ、返信、スレッド操作、必要なタイトルと説明の編集、対応内容のサマリー1件、および再レビュー依頼を許可します。リポジトリの規約に従い、対応者の認証済み ID で作業してください。この作業は既存のプルリクエスト内で行ってください。マージ、レビューの却下、レビューアプリとしての操作には、別途許可が必要です。

docs/agents/issue-tracker.md が存在する場合は、読み込んでください。フィードバックの識別情報、返信の形式、処置と判定の用語、スレッドの状態、チェックの証拠、サマリー、フォージ操作については、対応プロトコルを使用してください。現在の作業に必要なセクションを、入力と失敗時の契約を含めて読んでください。各操作では、対象のチェックアウトに記載された呼び出し方法を使用してください。収集、チェック実行の読み取り、スレッドへの書き込みには、絶対パスでインストール先を指定するランチャーコマンドがあります。実行可能ファイルの本体をモデルのコンテキストに読み込む必要はありません。「インベントリ以降の新規項目」コマンドには専用の呼び出し方法があります。終了コードがゼロ以外の場合は、記載された失敗時の手順に従い、成功したと決めつけてはいけません。

1. インベントリ

編集前に対象のプルリクエストを特定し、曖昧な場合は確認してください。プロトコルの収集ブロックを使用して、メタデータ、レビュー、インラインコメント、一般コメント、スレッドの状態をすべてのページにわたって収集してください。初期ヘッド、ブランチ、収集ディレクトリ、および各フィードバック項目の安定した ID またはコメント ID を記録してください。人間からのフィードバックと、スレッド以外に新たな指摘を含むレビュー本文も対象にしてください。ステータスのみの自動メッセージは除外してください。

各項目の懸念点、これまでの議論、処置、返信を安定した識別情報にひも付けて記録し、フィードバックを見落としたり、二重に回答したりしないようにしてください。ブロッキングと任意の分類には、プロトコルの規定を適用してください。収集範囲が不完全であれば報告し、取得できたものだけに対応してください。取得できていないフィードバックには処置を割り当てることも、対応済みとして数えることもできません。

2. 対応

証拠に基づいて必要な変更を行い、プロトコルの形式に従って各項目への返信を1件ずつ用意してください。ユーザーが実装スキルを指定している場合は、それに従い、指定がなければ実装方法を選んでください。任意の提案については、プロトコルの「Questions」セクションにある任意の指摘に関する既定の扱いを考慮してください。質問には回答し、意見が異なる場合はその理由を説明し、解決できない場合は needs-info または blocked を使用してください。手元の証拠で回答できない場合は、セッションまたはプルリクエスト上で、呼び出し元が許可する方法により、焦点を絞った質問をしてください。

以前に却下した指摘について、元のレビュー担当者が not-fixed と判定している場合は、見解が対立しています。レビュー担当者の反論に回答してください。どちらも譲らない場合は、プロトコルに定める2回までのやり取りの上限に従い、人間の判断が必要であると伝えてください。

修正をコミットし、プロトコルの「Check evidence」セクションに従って検証してください。変更した動作とその依存関係に合ったチェックを選んでください。有効な証拠は再利用し、チェックの繰り返しは避けてください。コマンドまたは CI の識別情報、ヘッド、入力状態、結果、対象範囲を記録してください。その後に変更を加えた場合は、プロトコルの「Invalidating」ルールを適用してください。以前のヘッドで得た証拠は、そのヘッドで得たものとして記録し、別のヘッドで明示的に求められているチェックの要件を満たすことはできません。

以下の独立レビューが完了するまで、プッシュ、処置に関する返信、スレッドの解決は保留してください。作業を進めるために必要な質問は、それより前に行ってもかまいません。

3. 公開前のレビュー

元の懸念事項、最初と最後のコミット済みヘッド、関連する仕様とリポジトリの指示、チェックの証拠を受け取り、実装時の会話を参照しない、隔離された読み取り専用のレビュアーを使用します。呼び出し元が指定したレビュアーのティアと、リポジトリのモデル選択ルールを尊重してください。

レビュアーは、提案された返信や対応方針を見る前に、証拠に基づく独自の評価を記録し、その後で返信の主張を確認します。この順序は、コードに変更がない場合も同様です。評価と、カバレッジに不足があればその内容を保持してください。承認の対象は、実際に確認したヘッドとドラフトです。

サポートされているホスト操作を使って、レビューの完了を待ちます。該当する操作がない場合は、レビューを開始する前に review-wait-unavailable を報告して停止し、不足している操作と保留中の作業を明示します。レビューが保留中、または評価が一部しか完了していない状態では、このゲートを通過できません。新しいレビュアーで置き換えられるのは完了済みのフェーズだけです。保留中の作業に対して並行する代替レビューを開始してはならず、フェーズが失敗または一部完了であれば公開を停止します。隔離が利用できない場合、重要なカバレッジが欠けている場合、または修正によって生じたブロッキングな不具合が残っている場合は、プッシュまたは対応方針の公開を行う前に停止し、その理由を報告します。

最初の評価で指摘された内容を検討し、妥当な修正をコミットします。根拠のない主張を正し、最終ヘッドとドラフトのレビューカバレッジを確保します。変更内容と利用可能なホスト操作に応じて、継続評価、新規評価、差分評価、または全体評価を選択します。評価をドラフトより先に行う順序と、以前のカバレッジを維持してください。最初の再検証以降、このラウンドで追加できるコミットは、修正によって生じたブロッキングな不具合、または返信に含まれる根拠のない主張への対応に限ります。任意のフォローアップは、ラウンドを延長するのではなく、受け入れた内容として報告します。

このレビューは、元のレビュアーに代わって意見の相違を解決するものでも、再レビューの依頼に代わるものでもありません。

4. 返信を公開する

コミットがあれば、既存のヘッドブランチにプッシュします。対応方針を公開する前に、ライブヘッドがレビュー済みヘッドと一致することを確認します。変更されていた場合は、変更内容を調整し、変更後のヘッドのレビューカバレッジを確保してください。

プロトコルの writes.jsonl 書き込みループを使って、レビュー済みのスレッド返信とアクションを公開します。正確な返信本文、書き込み確認後の照合、再試行回数の上限を守ってください。必要な返信と作業が確認された後に限り解決し、declined、needs-info、blocked の項目は未解決のままにします。誤って解決済みになったスレッドは再開し、その理由を説明します。スレッドのないフィードバックや、変更全体に関する質問には、プロトコルで定められたルートを使用してください。未解決の書き込みと、スレッドに対するアクションを妨げた権限上の問題をすべて報告します。

5. 完了処理

最終的な変更に合わせてタイトルと説明を調整し、Issue へのリンクと有効なコンテキストを維持します。プッシュ先のヘッド（ローカルヘッドと一致するもの）にある `` トレーラーを含め、プロトコルで定められた形式で対応状況のサマリーを1件投稿または更新します。同じヘッドで再実行する場合は、既存のサマリーを更新します。項目を索引化し、各チェックについて、確立したヘッドと入力状態を明記し、今後誰かの対応が必要な事項を記載します。ファイルの位置を明記する場合は、変更されないリンクを使用します。

フィードバックに対応した本人に再レビューを依頼します。ユーザー、プルリクエスト自体の作成者、アプリのレビュアーに対する依頼には、プロトコルのルーティングルールを使用します。アプリのレビュアーには、依頼もメンションもしません。

6. 照合して報告する

レビューのアクティビティを再度収集し、このラウンドで確認済みの書き込み ID と、それらによって生成された空のレビューを除外したうえで、プロトコルの「インベントリ以降の新規項目」コマンドを使ってインベントリと比較します。新しいフィードバックは未対応として報告し、概要を更新します。読み取りが不完全な場合、照合が完了したとは主張できません。スレッドのループ外で行った書き込みについて、結果が不明瞭な場合は、再試行を最大 1 回にとどめ、対象と照合します。

対応済みのヘッド、概要へのリンク、処置件数、変更内容とチェック、独立レビューの結果、スレッドに対する操作、再レビューの経路、未対応の作業や失敗へのリンクを記載して終了します。レビューを待つために使用した、サポート対象のホスト操作も記載します。情報待ちまたは作業がブロックされているラウンドは、完了ではなく待機中です。求められており、かつ利用可能な場合は、コストの測定値を報告し、実測した実行、再利用した証拠、利用できない指標を区別します。