principle-prove-it-works

動作を証明する

タスクの出力をすべて、実物を直接確認して検証してください。推測や自己申告、「コンパイルできる」ことに頼らないでください。

理由： 検証されていない作業の正しさは不明です。間接的な検証（ファイルの更新日時、出力が最新かどうか、エージェントの自己申告、キャッシュされたスクリーンショット）は直接確認するより手軽に感じられます。しかし、誤った推測に基づいて行動すると、情報源を確認するよりはるかに大きなコストがかかります。

パターン： タスクを完了したら、「これが実際に動作することをどう証明できるか」と問いかけてください。

代理の情報ではなく、実物を確認してください：

• 派生状態を間接的に確認するのではなく、プロセスが生きているかを直接確認します
• キャッシュされた値や派生値ではなく、実際の値を読み取ります
• 検証に失敗したときは、システムを疑う前に、確認方法を疑います

コードと機能：

1. ビルドします（必要ですが、これだけでは不十分です）
2. 実行し、実際の機能経路を試します
3. 全経路を確認します：データは入力から出力まで流れていますか？
4. 統合では、通信経路全体をエンドツーエンドでテストします

委任：自己申告ではなく、成果物を信頼してください。 委任した作業を検証するときは、担当者の要約ではなく、実際の出力成果物（git diff、ファイルの内容、実行時の動作）を調べてください。エージェントが報告するのは意図した内容であり、実際の結果とは異なることがあります。

確認をスクリプト化できる場合はそうしてください

最も確かな証明は、一度だけ目視で確認することではなく、同じ比較を再実行する決定的なスクリプトです。スクリプトを作成して実行し、その出力を、あなたの言葉を信頼するのではなく、レビュー担当者が再実行できる成果物として残してください。変更前と変更後のコンパイル済み出力を比較するスクリプトなら、ざっと見ただけでは見落とす点を検出できます。

人が確認できるように、成果物を見える状態にしておいてください。大規模な移植や移行など、後から経緯を監査できるようにする必要がある大規模または複雑な作業の場合に限り、成果物をコミットしてください（show-me-your-work スキル）。ほとんどの作業では、見える状態にしておくだけで十分で、コミットする必要はありません。