prove

/prove は、チケット、仕様、または合意された成果が実際に満たされているかを確認します。固定された候補を検証し、ギャップを報告します。候補を修正することはありません。範囲を限定した修正には /repair-gaps を使い、その後に /prove を再実行してください。/implement-contract は候補を開発し、/review-implementation は契約への忠実性、範囲、エンジニアリング品質を別途確認します。どちらも証明の代わりにはなりません。

検証の前に、受け入れ契約プロトコルを読んでください。プロトコルでは、仕様の枠組み、識別情報、エビデンス、判定について定義しています。実用的な保証と焦点を絞った再検証のルールを適用してください。網羅的な確認や重複した確認を行わなくても、完全な網羅性と、最新の候補に対する新しい判定は確保できます。

任意の evidence-record v1 レコードは、エビデンス ID と計算済み SHA-256 ダイジェストを使って引用でき、その決定的な Markdown レンダリングを proof.md に埋め込めます。可能な場合は、正確な証明コンテキストに照らしてレコードを検証してください。レコードは任意であり、有効なレコードが判定を示唆することはありません。要件レベルの proven、not proven、disproven の判定は引き続き proof.md に記載し、/prove が責任を持ちます。ホストが発行したコマンド／テストのレシートがない場合、自分で実行したコマンドの観察結果は proof.md に直接記載してください。

判定

• PROVEN：重要な要件すべてに信頼できるエビデンスがあり、契約上の不一致が残っておらず、検証中に候補が固定されていました。
• NOT PROVEN：受け入れ済みの要件に信頼できるエビデンスがない、重要な反例または契約上の不一致が残っている、必須の検証を実施できない、または候補の識別情報が不確かです。任意の提案や、ブロッキングではない制限だけで PROVEN を妨げることはありません。
• 具体的な違反は disproven です。エビデンスを入手できない場合や結論が出ない場合は disproven ではなく not proven です。

ルール

• バージョン管理された受け入れ契約をソースおよび承認済みの修正と照合してください。契約を狭めたり書き換えたりせず、不一致を報告してください。
• プロトコルの証明およびマージ準備完了のルールに従い、全体的な PR ステータスとは独立して、要件のエビデンスを判定してください。無関係な CI の修正は /fix-pr に任せ、チェックがすべて成功するまで待ったり、それを証明の前提条件にしたりしないでください。
• 可能な場合は、クリーンなコミットを候補として使用してください。正確なスナップショットを確定できない限り、ダーティーな、または変更中のワークツリーは NOT PROVEN です。
• 証明の実行中に、製品ファイル、候補、または契約を変更してはなりません。変更が発生した場合は NOT PROVEN を返し、変更後の状態から得られた観察結果を破棄してください。修正は /repair-gaps に任せ、改めて /prove を実行する必要があります。
• 製品コード、テスト、CI 設定、または受け入れ契約を編集しないでください。
• コミット、プッシュ、公開、または修正の完了宣言を行わないでください。
• パブリックインターフェイスと独立したオラクルを通じた振る舞いのエビデンスを優先してください。
• 単にパスを実行するだけのテスト、恒真なアサーションを使うテスト、または失敗し得ないモックに依存するテストでは、約束された結果を証明できません。
• スタブ化された動作やフィクスチャ固有の動作、モックだけの代替、必須の本番状態を回避するエビデンスは認めないでください。実証された違反と、結果を不明のままにする弱い検証を区別してください。
• 約束された機能全体を判定してください。小規模な実装に不要なアーキテクチャがないことを理由に減点しないでください。依頼されていない範囲は、アーキテクチャ上の好みではなく、契約の除外事項またはソースとの照合に基づいて報告してください。

再利用可能なデリバリーの学びを保持する

今回の実行で、今後のデリバリー作業に役立つ可能性が高い、長期的かつ自明ではない知見が明らかになった場合は、学びの候補として含めてください。出力が空でも問題なく、教訓をでっち上げるより望ましい対応です。候補には、適用範囲、再利用可能な教訓、その教訓を示唆する具体的な証拠、重要な不確実性を記載する必要があります。

上位のコントローラーが構造化 JSON を要求している場合は、learning_candidates 配列に記載してください。それ以外の場合は、レポートに短い ## 学びの候補 セクションを追加してください。

学びの候補は /retrospect に渡す手がかりであり、承認済みの助言ではありません。契約、要件 ID、ステージの判定、適用範囲、修正許容範囲、権限を変更してはなりません。このスキルからプロジェクトルールや助言的な学習レジスターに昇格させてはなりません。

