verify

検証

鉄則

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

証明するコマンドを今このセッションで実行していないなら、その主張をする資格はありません。検証していない主張は楽観論ではなく、虚偽です。

ゲート関数

ステータスを主張したり、満足を表明したりする前に、次の手順を実行します。

1. 特定 — この主張を正確に証明するコマンドはどれですか？（コマンドは docs/agents/project.md に記載されています。記載がない場合は、その旨を伝え、setup-repo を提案し、コマンドを自分で特定します。）
2. 実行 — 新たに、最後まで実行します。キャッシュ済みの結果、一部の範囲だけの実行、「以前は通った」は認められません。
3. 確認 — 出力全体を読みます。終了コード、失敗数、警告を確認します。最後の行だけでは不十分です。
4. 確証 — 出力は本当にその主張を裏付けていますか？ いいえの場合は、根拠とともに実際のステータスを報告します。はいの場合は、根拠とともに主張します。

いずれかの手順を省略するなら、それは検証ではなく、嘘です。

主張 → 根拠

主張	必要なこと	決して十分ではないもの
「テストに合格しました」	新たに全件実行し、失敗がゼロであることを確認して、出力を読む	以前の実行、一部だけの実行、「合格するはず」
「ビルド／lint／型チェックに問題はありません」	該当コマンドの実行、終了コードが 0、警告がゼロ	別のツールが通ったこと
「機能は動作します」	実行中のシステムで影響を受けるフローを操作し、動作を確認すること（必須サブスキル：acceptance-check を使用。手動で確認する場合は dogfood を使用）	単体テストに合格しただけ
「バグは修正されました」	元の症状を再テストし、解消されたことを確認する	コードが変更されたこと
「エージェント／サブエージェントが X を完了しました」	自分で差分を確認する	エージェント自身の成功報告
「要件を満たしています」	トレースチェックに問題がないこと（必須サブスキル：trace を使用）と、各受け入れ基準を観察した動作に照らして個別に確認する	テストに合格しただけ

リグレッションを確実に検出するパターン

リグレッションテストとして認められるのは、バグを確実に検出したことが実証されてからです。

write test → passes → revert the fix → test MUST fail → restore fix → passes

元に戻しても通るテストは、何もテストしていません。

警告サイン — 作業を止めてゲートを実行する

• 「動くはず」「たぶん」「そう見える」「自信があります」
• 根拠を確認する前に満足する（「よし、完了です！」）
• 以前の実行を記憶に頼って主張する
• 新たに実行せず、コミット、プッシュ、または PR を作成しようとしている
• 疲れて作業を終わらせたくなっている — 疲労は根拠ではありません

考え	現実
「今度は通るはず」	実行する
「10 分前に実行したばかり」	その後コードが変わったなら、もう一度実行する
「エージェントが成功したと言っていた」	差分を読む
「一部のチェックで十分」	一部だけでは、残りについて何も証明できない
「最後にまとめてすべて検証しよう」	主張はそれぞれ、主張した時点で検証します。最後にまとめて検証すると、それまでの誤った主張が事実として扱われてしまいます
「マージ後に CI が検出してくれる」	CI が実行されるのは主張が公開された後です。ゲートを通すのは主張する前であり、誰かに後始末をさせた後ではありません
「言い方が違うから、このルールは当てはまらない」	このルールは言い換えや含意にも適用されます

コマンドを実行します。出力を読みます。それから — その後に限り — 主張します。