verification-before-completion

obra/superpowers のコミット b36e0829c6d0140e93cfef2ca599b1b07d4a7797（MIT）を基にしています。

同じサーフェスで証拠を示す規律は、Cursor の poteto-mode のコミット 93b00b89ef425a9c1bac0d0b317dfc49c930ac99（MIT、Copyright (c) 2026 Cursor）を基にしています。

完了前の検証

NO COMPLETION CLAIMS WITHOUT VERIFICATION EVIDENCE MATCHING THE CLAIM

成功を主張する前、コミットする前、または PR を作成する前に、次のことを行います。

1. 各主張を裏付けるコマンドまたは観察内容を特定し、その主張が示すサーフェスで実行します。
2. 適用可能な証拠に基づいて主張します。対象を絞ったチェックを今すぐ実行するか、関連するコード、テスト、入力、環境が今も一致している検証済みの証拠を再利用します。ツリーが同一であることは十分な条件の一つですが、それだけが条件ではありません。名前を付けられる到達可能なシナリオがないテストやコマンドを追加しないでください。カバレッジ率や重複した証拠を増やすことは目的ではありません。プロジェクトで必須のチェックは引き続き適用されます。サービスが現在稼働している、成果物が現在存在するといった現状に関する主張には、現時点での観察が必要です。過去の結果では証明できません。
3. 関連する出力を最後まで読み、終了ステータスと失敗件数を確認します。
4. 作業を委任した場合やファイルを変更した場合は、VCS の差分を確認します。
5. 承認されたタスクを一文で言い直し、要件と記述された規約に照らして結果を比較し、「承認／修正／引き継ぎ／確認」を選びます。追加のアイデアはコードではなく一行で示します。修正を始める前に、レビューでの指摘への対応を決めます。失敗したゲートは却下し、範囲内の小さな違反は修正し、規模が大きい作業や範囲外の作業は人間に引き継ぎます。修正は一度、差分の再確認も一度だけ行います。未解決の指摘は、再度の対応に進まず人間に引き継ぎます。
6. 実際の結果を証拠とともに報告します。チェックに失敗した場合や実行していない場合はその旨を伝え、未検証の項目を明示します。引き継ぎ、コミット、内容に変更のないマージがあっても、引き続き適用可能な証拠は無効になりません。再実行が必要なのは、関連する差分または具体的な仮説がある場合であり、「最終」というラベルを付けるだけでは不十分です。

証拠は主張するサーフェスに合致している必要があります。コンパイルはコンパイルを証明し、ユニットテストが証明するのはそのテストで検証した動作だけです。例は主張に合致させます。UI に関する主張にはレンダリング済み UI、CLI に関する主張にはビルド済みまたはインストール済みの CLI、永続化に関する主張には再起動後の読み取り、移行に関する主張には変換済みデータと古いパスのチェックを用います。テストはビルドを証明せず、リンターは型を証明せず、コード変更はバグの修正を証明せず、エージェントの報告はその作業を証明しません。回帰テストが信頼できるのは、実用上可能な場合に、意図したレッド／グリーンの挙動が確認された後だけです。

アサーションを弱めたり、失敗したチェックをスキップしたり、古いチェックや一度も実行していないチェックを証拠として提示したりしないでください。また、証拠の代わりに「はずです」「おそらく」「そう見えます」といった表現を使わないでください。チェックの失敗は、より広範なテストの実行、期待値の緩和、成功するまでの再実行を正当化しません。名前が示された失敗を調査したら、そこで停止するか、エスカレーションしてください。