verification

name	verification
description	レビュー完了後の最終検証に使用。テスト結果・要件充足・スコープ逸脱がないことを証拠付きで確認し、完了宣言の根拠を作る。

Verification（完了検証）

概要

「完了した」と言える根拠を作る。 テストが通る、レビューが通った、だけでは完了ではない。要件を全て満たし、スコープを逸脱していないことを証拠付きで確認する。

入力: REQ パス（例: requirements/REQ-001/）+ レビュー完了済みの実装コード + テストコード + requirements.md 全文 + レビュー報告 出力: 検証報告書（全 FR/AC の充足証拠 + スコープ確認 + 最終テスト結果）

原則: 「テストが通っている」は検証ではない。「要件が全て満たされている」が検証だ。

Iron Law

検証証拠なしに完了を宣言するな

レビューが通った ≠ 完了。レビューは品質を検証する。verification は要件充足を検証する。

• 「テスト全 GREEN だから完了」→ テストが要件を全てカバーしているとは限らない
• 「レビューで指摘がなかったから完了」→ レビュアーが見落としている可能性がある
• 「動いているから完了」→ 何が動いているかの定義がない

いつ使うか

常に:

• code-review（[8]）が完了した後
• コミット・PR（[11]）に進む前

例外（人間パートナーに確認すること）:

• ドキュメントのみの変更
• 設定ファイルのみの変更

プロセス

digraph verification {
    rankdir=TB;
    input [label="レビュー完了\nMUST指摘なし", shape=ellipse];
    test [label="テストスイート\n全体実行", shape=box, style=filled, fillcolor="#ccffcc"];
    fr_check [label="FR充足チェック\n各FRに対応する証拠", shape=box, style=filled, fillcolor="#cce5ff"];
    ac_check [label="AC充足チェック\n各ACのテスト結果", shape=box, style=filled, fillcolor="#cce5ff"];
    scope_check [label="スコープチェック\nやらないことを実装していないか", shape=box, style=filled, fillcolor="#ccccff"];
    report [label="検証報告書\n作成", shape=box, style=filled, fillcolor="#ffffcc"];
    judge [label="全項目\n充足?", shape=diamond];
    done [label="検証完了\n完了宣言可能", shape=ellipse];
    fail [label="不足箇所を\n報告→差し戻し", shape=box, style=filled, fillcolor="#ffcccc"];

    input -> test;
    test -> fr_check;
    fr_check -> ac_check;
    ac_check -> scope_check;
    scope_check -> report;
    report -> judge;
    judge -> done [label="はい"];
    judge -> fail [label="いいえ"];
}

1. テストスイート全体実行

全テストを実行し、GREEN であることを確認する。

• RED のテストがある場合、verification に進まない。差し戻す
• テスト実行のログを証拠として記録する

2. FR 充足チェック

requirements.md の各 FR（機能要件）に対して、実装が存在する証拠を確認する。

確認項目	方法
FR の振る舞い（WHEN）	対応するコードが実装されているか
FR の異常系（IF）	エラーハンドリングが実装されているか
FR の入力/出力	インターフェースが仕様通りか

各 FR に対して「充足 / 未充足 / 部分充足」を判定する。

3. AC 充足チェック

requirements.md の各 AC（受け入れ条件）に対して、テストが存在し通っている証拠を確認する。

確認項目	方法
AC に対応するテストの存在	テストコード内で AC の Given/When/Then に対応するテストを特定
テストの結果	テスト実行結果で GREEN であることを確認
Covers 対応	AC の Covers: FR-x が正しく対応しているか

各 AC に対して「テストあり GREEN / テストあり RED / テストなし」を判定する。

4. スコープチェック

requirements.md の「やらないこと」「スコープ外」に記載された項目が実装されていないことを確認する。

• decisions.md がある場合、除外判断された項目も確認する
• スコープ外の機能が実装されている場合、報告する

5. 検証報告書の作成

全チェック結果を検証報告書としてまとめる。

検証報告書のフォーマット

# 検証報告書

## テスト結果
- 実行日時: [YYYY-MM-DD HH:MM]
- テスト数: [N件]
- 結果: 全GREEN / N件RED

## FR 充足状況
| FR | 状態 | 証拠 |
|----|------|------|
| FR-1 | 充足 | [対応するコード・テストの要約] |
| FR-2 | 充足 | [対応するコード・テストの要約] |

## AC 充足状況
| AC | Covers | テスト | 結果 |
|----|--------|--------|------|
| AC-1 | FR-1 | test_xxx | GREEN |
| AC-2 | FR-1 | test_yyy | GREEN |

## スコープ確認
- スコープ外の実装: なし / [あれば詳細]

## 判定
- [PASS: 全項目充足、完了宣言可能]
- [FAIL: 不足箇所あり、差し戻し]

よくある合理化

言い訳	現実
「テストが通っているから検証不要」	テストが要件の全てをカバーしているとは限らない
「レビューが通ったから大丈夫」	レビューは品質の検証。要件充足の検証は別
「小さい変更だから検証は省略」	小さい変更でも要件との乖離は起きる
「動作確認は手動でやった」	記録がなければ証拠にならない。再現もできない
「前回と同じパターンだから」	同じパターンでも要件が違えば検証項目も違う

危険信号

以下のどれかに当てはまったら、検証をやり直せ。

