verify-this

これを検証する

Cursor の cursor-team-kit/verify-this（MIT。THIRD_PARTY.md を参照）を、このアプリのサーフェスに合わせて改変したものです。

検証は要約ではありません。再現可能な証拠で、特定の主張を立証または否定します。

使用するタイミング

• 「これを検証して」「動作することを証明して」「これで直った？」「証拠を見せて」と依頼された場合。
• バグ修正に修正前と修正後の再現が必要な場合。
• ページ、API、エージェントの出力、パフォーマンスに関する主張を測定する必要がある場合。
• テストは成功しているものの、ユーザーに見える挙動を確認する必要がある場合。

「コードがすっきりした」のような曖昧な主張には使用しないでください。まず測定可能な主張を尋ねてください。

ワークフロー

1. 主張を反証可能な形で言い換えます。条件、指標、しきい値を明確にします。
2. それを否定できる、最小のローカルサーフェスを選びます（以下を参照）。
3. 変更前の状態からベースラインを取得します。マージベース、親コミット、または現在の不具合の再現を使用します（ベースの git worktree には、それぞれ専用の検証インスタンスがあります）。
4. 同じコマンド、データ、環境を使い、変更後の状態から検証対象の結果を取得します。
5. 生の成果物を比較します。数値、スナップショット、HTTP レスポンス、実行結果の行、評価テーブルなどです。
6. 次の判定を 1 つだけ返します。VERIFIED、NOT VERIFIED、INCONCLUSIVE。

このアプリのローカルサーフェス

• コードの挙動：対象を絞ったユニットテスト（node --test test/unit/<file>）。
• ページ：アプリのジャーニー（npm run build && npm run journey。boring-app-template を参照）、またはブラウザードライバー（control-ui）を使った snapshot、screenshot、network-summary、trace。
• API とワイヤー上の通信：変更前と変更後に verify api <path> を実行します。
• エージェントが出力する内容：アプリをローカルで起動（npm run dev）して操作するか、エキスパートのスキルについては hachej/boring-stack の評価を使います。
• パフォーマンス：verify perf、またはベースラインと検証対象で同じマシンを使って計測します。

判定ルール

• VERIFIED：明らかな交絡要因がなく、ベースラインと検証対象に、主張されたしきい値を満たす予測どおりの差があります。
• NOT VERIFIED：挙動に変化がない、予測と逆方向に変化する、またはしきい値に届きません。
• INCONCLUSIVE：有効なベースラインがない、シグナルが不安定（3 件のケースにおけるエージェントの出力は不安定です）、測定に失敗した、または環境の違いによって比較が無効です。

出力

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 は有用です。コミットする成果物に実際のユーザーデータを含めないでください。