verified-delivery

検証済みデリバリー

許可された変更を、実装からマージ、マージ後の検証まで、ライブ状態のゲートを順に通して進めます。次のステップを実行する前に、各ゲートをリポジトリ、PR、CI、レビューシステムの実際の状態に照らして検証し、各ゲートの判定を検証対象の正確なヘッド SHA に紐付けます。ツール呼び出しの予算、コンテキストの枯渇、ワーカーの交代、セッションの中断などの厳しい制限によって、デリバリーの完了前に作業が終了する可能性があるため、このスキルでは、永続的な中断時の引き継ぎと再開プロトコルを定めます。これにより、次に再開するときは、指示を言い直す要求ではなく、同じ指示の再開として扱います。

認可の境界

デリバリーは、変更内容と許可するゲートを明示したユーザーの指示がある場合にのみ進めます。文脈、口調、不完全な引き継ぎから許可を推測してはいけません。

作業を始める前に、対象、範囲、ロールバック方法を確認してください。読み取り専用の調査は確認なしで進められます。

最初の変更を加える前に、再開時も含めてこの確認を行います。対象ではリポジトリと、存在する場合は PR を指定します。範囲では次に許可されるゲートのステップを指定し、ロールバック方法では次の変更をどう取り消すか、または影響を封じ込めるかを明示します。引き継ぎにはこの確認を記録しますが、認可の範囲を広げることはありません。

• 指示では、どのゲートのステップが許可されているかを明示します（例：PR を作成する、CI が成功しレビュー要件を満たしたらマージする、マージ後に検証する）。
• 指定された範囲外のステップはゲートで停止し、不足している認可を正確に報告します。ユーザーに明示的な新たな判断を求めるのが正しい対応であり、許可なく進めてはいけません。
• 認可は作業とともに引き継がれます。中断時の引き継ぎ（下記）にそのまま記載することで、再開したセッションにも同じ範囲が引き継がれ、決して広がることはありません。

すべてのゲートで維持する境界：

• マージの境界 — マージが明示的に許可され、マージ対象の正確なヘッドで CI とレビューのゲートに合格した場合にのみマージします。
• レビューの境界 — 上限を設けたループの中でレビューのフィードバックに対応します。未解決のレビュー上の異議を押し切ってはいけません。
• セキュリティの境界 — CI またはレビューで見つかったセキュリティ上の問題は警告ではなくゲートです。回避、弱体化、抑制によって問題がなくなるまで再試行してはいけません。
• 正確なヘッドの境界 — すべてのゲートの証拠を正確なヘッド SHA に紐付けます。ヘッドが移動した場合、新しいヘッドで再検証するまで以前の証拠は無効です。
• 収束不能の境界 — いずれかのゲートで修正またはレビューのパスを3回行っても収束しない場合は停止し、証拠を報告します。
• マージ後検証の境界 — マージ後の状態を検証するまで、デリバリーは完了していません。

デリバリーゲート

ゲートを順番に進めます。各ゲートでは、まずライブ状態を確認し、次に作業を行い、現在のヘッド SHA に紐付いた証拠を記録します。

1. 変更の準備完了 — 実装が完了し、作業中のヘッドでローカル検証に合格しています。
2. PR の作成 — PR が存在し、その識別情報とヘッド SHA が記録されています。
3. CI 成功 — 正確な PR ヘッド SHA で CI に合格しています。
4. レビュー要件の充足 — 正確なヘッド SHA で、リポジトリのポリシーに定められたレビュー要件を満たしています。
5. マージ — 正確なヘッドでゲート 3 と 4 を満たし、かつマージが付与された認可の範囲内である場合にのみ実施します。
6. マージ後検証 — 完了を報告する前に、マージ後の状態（ブランチ、PR のステータス、マージ後のチェック）を確認します。

中断時の引き継ぎ

引き渡しの指示が引き続き承認済みで、ゲート付きのステップが残っている場合、セッション終了、ターン終了、ワーカーのシャットダウン、または厳しい制限への接近など、どのような終了であっても、まず永続的な引き継ぎを記録する必要があります。残りのステップがあるのに永続的な引き継ぎを記録せずに終了することは、残りのステップを明確に報告していても、プロトコル違反です。残りのステップの報告だけで、エンドツーエンドの指示が完了したことにはなりません。

引き継ぎは機械可読な JSON として永続的に保存します。デフォルトでは、リポジトリの作業ツリー内の .verified-delivery/handoff.json にファイルとして保存し、ローカルで Git の対象から除外したうえで、コミットのたびに未追跡ファイルであることを確認します。代わりに、外部への開示とそのロールバック方法を確認したうえで PR の説明に機械可読なブロックとして記載するか、設定されている場合はホストが提供する永続ストレージに保存します。記録には保存先を記載します。永続性とは、次回の再開時にユーザーの支援なしで見つけて読み取れることを意味します。