• テストを実行せずに「通るはず」と判断した
• FR/AC との突き合わせをせずに完了とした
• スコープ外の確認をスキップした
• 検証報告書を作成していない
• 「前のステップで確認済み」と言って検証を省略した

例: ユーザー登録API

FR 充足チェック:

| FR | 状態 | 証拠 |
|----|------|------|
| FR-1: ユーザー登録 | 充足 | POST /users 実装済み、createUser関数でバリデーション→保存→レスポンス |
| FR-2: メール重複チェック | 充足 | findByEmail で既存ユーザー検索、409 Conflict 返却 |
| FR-3: パスワードハッシュ化 | 充足 | bcrypt.hash(password, 10) で保存前にハッシュ化 |

AC 充足チェック:

| AC | Covers | テスト | 結果 |
|----|--------|--------|------|
| AC-1: 有効な入力で登録成功 | FR-1 | test_create_user_success | GREEN |
| AC-2: メールなしでエラー | FR-1 | test_create_user_no_email | GREEN |
| AC-3: 重複メールでエラー | FR-2 | test_create_user_duplicate | GREEN |

判定: PASS — 全 FR 充足、全 AC テスト GREEN、スコープ外実装なし

検証チェックリスト

検証完了前に確認:

• テストスイート全体を実行し GREEN を確認した
• 全 FR の充足状況を確認した
• 全 AC に対応するテストの存在と GREEN を確認した
• スコープ外の実装がないことを確認した
• 検証報告書を作成した

行き詰まった場合

問題	解決策
FR に対応するコードが見つからない	未実装の FR がある。TDD に差し戻す
AC に対応するテストがない	テストが漏れている。test-quality に差し戻す
スコープ外の機能が実装されている	人間パートナーに報告。削除するか要件に追加するか判断を仰ぐ
requirements.md が不明確で判定できない	人間パートナーに仕様の明確化を依頼する

委譲指示

あなたはこのスキルのプロセスを自分で実行しない。以下のエージェントにディスパッチする。

前提: 対応する REQ を特定する。 ディスパッチ前に、このタスクに対応する requirements/REQ-*/requirements.md を特定しろ。タスクのコンテキスト（plan、直前のステップの出力）に REQ パスが含まれていればそれを使う。見つからなければ requirements/ を確認し、候補を人間パートナーに AskUserQuestion で提示して選択してもらう。推測で REQ を決めるな。必ず人間に確認しろ。

メタループ駆動の場合の例外: requirements/ が存在しない環境（workspace/ec-sample 等）では、progress.txt のストーリー定義を requirements の代替として使用する。

1. test-runner エージェントをディスパッチしてテスト全体実行

   • テストスイート全体を実行し、結果を取得する
   • RED のテストがある場合、verification に進まない

2. verifier エージェントをディスパッチする

   • プロンプトに REQ パス + 対応する REQ の requirements.md 全文 + テスト実行結果 + 実装コード + テストコード + レビュー報告を含める
   • コンテキストはプロンプトに全文埋め込む。 エージェントにファイルを読ませるな
   • verifier が FR 充足チェック → AC 充足チェック → スコープチェック → 検証報告書作成を実行する
   • verifier は完了時に 4ステータス（DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED）で報告する

3. あなたが結果を判断する

   • PASS（全項目充足）かつ DONE → 次のステップ（cleanup）に進む
   • FAIL（不足あり）→ 不足の種類に応じて差し戻す:
     • FR 未充足 → TDD に差し戻す
     • AC テストなし → test-quality に差し戻す
     • スコープ逸脱 → 人間パートナーに判断を仰ぐ
   • NEEDS_CONTEXT → 不足情報を補って再ディスパッチ
   • BLOCKED → エスカレーション判断ツリーに従う

4. あなた（コーディネーター）が検証証拠を記録する

   • verifier の報告を受けて、あなたが .claude/harness/last-verification.json に Write ツールで書き出す
   • verifier は Write 権限を持たない。証拠ファイルの書き出しはコーディネーターの責務
   • このファイルは verification-gate フックが git commit 前に参照する

   スキーマ（必須フィールド）:

   {
     "status": "PASS" | "FAIL",
     "timestamp": "ISO8601 UTC e.g. 2026-04-11T10:44:40Z",
     "req_path": "requirements/REQ-XXX/ or improvement-proposal-N or docs/design/XXX.md",
     "evidence_type": "test_run" | "integration_test" | "report",
     "evidence_paths": ["path1", "path2", ...],
     "reason": "1-2 行の検証結果要約"
   }
   

   任意フィールド:

   {
     "test_count": 103,
     "test_result": "103 tests GREEN",
     "notes": ["補足情報1", "補足情報2"]
   }
   

   evidence_type の使い分け:

   • test_run — 既存 TDD テストスイートの実行結果（node:test や bats の単体実行）
   • integration_test — 統合テスト or E2E シナリオ（複数コンポーネントの動作確認、手動フロー含む）
   • report — 検証エージェントの詳細レポート（間接検証や人手検証の記録）

Integration

前提スキル:

• code-review — 3観点レビュー完了、MUST 指摘なし

必須ルール:

• testing — テストルール（常時適用）

次のステップ:

• cleanup — 検証完了後の不要ファイル整理

このスキルの出力を参照するエージェント:

• 検証報告書はコミットメッセージ・PR 本文の根拠として使用される