comet-build

Comet フェーズ 3：計画とビルド

フェーズに初めて入るとき、新しいエージェントに引き継ぐとき、またはコンテキストを復元するときは、タスクのコンテキストと成果物の言語を読み、従ってください。同じフェーズで作業を中断せずに続けている間は、現在の継続情報または要求済みのアクションの contextRequest を優先し、繰り返し取得しないでください。

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

SDK の実行パス

現在の SDK フェーズに初めて入るとき、新しいエージェントに引き継ぐとき、またはコンテキストを復元するときは、フェーズの開始と復旧と、そのリファレンス内の現在のフェーズのセクションを読んでください。このセッションですでに利用可能で、なお有効な場合は再利用してください。以下のフェーズの手順に進んでください。nextAction.kind に基づく復旧ルートは、継続モードのない古いレスポンスにのみ適用されます。

現在の有効な結果にある agent.continuation／data.nextAction と紐付け済みの状態を再利用してください。comet state next <change-name> --json を実行するのは、コールドレジューム時、外部の状態が変更された後、または必要な情報が不足している場合に限ります。data.runtimeFormat: sdk の場合は、この Run のみを進めてください。実装方法、計画の内容、レビューについては SDK 実行方法を参照し、このセクションを通じて状態と証跡を提出してください。data.phase は build である必要があります。すでにコンテキストにある有効なレイアウトと設定を再利用してください。それらが不足している場合に限り、comet state check <change-name> build --json を使用してください。nextAction.kind: reconcile の場合は、comet state check <change-name> build --recover --json を実行し、外部作業を繰り返す前に元の結果を確認してください。

有効な設定または現在の nextAction.stepId で、まず workflow を確認してください。tweak.build.*／workflow: tweak の場合は、直ちに実行してください： Skill ツールを使用して comet-tweak スキルを読み込みます。この手順を省略することは禁止されています。hotfix.build.*／workflow: hotfix の場合は、直ちに実行してください： Skill ツールを使用して comet-hotfix スキルを読み込みます。この手順を省略することは禁止されています。スキルの読み込み後、同じ変更、ワークスペース、フェーズ、Run リビジョン、継続情報を渡し、SDK のビルドステップを再開してください。完全な設計ドキュメントや実装計画は不要です。また、Open を繰り返さないでください。古い Run では comet-build が未加工の Action 参照として保存されている場合があります。その場合も同様に振り分けてください。アップグレードが承認された後、現在のステップが full.build.* の場合は、SDK 実行方法に記載された完全なパスを使用してください。

1. full.build.configure では、SDK execution methods にある既存の選択肢を確認し、実行、TDD、レビューについて未決定の項目だけを質問します。確定した build_mode、tdd_mode、review_mode、subagent_dispatch と、必要な場合は direct_override を、リポジトリ内の一時的な JSON ファイルに保存します。ユーザーがこの完全な構成をすでに明示的に選択している場合は、comet state propose-build <change-name> --file <configuration-json> --confirmed を実行し、提案と承認をまとめて保存します。それ以外の場合は、comet state propose-build <change-name> --file <configuration-json> を実行します。保留中の Wait が残っている場合に限り、data.wait.proposalHash を保存して実際の構成を提示し、decision-point.md に従って確認を待ちます。その後、comet state decide-build <change-name> --proposal-hash <proposalHash> --choice <approved|rejected> を実行します。却下された場合は、修正した選択肢を提案します。復旧時には、既存の保留中の Wait を再利用します。
2. full.build.plan では、SDK execution methods に従って計画を作成または確認します。現在の Design Doc と tasks.md を参照し、タスクを と に対応付けます。別のチェックボックスリストは作成しません。comet state submit-plan <change-name> --plan <plan-ref> を実行します。ユーザーが計画後の一時停止を明示的に求めた場合に限り、--pause を追加します。plan-ready Wait の場合は、続行するよう明示的な指示があるまで待ち、現在のハッシュを使って comet state continue-plan <change-name> --proposal-hash <proposalHash> を実行します。計画やタスクの要件が変更された場合、以前の承認は再利用しません。
3. full.build.execute では、選択した方法で実装し、タスクまたはセグメントをレビューして、関連するチェックを実行します。実際に完了し、レビューにも合格したタスクのみ、同じ tasks.md でチェック済みにします。タスク ID、完了状況、進捗の調整には、共有の state tasks、state task-complete、state checkpoint ツールを使います。これらのツールでは SDK Run は進みません。SDK はレガシーの comet handoff --write を呼び出してはいけません。計画、タスク、ワークスペースが一致したら、comet state complete-build <change-name> --session <builder-execution-ref> を実行して check Action に進みます。送信前に不整合を解消してください。
4. full.build.check では、このワークスペース用の明示的かつ完全なビルドまたは受け入れコマンドを指定して、comet guard <change-name> build --apply -- <program> [args...] を実行します。ここで新たなユーザー判断はありません。--apply は、チェックを実行して同じ Run にレシートを記録する前に、現在のタスク、構成、ワークスペース、証拠を再検証します。有効な成功証拠がある場合に限り、Verify に進みます。診断が必要な場合のみ、読み取り専用の comet guard <change-name> build プレビューを使います。レシートの送信が中断された後は、何かを再実行する前に Action とチェック記録を調査します。失敗した場合は、返された現在の Build Action に従って原因を修正します。継続情報が返されなかった場合に限り、state next --json を読み取ります。

各段階の進行後は、その結果の agent.continuation／data.nextAction を使います。状態が有効かつ完了している間は、next、select、check を繰り返しません。読み直すのは、状態のない状態から再開するとき、外部状態の変更後、または情報が不足しているときだけです。次のフェーズで action が示された場合に限り、次の Skill を読み込みます。decision、evidence、reconcile は現在の Run 内で解決します。 決定的なローカルチェックでは、SDK execution methods の説明に従い、-- の前に --local を追加します。Runtime は、再利用前にすべての入力とログを検証します。外部チェックは引き続き実行されます。SDK Build には、安定した --session <builder-execution-ref> を関連付けます。--session が指定されている場合、full complete-build にはすでにその値が含まれています。

Compat path

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