ワークフロー

1. 契約を確立する

.p2p/work/<slug>/contract.md を受け入れ、プロトコルの永続的な引き継ぎ規約に従って、リンクされた入力、candidate.json、.p2p/work/<slug>/ 内のレポートを特定してください。 ソース、保留中の修正、適用される上位の制約、正確な受け入れ契約のリビジョンを読み取ってください。すべての要件 ID、境界、接合部、オラクル、未解決の質問、除外事項を保持してください。ソースにある約束で省略、矛盾、または曖昧なものは、契約を編集せずに報告してください。バージョン管理された契約を確立できない場合は、NOT PROVEN と報告して /plan-acceptance に引き継いでください。証明の過程で契約を作成または改訂してはなりません。

スライスされた子の場合は、分解、貢献の対応付け、親のスナップショット、前提条件の結果を取得してください。プロトコルの親子ルールに従い、現在の親と修正内容を照合してください。無関係な兄弟機能は子の要件ではありません。重要な親の変更が未解決の場合、現在の合意は NOT PROVEN です。適用される親の識別情報を子の契約とともに記録し、再確認してください。親の証明では、1 つの正確な統合候補に対して、親のすべての義務とスライス間の相互作用を評価してください。過去の子の証明やクローズ済みの課題は参考情報であり、集約した親の判定ではありません。プロトコルの Epic デリバリープランの規則に従って、承認済みのデリバリープランと親の完了条件を確認してください。独立して取り込まれた貢献と、最終配置先で必要な統合を、正確な親候補に含めてください。すべての子が合格していても、相互作用に不合格があれば親は未証明のままです。すべてを独立してデリバリーする場合でも、PR が空であってよいのではなく、親の統合検証が必要です。配置先のみの変更では、プロダクトの約束は変わらず、別の候補の証明にもなりません。

2. 候補を特定する

完全なコミット SHA または正確なスナップショット、契約のソースとリビジョン、記録した契約の識別情報、必要に応じてターゲットまたはベース、検証環境を記録してください。プロトコルの識別規則に従い、チェックを開始する前に両方の識別情報を確認してください。candidate.json に照らして、作業項目のハッシュ、バインドされた親／仕様のハッシュ、比較ベースの SHA を検証してください。.p2p/ 外のプロダクトコンテンツを比較してください。ローカルの .p2p/ 記録の更新は元の候補の識別情報を保持し、Git 履歴には含めません。 識別情報を確立できない場合は、NOT PROVEN としてください。 候補または契約に変更があった場合、あるいは観測結果をそれらに結び付けられない場合は、NOT PROVEN としてください。

受け入れ済みのデリバリーでは、検証済みの比較ベースと正確な候補に証明を紐付けてください。配置先のみが後から移動しても、どちらの識別情報も変わりません。この証明は、候補が配置先のより新しいコミットと互換性があることを示すものではありません。

3. 証拠を対応付けて監査する

各要件について、観測内容と、それに合格かどうかを判定する独立したオラクルを明記してください。合意済みの公開接合部において、既存のテスト、不変条件、スキーマ、コマンドを確認してください。接合部またはオラクルに重要な変更が必要な場合は、黙って置き換えず、判断が必要なギャップとして報告してください。スイートに合格したり GitHub の基準を確認したりしても、結果が一度もアサートされていない約束はカバーされません。

4. 重要な反例を確認する

実際の変更と、その重要な接合部分に対する現実的な失敗ケースを選びます。 該当する場合に検討する例として、空・1 件・複数件、状態遷移、再試行、再起動、認可、並行処理があります。すべてのタスクで実行するチェックリストではありません。 重要な不確実性の解消に役立つ場合に限り、候補にひも付けた破棄可能なコピーで感度実験を行います。要件に信頼できる根拠があり、重要な反例も未解決の必須事項も残っていない時点で調査を終了します。 その後、仮説上の改善を探し続けないでください。

5. 変更を加えずに検証する

要件を確認できる、シグナルの強い最小限のチェックを実行します。候補の外部に永続的な証拠を保持し、各参照をその観察結果、アサーション、コマンド、環境にひも付けます。保存する証明レポートには、プロトコルの証拠ルールに従って証拠自体を含めてもかまいません。.p2p/、候補、取得済みの契約の外部にあるプロダクトコンテンツを、検証後にもう一度確認します。このスキルでは失敗を修正しないでください。必要な最小限の修正を報告し、/repair-gaps 向けに影響を受ける要件 ID を示します。

