verify

/verify — 7 フェーズ検証パイプライン

概要

コンパイラーエラーから、見つけにくいアンチパターンやフォーマットのずれまで、あらゆるレベルの問題を検出する、逐次実行型の7フェーズ検証パイプラインを実行します。各フェーズでは、詳細とともに明示的な PASS、WARN、または FAIL を出力します。「問題なさそう」は検証結果ではありません。ステータス一覧こそが検証結果です。重大な失敗（フェーズ1のビルド、フェーズ4のテスト）が発生すると、後続フェーズでは意味のある結果を得られないため、パイプラインをそこで終了します。

このパイプラインが答えるのは、次の質問です。「このコードはレビューに出せる状態ですか？」

フェーズ	ツール	検出する問題	重大
1. ビルド	dotnet build	コンパイルエラー、参照の不足	はい
2. 診断	get_diagnostics (MCP)	新たなアナライザー警告、null 許容性の問題	新たなエラーがあれば FAIL
3. アンチパターン	detect_antipatterns (MCP)	async void、同期処理による非同期処理の呼び出し、DateTime.Now など	いいえ
4. テスト	dotnet test	テストの失敗、リグレッション	はい
5. セキュリティ	dotnet list package --vulnerable + スキャン	シークレット、SQL インジェクション、認証の欠如、脆弱なパッケージ	重大／高リスクなら FAIL
6. フォーマット	dotnet format --verify-no-changes	スタイルのずれ、フォーマットの不整合	いいえ
7. 差分レビュー	git diff の分析	意図しない変更、デバッグコードの残骸、TODO	いいえ

実行するタイミング

• 機能の実装、バグ修正、大規模なリファクタリングが完了した後
• プルリクエストの作成前 — 省略せず、パイプライン全体を実行します
• 上流の変更をマージした後、または依存関係を更新した後
• ユーザーが「verify」「すべて確認して」「準備できている？」「すべてのチェックを実行して」と言ったとき
• タスクを完了としてマークする前の最後の手順として

実行するフェーズ

デフォルトではパイプライン全体を実行します。変更範囲が限定されている場合は、一部のフェーズを実行します。

シナリオ	フェーズ	備考
機能の実装完了／プルリクエスト前／新しいエンドポイント	7つすべて	省略しません
バグ修正	1、2、4	対象をカバーするテストがない場合は、まずテストを追加します
リファクタリング後	1、2、3、4	正確性を重視します。セキュリティに関わる場合は5〜7も追加します
依存関係の更新	1、4、5	ビルド、テスト、脆弱性スキャン
設定またはテストのみの変更	1、4	ビルドとテスト
フォーマットのみ	6	フォーマットチェックで十分です

迷ったときは、7つすべてを実行してください。追加のフェーズにかかるのは数分ですが、セキュリティ問題を見落とすと、インシデント対応に数日かかります。変更が「安全そう」だからという理由で、フェーズを恣意的に選んではいけません。

実行方法

フェーズ1：ビルド（重大 — ここで終了）

dotnet build --no-restore --verbosity quiet

• ビルドが失敗した場合は、そこで終了します。エラーを報告して修正してから続行してください。コンパイルできないコードに対して、後続フェーズを実行しても意味がありません。
• PASS の場合も警告数を記録します。新しい警告はフェーズ2で追跡します。
• 出力：PASS（エラー0件）または FAIL（エラー一覧付き）

フェーズ2：診断

Roslyn MCP の get_diagnostics ツールを使用し、変更したファイル／プロジェクトに範囲を限定します（複数箇所にまたがる変更の場合は、ソリューション全体を対象にします）。ベースラインと比較し、現在の変更によって新たに導入された警告のみを指摘します。よくある指摘事項：CS8600／CS8602（null 許容性）、CS0219（未使用の変数）。

出力：PASS（新規0件）／WARN（新しい警告）／FAIL（新しいエラー）。新しい警告も対応すべき問題として扱ってください。今日の CS8600 は、来月の本番環境での NullReferenceException につながる可能性があります。

フェーズ3：アンチパターン検出

変更したファイルに対して Roslyn MCP の detect_antipatterns ツールを使用します（広範な変更の場合はプロジェクト全体を対象にします）。検出対象：async void、同期処理による非同期処理の呼び出し（.Result、.GetAwaiter().GetResult()）、new HttpClient()、TimeProvider の代わりに DateTime.Now／UtcNow を使用している箇所、広範な catch (Exception)、ログ出力での文字列補間、CancellationToken の欠落、AsNoTracking を使用していない EF の読み取りクエリ。

