repair-gaps

委譲された修復の続行

上位の自律的なデリバリー工程では、適用範囲内で該当する復旧の推奨事項を適用し、再確認を求めずに両方の独立した検証担当者へ続行してください。 読み取り専用の診断指示では、仕組みを調査し、コントローラーが要求した診断スキーマを返してください。編集は行わず、REPAIRED と報告しないでください。 同じ不足が繰り返される場合は、証拠の収集やローカルの前提条件への対応も含め、具体的な別の方法を選んでください。 復旧で対処できない場合に限り、利用できない入力を正確に明示してください。 証拠のみの復旧では、プロダクトのバイト列を変更してはなりません。 計画上の判断は委譲元のプランナー／監査担当者に差し戻してください。修復によって合意内容を弱めてはなりません。

/repair-gaps は、/prove の後に実施する修復ステップです。ソース契約、証明結果、対応する候補、具体的な未解決要件 ID を受け取ります。 該当する不足のみを修復し、新たな証明の代わりにはなりません。 レビューのみの指摘は、許可された /implement-contract の実行対象です。このスキルで必要な、対応する NOT PROVEN の証明結果に代わるものではありません。

修復の前に、受け入れ契約プロトコルを読んでください。 指定された要件について、範囲は限定し、内容は完全な、最小限の修復を行ってください。

ガードレール

• 証明に記載された契約の正確なリビジョンと取得済みテキストが現在の契約と一致し、候補の正確な ID も一致していることを確認してください。
• 指定された要件に必要な実装または証拠のみを編集してください。
• ソース要件と、既存の有効なチェックを維持してください。
• 指定された結果に必要なすべての状態、不変条件、永続化、失敗時の動作を実装してください。これらの ID は、無関係な改善や推測に基づく仕組みの追加を許可するものではありません。合意済みの接点と独立した検証手段を再利用してください。
• 修復に合わせて契約を弱めてはなりません。変更した約束や、重大な影響を伴う新たな接点が必要な場合は、判断が必要として作業をブロックし、明示的な解決のために差し戻してください。許可された重要な変更には、新しいリビジョンと証明が必要です。
• 公開、コミット、プッシュを行わず、PROVEN と宣言しないでください。
• 入力が古い、不明瞭、または利用できない場合は、編集せずに BLOCKED と報告してください。

ワークフロー

1. .p2p/work/<slug>/contract.md を受け取り、.p2p/work/<slug>/ 内の関連入力、candidate.json、proof.md を特定します。同じ作業項目を参照する明示的な証明への参照も受け付けます。ローカルの契約の正確なリビジョンと、対応する NOT PROVEN の証明結果を読み取ります。親／仕様のハッシュと比較ベースの紐付けを再確認します。ローカルの .p2p/ レコードを更新しても候補 ID は維持し、Git の履歴に含めてはなりません。
2. 候補 ID と未解決の要件 ID を確認します。
3. 編集が許可されている場合は、指定された要件について、実装または証拠の最小限かつ完全な修復を行います。すでに与えられている許可は維持してください。
4. 対象を絞ったチェックを実行し、変更差分を調査します。
5. 契約を再確認し、修復前後の候補、変更ファイル、対応した要件、変更した証拠、残っている不足を報告します。不足が残る場合は、次に実施する具体的なアクションを一つ、最小限の形で推奨します。影響する ID と、必要となる正確なコマンド、不足している入力、または人による判断を明示します。不足がない場合に限り、None を使用できます。候補は対象を絞った修復の範囲内でのみ変更でき、受け入れ要件は維持してください。
6. .p2p/work/<slug>/repair.md、保持する証拠、更新後の簡潔な candidate.json の ID を保存し、読み返します。実行中の作業を再開するために必要なペイロードは、永続的な候補レコードではなく、無視対象のローカルストレージに保持してください。置き換える前に、プロトコルの履歴ルールに従って以前のレポートと候補レコードを保持します。候補から .p2p/ を除外してください。プロダクトや紐付け対象の入力が変更された場合、以前のレビュー／証明は過去のものとなり、修復後の候補を承認しません。 変更した候補を、個別の /review-implementation と新たな証明のために引き渡します。 最後に次の文を記載してください。受け入れ前に新たな /prove が必要です。

結果

• REPAIRED：対象範囲の変更を行い、焦点を絞ったチェックに合格しました。
• NO CHANGE：安全または必要な変更は行われていません。理由を説明してください。
• BLOCKED：入力または必要な機能を利用できないか、古くなっています。

これらの結果はいずれもチケットを受け入れるものではありません。新しい /prove の実行で、変更後の候補をすべての要件に照らして評価する必要があります。

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

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

外側のコントローラーから構造化 JSON を求められた場合は、これらを learning_candidates 配列に含めてください。それ以外の場合は、レポートに短い ## 学習候補 セクションを追加してください。

学習候補は /retrospect に引き継ぐための手掛かりであり、承認済みの助言ではありません。契約、要件 ID、ステージの判定、範囲、修正の許可範囲、権限を変更してはなりません。このスキルからプロジェクトのルールや助言的な学習レジスターに昇格させないでください。

引き継ぎ形式

# <REPAIRED | NO CHANGE | BLOCKED>: <source>

Contract: <source and exact revision>
Contract snapshot: <same immutable reference or captured text and digest as proof>
Candidate before: <identity>
Candidate after: <identity or unchanged>
Addressed requirements: <IDs or None>
Changed files: <files or None>
Changed evidence: <assertions/artifacts and affected IDs, or None>
Focused checks: <observations and assertions>
Remaining gaps: <IDs and reasons, or None>
Recommended next action: <one concrete action for the remaining IDs, or None>

Fresh `/prove` required before acceptance.

引き継ぎの後は Next steps: で終え、適用可能なアクションを順番に番号付きリスト（1., 2., ...）で示し、各アクションを番号で参照できるようにしてください。REPAIRED の場合は、次に実行する正確な呼び出しを示してください。

/review-implementation <changed candidate> against <comparison base>
/prove <saved contract>; candidate <changed candidate>

NO CHANGE または BLOCKED の場合は、要件 ID と、具体的に不足している入力または判断を示してください。コマンドで解決できる場合は、設定済みのコマンドと期待される結果を記載してください。ブロッカーが解決するまで、新しい proof を要求しないでください。