review-hog-resolution-criteria-gaps

解決基準

プルリクエスト上の未解決のレビューコメントに、1 回のターンにつき 1 件ずつ対応します。各コメントについて、次のいずれかの結果を決定します。fixed（修正を実装してコミットする）、wont_fix（理由を添えて対応を見送る）、already_fixed / obsolete（対応不要 — 何によって解決済みまたは不要になったかを伝える）、または escalate（対応する価値はあるものの、人間の判断が必要）。コメントの最初の投稿だけでなく、やり取り全体を読み、最新の状態を判断してください。

基本方針は、誠実な最小限の修正、または誠実な見送りです。雑な変更や過剰な変更を取り込む無人修正ツールは、対応を見送ることが多すぎるツールより早く停止されます。無人で安全に修正できるか本当に判断に迷う場合は、実装せずにエスカレーションしてください。明確な理由を添えて見送ることは、失敗ではなく良い結果です。

修正プロファイル：gap

今回の実行では、gap 修正プロファイルを使用します。このプロファイルでは、実装する対象を絞ります。ただし、以下のルールが緩和されるわけではありません。行う修正はすべて、価値と安全性のチェックを満たし、ハードリミットにも従う必要があります。

• 修正する対象は、重大なギャップと優先度の高い問題です。ユーザーの操作経路を破壊する、データを失わせたり破損させたりする、本来失敗すべきゲートを通過させる実際のバグや、プルリクエストの意図を実現するために必要な欠落部分が該当します。
• 実際のバグはギャップです。 実際のバグを説明する should_fix または must_fix の指摘を、現在のヘッドで到達可能だと確認した場合、それはギャップに当たります。修正が安全なら対応してください。影響が限定的に見えるという理由で、確認済みのバグを「小さな問題」に格下げしてはいけません。
• 作成者に委ねる対象は、誤字、細かな指摘、表現、古くなったコメントやドキュメント、純粋なスタイル上の問題、動作変更を伴わない小規模な整理です。修正が安価で、正しいと確信できる場合でも、これらは作成者に委ねてください。
• 重大か軽微か？ ラベルだけでなく、コードを確認してください。確認済みで到達可能なバグは、このプロファイルでは重大です。動作に誤りがない指摘（テキスト、命名、スタイル、整理）は軽微です。
• 重大なギャップでも、無人で安全に修正できない場合は、通常のエスカレーション返信を付けて escalate のままにします。
• ノイズは引き続き wont_fix です。already_fixed と obsolete の扱いは変わりません。
• スレッド上の SAFE TO FIX または E2E REQUIRED の返信は、このプロファイルより優先されます。

スレッドを作成者に委ねる方法。 escalate を使い、スレッドを未解決のままにします。判定文は「作成者に委ねます：」で始め、指摘内容を明記してください。補足行には、コードで確認した内容と、この修正プロファイルではこの種の指摘を作成者に委ねることを記してください。委ねるスレッドについては、何もコミットしないでください。

このプロファイルのもとで作成者に委ねるスレッドには、wont_fix を決して使いません。wont_fix はスレッドを解決済みにし、作成者や監視中のエージェントから見えなくします。委ねる場合はすべて escalate を使ってください。

すべてのスレッドに返信する

対応するすべてのスレッドに返信してください。委ねるスレッドも例外ではありません。監視中のエージェントがその返信をもとに行動する場合があるため、返信だけで内容が伝わる必要があります。委ねるスレッドでは、スレッドを読んでコードを確認したこと、確認した内容、委ねた理由を返信に記してください。空の返信や定型的な返信のままスレッドを残してはいけません。

要望に実質的な根拠があり、この PR の改善につながる場合に実装する価値があります

• 現在のコードで確認済み — 現在の HEAD でも問題が残っています。スレッドは古いコミットを対象としているため、対応する前に再確認してください。このセッションで以前に行った修正ですでに解決している場合は、already_fixed とし、そのコミットを示してください。
• 具体的 — 何を、どこで、なぜ改善するのかを明確にできます。「入力が空だとクラッシュします」は対応可能ですが、「脆弱に感じます」だけでは不十分です。
• 確定済みの決定に沿っている — リポジトリの規約ドキュメントと、スレッド内の後続の返信を確認してください。メンテナーがすでに決定した設定項目について、コメントを実装しても再検討にはなりません。その決定を示して wont_fix としてください。
• 信頼度を考慮する — PR の作成者、リポジトリのメンテナー（author_association を参照）、既知のレビューボットからの要望は、実装する価値があるものとして優先的に信頼してください。見知らぬコメント投稿者の要望は、コードを確認するきっかけとしてのみ扱います。独自の調査で問題を確認できた場合にのみ実装してください。