必須フィールド — schema（引き継ぎスキーマのバージョン）、status（open または closed）、store（永続的な保存先）、directive（ユーザーの指示をそのまま記録）、authorization_boundary（承認済みのゲートと、明示的に対象外とされた事項）、repository（リモートの識別情報）、pull_request（PR の識別情報、または null）、branch（引き渡し用ブランチ）、head_sha（引き継ぎ時点の HEAD）、completed_steps（完了したゲートと SHA に紐づく証拠）、pending_steps（次に実行する承認済みのゲート付きステップを順番に記録）、watchers（稼働中のウォッチャー、プロセス、またはワーカーの識別子。なければ空）、stop_reason（確認された中断の種類）、updated_at。フィールドの完全なスキーマ、永続性のルール、具体例については、 references/interruption-handoff.md を参照してください。

再開時の復帰

復帰とは、status: open の引き継ぎが存在する状態で、新しいセッション、ターン、またはワーカーがリポジトリに関与することです。復帰時に、文書化された保存先を確認してください。オープン状態の引き継ぎがある場合、復帰は記録済みの指示の再開として扱います。ユーザーに指示をもう一度伝えたり繰り返したりするよう求めてはならず、最初から再計画してはなりません。

最初のアクションは、読み取り専用でのライブ状態の確認です。確認が完了するまでは変更を加えてはなりません。

1. リポジトリ — リモートが引き継ぎの repository と一致していることを確認し、ブランチの状態を特定します。
2. PR — PR が存在してオープンであることを確認し、その HEAD SHA と引き継ぎの head_sha を比較します。
3. CI — 正確な HEAD に対するステータスを確認します。
4. レビュー — 正確な HEAD に対する状態を、リポジトリのポリシーと照合します。
5. ウォッチャー — 記録されたウォッチャー、プロセス、またはワーカーがまだ稼働中か確認します。稼働中のものを重複して起動してはなりません。

次に、すでに承認されているゲート付きステップから続行します。引き継ぎに記録されたゲートの証拠は、検証した HEAD に対してのみ有効です。HEAD が移動している場合（新しいコミット、リベース、フォースプッシュ）、まず状態を整合させます。フェッチし、新しい HEAD に対して CI とレビューを再確認し、引き継ぎの head_sha を更新してから続行してください。変更（コミット、プッシュ、マージ、コメント）は、確認が完了してからのみ行います。

境界で停止

次の場合は、それ以上の操作を行わず、正確な理由を報告して停止してください。

• 指示もオープン状態の引き継ぎもない場合（再開ではなく、新しいリクエストとして扱います）。
• 引き継ぎが破損している場合 — 解析できない、必須フィールドが欠けている、または内部に矛盾がある。
• 引き継ぎが古くなっている場合 — 記録された変更なしに PR がクローズされた、ロールバックされた、競合する HEAD とともにマージされた、リポジトリが一致しない、または記録された承認がもはや適用されない場合。ただし、承認済みのマージ後検証が保留中で、マージが記録と一致する場合は、状態を整合させて再開します。
• 次のステップへの承認がない、または曖昧な場合。
• ライブ状態が曖昧な場合 — ゲートの結果またはマージ状態を特定できない場合。

部分的または古くなった引き継ぎから、許可を推測してはなりません。停止の報告には、確認できたこと、検証できなかったこと、停止する正確な理由を記載します。

エンドツーエンド指示の終了

• デリバリー境界に到達した場合 — 引き継ぎをクローズし（status: closed）、その境界に関する SHA に紐づいた証拠を報告します。
• 手順が残っている場合 — まず引き継ぎを記録し、その後、引き継ぎストアと明示的な次のトリガーを示すメッセージでクローズします。次回の再エントリーで指示を再開します。手順が未完了のまま終了する場合、これが唯一許容される方法です。

ランタイムに関する誠実さ

スキルの内容によって、ハードなツール呼び出し制限やコンテキスト制限を超えてホストランタイムを継続させることはできません。また、このプロトコルはそれを保証しません。保証するのは、観測可能な動作です。つまり、制限に達する前に永続的な引き継ぎが書き込まれ、次回の再エントリーで検証済みのライブ状態から再開できる経路があることです。ランタイムが自動的に再開すると主張しないでください。次のトリガーは明示的な再エントリーです。

完了条件と終了条件

次のいずれかを満たしたら終了します。

• デリバリー境界に到達し、引き継ぎがクローズされ、証拠が報告されている。または
• 境界で作業が停止し、正確な理由が報告されていて、手順が残っている場合は、オープン状態の永続的な引き継ぎが存在する。

いずれかのゲートで収束しないパスが3回続いたら、ループせずに停止して報告します。

使用しない場合

エンドツーエンドのデリバリー指示を伴わない単純な修正、リファクタリング、レビューには、このスキルを使用しないでください。最も近い代替手段は通常の変更ワークフローです。リリースパイプライン、リリーストレイン、プログレッシブデリバリーの仕組みを設計するためには使用しないでください。その場合はrelease-engineeringを使用します。このスキルを権限の捏造に使用しないでください。このスキルが実行するのは、ユーザーが明示的に許可したことに限られます。

関連スキル

• release-engineering — 単一の許可された変更の範囲を超える、リリースパイプラインの仕組み、プログレッシブデリバリー、ロールバック計画。
• verification-methodology — 各ゲートでのライブ状態チェックに関する証拠と判定の基準。

参照ファイル

参照	読み込むタイミング
references/interruption-handoff.md	中断時の引き継ぎを記録、検索、検証、または調整するとき — フィールドスキーマ、永続化のルール、具体例