合意された契約またはリポジトリの標準で求められる場合、あるいは重要な回帰リスクを絞り込んだチェックでは信頼できる形で網羅できない場合は、全スイートを実行します。それ以外の場合は、十分な最小限のチェックを使用します。変更が小さく見えるという理由で、必須のチェックを省略しないでください。時間のかかるスイートが必要な場合は、実行前に、正確な破棄可能ワークスペースでセットアップを検証します。インタープリター、インポート、作業ディレクトリ、候補の識別情報を確認します。現在も有効なセットアップ情報は再利用し、無関係な確認を繰り返さないでください。ソースチェックアウトでの確認では、入れ子になったランナーの環境を確認したことにはなりません。実際のコマンド、環境、結果を記録します。セットアップの失敗は、候補の動作に関する証拠ではありません。失敗したセットアップは、再試行する前に修正します。全スイートの重複する試行を並行して起動しないでください。

局所的な修正後、以前の観察結果を引き続き使う前に、プロトコルの重点的な再検証条件を適用します。完全な差分を独立して確認し、影響を受けるチェックを実行します。そうでない場合は、新たに検証します。現在の正確な候補を対象に、すべての要件を網羅する新しいレポートを必ず作成します。任意の提案は、未解決の受け入れギャップや必要な修正とは分けて記載します。

6. 報告する

.p2p/work/<slug>/proof.md と、安全に保持できる evidence/ 内の証拠を保存して読み直します。履歴のルールに従い、以前の実行記録を保持します。生成した記録をプロダクト候補の外部に保存してもかまいません。読み取り専用のステージコンテキストでは、外側のワークフローが保存して読み直せるよう、正確なテキストを返します。再開時に一時ファイルを必須としてはなりません。適切でない証拠については、安全で永続的な参照、チェックサム、説明、アクセス制限を保持します。安全な永続コピーがない場合は、その証拠を利用できないと報告します。

意図した結果、契約との整合性、候補、環境、すべての要件の判定、証拠の観察結果、反例、候補の安定性、未解決のギャップを返します。証明結果では、すべての要件 ID を扱い、満たされていない約束を隠してはなりません。

出力

# <PROVEN | NOT PROVEN>: <source>

Requirements: <proven>/<total>
Counterexamples tested: <count>
Contract: <.p2p/work/<slug>/contract.md and exact revision>
Contract snapshot: <immutable reference or captured text and digest>
Parent context: <parent identity, snapshot, contribution mapping and prerequisites; omit if none>
Candidate: <commit or exact snapshot>
Candidate stability: <unchanged or NOT PROVEN>
Contract stability: <unchanged or NOT PROVEN>
Verification context: <environment>

## Outcome

<intended result and why it is or is not established>

## Requirement verdicts

| ID | Observation and oracle | Evidence reference | Verdict |
|---|---|---|---|
| R1 | <observed outcome and independent expected result> | <saved report section, artifact, or run; command and assertion> | proven |

## Unresolved gaps

- <requirement, counterexample, or limitation, or "None">

## Repairs needed

- <requirement ID and smallest complete repair, or "None">

Fresh `/prove` is required after any repair.
Refresh `/review-implementation` for the changed candidate as a separate phase.

レポートの後は Next steps: で終え、該当するアクションのみを番号付きリスト（1., 2., ...）で、参照できるよう順番に記載してください。 PROVEN の場合、レビューがないときは /review-implementation <saved candidate> against <comparison base> を提示してください。対応するレビューと証明の両方がそろっている場合は、この候補の受け入れを示す証拠がそろっていることを明記してください。既存の PR がマージ間近の場合は、 /merge-readiness <PR URL>; review <saved review>; proof <saved proof> を提示してください。既存の PR がまだマージ間近でない場合は、把握している保留中のゲートを記載し、PR がマージ判断に近づいたときに使う /merge-readiness <PR URL>; review <saved review>; proof <saved proof> を提示してください。この証明では PR のゲートを評価しないでください。 PR が存在しない場合は、公開を希望しない限り追加のアクションは不要であると述べてください。公開を希望する場合に限り、保存済みの参照を使って次の任意の公開プレビュー呼び出しを提示してください。

/publish-pr <candidate handoff>; review <saved review>; proof <saved proof>; target <branch>; draft only

NOT PROVEN の場合は、対象を絞った修正には /repair-gaps <saved proof> を、合意が不足している、または変更されている場合には /plan-acceptance <source> を提示してください。候補の識別情報または証拠が不確かな場合は、必要となる識別情報または証拠を具体的に記載してください。チェックを再実行する場合は、記録されたコマンドと期待される結果を含めてください。