verification

検証は、元のリクエストが実際に満たされていることを確認します。これは、コードがクリーンであることだけを確認する sniper とは異なります。検証は 6 ステップのプロセスを実行します。元のリクエストを一字一句読み直し、すべての受け入れ基準（明示的および暗黙的）を列挙し、それぞれを具体的な証拠（テスト出力、ログ、スクリーンショット、差分）で確認し、リグレッションがないか完全なテストスイートを実行し、変更されたすべてのファイルに偶発的な副作用がないかレビューし、そして「機能的に解決済み」という主張を書き留める前に `challenger` エージェントを通します。

ステップ 6 は常に .claude/apex/docs/verify-{task-slug}.md を永続化します -- コンテキスト内だけの「動作します」という宣言はセッションの境界を越えて残らず、この成果物こそが後続のゲート（sniper、elicitation）が実際に確認するものです。これは APEX において eLicit と eXamine の間に位置します。検証と sniper の両方がパスしたときにのみ、タスクは完了となります。

完了前の検証

概要

Sniper はコードの品質を検証します。検証は機能的な解決を検証します。 タスクをクローズする前に、両方が必要です。

Sniper はリンターエラー、SOLID 違反、コードスタイルの問題を検出します。検証は、元のリクエストが実際に満たされていること -- 正しい動作、正しい出力、正しい修正 -- を保証します。タスクはエラーゼロで sniper をパスしても、機能的には誤っている可能性があります。

観点	Sniper	検証
焦点	コードの品質	機能的な正しさ
確認項目	リンティング、SOLID、スタイル	受け入れ基準、リグレッション、副作用
実行タイミング	コード変更後	タスクを完了とする前
結果	クリーンなコード	解決された問題

---

エージェントのワークフロー

呼び出されたら、タスクを完了とする前に、以下の 6 ステップの検証プロセスに従ってください。

6 ステップの検証プロセス

ステップ 1: 元のリクエストを再読する 元の issue、タスクの説明、またはユーザーメッセージに戻ってください。一言一句読み直してください。記憶や思い込みに頼ってはいけません。

ステップ 2: すべての受け入れ基準を列挙する 元のリクエストから、明示的および暗黙的な要件をすべて抽出してください。番号を振ってください。リクエストが曖昧な場合は、合理的なユーザーが期待するであろう内容を列挙してください。

ステップ 3: 各基準を証拠とともに検証する 各基準について、解決を示す具体的な証拠を提示してください：

• 期待される動作を示すテスト出力
• 修正を確認するログ出力
• UI 変更のスクリーンショット
• 実装を示すコード差分

ステップ 4: リグレッションを確認する テストスイート全体を実行してください。実行前後の結果を比較してください。新たな失敗も新たな警告もあってはいけません。

ステップ 5: 副作用を確認する 変更したすべてのファイルをレビューしてください。無関係なコードに偶発的な変更がないことを確認してください。依存関係と設定が、必要でない限り変更されていないことを検証してください。

ステップ 6: 機能的な解決を確認する -- 異議を唱えてから、成果物を書く 「元の問題は機能的に解決された」と書く前に、必ずその主張を challenger エージェント（または challenge スキル）に、新しいコンテキストで通してください：主張 = 「機能的に解決された」+ ステップ 3～5 の証拠であり、調査の推論を決して含めないでください。これは系統的なものであり、すべての Verify ゲートで例外なく、ちょうど sniper がすべての eXamine で実行されるのと同じです。CONFIRMED の結果（またはオーナーが明示的に受け入れた UNCERTAIN）を得た後にのみ、「FUNCTIONALLY resolved」の判定を書いてください。REFUTED の判定は、その主張がオーナーに届く前に解決（修正と再検証）されなければなりません -- ソフトゲートであり、ハードな拒否権ではありません。

.claude/apex/docs/verify-{task-slug}.md を書いてください（テンプレート：references/verify-template.md）：すべての検証ステップが確認され、各基準につき 1 つの証拠項目（コマンド出力、ログの抜粋、スクリーンショットのパス、または差分）、さらにこのステップの異議判定を含めます。コンテキスト内だけの「動作する」という宣言はセッションの境界を越えて生き残りません。書き出された成果物こそが、ガードレールゲート（sniper、後の elicitation パス）が実際に確認するものです。次に、回答内で明示的に述べてください：「元の問題は機能的に解決されました」と証拠の要約を添えるか、未解決のまま残っているものを列挙してください。

{task-slug}：apex-methodology/references/init-tracking.md に従って導出します（git ブランチのスラッグまたはアクティブな TaskCreate id）-- elicitation スキルの成果物が使用するのと同じパターンです。

---

リファレンスガイド

リソース	パス	内容
チェックリスト	references/checklist.md	すべてのカテゴリを含む完全な検証チェックリスト
よくある見落とし	references/common-misses.md	忘れられがちな検証項目
成果物テンプレート	references/verify-template.md	verify-{task-slug}.md テンプレート + task-slug の導出

---

APEX との統合

検証は APEX ワークフローにおいて eLicit と eXamine の間 で実行されます：

Analyze -> Plan -> Execute -> eLicit -> [VERIFICATION] -> eXamine (sniper)

これにより、コード品質の検証の前に機能的な正しさが確認されます。タスクは、検証と sniper の 両方 が合格したときにのみ完了します。

---

重要なルール

ルール	理由
元のリクエストの再読を決して省略しない	間違った問題を解決することを防ぐ
すべての基準に証拠が必須	「動作する」は証拠ではない
新しいテストだけでなく、テストスイート全体を実行する	リグレッションを検出する
変更したすべてのファイルをレビューする	偶発的な副作用を検出する
検証と sniper の両方が合格しなければならない	正しさのない品質は無意味である
ステップ 6 は verify-{task-slug}.md をディスクに書き込む	永続化された状態のないコンテキスト内自己レビューはセッションをまたいで劣化する