plan-acceptance

委任された継続

選択された恒久的な委任事項を通じて、上位のワークフローから計画の策定を委任された場合は、適用範囲内の質問を解決し、元の内容を保持する提案を、再確認せずに適用します。約束、除外事項、制約、リンク、IDを保持します。採用には、内容が変更された場合の新しいリビジョン、以前のバイト列の保持、独立した監査、委任事項の帰属の記録が必要です。コントローラーの計画セッションでは、指定されたスキーマで提案文を返します。保存と採用の責任はコントローラーにあります。委任事項の範囲外の製品変更については、不足している決定権者を明記します。

元の約束を、候補に依存しない受け入れ基準に変換します。このスキルでは、受け入れ基準を計画します。実装や検証は行いません。直接イシューから呼び出された場合も、プロトコルのスタンドアロン計画ルールに従って、計画の引き継ぎを公開します。

計画を始める前に、受け入れ基準プロトコルを読んでください。 仕様のエンベロープ、リビジョンのルール、エビデンスの用語、引き継ぎについて説明しています。

受け入れ基準を作成する

1. サポート対象のトラッカー課題、合意済みの直接提供テキスト、またはリポジトリ内の任意のパス（specs/ や work/ を含む）にあるプロジェクト作成のソースファイルを受け付けます。作業項目のスラッグを導出し、生成した契約を .p2p/work/<slug>/contract.md に保存します。書き込む前に競合を確認します。 課題が入力の場合は、設定済みのトラッカー手順と、課題の本文、コメント、既存の計画引き継ぎ、承認、修正内容を先に読みます。 単独のローカル作業項目に仕様やトラッカーは必要ありません。 最小限の受け入れ条件の箇条書きを、生成した契約のマトリクスに正規化します。既存の ID と約束は保持します。依頼があれば、外部ソースの約束をローカルに取り込みます。トラッカーは任意のソースまたはミラーのままです。取り込んだ拘束力のあるテキストは、外部 URL と取得時の識別情報を帰属情報として添え、作業項目内またはリンクされたローカルソースファイルに保持します。外部 URL だけでは、ハッシュ化可能な入力として有効ではありません。 ソース、既存の契約、保留中の修正内容、該当する親契約を読みます。ソースを確定できない場合は、その不足を報告して停止します。 分割された子作業項目の場合は、プロトコルの親子ルールに従い、その分解内容、正確な貢献範囲、前提条件、親の正確なスナップショットを取得します。計画前に現在の親と保留中の修正内容を比較し、重大な不一致があれば、変更された親を黙って採用せずに解決します。 プロジェクトの助言用学習レジスターがある場合は（デフォルトでは docs/retrospective-learnings.md）、それを読みます。関連する active 状態の承認済み学習内容を検討し、使用したものは ID と評価への参照とともに記録し、その他が適用されない理由も記録します。置き換えられた助言やレジスターの不在は、計画の妨げにはなりません。学習内容はあくまで助言であり、現在のソースとその承認プロセスによる裏付けなしに、要件、除外事項、標準、改訂を追加する権限にはなりません。
2. GitHub のチェックボックスを含む既存の受け入れ基準を契約と照合します。重要な約束と必要な不変条件をすべて抽出します。各基準が要件に重複なく対応するよう、ソースへの参照を保持します。 子作業項目の行は、Source を介して該当する親の義務に対応付けます。適用される継承済みの境界と除外事項を保持しつつ、子作業項目に求めるのはその成果と貢献に限り、無関係な兄弟作業項目の機能は求めません。
3. 個別に反証可能な約束ごとに 1 行を割り当てます。複合的な基準は分割し、重複する主張は統合し、既存の行を再編する場合は ID の対応関係を記録します。再実行時も既存の ID を保持し、新しい行には未使用の ID を割り当てます。
4. ソースまたは必要な成果に裏付けられた境界（該当する場合は、空の入力、再試行、再起動、認可、並行処理、部分的な失敗など）を記録します。推測に基づく動作は契約の対象外とします。
5. 合意済みの仕様と TDD の接点、公開インターフェース、既存のテスト、制約、設定済みコマンドを調査します。それらの接点を再利用し、各行について独立したオラクルと具体的な証拠パスを明記します。信頼できるパスが見つからない場合は gap と記し、不足内容を説明します。
6. プロトコルの改訂ルールを適用します。承認された重要な変更を記録し、以前の改訂を保持します。未解決の変更は、合意を黙って変更せず、質問として提示します。
7. 提案を提示する前に、ソースと関連するプロジェクトのコンテキストを監査し、該当する曖昧さ、矛盾、成功時または失敗時の動作の不足、重要な暗黙の境界や不変条件、リグレッション制約、スコープの不明確さ、検証不可能な約束、利用できない証拠または権限、環境、データ、タイミング、順序、権限、互換性、外部システムに関する前提を確認します。重大な指摘ごとに、承認された結果または境界、明示的な証拠不足、あるいは未解決の質問を記録します。関連するカテゴリのみを適用し、要件を捏造したり、すべてのカテゴリを各契約に無理に盛り込んだりしないでください。監査は簡潔にし、リスクに見合ったものにします。
8. 各承認済みの行は、観測可能な期待結果、合意済みで信頼できる接点、独立したオラクル、具体的な証拠パスを条件とします。利用できない場合は、不足している接点、オラクル、または証拠を明記します。証拠不足と未解決の製品上の決定は区別します。不確実性が正しさやスコープを変える可能性がある場合に限り、依頼者に質問して実装をブロックします。推測してはいけません。そのような質問が未解決のまま、準備完了として引き継いではいけません。
9. 承認済み契約の計画を再実行する場合は、承認済みの正確なバイト列、改訂、要件 ID、承認の紐付けを確認して保持します。変更のない再実行や証拠のみの再実行では、これらの識別情報を変更しません。重大な変更によって正規の契約を置き換えられるのは、明示的に承認された通常の改訂プロセスを経た場合に限ります。承認内容、従来の合意と提案する合意、ID の対応関係があればそれも記録し、以前の正確なバイト列を保持します。その承認がない場合は、承認済みの契約を変更せず、変更案を未解決の質問として提示します。

