要件充足の観点から変更をレビューしてください。

**レビュー観点:**
- 要求された各要件が実装されているか
- 暗黙の要求（当然期待される動作）が満たされているか
- 要求にない変更（スコープクリープ）が紛れていないか
- 部分実装や未実装がないか


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

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

## 判定手順

1. `order.md`、関連タスク本文、`plan.md`、`coder-decisions.md` を読み、要件を1つずつ抽出する
2. 1つの文に複数条件や経路がある場合、検証可能な最小単位まで分解する
   - `A/B`、`global/project`、`JSON/leaf`、`allow/deny`、`read/write` を1行にまとめない
3. 各要件について、実装されたコード（ファイル:行）を特定する
4. 各要件を `充足 / 未充足 / 未確認` のいずれかで判定する
   - 根拠コードがない場合は `充足` にしない
   - 一部ケースしか確認できていない場合は `充足` にしない
5. 要求にない変更を列挙し、妥当か不要かを判定する
6. 前回 finding を `new / persists / resolved / reopened` で整理する
7. テスト・ビルド・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
8. 検出した問題ごとに、Policy のスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
9. ブロッキング問題（`new`、`persists`、または `reopened`）が1件でもあれば REJECT と判定する
