verification-before-completion

完了前の検証

完了を主張する際は、実際の主張を裏付ける最新の証拠がある場合に限ります。ユーザーが許可した範囲に従ってください。リポジトリの指示は適用されるチェックを定めるものであり、変更、公開、要件の緩和を許可するものではありません。

手順

1. 編集前に、曖昧な対象範囲を明確にします。リポジトリを調べ、解釈が一つに定まる場合は安全な前提を明示します。実質的に異なる解釈が残る場合に限り質問し、回答を待つ間は争点となっている範囲を編集しないでください。

2. git status --porcelain を確認し、無関係な作業を保持します。ベースラインを含め、スイートやマイグレーションを実行する前に、対象のデータベースとサービスが破棄可能であることを確認します（専用のテストデータベース、コンテナー、または使い捨てスキーマを使用し、開発用データベースは決して使用しないでください）。(proof-integrity.md、検証前チェック）依存関係やフレームワークのアップグレード、コード生成、またはマイグレーションを行う場合は、書き始める前に既存の検証コマンド一式を記録し、変更後にそのまま再実行します。ベースラインが失敗した場合は、先に報告してください。ダーティーツリーで共有モジュールを検証する場合は、分離したベース比較が必要です。

3. 特定：主張を証明するコマンドを特定します。出荷可能な状態を主張する場合は、該当する全工程（ビルド、型チェック、リント、テスト、セキュリティスキャン、差分レビュー）を確認し、最初の失敗で停止します。プロジェクトで定められたゲートを読み、この作業に適用されるものを所定の順序で実行します。ゲートを独自に作り出さないでください。

4. 実行：証拠を今すぐ取得します。以前の出力、サブエージェントの報告、自信、成功を言い換えた表現は、最新の実行に代わるものではありません。

5. 確認：警告、実行数・成功数、欠落した成果物を含め、出力全体と終了ステータスを読みます。何も実行されないスイートは証拠になりません。意図したバイナリ、インタープリター、ソースリビジョン、エントリーポイントが実際に実行されたことを確認します。

   • 生の証拠を保持します。 表示フィルターによって、もっともらしい要約が生成される一方で、レコードが欠落したりバイト列が書き換えられたりすることがあります。解析、パッチ、件数、比較、レビューで完全なレコードや正確なバイト列が必要な場合は、フィルターを通さない出力を使用します。後続の head、tail、または cat では、生成元でフィルターされた出力を復元できません。

6. 検証：証拠が要件と関連する失敗経路を網羅していることを確認します。実装された安全な正の機能は、意図されたエントリーポイントを通じて動作しなければなりません。拒否のみの経路、スタブ、モック、または到達不能な実装は不完全です。

7. 主張：証拠で立証されたことだけを主張します。結果、実行したコマンド／URL／クリックの経路、失敗またはスキップしたチェック、重要な残存リスクを報告します。証明できた範囲がより狭い場合はその旨を示し、決定論的なフィクスチャと実環境での動作を区別します。

合格させるためにオラクルを満たしやすくしてはいけません。期待出力を再生成する前に、意味上の変更をレビューし、その妥当性を説明します。検証対象や成功経路をハードコードしてはいけません。関連する基準を網羅していれば、レビューで問題が見つからなかったことも有効です。残っているリスクを明示したうえで、そのリスクに対してのみチェックを拡張します。

検証リスクに応じた参照先

• ワークツリーに未コミットの変更がある場合、変更範囲が広い場合、厳格な入力検証が必要な場合、またはフィクスチャと実際のデータの由来を区別する場合は、proof-integrity.md を参照してください。無関係な編集が含まれる共有モジュールの場合は、isolated-verification.md も参照してください。
• リポジトリ全体の調査や「すべての項目」に関する主張を行う場合は、scope-and-sweeps.md を参照してください。追跡対象外または無視対象の一時状態にある項目をすべて列挙し、明示的な処置内容を保持し、移動後に再列挙し、削除された項目も確認してください。完了とするには、保留中の項目もブロックされている項目もゼロである必要があります。
• コマンドラッパー、空の結果、集計値、インストール済みバイナリ、または具体化されたリビジョンについては、verification-oracles.md を参照してください。結果がないことを解釈する前に、同じ実行形式で有効な対象を用いた検証が成功することを確認してください。
• ベンチマーク結果、高速化、またはパフォーマンスの回帰については、performance-measurement.md を参照してください。計測時間を解釈する前に、作業の完了状況と失敗の有無を確認し、計測された効果とその因果関係の説明を区別してください。
• フロントエンド、バックエンド、CLI、インフラストラクチャ、移行、パッケージ、スキーマ、ドキュメント、またはスクリプトによる一括処理の変更については、change-strategies.md の該当する行を参照してください。敵対的なプローブ、履歴の書き換え、古くなったレビューについても説明しています。
• 統合境界、コールバック、または孤立した状態については、system-wide-test-check.md を参照してください。
• 成果物の分類、チェックの失敗への対処、ブランチの範囲の説明、または pre-commit の失敗が発生した場合は、claims-and-failures.md を参照してください。

失敗と引き継ぎのルール

変更を加えずに、たまたま通るまで検証を再試行してはいけません。許可された範囲の実装上の失敗は修正して再実行してください。それ以外の場合は、具体的なブロッカーを明示してください。「既存の問題」「環境による問題」「不安定」とする場合は、意図的に選定したベースに対する証拠、または独立して確認された原因が必要です。

この作業が原因の pre-commit の失敗を回避してはいけません。文書化された例外を適用するには、ベースブランチで失敗が再現され、かつ事前にユーザーへ共有されている必要があります。このスキルによって、新たな回避権限が与えられることはありません。

委任された作業は、差分と関連するコマンドを使って直接検証してください。仕様への準拠と品質は分けて確認してください。要件を一行ずつ読み直してください。テストに合格することと、要件を満たすことは別の主張です。新しいコミットや外部の状態によって以前のレビューが無効になる可能性がある場合は、事実と位置情報を更新してください。報告は意思決定に必要な内容に絞り、空のステータス欄や、根拠のない確実性の表明は避けてください。