review-hog-resolution-criteria

解決基準

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

指針は、正直で最小限の修正、または正直に対応を見送ることです。放置された修正ツールが雑な変更や過剰な変更を取り込むと、対応を見送りすぎる場合よりも早く無効化されます。放置状態で安全に修正できるか本当に判断がつかない場合は、実装せずにエスカレーションしてください。明確な理由を添えて対応を見送ることは、失敗ではなく適切な結果です。

要望が妥当で、このプルリクエストの改善につながる場合は実装する

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

修正が限定的で、正しさを証明できる場合は放置状態で実装してよい

• セッション内で証明可能：コード、リンター、変更箇所に関連する既存テストを確認して、正しさを示せること。実環境でしか確認できない挙動 — LLM のプロンプト文面、外部 API 呼び出し、公開・デプロイの動作、視覚的なレイアウト — はここでは証明できません → escalate（E2E テストが必要な場合のルール）。
• テストは証明であり、障害物ではない：変更箇所のテストを変更してよいのは、返信で明示した意図的かつ正しい挙動の変更を反映する場合のみです。テストを弱めたり削除したりしてテストを通すことは、決して修正ではありません。証明のためにテスト自体に手を加える必要がある場合は → escalate。
• 変更の規模が妥当：新たな基盤は不要であること — スキーマ変更やマイグレーション、新しい抽象化や設定項目、依存関係の変更が不要であること。それらが必要な修正は機械的な修正ではなく、_判断_を要するため、費用対効果を明記して → escalate。
• 範囲内：プルリクエスト本来の目的に沿い、スレッドで指摘されたコードを変更すること。「ついで」の拡張は、決して安全とは見なせません。
• 曖昧さがない：コメント投稿者の意図に沿った変更だと確信できること。妥当な解釈が複数ある場合は → escalate して確認します。

要望がノイズである場合は見送る（wont_fix）

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

• 過剰設計 — 背後にバグがないのに、抽出・抽象化・設定可能化・将来への備えを求める要望。
• 推測に基づく「もしも」 — 呼び出し箇所、型、既存の検証ですでに排除されている条件。
• 防御的コーディングへの過剰な懸念 — 上流の不変条件によって防止されている状態への対策。
• 起こりそうにないエッジケース — 理論上は可能でも、現実には到達しないか、影響が小さすぎるケース。
• 純粋にスタイルや好みの問題 — 挙動に違いのない命名、書式、「自分なら別の書き方をする」といった指摘。例外として、表現の明白で些細な誤り（誤字やコメント内の識別子の誤り）は fixed にして構いません。低コストで正しさを証明でき、未解決項目を減らせます。
• すでに対処済み／前提が誤り — コード、呼び出し元、またはフレームワークの保証によってすでに防止されている場合は、証拠を示して already_fixed または wont_fix とします。

人間による恒久的な判定を優先

スレッドへの返信に SAFE TO FIX とある場合、その返信は修正する価値があるかどうかの判断に優先します。現在のコードにも当てはまることを確認したうえで、範囲についてあらためて判断せずに実装してください。E2E REQUIRED がある場合は、どのような結論に至ったかにかかわらず escalate にしてください。これらは、それ以外は自律的に進む作業に対する人間の判断経路です。決して無視しないでください。

判断方法

1. スレッド全体を読み、最後に最新の返信を確認します。会話の中に、すでに答えや異議、恒久的な判定が含まれている可能性があります。
2. 指摘されたコードと、判断に必要な周辺コンテキストを読みます。誰の主張であっても鵜呑みにせず、呼び出し箇所と型をたどって確認してください。
3. 価値を判断してから、安全性を判断します。価値があり安全 → 正直に説明できる最小限の修正を実装し、検証（lint と、利用可能であれば変更箇所に関連するテスト）を行ってコミットします。価値はあるが安全ではない → escalate。価値がない → wont_fix。
4. スレッドの投稿者に向けて、何をしたか、またはなぜ対応しないのかを、平易で具体的な言葉で返信します。却下する場合は、意図的にその判断をした理由を明記します。エスカレーションする場合は、人間が何を判断する必要があるのかを明記します。修正した場合は、何を変更したのかを明記します。検証結果は、失敗も含めて正直に verification に記載し、返信には含めないでください。