実行済みのテスト・ビルド・動作確認の証跡を確認し、最終承認を行ってください。

**ワークフロー全体の確認:**
1. レポートディレクトリ内の全レポートを確認し、ワークフロー全体の整合性をチェックする
   - 計画と実装結果が一致しているか
   - 各レビューステップの指摘が適切に対応されているか
   - タスクの本来の目的が達成されているか
   - 前段レビューの finding が、指示書・計画・実コードに照らして妥当か
2. 指示書・計画・意思決定履歴を一次情報として確認する
   - `order.md` を読み、要求と禁止事項を抽出する
   - `plan.md` を読み、実装方針とスコープを確認する
   - `coder-decisions.md` を読み、なぜその修正に進んだかを確認する
   - 前段レポートの判断を鵜呑みにせず、上記3つと実コードの整合で再評価する
3. タスク指示書の各要件が達成されているか
   - タスク指示書から要件を1つずつ抽出する
   - 1つの文に複数の条件や経路が含まれる場合は、検証可能な最小単位まで分解する
     - 例: `global/project` は別要件として扱う
     - 例: `JSON override / leaf override` は別要件として扱う
     - 例: `A と B`、`A/B`、`allow/deny`、`read/write` のような並列表現は原則分解する
   - 各要件について、実装されたコード（ファイル:行）を特定する
   - コードが要件を満たしていることを実際に確認する（ファイルを読む、実行済みテストやビルドの証跡を確認する）
   - 片側のケースだけを確認して複合要件全体を ✅ にしてはいけない
   - 根拠は、その要件行の内容全体をカバーしている必要がある
   - 計画レポートや requirements-review の判断を鵜呑みにせず、要件ごとに独立照合する
   - 充足していない要件が1つでもあれば REJECT する
4. 前段レビューの finding を再評価する
   - 各 `new / persists / resolved` を、指示書・`plan.md`・`coder-decisions.md`・実コードで照合する
   - finding がコード上成立しない場合は false positive として記録する
   - finding が成立しても、タスク目的を外れた追加要求や過剰な一般化なら overreach として記録する
   - false positive / overreach を暗黙のまま流さない
5. テスト・ビルド・動作確認の扱い
   - このステップでコマンドを再実行する前提で書かない
   - 実行ログ、レポート、CI結果など、この run で確認できる証跡だけを使う
   - 証跡がない項目は「未確認」と明記し、成功扱いにしない
   - レポート本文と実行証跡が矛盾する場合は、その矛盾自体を指摘する

**レポートの読み方:**
- 同名レポートは、無印ファイルを最新結果、`{レポート名}.{タイムスタンプ}` を履歴として扱う
- 前段 finding の再評価では、無印ファイルと直前のタイムスタンプ付き履歴を比較し、`new / persists / resolved / reopened` の意味が維持されているか確認する
- 要約レポートは一次証跡としては扱わない。一次証跡は、実行結果を記録したレポート、具体的な確認内容を記したレビューレポート、実コードの順で確認する
- 実行結果を記したレポート内の `ビルド結果` / `テスト結果` は一次証跡として扱ってよい
- レビューレポートの「成功を確認した」という記述は、確認対象・確認内容・結果が具体的に書かれている場合のみ補助証跡として扱う
- 証跡同士が矛盾する場合は、`実行結果を記したレポート > 具体的な確認内容を持つレビューレポート > 要約レポート` の優先順位で判断する
- 後続レポートが前段 finding を `resolved` / `false_positive` / `overreach` と再評価している場合、その再評価が task・plan・実コードと整合するかを確認して採否を決める

**レポートの確認:** Report Directory内の全レポートを読み、
未解消のブロッキング finding が残っていないか、またその finding 自体が妥当か確認してください。

**Validation出力契約:**
```markdown
# 最終検証結果

## 結果: APPROVE / REJECT

## 要件充足チェック

タスク指示書から要件を抽出し、各要件を実コードで個別に検証する。

| # | 要件（タスク指示書から抽出） | 充足 | 根拠（ファイル:行） |
|---|---------------------------|------|-------------------|
| 1 | {要件1} | ✅/❌ | `src/file.ts:42` |
| 2 | {要件2} | ✅/❌ | `src/file.ts:55` |

- ❌ が1件でもある場合は REJECT 必須
- 根拠なしの ✅ は無効（実コードで確認すること）
- 一部ケースしか確認できていない場合は ✅ にしない
- 計画レポートの判断を鵜呑みにせず、要件ごとに独立照合する

## 前段 finding の再評価

| finding_id | 前段判定 | 再評価 | 根拠 |
|------------|----------|--------|------|
| {id} | new / persists / resolved | 妥当 / false_positive / overreach | `src/file.ts:42`, `reports/plan.md` |

- 前段レビューの結論と最終判定が異なる場合は、必ず根拠を書く
- false_positive / overreach を判定した場合は、task と plan のどちらに照らして不適切か明記する
- requirements-review の結論を覆す場合は、その理由を必ず根拠付きで明記する

## 検証サマリー
| 項目 | 状態 | 確認方法 |
|------|------|---------|
| テスト | ✅ / ⚠️ / ❌ | {実行ログ・レポート・CI等の証跡} |
| ビルド | ✅ / ⚠️ / ❌ | {実行ログ・レポート・CI等の証跡} |
| 動作確認 | ✅ / ⚠️ / ❌ | {確認した証跡。未確認ならその旨} |

## 成果物
- 作成: {作成したファイル}
- 変更: {変更したファイル}

## 未完了項目（REJECTの場合）
| # | 項目 | 理由 |
|---|------|------|
| 1 | {項目} | {理由} |
```

**Summary出力契約（APPROVEの場合のみ）:**
```markdown
# タスク完了サマリー

## タスク
{元の要求を1-2文で}

## 結果
完了

## 変更内容
| 種別 | ファイル | 概要 |
|------|---------|------|
| 作成 | `src/file.ts` | 概要説明 |

## 検証証跡
- {確認したテスト/ビルド/動作確認の証跡}
```
