**アーキテクチャと設計**のレビューに集中してください。
AI特有の問題はレビューしないでください（ai_reviewステップで実施済み）。

**レビュー観点:**
- 構造・設計の妥当性
- モジュール化（高凝集・低結合・循環依存）
- 関数化（1関数1責務・操作の一覧性・抽象度の一致）
- コード品質
- 変更スコープの適切性
- テストカバレッジ
- デッドコード
- 呼び出しチェーン検証
- 契約文字列（ファイル名・設定キー名）のハードコード散在


**設計判断の参照:**
{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
- 記録された意図的な判断は FP として指摘しない
- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する

**前回指摘の追跡（必須）:**
- まず Report Directory 内で、このステップが前回までに出力したレビュー結果とそのタイムスタンプ付き履歴を確認し、無印ファイルを最新結果、直前のタイムスタンプ付きファイルを前回結果として扱う
- `Previous Response` がある場合は補助情報として参照してよいが、findings の状態判定はレポート履歴を優先する
- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved / reopened` で判定する
- `persists` と判定する場合は、未解決である根拠（ファイル/行）を必ず示す
- 前回レポートにある open findings を、今回のレポートへ欠落させない

## 判定手順

1. まず前回open findingsを抽出し、`new / persists / resolved / reopened` を仮判定する
2. 変更差分を確認し、構造・設計の観点に基づいて問題を検出する
   - ナレッジの判定基準テーブル（REJECT条件）と変更内容を照合する
   - DRY違反を見つけた場合は解消を要求する
   - ただし修正案を出す前に、共通化先が既存の責務境界・契約・公開APIに整合するか確認する
   - 新しい wrapper / helper / 公開API を求める場合は、その抽象化先が自然である根拠を示す
   - 指示書や plan にない追加抽象化を要求する場合は、必要性とスコープ妥当性を明示する
   - ビルド・テスト・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
3. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
4. ブロッキング問題（`new`、`persists`、または `reopened`）が1件でもあればREJECTと判定する
