phase-finished-verification

name	phase-finished-verification
description	フロントエンド実装フェーズの完了検証を実行。各フェーズの修了条件チェックリストに基づき、間違い・抜け漏れ・手抜きがないかを網羅的に検証する。Use when: 各フェーズが終了後、実装品質チェック、抜け漏れ検証、フロントエンド実装の検収
argument-hint	Phase 番号（0〜10）を指定。例: Phase 0, Phase 4

phase-finished-verification — フロントエンド実装フェーズ完了検証 Skill

目的

front-end-impl-plan.md に定義された各フェーズ（Phase 0〜10）の実装が完了した際に、以下の 3 観点で 網羅的かつ厳格に 検証を実施する:

1. 修了条件チェックリスト完全充足: 各フェーズの修了条件チェックリストの全項目が対応済みか
2. 設計書準拠（抜け漏れ検出）: front-end-need.md の該当セクションに記載された要件が全て実装に反映されているか
3. 実装品質（手抜き検出）: コードがスタブ・ハードコード・TODO 放置等の手抜きなく、本番品質で実装されているか

Fail-Safe 原則: 判定に迷う場合は「不合格（要修正）」に倒す。AI の判定はあくまで「助言」であり、最終判断は人間が行う。

前提条件

• 検証対象の Phase 番号（0〜10）が指定されていること
• front-end-impl-plan.md が存在し、対象フェーズのセクションが読み取り可能であること
• front-end-need.md（フロントエンド要件定義書）が存在すること
• 対象フェーズの実装コードが frontend/ ディレクトリ配下に存在すること
• 前提フェーズが完了済みであること（Phase 依存関係は front-end-impl-plan.md 付録 A 参照）

手順

以下の 6 ステップで検証を実施する。各ステップで問題を発見した場合も、全ステップを完了してから結果をまとめて報告すること（途中で打ち切らない）。

Step 1: フェーズ情報の読み取り

1. front-end-impl-plan.md から対象フェーズのセクション全体を読み取る
2. 以下の情報を抽出する:
   • フェーズの 目的
   • 前提条件
   • 実装タスク一覧（P{N}-1, P{N}-2, ... の全タスク）
   • 対応要件（front-end-need.md のセクション参照）
   • 修了条件チェックリスト（全チェック項目）
3. フェーズ別検証ガイド から対象フェーズの検証ポイントを取得する

Step 2: 修了条件チェックリストの全項目検証

対象フェーズの修了条件チェックリストの 全項目 について、以下を実施する:

1. ファイル存在確認: チェック項目が言及するファイル・コンポーネントが実在するか（file_search / grep_search で確認）
2. 実装内容確認: ファイルの内容がチェック項目の要求を満たしているか（read_file で確認）
3. 動作要件確認: 動作に関するチェック項目は、コードの制御フロー・ロジックが正しいか確認
4. 各項目の結果を ✅ PASS / ❌ FAIL / ⚠️ PARTIAL で記録する

重要: 1 項目でも FAIL がある場合、フェーズは 不合格 とする。PARTIAL は条件付き合格の候補だが、3 件以上ある場合は不合格。

Step 3: 設計書要件との突合せ（抜け漏れ検出）

1. front-end-need.md から対象フェーズに該当するセクションを読み取る
   • 要件トレーサビリティマトリクス を参照し、対象フェーズの全要件 ID を特定する
2. 各要件 ID（FR-xxx, AC-xxx, §x.x.x）について:
   • 機能要件（FR-）: 対応するコンポーネント・ページ・BFF Route Handler が存在し、要件の全機能が実装されているか
   • 受入基準（AC-）: 受入基準の条件がコードで表現されているか（条件分岐、表示制御、バリデーション等）
   • セクション要件（§）: 該当セクションの仕様がコードに反映されているか
3. 要件定義書に記載されているが実装されていない要件を 「未実装要件」 として記録

Step 4: 実装品質チェック（手抜き検出）

以下のパターンを対象フェーズの実装ファイルから検索し、手抜きがないか確認する:

4.1 コード品質チェック

検索パターン（grep_search で実施）:
  - "TODO"、"FIXME"、"HACK"、"XXX"、"TEMP"  → 未完了作業の痕跡
  - "console.log("  → デバッグログの残存（本番不可）
  - "any"  → TypeScript の型安全性の欠如（型定義ファイル以外）
  - "// @ts-ignore"、"// @ts-expect-error"  → 型エラーの握りつぶし
  - "as any"  → 型の強制キャスト
  - "localhost"、"8080"、"8090"  → ハードコードされた URL / ポート
  - "password"、"secret"、"token" (文字列リテラル内)  → ハードコードされた秘密情報

4.2 アーキテクチャ準拠チェック