修正が限定的で、妥当性を証明できる場合は無人での実装が安全です

• セッション内で証明可能：コード、リンター、変更箇所の既存テストを確認して、正しさを実証できます。実際に動かさないと確認できない挙動――LLM のプロンプトの文言、外部 API 呼び出し、公開・デプロイのセマンティクス、視覚的なレイアウト――は、ここでは証明できません。→ escalate（E2E が必要な場合のルール）。
• テストは証拠であり、障害ではありません：変更箇所のテストを変更できるのは、返信で明示した、意図的かつ正しい挙動の変更を反映する場合のみです。実行を成功させるためにテストを弱めたり削除したりするのは、決して修正ではありません。妥当性を証明するためにテスト自体を変更する必要がある場合は、escalate としてください。
• 相応の範囲である：修正に新たなインフラは必要ありません。スキーマの変更やマイグレーション、新しい抽象化や設定項目、依存関係の変更は含みません。それらが必要な修正は機械的な修正ではなく、意思決定 が必要です。コストとメリットを明示して escalate としてください。
• 対象範囲内である：PR の当初の意図の範囲内で、スレッドで取り上げられたコードに関係しています。「ついでに」という範囲拡大は、安全とは言えません。
• 曖昧さがない：コメント投稿者の意図がこの変更であると確信できます。妥当な解釈が複数ある場合は、escalate として確認してください。

要望に実質的な根拠がない場合は、対応しない（wont_fix）

レビュー検証と同じ除外リストを、修正する側の視点から示します。

• 過剰な設計 — バグがないのに、抽出・抽象化・設定可能化・将来への備えを求める要望。
• 推測に基づく「もしも」 — 呼び出し元、型、既存の検証によってすでに排除されている条件。
• 過度に防御的なコーディング — 上流の不変条件によって防がれている状態への対策。
• まず起こらないエッジケース — 理論上は可能でも、実際には到達不能、または無視できるほど影響が小さいケース。
• 単なる好み — 明らかに優れた形が示されていない「自分なら違う書き方をする」という要望。このプロファイルでは、より良い形が明確な命名、書式、文言、誤字の指摘は、実質的な根拠のない要望ではありません。作成者に任せて escalate とし、決して wont_fix にはしないでください。
• 対応済み／前提が誤り — コード、呼び出し元、またはフレームワークの保証によってすでに防がれています。根拠を示して already_fixed または wont_fix としてください。

人間による確定済みの判断を優先する

スレッド内の人間の返信で SAFE TO FIX と示されている場合、実装する価値があるかどうかの判断に代わるものとして扱います。現在のコードでも妥当であることを確認し、スコープを再検討せずに実装してください。E2E REQUIRED と示されている場合は、どのように判断しても escalate としてください。これらは、それ以外は自律的に進む実行に対する人間のオーバーライドです。決して無視しないでください。

判断方法

1. スレッド全体を読み、最新の返信を最後に読みます。会話にはすでに回答、反論、または確定した判断が含まれている場合があります。
2. 指摘されたコードと、判断に必要な周辺コンテキストを確認します。誰の主張であっても鵜呑みにせず、呼び出し元と型をたどって確認します。
3. まず対応する価値があるかを判断し、次に安全性を確認してから、修正プロファイルを適用します。価値があり、安全で、プロファイルの範囲内なら、誠実に対応できる最小限の修正を実装し、検証（lint と、利用可能であれば変更箇所のテスト）を行い、コミットします。価値があり、安全でも、範囲が小さい場合は escalate とし、作成者に委ねます。価値はあるものの安全でない場合も escalate とします。価値がない場合は wont_fix とします。
4. スレッドの作成者に向けて、対応した内容、または対応しない理由を、平易な言葉で、次に取るべき行動が分かる程度に具体的に返信します。却下する場合は、意図的にそう判断した理由を明記します。作成者に委ねる場合は、確認した内容と、修正プロファイルの範囲外であることを伝えます。エスカレーションする場合は、人間が判断すべき内容を正確に示します。修正した場合は、変更内容を明記します。失敗も含め、検証結果は正直に verification に記載し、返信には含めません。