実装の差分をレビューする

PR作成前に必ず1回、実装とは別セッションで実行する。P0・P1の修正後は再レビューに戻す。

1. 渡すもの

実装の対話履歴や経緯は渡さない。差分と、判定の基準になる要件・プランを渡す。差分に含まれるファイルのパスをagents/rules/の各ルールのpaths:と照らし、一致するルールをすべてReadで読む。判断に必要な周辺コードも読む。

観点は、プランとの整合、異常系と境界値（対応するテストと骨抜きテストを含む）、セキュリティ、SSoT・過剰設計、これ以上単純にできないか、名前が意図を表し、コメントが「なぜ」を書いているか、該当ルールへの準拠。観点別に分ける場合は、design-reviewer、edge-case-reviewer、security-reviewerへ同じ資料を渡して並列で走らせる。

2. 指摘の優先度

• P0（必須修正）: セキュリティ・データ破壊・機能の誤り。マージをブロックする
• P1（推奨修正）: 深刻なバグの芽・テスト網羅の欠落。合理的理由があればスキップ可。スキップする場合は人間の判断と理由を記録する
• P2（軽微）: スタイル・命名。時間があれば修正、なければTODO化

いまの要件にない汎用化・防御・抽象化を勧める指摘は出さない。

3. 報告で守ること

• 各指摘に、ファイルと行、問題を起こす条件、根拠を添える。推測は「要確認」と分ける
• レビュー中はファイルを編集しない（実装者が自分で見直す場合を除く）
• 静的に読んだだけなら、実行時の挙動を確認した扱いにしない。差分を読むレビューでは、表示崩れ・空データの無限ローディング・状態の取り違えは捕まらない。UIや実行時の挙動を変えたら、最後は自分で動かして確かめる
• 差分や資料を取得できない対象を、問題なしと判定しない
• 指摘がなくても、何を確認したかを示す

4. 終わりの条件

• P0・P1がゼロなら合格。P2だけなら修正せずマージしてよい
• 3ラウンドを超えて指摘が循環したら、人間が裁定する
• 同じ種類の指摘が繰り返し出たら、agents/rules/への追加案として報告に書く。ルールへ足すかは人間が決める

実装者が出す前に見直す場合

別セッションのレビューの前に、実装者が同じ観点で自分の差分を読み直してよい（観点はGoogle Engineering Practicesのコードレビュー基準にもとづく）。この場合は指摘を自分で直し、判断に迷う点はPR本文の「レビュー観点」に書いてレビューアーへ渡す。自分で見直しても、別セッションのレビューは省略しない。