prove-claim

主張を証明する

鉄則

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

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

ゲート関数

ステータスを主張したり、満足を表明したりする前に、次の手順を踏んでください。

1. 特定 — この主張を正確に証明するコマンドはどれですか？（コマンドは docs/agents/project.md に記載されています。見つからない場合は、その旨を伝え、configure-repo を提案し、コマンドを手動で特定してください。）ある記録（チケット、リモート、保存された行など）に変更が反映されていることが主張の内容である場合、証明コマンドは書き込みではなく読み取りです。したがって、特定されるのはコマンドの組み合わせであり、書き込みだけではこのゲートを決して通過できません。
2. 実行 — 新たに、最後まで実行してください。プロジェクト全体のスイートコマンドを使い、パスやパターンを限定したサブセットを使ってはいけません。キャッシュされた結果や「以前は通った」は認められません。スコープを限定した実行の集計はそのスコープのものであり、スイート全体のものではありません。それをスイート全体の結果として引用すれば、実際にコマンドを実行していたとしても、主張は虚偽です。
3. 出力を読む — 終了コード、失敗件数、警告を含む、出力全体を確認してください。最後の行だけでは不十分です。
4. 確認 — 出力は実際に主張を裏付けていますか？裏付けていない場合は、証拠を添えて実際の状況を報告してください。裏付けている場合は、証拠を添えて主張してください。

どれか一つでも省けば、検証ではなく嘘になります。

主張 → 証拠

主張	必要なもの	決して十分ではないもの
「テストに合格しました」	新たに実行した全体テスト、失敗ゼロ、出力の確認	以前の実行、サブセット、「合格するはず」
「タスクゲートがグリーンです」	最終コミット時点での該当ゲートと、そのスコープの明記：変更されたユニット、それらの依存先、ベースラインに対する lint — または、エスカレーション理由を添えたスイート全体	「テストに合格しました」として引用すること；変更されたユニットや依存先が含まれていないスコープ
「ビルド／lint／型チェックに問題はありません」	該当コマンドの実行、終了コード 0、警告ゼロ	別のツールが成功すること
「機能は動作します」	実行中のシステムで対象のフローを動かし、その動作を確認すること（必須のサブスキル：validate-feature を使用；製品のウォークスルーでは、ガイドを実行すること — run-dogfood の実行ファイル、または記録された人間によるチェック項目を使う）	ユニットテストがグリーンであることだけ；write-dogfood のガイドが存在するだけで、実際にウォークスルーされていないこと
「バグは修正されました」	元の症状を再テストし、解消したこと	コードを変更したこと
「エージェント／サブエージェントが X を完了しました」	自分で差分を確認したこと	エージェント自身の成功報告
「チケットが更新／移動／コメントされました」	書き込み後に記録を読み返すこと — トラッカー独自の読み取りコマンドで課題を再読み込みし、正確な変更が反映されていることを確認する	書き込みコマンドの成功行；終了コード 0；コマンドを実行したという事実
「要件を満たしています」	ドキュメントのみを対象とする監査トレースチェックに問題がないこと（必須のサブスキル：audit-trace を使用 — タスク／定義の整合性を確認し、ID がテスト内にあるかを grep するのではありません）、かつ、各受け入れ基準を観察された動作に照らして個別に確認すること	テストがグリーンであることだけ；テストファイルに CODE-N.M の文字列があること
台帳またはチェックポイントに「検証済み」と記載されている	行に証明コマンドとその実行範囲が記されていること	ID だけ（Verified: BILL-1.4）；「スイートはグリーンだった」

回帰を確実に検出するパターン

回帰テストは、バグを確実に検出したことが実証されて初めて有効になります。

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

リバート後も通るテストは、何もテストしていません。

危険信号 — 作業を止めてゲートを実行してください

• 「動くはずです」「たぶん」「そう見えます」「自信があります」
• 根拠を確認する前に満足する（「よし、完了です！」）
• 以前の実行時の記憶を根拠に主張する
• 台帳の Verified: 行が、コマンドも対象範囲もなく、IDだけになっている
• 書き込みコマンドに成功メッセージが表示されたものの、変更されたとされる記録を読み直していない
• 直近の実行をしないまま、コミット、プッシュ、PR をしようとしている
• 疲れてタスクを終わらせたくなっている — 疲労は根拠ではありません

考え	実態
「これで通るはずです」	実行してください
「10分前に実行したばかりです」	その後コードが変わっています。もう一度実行してください
「エージェントが成功したと言いました」	差分を読んでください
「部分的なチェックで十分です」	部分的なチェックでは、残りについて何も証明できません
「変更したファイルのテストは実行しました」	実行したのは一部だけなのに、その件数をテストスイート全体の件数として述べています。回帰は選ばなかったファイルに潜んでいます
「Verified: BILL-1.4 で十分です — テストスイートは実行したばかりです」	ID は対象範囲を示しません。この行には、コマンドとその対象範囲を記載します
「最後に全部まとめて検証します」	主張はそれぞれ、その都度検証します。最後にまとめると、それまでに述べた誤った主張が事実として扱われてしまいます
「マージ後に CI が検出します」	CI が実行されるのは主張が公開された後です。ゲートは主張する前に設けるものであり、後から他の人に負担をかけるものではありません
「表現が違うので、このルールは当てはまりません」	このルールは言い換えや暗示も対象とします

コマンドを実行してください。出力を読んでください。そして、その後に限り、そう述べてください。