principle-prove-it-works

動作を証明する

すべてのタスクの出力を、実物を直接確認して検証します。代理指標、自己申告、「コンパイルできた」ことから推測してはいけません。

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

代理指標ではなく、実物を確認します。

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

承認されたスコープを考慮する

当初承認された要件に照らして確認します。計画、要約、委任によって、要件の範囲を暗黙に狭めてはいけません。各要件を、既存のタスク記録にある証拠または明示的な不足事項に結び付けます。要件が満たされていなければ、完全に完了したとは主張できません。backstop または judgment タグはそのまま保持し、承認されたスコープ変更は別途記録します。ランナーの記録がある場合は、それを再利用します。

作業に脅威モデルまたはセキュリティレビューが含まれる場合は、宣言されたすべての脅威について、脅威が及ぶ境界での緩和策の証拠と照合します。緩和したという主張は証拠ではありません。承認された責任者を伴う受容済みリスク、責任者と証拠を伴う移管済み責任、または未解決の不足事項を記録します。未解決の脅威は、完了判定に明示したままにします。

証明を結果に結び付ける

各チェックで検証した成果物、該当する場合はそのリビジョン、および関連する環境を記録します。変更を統合した後は、統合済みの結果に対して、影響を受けるパスのチェックを再実行します。個別のブランチでチェックに合格していても、それらを組み合わせた結果の証明にはなりません。

タスクまたはプロジェクトで指定されている場合は、名前付きの受け入れヘルパーを実行します。実行できない場合は、その不足事項を報告します。代替手段を同等として扱う前に、同じ受け入れ基準を満たす根拠を示します。

可能であればチェックをスクリプト化する

最も強力な証明は、一度限りの目視確認ではなく、同じ比較を再実行する決定的なスクリプトです。スクリプトを作成して実行し、その出力を成果物として保持します。レビュー担当者があなたの言葉を信じる代わりに、自分で再実行できるようにしてください。

成果物を人間が確認できる状態にしておきます。記録の保存と証拠の保持に関するルールには、show-me-your-work スキルを使用します。