verify-claims

STARTER_CHARACTER = 🧾

主張を検証する

証拠によって主張を裏付けるための3つの手順です。各手順は、主張を行った後ではなく、行う前に実施します。

主張の種類別の検証コマンド

主張に、それを裏付けるコマンドを対応付けます。このターンでコマンドを実行してください。過去の実行結果を記憶に頼るのではなく、実際の出力を使用してください。

主張	コマンド	不十分なもの
テストが成功する	プロジェクトのテストコマンド。全テストまたは指定したテスト	過去の実行、「成功するはず」
リンターに問題がない	プロジェクトのリンターコマンド	部分的なチェック、推測
ビルドが成功する	プロジェクトのビルドコマンド。終了コードが0	リンターが成功、ログに問題がなさそう
バグが修正されている	元の症状を再現するテスト	コードを変更した、「修正されたように見える」
回帰テストが機能する	レッド・グリーン・リバート・リストア（下記参照）	テストが一度成功すること
サブエージェントが完了した	VCS の差分と対象を絞った再確認	サブエージェントの自己報告
要件を満たしている	仕様を読み直し、行ごとにチェックリストで確認	テストが成功すること

サブエージェントの結果を検証する

サブエージェントは最終メッセージで成功を報告します。その報告は証拠ではありません。差分が証拠です。

サブエージェントから結果が返されたら：

1. サブエージェントの要約を読む
2. git status と git diff を実行し、実際に何が変更されたか確認する
3. サブエージェントがテストの成功を主張した場合は、このターンでテストコマンドを実行する
4. サブエージェントがバグの修正を主張した場合は、このターンで再現ケースを実行する
5. その後で初めて結果を受け入れ、次に進む

サブエージェントはプレッシャーを受けると、成功したという報告を捏造することがあります。その報告は事実として受け入れるのではなく、検証すべき仮説として扱ってください。

回帰テストのためのレッド・グリーン・リバート・リストア

修正後に書いたテストは、すぐに成功します。すぐに成功しても、何も証明できません。テストがバグを検出できることを証明するには：

1. 回帰テストを書く
2. 修正を適用した状態でテストを実行する。期待結果：成功。
3. 修正のみを元に戻す。
4. テストを実行する。失敗しなければなりません。
5. 修正を復元する。
6. テストを実行する。期待結果：成功。

手順4でテストが成功した場合、そのテストはバグを検証できていません。破棄して、新しいテストを書いてください。

テスト駆動開発の順序（先にテストを書き、その後で修正する）に従っている場合、この手順は不要です。これは、順序が逆になった場合の復旧手順です。