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：すべての受け入れ基準を列挙する 元の依頼から、明示的および暗黙的な要件をすべて抽出します。番号を付けます。依頼が曖昧な場合は、合理的なユーザーが期待する内容を列挙します。 途中で追加された内容も含め、依頼者が求めた各項目を特定します。ある項目（ゴミ箱、スラッグ、形式など）について得られたルールは、関連項目にも適用されます。同等性を保つため、それらも grep で確認します。

ステップ 3：証拠を示して各基準を検証する 各基準について、解決したことを示す具体的な証拠を提示します。

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

完了前に実物を見る（基本ルール）： 実際の出力、つまりレンダリングされたページ／スクリーンショット、抽出されたフレーム、対象環境の実行時ログ（稼働中の開発サーバー、実 DB、インストール済みビルド）を開き、そこに何が表示されているかを明記します。テストの成功や切り離されたフィクスチャだけでは完了とはいえません。クラッシュの修正では、まずテストでクラッシュを再現します。「エラーがなくなった」だけでは動作が正しいことの証明にはなりません。

ステップ 4：リグレッションを確認する テストスイート全体を実行します。変更前後の結果を比較します。新たな失敗や警告がないことを確認します。

ステップ 5：副作用を確認する 変更したファイルをすべて確認します。無関係なコードに誤って変更が加わっていないことを確認します。必要な場合を除き、依存関係と設定が変更されていないことを確認します。

ステップ 6：機能面での解決を確認する――異議を申し立ててから成果物を書く 「元の問題は機能面で解決しました」と書く前に、必ずその主張を challenger エージェント（または challenge スキル）に通します。コンテキストは新規にし、主張には「機能面で解決済み」という結論とステップ 3～5 の証拠のみを含めます。調査の推論は含めません。これは例外のない体系的な手順であり、すべての Verify ゲートで実行します。sniper がすべての eXamine で実行されるのと同様です。「FUNCTIONALLY resolved」という結論を書くのは、CONFIRMED の結果が得られた後（または、依頼者が明示的に受け入れた UNCERTAIN の場合）に限ります。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 の両方に合格して初めて、タスクは完了となります。

---

重要なルール

ルール	理由
元の依頼を必ず読み直してください	誤った問題を解決してしまうのを防ぎます
すべての基準に証拠が必要です	「動作する」だけでは証拠になりません
新しいテストだけでなく、テストスイート全体を実行してください	リグレッションを検出できます
変更したファイルをすべてレビューしてください	意図しない副作用を検出できます
検証とスナイパーの両方に合格する必要があります	正しさのない品質には意味がありません
ステップ 6 では verify-{task-slug}.md をディスクに書き込みます	状態を保存しないコンテキスト内でのセルフレビューは、セッションをまたぐと退行します