/tdd-verify-complete

description: TDD開発でテストケースの実装が完全に完了しているかを検証します。すべてのテストが通ることを確認し、開発完了を保証します。
allowed-tools: Read, Glob, Grep, Task, Write, Edit, TodoWrite
argument-hint: "[要件名] [TASK-ID]"

TDD開発でテストケースの実装が完全に完了しているかを検証します。

context

出力ディレクトリ="./docs/implements" 機能名={{feature_name}} タスクID={{task_id}} 要件名={{requirement_name}} メモファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md 要件定義ファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md テストケースファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md Refactorフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-refactor-phase.md 元タスクファイル=docs/tasks/{taskfile}.md

step

• $ARGUMENTS がない場合、「引数に要件名とTASK-IDを指定してください（例: ユーザー認証機能 TASK-0001）」と言って終了する
• $ARGUMENTS の内容と context の内容をまとめてユーザに宣言する
• step2 を実行する

step2: コンテキスト準備

検証コンテキストの準備を実行する：

1. **タスクノートの読み込み（唯一のコンテキストソース）**

• `./docs/implements/{要件名}/{{task_id}}/note.md` を読み込み
• 存在しない場合: @task で `/tsumiki-legacy:tdd-tasknote {要件名} {{task_id}}` を実行して生成
• note.mdには技術スタック、開発ルール、関連実装、設計文書、テスト関連情報、注意事項が集約済み

2. **直前フェーズの出力を読み込み**

• `./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md` - 要件定義
• `./docs/implements/{要件名}/{{task_id}}/{feature_name}-testcases.md` - テストケース定義
• `./docs/implements/{要件名}/{{task_id}}/{feature_name}-refactor-phase.md` - Refactorフェーズの結果
• `./docs/implements/{要件名}/{{task_id}}/{feature_name}-memo.md` - 開発履歴メモ（存在する場合）

3. **元タスクファイルを直接読み込み**

• `docs/tasks/{taskfile}.md` - タスクの完了状態を確認
• プロジェクト全体のタスク進捗を把握

読み込み完了後、step3 を実行する

step3: 既存テストのグリーン状態確認

• **必須**: @task で全ての既存テストが成功していることを確認
• **テスト結果のスコープ分類**:
• テストケースファイル（{feature_name}-testcases.md）に記載されたテストファイルを「スコープ内」とする
• それ以外の失敗テストは「スコープ外」として分類
• **スコープ内テスト失敗がある場合**: 要改善として記録（後のstep7で差し戻し判定に使用）
• **スコープ外テスト失敗がある場合**: memoファイルに記録し、auto-debug対応を推奨として記録
• **この工程では修正禁止**: テスト失敗を発見してもここでは修正しない
• **テスト実行時間の確認**:
• 総実行時間が30秒以上の場合は記録
• 2秒以上かかるテストファイルを特定して記録
• 遅いテストがある場合は以下を推奨として記録:

    📝 推奨事項: テスト実行速度の改善

    総実行時間: XX秒（30秒以上）
    遅いテストファイル:
    - test/user.test.js: 15秒
    - test/integration.test.js: 8秒

    改善方法:
    1. `/tsumiki:dcs:test-performance-analysis` で詳細分析
    2. `/tsumiki:test-optimization-patterns` でパターンを確認
    3. 次のTDDサイクルで段階的に改善

• テスト状態（スコープ内/スコープ外それぞれ）を記録し、step4 に進む

step4: 実装状況の分析

• 現在のテストファイルを確認
• 実装済みテストケース数をカウント
• 各テストケースの内容を予定（テストケース定義ファイル）と照合
• <analysis_format> の形式で分析結果を提供する
• 品質判定基準に基づいて合否判定を行う
• step5 を実行する

step5: 検証結果のメモファイル記録

• {{メモファイル}} の既存内容を整理・統合し、<memo_format> の形式で更新
• **統合更新ルール**に従って、重要情報を保持し重複を削除
• 実装パターン、テスト設計、品質保証の学習ポイントを記録
• 修正が必要な項目がある場合、後工程での対応方針を記載して step7 を実行する
• 修正が必要ない場合、step6 を実行する

step6: 元タスクファイル完了マーク更新

検証が完了した場合、以下の手順で元タスクファイルを自動更新：

1. **完了タスクの特定**: 現在のTDD開発対象タスクを元タスクファイルから特定 2. **完了マーク追加**: 該当タスクに `✅ **完了**` マークを追加 3. **完了理由記載**: `(TDD開発完了 - [テスト数]テストケース全通過)` を追記 4. **サブタスク更新**: 関連するサブタスクにも `[x]` チェックマークを追加

例：

### 1. JSONファイルパス引数処理機能 ✅ **完了** (TDD開発完了 - 15テストケース全通過)

- [x] コマンドライン引数でJSONファイルパスを受け取る機能を追加
- [x] 複数のJSONファイルパスに対応（sample/ディレクトリ全体の読み込み）
- [x] 引数バリデーション機能

step7 を実行する

step7: TODO更新と次ステップ判定

• TodoWrite ツールで TODO ステータスを更新する
• 現在のTODO「検証フェーズ（完全性確認）」を「completed」にマーク
• 検証結果をTODO内容に反映
• 品質判定結果をTODO内容に記録

