verifying-consistency

Spec・テスト・実装の整合性チェック

このセッション/ブランチで作成・修正した機能について、Spec・テスト・実装の整合性を確認する。

1. 対象ファイルの特定

ブランチ分岐点からの差分を特定

.stdd.config.yml の project.primary_branch（PR/統合先ブランチ）を読み、その分岐点からの差分を特定する。

# <primary_branch> は .stdd.config.yml の project.primary_branch（例: main / develop）
git fetch origin <primary_branch>
git log --oneline origin/<primary_branch>...HEAD
git diff origin/<primary_branch>...HEAD --name-only

以下を特定:

• Specドキュメント: docs/ 配下の REQUIREMENTS.md, TECH_DESIGN.md
• テスト: *.test.ts, *.test.tsx, e2e/tests/**/*.spec.ts
• 実装: app/, components/, lib/, actions/, domain/ 配下のファイル

2. ID ベース・トレーサビリティ監査（機械的・最優先）

名前一致ではなく安定 ID（UC-<feature>-NN / FL-<feature>-NN）で 要件 → 技術設計 → テスト → 実装 を突合する。 検知は共通スキャナ .claude/hooks/trace-audit.sh（依存なし・pre-push / CI と同一ロジック）に委ね、 結果を解釈して報告する。設定は .stdd.config.yml の traceability（enforce / patterns / scan 等）。

2A. 順方向（抜け漏れ検知）

bash .claude/hooks/trace-audit.sh

• トレーサビリティ行列（ID × 設計 / テスト計画 / テスト / 実装）と抜け漏れ一覧を出力する。
• 検知する抜け漏れ: 設計漏れ / テスト計画漏れ / テスト実装漏れ / 実装漏れ（require_impl_annotation 時）/ 孤児参照 / ID 重複。
• traceability.enforce=block のとき、抜け漏れがあれば非ゼロ終了する（それを NG 判定に用いる）。

2B. 逆方向（テスト/実装起点の改修 → 影響範囲）

このセッション / ブランチの変更ファイル（§1 で取得済み）を渡し、テスト・実装起点の改修がどの要件に波及するか、 および追跡不能変更（どの ID にも紐づかないテスト / 実装変更 ＝ spec-first 逸脱の疑い）を検知する。

# <primary_branch> は .stdd.config.yml の project.primary_branch
CHANGED=$(git diff --name-only origin/<primary_branch>...HEAD)
bash .claude/hooks/trace-audit.sh --changed $CHANGED

# 特定 ID の全リンク先を辿るとき
bash .claude/hooks/trace-audit.sh --impact UC-<feature>-01

• 各変更が紐づく ID と、その ID の全リンク先（対応要件・技術設計箇所・他テスト / 他実装）を列挙する。
• ID に解決しないテスト / 実装変更は 追跡不能変更として報告し、spec-first（Spec 起点）に立ち返るよう促す。

トレーサビリティ監査で検知した抜け漏れ・追跡不能変更は、§4 の出力にトレーサビリティ行列・影響範囲サマリとして必ず載せる。以降の §3 は ID では機械化しきれない内容（設計判断の反映・モック整合など）を人/AI が補完的に確認する。

3. 整合性チェック項目（補完・人/AI による確認）

A. REQUIREMENTS.md ⇔ 実装

• REQUIREMENTS.md のユースケース（振る舞い＋受入基準）が実装で網羅されているか
• REQUIREMENTS.md の画面仕様（ボタン、フォーム、表示項目）が実装と一致しているか
• REQUIREMENTS.md に記載された機能要件が全て実装されているか