comet-archive

Comet Phase 5：アーカイブ

フェーズへの初回参加時、新しい Agent への引き継ぎ時、またはコンテキストの復元時には、Task Context and Artifact Languageを読み、その指示に従ってください。同じフェーズで作業を中断せずに続ける場合は、現在の continuation または claim 済みの Action の contextRequest を優先し、繰り返し取得しないでください。

参加後にレイアウトが返されたら、comet-classic/reference/classic-layout.mdに従って、各論理ルートをディレクトリに対応付けてください。すでにプロトコルがコンテキストに含まれている場合は、再読み込みしないでください。OpenSpec CLI の呼び出しにはアダプターを使用し、パスには対応付け済みの <classic-*> ルートを使用してください。先に追加のルート表示コマンドを実行しないでください。

SDK 実行パス

現在の SDK フェーズへの初回参加時、新しい Agent への引き継ぎ時、またはコンテキストの復元時には、フェーズへの参加と復旧と、そのリファレンス内の現在のフェーズのセクションを読んでください。このセッションで引き続き有効な場合は、それらを再利用してください。以下のフェーズに進んでください。nextAction.kind に基づく復旧ルートは、continuation mode がない古い応答にのみ適用されます。

同じ change、workspace、Run に対する最新の有効な応答を再利用してください：agent.continuation、data.nextAction、phase、revision、path summaries。comet state next <change-name> --json を実行するのは、コールド復旧時、workspace または外部状態の変更時、応答バージョンが古い場合、または現在のステップに必要な情報が不足している場合に限ります。次の Skill を読み込むことは、再度問い合わせる理由にはなりません。書き込み時にはランタイムが最新バージョンとエビデンスを引き続き検証します。キャッシュ済みコンテキストによってチェックや承認を回避することはできません。data.runtimeFormat: sdk、phase、nextAction.kind を確認し、対応付け済みの projectRoot で作業してください。パスが不足している場合、または対応付けが変更された場合に限り、comet classic workspace resolve <change-name> --json を実行してください。検証レシートは引き続き有効でなければなりません。状態ファイルやレポートファイルは、成果物の引き渡しを許可するものではありません。reconcile では、comet state check <change-name> archive --recover --json を使って、元の Action とディスク／Git のエビデンスを調べてください。結果が不明な場合は、archive、commit、push、PR を繰り返さないでください。

1. 現在有効な状態、ワークスペース、エビデンスの要約を再利用し、不足している場合に限り comet state check <change-name> archive --json を実行します。SDK 実行方法の「検証」「紐付けられたブランチ」「アーカイブの影響」「無関係な編集」を確認します。プッシュまたは PR の場合は、リモートと PR のベースを確認し、候補から推測で選ばないでください。必要に応じて --remote <name> と --pr-base <branch> を追加し、comet state propose-archive <change-name> --summary "<delivery-summary>" を実行します。data.wait.proposalHash を <proposalHash> として保存します。既存の保留中の Wait を再利用します。
2. decision-point.md と SDK 実行方法の「アーカイブと Git 配信」セクションに、現在の提案と配信オプションを提示します。現在のアーカイブの影響と同じ配信先を明示的に許可する承認がなければ、ユーザーの選択を待ちます。comet state decide-archive <change-name> --proposal-hash <proposalHash> --choice <local|push|pr|reverify|later> を実行します。local はアーカイブしてコミットし、push はさらにプッシュし、pr はプッシュして PR を作成し、reverify は Verify に戻り、later は作業を保持してこの呼び出しを停止します。配信先または Verify のエビデンスが変わった場合は再確認し、新しい承認を得てください。古い提案ハッシュを再利用しないでください。
3. 有効な local|push|pr の決定がある場合に限り、comet guard <change-name> archive --apply を直接適用します。Guard は承認、ブランチ、Verify のレシートを確認し、Run 内で OpenSpec を一度だけアーカイブします。中断後は state next --json と --recover を確認し、完了済みのアーカイブを再適用しないでください。
4. SDK 実行方法の「アーカイブと Git 配信」セクションで、ダーティなワークツリーの所有者を確認し、この変更の実装、アーカイブディレクトリ、メイン仕様、Design Doc/Plan の注釈を明示的にステージします。ステージした差分を確認してから、アーカイブのコミットを1つ作成します。SDK Guard は Git 操作を実行しません。従来の state set branch_status、state delivery、archive-confirm は使用しないでください。push の場合は、承認済みのリモート／ブランチにのみプッシュします。PR の場合は、先にプッシュしてから、承認済みのターゲットで PR を作成します。結果が不明な場合は、再試行する前にリモートまたは PR を確認します。
5. 実際のコミットを指定して comet state complete-delivery <change-name> --commit <sha> を実行します。PR の場合は --pr-url <url> を追加します。これはアーカイブのコミットと、承認済みのリモート／PR 配信を検証して Run を完了します。コミット、プッシュ、PR 作成は行いません。失敗した場合は Run と決定を保持し、報告された不足に対処します。応答に完了済みの Run と done の continuation が示された場合に限り、配信完了を宣言します。終端状態が不足している場合に限り、comet state next <change-name> --json を実行します。

互換パス

残りの元の Runtime 手順は、runtimeFormat: compat の場合に限り適用されます。Compat operations を読み、現在のフェーズを続行してください。SDK はそのリファレンスを読み込みません。