• BFF パターン: ブラウザコンポーネント（src/app/(ec)/, src/app/(admin)/）から直接バックエンド API（/api/v1/）を呼んでいないか。BFF Route Handlers (src/app/api/) 経由であること
• 環境変数: API ベース URL が環境変数経由であること（front-end-need.md §1.4）
• i18n-ready: UI テキストがハードコードされず、翻訳キー方式であること（front-end-need.md §4.6）
• エラーハンドリング: API 呼び出し箇所に RFC 7807 エラーハンドリングが実装されていること（front-end-need.md §4.2.1）

4.3 セキュリティチェック

• トークン保存: localStorage.setItem / sessionStorage.setItem でトークンを保存していないこと（front-end-need.md §4.3.1）
• 入力バリデーション: フォームに zod スキーマバリデーションが実装されていること
• 認可チェック: 管理画面のコンポーネントにロールチェックが実装されていること

Step 5: テスト存在確認

対象フェーズで実装されたコンポーネント・ページ・hook・util に対して:

1. 単体テストファイルの存在: 各コンポーネントに対応するテストファイル（.test.tsx / .test.ts）が存在するか
2. テストの充実度: テストがスタブ（it('should pass', () => expect(true).toBe(true))）ではなく、実際のレンダリング・操作・アサーションを含むか
3. テスト実行: npm run test がエラーなく通過するか（実行可能な環境の場合）

Step 6: 検証レポートの生成

全ステップの結果を以下のフォーマットで統合レポートとして出力する:

# Phase {N} 完了検証レポート

## 実施日時
YYYY-MM-DD

## 総合判定
✅ 合格 / ⚠️ 条件付き合格 / ❌ 不合格

## 1. 修了条件チェックリスト結果

| # | チェック項目 | 結果 | 備考 |
|---|------------|------|------|
| 1 | {項目} | ✅/❌/⚠️ | {詳細} |
| ... | ... | ... | ... |

**合計**: ✅ {n}件 / ❌ {n}件 / ⚠️ {n}件

## 2. 設計書要件 突合せ結果

| 要件 ID | 要件概要 | 実装状況 | 備考 |
|---------|---------|---------|------|
| FR-xxx | {概要} | ✅ 実装済 / ❌ 未実装 / ⚠️ 部分実装 | {詳細} |
| ... | ... | ... | ... |

**未実装要件**: {件数}件

## 3. 実装品質チェック結果

### コード品質
| チェック項目 | 結果 | 検出箇所 |
|------------|------|---------|
| TODO/FIXME 残存 | ✅/❌ | {ファイル:行} |
| ハードコード URL | ✅/❌ | {ファイル:行} |
| ... | ... | ... |

### アーキテクチャ準拠
| チェック項目 | 結果 | 備考 |
|------------|------|------|
| BFF パターン | ✅/❌ | ... |
| ... | ... | ... |

### セキュリティ
| チェック項目 | 結果 | 備考 |
|------------|------|------|
| トークン保存方式 | ✅/❌ | ... |
| ... | ... | ... |

## 4. テスト確認結果

| 対象 | テストファイル | テスト充実度 | 備考 |
|------|-------------|------------|------|
| {コンポーネント} | ✅/❌ | ✅/⚠️/❌ | ... |
| ... | ... | ... | ... |

## 5. 是正が必要な項目

| # | カテゴリ | 重要度 | 内容 | 対応方針 |
|---|---------|--------|------|---------|
| 1 | {カテゴリ} | 高/中/低 | {内容} | {方針} |
| ... | ... | ... | ... | ... |

判定基準

判定	条件
✅ 合格	修了条件チェックリスト全項目 PASS、未実装要件 0 件、品質チェック全項目 PASS
⚠️ 条件付き合格	PARTIAL が 1〜2 件、かつ低重要度の品質指摘のみ（次フェーズ開始前に修正必須）
❌ 不合格	FAIL が 1 件以上、または未実装要件あり、またはセキュリティ指摘あり

注意事項

• 全項目を必ず検証すること: チェックリストの項目を飛ばしたり、「おそらく問題ない」と推定で PASS にしない。ファイルを実際に読んで確認する
• 設計書を正として判断する: 実装コードと設計書に矛盾がある場合、設計書（front-end-need.md）を正とし、実装側を「不適合」と判断する
• 手抜きパターンを厳格にチェックする: スタブ実装（空の関数、ダミーデータ返却、TODO コメントのみ）は FAIL とする
• 前のフェーズの修了条件が壊れていないか確認する: リグレッション検出のため、前フェーズの主要チェック項目も抜き打ちで確認する

参照ドキュメント

• フェーズ別検証ガイド — 各フェーズ固有の検証ポイント・重点確認事項
• 要件トレーサビリティマトリクス — 全要件 ID とフェーズのマッピング・確認すべきファイルパス
• 品質チェックパターン集 — 手抜き検出パターン・コード品質基準の詳細
• front-end-impl-plan.md — フロントエンド実装計画書（修了条件チェックリスト）
• front-end-need.md — フロントエンド要件定義書（設計書・仕様の正）