• **完全実装済み判定**: 以下の条件を満たす場合は 完全実装済み とする
• 今回のタスクのテスト状態: すべてグリーン（スコープ内テストが全パス）
• 要件網羅率: 100%（全要件項目実装・テスト済み）
• テスト成功率: 100%（スコープ内のみ）
• 未実装重要要件: 0個

• **完全実装済みの場合**:
• スコープ外テスト失敗なし → <complete_output> の形式で出力し、次のステップを提案
• スコープ外テスト失敗あり → <complete_with_scope_warning_output> の形式で出力し、auto-debug対応を推奨

• **実装不足がある場合（スコープ内テストに失敗あり）**: <incomplete_output> の形式で出力し、状況を報告

rules

検証の原則

• **この工程では修正を行わない**
• この検証フェーズではコードやテストの修正は一切行わない
• 問題を発見した場合は内容をmemoファイルに記載する
• 修正作業は後の工程（次のTDDサイクルや別のタスク）に委ねる
• 検証・記録・報告に専念する
• テストの実行は @task で実行する

禁止事項（NEVER）

• コードやテストの修正禁止
• 新規実装の追加禁止
• テストケースの削除・変更禁止
• 全体のテストケースの実装率と成功率のレポートは省略禁止

品質基準

最低品質基準

• **実装率**: 80%以上
• **成功率**: 100%
• **重要テスト**: すべて実装
• **要件網羅性**: 要件定義書の主要機能をすべて網羅
• **コンパイルエラー**: なし

理想品質基準

• **実装率**: 100%
• **成功率**: 100%
• **網羅性**: 全ケース対応
• **要件完全網羅**: 要件定義書の全項目を網羅

品質判定基準

✅ 高品質（完全達成）:
- 今回のタスクのテスト: すべてグリーン
- スコープ外テスト: すべてグリーン
- 要件網羅率: 100%（要件定義書の全項目に対する完全な実装・テスト）
- テスト成功率: 100%
- 未実装重要要件: 0個
- 要件充実度: 要件定義に対する完全な充実度を達成

✅ タスク完了（スコープ外問題あり）:
- 今回のタスクのテスト: すべてグリーン
- スコープ外テスト: 失敗あり（auto-debug対応推奨）
- 要件網羅率: 100%
- 今回のタスクの要件充実度は完全達成
- スコープ外の問題は別途 /tsumiki:auto-debug で対応

⚠️ 要改善（タスク未完了）:
- 今回のタスクのテスト: 失敗あり
- 要件網羅率: 100%未満（要件定義書の項目に対する実装・テスト不足）
- 重要な要件項目が未実装・未テスト
- 要件充実度: 要件定義に対する充実度が不十分
- 追加実装による要件充実度向上が必要

ファイルパスの記載ルール

• **プロジェクトルートを基準とした相対パスを使用する**
• フルパス（絶対パス）は記載しない
• 例:
• ❌ `/Users/username/projects/myapp/src/utils/helper.ts`
• ✅ `src/utils/helper.ts`

info

<analysis_format>

テストケース実装状況

📋 TODO.md対象タスク確認

• **対象タスク**: [現在のTDD開発対象タスク名]
• **現在のステータス**: [未完了/部分完了/完了済み]
• **完了マーク要否**: [要/不要]

📋 予定テストケース（要件定義より）

• **総数**: [予定していた総テストケース数]
• **分類**:
• 正常系: [数]個
• 異常系: [数]個
• エッジケース: [数]個
• その他: [数]個

✅ 実装済みテストケース

• **総数**: [実装済み総テストケース数]
• **成功率**: [通過テスト数]/[実装テスト数] ([成功率]%)

❌ 未実装テストケース（[数]個）

1. **テストケース名**: [予定していたが未実装のテスト]

• **種類**: [正常系/異常系/エッジケース]
• **内容**: [テストの詳細内容]
• **重要度**: [高/中/低]
• **要件項目**: [対応する要件定義書の項目]

2. **テストケース名**: [2つ目の未実装テスト] ...

📋 要件定義書網羅性チェック

• **要件項目総数**: [要件定義書の総項目数]
• **実装済み項目**: [実装・テスト済みの項目数]
• **要件網羅率**: [実装済み]/[総数] = [網羅率]%

未網羅の要件項目（[数]個）

1. **要件項目**: [未実装の要件項目名]

• **分類**: [入力パラメータ/出力仕様/制約条件/使用例/エラーケース等]
• **内容**: [要件の詳細内容]
• **実装不足の理由**: [なぜ未実装なのか]
• **対応の必要性**: [必須/推奨/任意]

2. **要件項目**: [2つ目の未網羅項目] ...

📊 実装率

• **全体実装率**: [実装数]/[予定数] = [実装率]%
• **正常系実装率**: [実装数]/[予定数] = [実装率]%
• **異常系実装率**: [実装数]/[予定数] = [実装率]%
• **エッジケース実装率**: [実装数]/[予定数] = [実装率]%

要件定義書の網羅性チェック

要件定義書（requirements.md）に記載された以下の項目が実装・テストされているかを確認：

必須チェック項目

• **入力パラメータ**: 全ての必須・オプション引数の処理
• **出力仕様**: 期待される出力形式・構造の実装
• **制約条件**: パフォーマンス・セキュリティ・互換性要件
• **基本使用例**: 想定される基本的な使用パターン
• **エッジケース**: 境界値・例外条件の処理
• **エラーケース**: 異常系の適切な処理
• **主要アルゴリズム**: 機能の核となる処理ロジック

網羅性判定基準