出力：PASS（指摘事項0件）／WARN（指摘事項あり）／FAIL（重大なアンチパターン）

フェーズ 4：テスト（重大 — 失敗時は後続フェーズをスキップ）

dotnet test --no-build --verbosity quiet

• 大規模なソリューションの場合は、テストスイート全体を実行するか、影響を受けるテストプロジェクトに範囲を絞ります。
• テストが1つでも失敗した場合は FAIL です。例外はありません。後続フェーズに進む前に停止して修正してください。
• テストプロジェクトがない場合は、SKIP とし、テストの追加を推奨します。

出力：PASS（すべて成功）または FAIL（失敗したテスト名とエラーメッセージ）

フェーズ 5：セキュリティスキャン

dotnet list package --vulnerable --include-transitive

次に、変更したファイルを確認し、ハードコードされたシークレット／接続文字列／API キー、 SQL インジェクション（パラメーター化されていない生の SQL）、必要なエンドポイントでの [Authorize] の欠落、 過度に許可的な CORS、入力検証の欠落、HTTPS または証明書検証の無効化がないか確認します。

出力：PASS／WARN（中程度／低程度の指摘事項）／FAIL（重大／高リスクの脆弱性）

フェーズ 6：フォーマットチェック

dotnet format --verify-no-changes --verbosity quiet

自動修正は行わず、差分を報告します。解決するには、dotnet format を実行し、その変更をコミットに含めてください。.editorconfig がない場合は、推奨事項として記載してください。

出力：PASS／WARN（ファイル一覧付き）

フェーズ 7：差分レビュー

git diff --stat と git diff（ステージ済み＋未ステージ）を分析し、次の点を確認します。

• 誤った変更や無関係なファイルの変更（.vs/、bin/、obj/、.env、シークレット）
• デバッグ用コードの残り（Console.WriteLine、本番環境のコードパスにある #if DEBUG）
• 未解決の TODO／HACK／FIXME マーカー
• スコープの不一致 — 変更内容がタスク／PR の説明と一致している必要があります

出力：PASS（問題がなく、意図と一致）／WARN（指摘事項あり）

修正と再試行のループ

1回の実行ですべてが成功することはほとんどありません。このループが重要です。

1. 特定 — どのフェーズが失敗したか、具体的なエラーは何か
2. 修正 — 解決に必要な最小限の変更を行います
3. 再実行 — 修正でコードが変わった場合はフェーズ 1 から、それ以外は失敗したフェーズから実行します
4. 繰り返し — すべてのフェーズが成功するまで、またはユーザーへの確認が必要な問題が発生するまで続けます

最終サマリー

## Verification Results

| Phase | Result | Details |
|-------|--------|---------|
| 1. Build | PASS | 0 errors, 0 warnings |
| 2. Diagnostics | PASS | 0 new diagnostics |
| 3. Antipatterns | WARN | 1 missing CancellationToken |
| 4. Tests | PASS | 47 passed, 0 failed |
| 5. Security | PASS | No findings |
| 6. Format | PASS | Clean |
| 7. Diff Review | WARN | 1 TODO marker found |

**Verdict: READY FOR REVIEW** (with 2 non-blocking warnings)

判定：レビュー準備完了（すべて PASS、またはブロック要因のない WARN のみ）または 修正が必要（FAIL がある場合は、具体的な修正手順を提示）。PR 作成前の実行では、検証レポートを PR の説明に含めてください。

例

User: /verify

Claude: Running 7-phase verification pipeline...

Phase 1: Build ............ PASS (0 errors)
Phase 2: Diagnostics ...... PASS (0 new warnings)
Phase 3: Antipatterns ..... WARN
  - src/Features/Orders/CreateOrder.cs:42 -- DateTime.Now usage, use TimeProvider
Phase 4: Tests ............ PASS (23 passed, 0 failed, 0 skipped)
Phase 5: Security ......... PASS
Phase 6: Format ........... PASS
Phase 7: Diff Review ...... PASS

Verdict: READY FOR REVIEW (1 non-blocking warning)

Recommendation: Replace DateTime.Now with TimeProvider on line 42 before
merging. Not blocking, but it will fail the antipattern check in CI.

関連項目

• /build-fix — フェーズ 1 が失敗した場合にビルドエラーを自動修正します
• /code-review — 検証に合格した後、多角的にレビューします
• /health-check — プロジェクト全体を段階評価します（この変更セットの範囲を超えます）