納品の形を評価して記録する

約束する成果と受け入れ項目が明確になったら、作業項目全体を、境界の明確な1つの納品として妥当に実装し、独立してレビューし、検証できるかを確認します。次の推奨ルートを1つ選びます。

• Direct delivery：成果のまとまりが明確で、1回の納品サイクルで対応可能な場合。
• Sizing inspection：成果の範囲が明らかに広い場合、または境界の不確実性が、確実な実装、独立したレビュー、あるいは検証に重大な影響を及ぼす場合。
• Deferred：未解決のプロダクト成果によって合意を確立できない間に限ります。その成果は受け入れ計画を通じて明確にし、分割によって判断しないでください。

複数の受け入れ項目、通常の実装上の不確実性、不慣れな領域、難しいアルゴリズム、過去の測定値の不足、またはファイル、行、単語、テスト、時間、トークン、ストーリーポイント、コンポーネント、子項目の件数を理由に、見積もり確認を開始しないでください。これらは観察事項として記録してもかまいませんが、しきい値として扱ってはいけません。

既存のローカル P2P ストレージおよび履歴のルールに従い、.p2p/work/<slug>/delivery-shape.md を保存し、書き戻された内容を読み取って確認します。正規の契約パス、リビジョン、SHA-256 の正確な値に加え、該当するすべてのソース、仕様、親項目、承認済み計画の識別情報を関連付けます。ルート、簡潔で根拠に基づく理由、取得可能なパスとリビジョンを含む調査済みコンテキスト、前提条件、該当する分割結果（none、正確な NO SPLIT、または承認済み計画の識別情報）、最も早い次のアクションを1つ、未完了のゲートを記録します。理由は簡潔に保ち、非公開の推論は記録しないでください。読み戻し後にハッシュを再計算します。契約または関連付けられた入力が変わった場合、推奨内容は古くなるため、新たに評価する必要があります。過去の記録は保持してください。

直ちに実行する次のアクションは、次のいずれか1つに限ります。未解決の成果を明確にする、必要な承認を得る、重大な証拠不足または前提条件を解消する、ストレージを修復する、直接納品の場合は /deliver-issue <contract> を実行する、または見積もり確認の場合は /slice-contract <contract> を実行することです。ゲートが保留中の場合は、推奨する後続ルートを別途記録しますが、そのゲートを唯一の次のアクションとします。直接納品はあくまで助言であり、合意や準備状態／受け入れ状態を変更せず、外部への影響を許可するものでもありません。

監査して引き継ぐ

すべてのソース上の約束を考慮し、追加する不変条件はそれを必要とする結果に照らして正当化してください。必要な状態、永続化、失敗時の動作を含め、ワークフローを完了まで追跡してください。不足している内容と、要求されていない範囲の両方を確認してください。実装上の好みを要件に含めないでください。

以下の形式で契約を返してください。計画状態には planned または gap のみを使用してください。従来の証拠判定があれば、元の候補とコンテキストを添えて、個別に識別できる証拠レポートへ移すか、出所の欠落をギャップとして示してください。

