test

test - 検証ステージ

不変条件

• タスク文書の受け入れ基準に照らして検証します。
• プロジェクトで利用できる最適な検証手順を使用します。
• 中核のワークフローで、特定のブラウザー自動化ツールを必須にしません。
• docs/testing/ に最終レポートを必ず 1 つ作成します。
• テストに合格し、ユーザーが承認したら、TASKS.md を Approved に更新し、行が移動したことを確認するためトラッカーを再度読み込みます。トラッカーが古いままだと、後続の処理やヘッドレスセッションがブロックされます。

ランタイムアダプターでは、このステージをスラッシュコマンド、メニューアクション、または自然言語によるスキル呼び出しとして公開できます。ポータブルなステージ名は test です。

ワークフロー

1. AGENTS.md を読みます。
2. タスク ID を特定し、docs/task/{ID}-{task-name}.md を読みます。
3. タスクが品質ゲートに到達したことを確認します。
4. Acceptance Criteria と Verification Approach に基づいて検証計画を作成します。
5. 既存のプロジェクトコマンドと CI 互換のチェックを優先します。
6. 安全な検証コマンドを実行します。
7. タスクで必要な場合に限り、ブラウザー自動化または手動チェックを使用します。
8. プロジェクトに docs/templates/test-report.md があれば、そのテンプレートを使用して docs/testing/{ID}-{task-name}.md を作成します。なければ、このファイルと同じ場所にバンドルされている templates/test-report.md を使用します。
9. テストに合格してユーザーが承認した場合に限り、タスクを Approved に移動します。修正が必要な場合は Testing のままにします。
10. 移動した場合は TASKS.md を再度読み込み、タスクの行が Approved にあり、Testing には存在しないことを確認します。行が想定したセクションにない場合、移動が反映されていません。引き渡し前に編集してください。

検証の優先順位

まず、信頼性を保てる範囲で最も対象を絞ったチェックを使用します。

1. 純粋なロジックにはユニットテストを使用します。
2. API、データベース、サービス、またはモジュール間の動作には統合テストを使用します。
3. ユーザーに見えるワークフローには、ブラウザーチェックまたはエンドツーエンドチェックを使用します。
4. プロジェクトの品質基準に含まれる場合は、型チェック、リント、ビルドなどの静的チェックを使用します。
5. 自動化が利用できない、または費用対効果が低い場合に限り、手動で確認します。

実行可能な検証方法がない場合は、不足しているものを説明した BLOCKED レポートを作成します。

証拠に関するルール

• 各基準のチェックを実行し、タスク文書の Baseline と比較します。 両方の値を記録します。チェックが実行され、期待される結果が示された場合に限り、その基準は合格です。
• 判定方法の信頼性を評価します。 ソーステキスト、ファイル構造、またはモックの呼び出し回数を検証するチェックで確認できるのは、コードの形状であり、動作ではありません。そのような結果は弱い証拠として示し、動作や出力を確認できる場合は、そちらも実行します。
• リグレッションがないことを確認するチェックは必須であり、省略できません。 タスクで変更してはならないとされている動作を再実行します。
• 推論だけを根拠に PASS と判定してはいけません。 チェックを実行できなかった場合は、その理由とともに SKIPPED または BLOCKED とします。

ライブ検証

テストに合格すればコードが正しいことは示せますが、変更が稼働中であることまでは示せません。変更が個別にデプロイされる複数の部分（サービス、関数、ワーカー、マイグレーション）を通じて反映される場合は、次のようにします。

• 稼働状況（ステータスコード、「ジョブ成功」、デプロイ済みバージョン番号）ではなく、実行中のシステムにおける出力（変更によって生成される行、メッセージ、レコード）を検証します。
• 先にデプロイまたは担当者による作業が必要なチェックは、PASS とせず、必要な手順を正確に記載して Deferred とします。

レポートのルール

• 最終レポートは docs/testing/ のみに作成します。
• 実行したコマンドは正確に記録します。
• スキップしたチェックとその理由を記録します。
• セッション履歴がなくても実装ステージで問題を修正できるだけの証拠を含めます。

引き渡し

PASS：

Verification passed for task {ID}
Report: docs/testing/{ID}-{task-name}.md
Next stage after user approval: document {ID}

FAIL または BLOCKED：

Verification failed or blocked for task {ID}
Report: docs/testing/{ID}-{task-name}.md
Return to implementation with the report context.