comet-design

Comet Phase 2：設計

フェーズに初めて入るとき、新しいエージェントに引き継ぐとき、またはコンテキストを復元するときは、Task Context and Artifact Languageを読んで、その指示に従ってください。同じフェーズ内で作業を中断せずに続ける場合は、現在の継続処理または割り当て済みの Action のcontextRequestを優先し、繰り返し取得しないでください。

entry の戻り値としてレイアウトが返されたら、comet-classic/reference/classic-layout.mdを使用して各論理ルートを解決してください。このプロトコルがすでにコンテキストにある場合は再利用してください。OpenSpec CLI の呼び出しはすべてアダプター経由で行い、ファイルパスにはバインドされた<classic-*>ルートを使用してください。最初に追加でルート表示を実行しないでください。

SDK 実行パス

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

同じ変更、ワークスペース、Run に対する最新の有効な応答（agent.continuation、data.nextAction、フェーズ、リビジョン、パスの概要）を再利用します。comet state next <change-name> --json を実行するのは、コールドリカバリー、ワークスペースまたは外部状態の変更、古い応答バージョン、または現在のステップに必要な情報の欠落がある場合のみです。次の Skill を読み込むことは、再度クエリする理由にはなりません。ランタイムは書き込み時に現在のバージョンと証拠を引き続き検証します。キャッシュされたコンテキストによってチェックや承認を回避することはできません。data.runtimeFormat: sdk の場合、状態変更にはこのセクションを使用します。調査、質問、正式なドキュメント要件には、SDK 実行メソッドの Design セクションを使用します。data.phase は design でなければなりません。Build が始まっている場合は、その開始地点に戻ります。nextAction.kind: reconcile の場合は、comet state check <change-name> design --recover --json を実行し、提案や再ディスパッチの前に、申告された Action の当初の結果を確認します。

1. full.design.handoff では、現在の応答にあるレイアウトと参照を再利用します。それらが欠けている場合のみ、comet state check <change-name> design --json を実行します。現在の OpenSpec 提案、タスク、差分仕様、関連する既存の design.md を読みます。SDK 実行メソッドの Design セクションに従って候補となる解決策を検討し、brainstorm-summary.md を最新の状態に保ち、未承認の内容には候補であることを明記します。SDK にはまだ引き継ぎパケットがありません。レガシーの comet handoff ... --write を呼び出したり、手書きの要約で代用したりしないでください。
2. Spec Patch が必要な場合は、SDK 実行メソッドの Design 確認ルールに従って説明し、差分仕様を編集する前に明示的な合意を得ます。重要なスコープ変更があれば、改めて確認します。ソースが安定したら、comet state propose-design <change-name> --proposal "<candidate-summary>" を実行します。要約には、提案する設計、トレードオフ、リスク、Spec Patch を含める必要があります。data.wait.proposalHash を <proposalHash> として保存します。これにより、追跡可能な引き継ぎが作成されます。提案の応答に含まれる data.configuration.handoffContext を使用し、欠けている場合のみ comet state next <change-name> --json を照会します。また、Markdown パケットが候補案とソースファイルに一致することを確認します。復旧時には、既存の保留中の Wait を再利用します。
3. SDK 実行メソッドの Design 確認ルールに従って設計を提示し、ユーザーに承認、変更の依頼、または保留を求めます。明示的な承認または却下があった場合のみ、comet state decide-design <change-name> --proposal-hash <proposalHash> --choice <approved|rejected> を送信します。却下された場合は修正して再度提案します。保留の場合は Wait に手を加えません。ソースまたは引き継ぎの変更により承認が無効になった場合は、古い決定を適用せず、原因を調査します。
4. 承認後、必須のフロントマターを含む単一の Design Doc を作成します。復旧時に full.design.document が示されている場合は、ここから続行します。comet state complete-design <change-name> --design-doc <design-doc-ref> --approval-hash <proposalHash> を直接実行します。失敗した場合は Run を維持し、具体的な原因に対処します。ランタイムが実際の状態ファイルを同期します。エージェントがフェーズを手動で進めることはありません。同じ成功応答から Build Action と継続情報に進みます。継続情報が欠けている場合のみ、comet state next <change-name> --json を実行します。

互換パス

残りの元の Runtime 手順は、runtimeFormat: compat の場合にのみ適用されます。互換操作を読み、現在のフェーズを続行します。SDK ではこのリファレンスを読み込みません。