wesleymatosdev/proof-bearing-verification

Proof-Bearing Verification（証明力のある検証）

既存の実装、委任された作業、またはリリース準備状況をレビューする際に使用します。グリーンなコマンド、静的レビュー、またはエージェントによる要約は、それが主張する動作を実際に実行しない限り、証明とはなりません。

使用すべき場合

• エージェントがタスク完了と報告した時。
• テストはパスするが、その動作検証の強度が不明な時。
• バグ修正、UI変更、統合、または運用上の変更を検証する必要がある時。
• 静的レビューが、以前にランタイムで検証された動作と矛盾する時。

新しいコードに対してtest-driven-developmentの代わりにこれを使用しないでください。実装と並行して、または実装後に証拠を検証するために使用します。

手順

1. 主張された動作を明確にする。

   • 主張されている、ユーザーから見える、または外部から観測可能な結果を明示します。
   • 完了条件：主張は実装の詳細を参照せずにテスト可能であること。

2. 最も適切な実際の境界を選択する。

   • インポートのみのテストやスナップショットのみのテストよりも、マウントされたコンポーネントとの相互作用、統合リクエスト、CLI呼び出し、API呼び出し、またはエンドツーエンドフローを優先します。
   • 現実的なペイロードと本番に近いフィクスチャを使用します。
   • 完了条件：プローブが、動作が主張されているコードパスに到達すること。

3. プローブに歯があることを証明する。

   • 変更または削除された動作の場合、まず実装がない状態、または安全であれば意図的にno-opを入れた状態で、失敗を観測します。
   • 変更されたユニットをバイパスしてもグリーンのままのテストは無価値であり、証拠として使用してはなりません。
   • 完了条件：プローブが正しい動作と関連する壊れた動作を区別できること。

4. 証明を実行し検査する。

   • 焦点を絞ったチェックを実行し、次にプロジェクトの該当するより広範なチェックを実行します。
   • テスト作成者の要約を信頼するのではなく、テストまたはテストハーネス自体を読みます。
   • 完了条件：出力と実装の両方が正確な主張を裏付けること。

5. 矛盾する証拠を処理する。

   • ユーザーが検証したランタイム動作は、静的レビューの推奨で置き換える前に説明を必要とする証拠として扱います。
   • 見かけ上の矛盾を引き起こしているフレームワーク、キャッシュ、インフラストラクチャ、またはランタイムのセマンティクスを追跡します。
   • 完了条件：あらゆる変更は、レビュー担当者の確信ではなく、最も強力な利用可能な証拠に従うこと。

落とし穴

• Nodeでブラウザコンソールの動作を検証しないでください。 Nodeのconsole.logは%cをサポートしていません。スタイル文字列をプレーンな引数として扱い、黙って破棄するため、Node/Pythonのハーネスはきれいなグリッドを出力し、壊れたDevToolsのレンダリングを隠蔽します。コンソール出力を検証するには、実際のブラウザをCDP経由で駆動するか（ヘッドレスChromeの--remote-debugging-port + Runtime.consoleAPICalledをキャプチャするWebSocketスクリプト）、実際のコンソールからユーザーに見える証拠を取得します。異なるコンソールエンジンで動作するハーネスは証明にはなりません。
• %cセグメントが非常に多いconsole.logはDevToolsをオーバーフローさせます。 コンソールフォーマッタは引数を1つの指定子ずつ消費します。1回の呼び出しにスタイル付きセグメントが多すぎる（例：約193個）場合、末尾のスタイル文字列はスタイルとして消費されず、文字通り書式設定されていないテキストとして出力されます（古典的なcolor:#...;font-family...ガベージダンプ）。Chromeのドキュメントによると、対策はconsole.logを1行につき1回、各回の%cの数を制限することです。これが、1つの巨大なconsole.log('%c%s%c%s...')としての文字ごとのASCIIアートがスタイルを漏洩させる理由です。
• 「スローせずにレンダリングする」、タイプのみのフィクスチャ、テスト対象のユニットを置き換えるモック、および.todo()テストは動作を証明しません。
• 浅いテスト用の足場を満たすためだけに、本番の動作を決して変更しないでください。
• 外部依存関係、UI操作、またはデプロイパスが実行されていない場合、完了を主張しないでください。検証されていない境界を報告してください。

検証

完了レポートには以下を含める必要があります：証明された動作、使用された正確なコマンドまたはアクション、観測された結果、および検証されていないままの境界。