テスト品質の観点から変更をレビューしてください。

**レビュー観点:**
- テスト計画の観点がすべてカバーされているか
- テスト品質（Given-When-Then構造、独立性、再現性）
- テスト命名規約
- 過不足（不要なテスト、足りないケース）
- モック・フィクスチャの適切さ
- 外部契約がある場合、request body / query / path の入力位置が契約どおりに検証されているか
- レスポンス標準の envelope を request 契約へ誤って流用する実装を検出できるテストになっているか


**設計判断の参照:**
{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. Report Directory内のテスト計画・テストスコープに関するレポートと実装されたテストを突合する
3. テスト・ビルド・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
4. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
5. ブロッキング問題が1件でもあればREJECTと判定する
6. 外部契約があるのに入力位置（root body / query / path）の検証が欠けていれば、原則としてカバレッジ不足として扱う
