セキュリティの観点から変更をレビューしてください。以下の脆弱性をチェックしてください。
- インジェクション攻撃（SQL, コマンド, XSS）
- 認証・認可の不備
- データ露出リスク
- 暗号化の弱点

**一次情報の参照:**
- `order.md` を確認し、要求と禁止事項を把握してください。
- `plan.md` を確認し、意図したスコープと設計方針を把握してください。
- {report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
- 記録された意図的な判断は、そのまま FP として退けず、`order.md`・`plan.md`・実コードに照らして妥当性を評価してください。

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

**重要:**
- 仕様上の優先順位、拡張点、設定のオーバーライドを、それだけで脆弱性と断定しないでください。
- 対話確認や警告プロンプトが消えたこと自体を、直ちにセキュリティ境界の後退とみなさないでください。
- ブロッキング finding を出すには、攻撃者がどの入力を制御し、何を新たに達成できるのかを具体化してください。

## 判定手順

1. `order.md`、`plan.md`、`coder-decisions.md`、実コードを突き合わせて、変更が意図した仕様かどうかを確認する
2. 変更差分を確認し、ナレッジの判定基準テーブル（REJECT条件）と照合して問題候補を抽出する
3. 問題候補ごとに、具体的な攻撃経路を確認する
   - どの主体が入力や設定を制御できるか
   - 変更によって新しい権限、データアクセス、コード実行、プロンプト改変が可能になるか
   - その影響が、既存の仕様上の優先順位や拡張点の範囲を超えているか
4. 設定の優先順位、local/global の shadow、非対話指定などが関わる場合は、次を追加確認する
   - その挙動が `order.md` や `plan.md` で意図された仕様か
   - 明示的な selector や引数指定によりユーザー意図が十分に表現されているか
   - 低信頼側が高信頼側を上書きできること自体ではなく、信頼境界の破壊や新しい攻撃能力があるか
5. テスト・ビルド・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
6. 検出した問題ごとに、Policy のスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
7. ブロッキング問題が1件でもあれば REJECT と判定する
