verify-this

これを検証する

検証は単なる振り返りではありません。再現可能な証拠によって、特定の主張を立証または反証します。

使用するタイミング

• ユーザーが「これを検証して」「動作することを証明して」「これで直った？」「証拠を見せて」と尋ねたとき。
• バグ修正の前後で再現テストが必要なとき。
• UI、CLI、API、パフォーマンス、メモリに関する主張を測定する必要があるとき。
• テストには合格しているものの、ユーザーから見える動作の確認が必要なとき。

「コードがきれいになった」など、曖昧な主張には使用しないでください。まず測定可能な主張を確認してください。

ワークフロー

1. 主張を反証可能な形式に言い換えます。条件、指標、しきい値を明確にします。
2. その主張を反証できる、最小のローカルな対象を選びます。
3. 変更前の状態からベースラインを取得します。マージベース、親コミット、失敗するブランチ、または現在の不具合を再現した状態を使います。
4. 変更後の状態から、同じコマンド、データ、ウォームアップ、環境で処置後の結果を取得します。
5. 生の成果物を比較します。数値、スクリーンショット、ターミナルの記録、HTTP レスポンス、プロファイル、ヒープスナップショット、テスト出力などです。
6. 次の判定をちょうど 1 つ返します。VERIFIED、NOT VERIFIED、INCONCLUSIVE。

ローカルな検証対象

• コードの動作：対象を絞った単体テスト／統合テスト、または最小限の再現スクリプト。
• CLI／TUI の動作：control-cli、ターミナルの記録、またはデモの録画。
• UI の動作：control-ui、スクリーンショット、アクセシビリティスナップショット、またはブラウザーのトレース。
• API の動作：ローカルの HTTP／RPC リクエストとレスポンスの差分。
• パフォーマンス：同一マシンでの変更前／変更後の実行時間または CPU プロファイル。
• メモリ：問題が疑われる操作の前後で取得したヒープスナップショット。

成果物の配置

成果物を安全に書き込める場合：

/tmp/verify-this/<claim-slug>/
├── claim.md
├── timeline.md
├── baseline/
├── treatment/
├── diff/
└── verdict.md

成果物に機密性の高いコード、プロンプト、スクリーンショット、HTTP 本文、ヒープデータが含まれる可能性がある場合、ユーザーがディスクへの保存に同意しない限り、インラインの証拠は必要最小限にとどめてください。

判定ルール

• VERIFIED：ベースラインと変更後の結果が予測どおりの方向に、主張されたしきい値以上の差で変化しており、明らかな交絡要因がありません。
• NOT VERIFIED：動作に変化がない、逆方向に変化した、またはしきい値に達していません。
• INCONCLUSIVE：有効なベースラインがない、シグナルにノイズがある、測定に失敗した、または環境の違いによって比較が無効になっています。

出力

次の形式を使用してください。

VERIFIED | NOT VERIFIED | INCONCLUSIVE
Claim: <falsifiable claim>

Evidence:
<metric/artifact>: baseline=<...>, treatment=<...>, delta=<...>, threshold=<...>

Reasoning:
<one tight paragraph naming the evidence and any confounds>

否定的な結果を曖昧にしないでください。明確な NOT VERIFIED は役に立ちます。