引き継ぐ前に、契約を .p2p/work/<slug>/contract.md に保存し、読み直してください。永続的な任意仕様は specs/ に保存し、Source でリンクしてください。親作業項目は Parent でリンクし、正確なスナップショットと貢献の対応付けを保持してください。プロトコルの履歴ルールに従って、以前の改訂版を保持してください。このコンテキストで書き込みができない場合は、保存と読み直しのために、囲んでいるワークフローへ正確なテキストを返し、取得が確認されるまで保存待ちと報告してください。ローカルファイルを保存しても、ステージング、コミット、トラッカーへの公開は許可されません。

提案、承認の受領記録、または承認済みの改訂版を保存した後、引き継ぐ前に、ポータブルなチェックポイントを更新してください：python3 <skill-dir>/scripts/p2p_filesystem.py --repo <root> checkpoint .p2p/work/<slug>/contract.md。デフォルトの p2p-state/<slug>.json は Git に適しており、プロトコルのポータブルチェックポイント規則に基づき、明示的に選択した issue を代替として使用できます。承認に紐づく正確な履歴と入力を保持してください。そのパス、バイト数、LOCAL_ONLY／COMMITTED／PORTABLE の保持状態を、承認とは別に報告してください。共有側からの読み戻しを確認せずに、ローカルファイルを破棄可能と呼んではいけません。

issue 上でユーザーから直接実行された場合は、プロトコルの単独計画ルールに従って、共有の計画引き継ぎを公開し、確認してください。ローカルのみ、またはドラフトのみを求められた場合、この書き込みは行いません。納品ワークフロー内での実行は、囲んでいるワークフローの権限に従い、ローカルにとどめます。コメント URL と、承認が必要な提案の正確な内容を返してください。公開しても承認されたことにはなりません。公開または読み戻しに失敗した場合は、ローカルの提案を保持し、issue の引き継ぎが未完了であると報告してください。

追跡対象の子項目の場合、準備状況の照合は、この処理を呼び出したワークフローに引き継いでください。契約を保存して読み直した後、そのワークフローは、設定されたトリアージの意味、必要な承認、未解決の判断事項、前提となる成果の利用可能性を確認します。ラベル編集権限がある場合、子項目が無人での実装に対応できる状態のときに限り ready-for-agent を適用し、無関係なラベルは保持します。それ以外の場合は、残っている阻害要因、または保留中のラベル更新を報告してください。前提条件が利用可能になったら再確認してください。契約を作成しただけでは、準備完了にはなりません。

出力

# Acceptance contract: <source>

Contract revision: v1
Source: <relative Markdown link to binding local spec/source text; omit for a standalone work item>
Source attribution: <external issue/spec URL and retrieval identity, if imported>
Parent: <relative Markdown link to parent work item and revision, or None>
Parent snapshot: <immutable reference or retrievable captured text and digest; omit if none>
Contribution: <decomposition reference, qualified parent obligations and precise contribution; omit if none>
Prerequisites: <references and required outcomes, or None>

Intended outcome: <observable user or operator outcome>

Advisory learnings: <active IDs considered and why used or inapplicable; None if no register>

## Acceptance matrix

| ID | Source | Requirement | Boundaries / counterexamples | Seam | Oracle | Planned evidence | Plan state |
|---|---|---|---|---|---|---|---|
| R1 | <criterion> | <one observable promise> | <what would falsify it> | <agreed public interface> | <independent expected result> | <named case and assertion, invariant check, or exact command> | planned |

## Unresolved gaps

- <missing evidence path, seam, or oracle, or None>

## Open questions

- <unresolved product or design decision, or None>

## Out of scope

- <excluded nearby concern, or None>

## Change notes

- <revision, affected IDs, old/new agreement and authorization; ID mappings, or Initial contract>

## Implementation handoff

For `Direct delivery`, hand off through `/deliver-issue`; its existing #60
admission must pass before it invokes implementation. For `Sizing inspection`,
hand off to `/slice-contract` before implementation. Implement the smallest
complete solution inside the spec envelope, preserve requirement IDs and
promised outcomes, and capture the candidate for separate
/review-implementation and /prove phases.

## Proof handoff

Evaluate every requirement against this contract revision and one fixed candidate.
Record actual evidence and verdicts in a separate proof report.

契約の後に Next steps: を付け、該当するアクションを順番に番号付きリスト（1., 2. ...）で記載してください。各アクションを番号で参照できるようにします。直ちに実行する唯一のアクションは、保存済みの納品形式レコードに従います。Direct delivery の場合は /deliver-issue <contract>、Sizing inspection の場合は /slice-contract <contract> です。承認、未完了の成果、証拠のギャップ、保存の失敗、または前提条件が保留中の場合は、そのゲートを唯一の次のアクションとして示し、ルートは条件付きのままにしてください。任意の監査は /audit-acceptance <proposed contract> against <source> です。直接ルーティングまたは #60 の受付を迂回して、/implement-contract に直接渡してはいけません。次のスキルを呼び出してはいけません。