計画の検証

実装計画が正しく実行されたことを検証し、すべての成功基準を確認し、逸脱や問題を特定するタスクです。

初期セットアップ

呼び出された場合：

•
コンテキストを判断する - 既存の会話にいるか、新規で開始するか？
- •既存の場合：このセッションで何が実装されたかを確認する
- •新規の場合：gitとコードベースの分析を通じて何が行われたかを発見する
•
計画を特定する：
- •計画のパスが提供された場合、それを使用する
- •そうでなければ、最近のコミットで計画の参照を検索するか、ユーザーに確認する

•

実装の証拠を収集する：

bash

# 最近のコミットを確認する
git --no-pager log --oneline -n 20
git --no-pager diff HEAD~N..HEAD  # Nは実装コミットをカバーする数

# 包括的なチェックを実行する
npm test  # または make test など

検証プロセス

ステップ1：コンテキストの発見

新規開始またはさらにコンテキストが必要な場合：

•
実装計画を完全に読み込む
•
変更されたはずのものを特定する：
- •変更されるべきすべてのファイルをリストする
- •すべての成功基準（自動および手動）を記録する
- •検証すべき主要な機能を特定する
•
task ツールで explore エージェントを使用して並行調査タスクを生成する：
- •データベース/スキーマの変更が計画と一致するか検証する
- •実際のコード変更と計画の仕様を比較する
- •テストが指定通りに追加/変更されたか確認する

ステップ2：体系的な検証

計画の各フェーズについて：

•
完了ステータスを確認する：
- •計画のチェックマーク（- [x]）を探す
- •実際のコードが主張された完了と一致するか検証する
•
自動検証を実行する：
- •「自動検証」の各コマンドを実行する
- •合格/不合格のステータスを記録する
- •失敗がある場合、根本原因を調査する
•
手動基準を評価する：
- •手動テストが必要なものをリストする
- •ユーザー検証のための明確なステップを提供する
•
エッジケースについて深く考える：
- •エラー条件は処理されたか？
- •不足しているバリデーションはないか？
- •実装が既存の機能を壊す可能性はないか？

ステップ3：検証レポートを生成する

包括的な検証サマリーを作成する：

markdown

## 検証レポート：[計画名]

### 実装ステータス
✓ フェーズ1：[名前] - 完全に実装済み
✓ フェーズ2：[名前] - 完全に実装済み
⚠️ フェーズ3：[名前] - 部分的に実装（問題を参照）

### 自動検証結果
✓ ビルド合格
✓ テスト合格
✗ リンティングの問題（警告3件）

### コードレビューの所見

#### 計画と一致：
- [計画と一致する実装の詳細]
- [別の正しい実装]

#### 計画からの逸脱：
- [file:line]で異なるアプローチを使用
- [file:line]で追加のバリデーションを追加（改善）

#### 潜在的な問題：
- [発見された問題]
- [別の懸念事項]

### 手動テストが必要：
1. UI機能：
   - [ ] [機能]が正しく表示されることを確認する
   - [ ] 無効な入力でエラー状態をテストする

2. 統合：
   - [ ] 既存の[コンポーネント]と連携することを確認する

### 推奨事項：
- マージ前にリンティングの警告に対処する
- [シナリオ]のテストの追加を検討する

既存のコンテキストでの作業

実装に参加していた場合：

•会話履歴を確認する
•完了したことをToDoリストで確認する
•このセッションで行われた作業の検証に焦点を当てる
•ショートカットや未完了の項目について正直に報告する

重要なガイドライン

•徹底的かつ実践的であること - 重要なことに焦点を当てる
•すべての自動チェックを実行する - 検証コマンドをスキップしない
•すべてを記録する - 成功も問題も
•批判的に考える - 実装が本当に問題を解決するか疑問を持つ
•メンテナンス性を考慮する - 長期的にメンテナンス可能か？

検証チェックリスト

常に確認する：

• 完了としてマークされたすべてのフェーズが実際に完了している
• 自動テストが合格する
• コードが既存のパターンに従っている
• リグレッションが導入されていない
• エラーハンドリングが堅牢である
• 必要に応じてドキュメントが更新されている
• 手動テストのステップが明確である