実行済みのテスト・ビルド・動作確認の証跡を確認し、保守変更として不要な差分が残っていないかも含めて最終承認を行ってください。

手順:
1. Knowledge と Policy の Source Path を Read ツールで開き、全文を取得する
2. それぞれの `##` セクションをすべて列挙する（取捨選択しない）
3. 列挙した各セクションの判定基準を、変更差分・実行証跡・レポートと照合する

## ステップ固有の追加手順

1. タスク指示書の各要件を 1 つずつ抽出する
   - 1 つの文に複数の条件や経路が含まれる場合は、検証可能な最小単位まで分解する
   - 並列表現は原則分解する
2. 各要件について、実装されたコード（ファイル:行）を特定する
3. コードが要件を満たしていることを実際に確認する（ファイルを読む、実行済みテストやビルドの証跡を確認する）
   - 片側のケースだけを確認して複合要件全体を ✅ にしてはいけない
   - 計画レポートや requirements-review の判断を鵜呑みにせず、要件ごとに独立照合する
   - 充足していない要件が 1 つでもあれば REJECT する
4. 保守変更スコープを検証する
   - 必須変更、関連変更、不要変更の分類が妥当か確認する
   - コメント、型名、ファイル配置、UI文言、アクセシビリティ名、テスト期待値が要求外で変わっていないか確認する
   - 一般的な品質改善や作法改善だけが理由の差分が残っていれば REJECT する
5. 前段レビューの finding を再評価する
   - finding がコード上成立しない場合は false positive として記録する
   - finding が成立しても、タスク目的を外れた追加要求や過剰な一般化なら overreach として記録する
   - false positive / overreach を暗黙のまま流さない

## レポートの優先順位（supervise 固有）

- 要約レポートは一次証跡としては扱わない。一次証跡は、実行結果を記録したレポート、具体的な確認内容を記したレビューレポート、実コードの順で確認する
- 実行結果を記したレポート内の `ビルド結果` / `テスト結果` は一次証跡として扱ってよい
- `architecture-review` / `qa-review` / `testing-review` / `security-review` / `requirements-review` では、各レポートの `検証証跡` セクションを優先して確認する
- `検証証跡` の各項目は、確認対象・確認内容・結果が揃っている場合のみ補助証跡として扱う。いずれかが欠ける場合は、その項目を `未確認` として扱う
- 証跡同士が矛盾する場合は、`実行結果を記したレポート > 具体的な確認内容を持つレビューレポート > 要約レポート` の優先順位で判断する

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

## 結果: APPROVE / REJECT

## 要件充足チェック

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

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

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

## 保守スコープチェック

| 観点 | 結果 | 根拠 |
|------|------|------|
| 必須変更のみか | ✅/❌ | {根拠} |
| 関連変更の理由が明確か | ✅/❌ | {根拠} |
| 不要変更が残っていないか | ✅/❌ | {根拠} |
| コメント削除が要求外で起きていないか | ✅/❌ | {根拠} |
| 型名・ファイル配置・公開APIが要求外で変わっていないか | ✅/❌ | {根拠} |
| UI文言・アクセシビリティ名・テスト期待値が要求外で変わっていないか | ✅/❌ | {根拠} |

## 前段 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` | 概要説明 |

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