comet-hotfix

Comet Preset：Hotfix

開始または再開する前に、comet-classic/reference/classic-layout.mdを読み、従ってください。OpenSpec CLI の呼び出しにはすべてアダプターを使用し、すべてのパスには割り当てられた<classic-*>論理ルートを使用してください。

短時間で不具合を修正するフローです：開始 → ビルド → 根本原因の確認 → 検証 → アーカイブ。ブレインストーミングと完全な実装計画を省略し、新機能を設計せずに既存の動作を修正する場合に適用します。

以下の適用条件をすべて満たす必要があります：

1. 機能を追加せず、既存機能の不具合を修正する。
2. インターフェースの変更やアーキテクチャの再設計を行わない。
3. スコープを見積もることができる。ファイル数はレビューを促すための目安にすぎず、自動的にエスカレーションするルールではありません。「エスカレーションの判断」を参照してください。

プリセットが適さなくなる可能性がある場合： 修正中に「エスカレーションの判断」に記載された変更が必要になった場合は、完全な/comet-classicフローを使用するかどうかをユーザーに判断してもらってください。

フェーズに初めて入るとき、新しい Agent に引き継ぐとき、またはコンテキストを復元するときは、タスクコンテキストとアーティファクトの言語を読み、従ってください。同じフェーズで作業を中断せずに続けている場合は、現在の継続情報または割り当て済み Action のcontextRequestを優先し、繰り返し取得しないでください。

個人用メモリには再利用可能なユーザー情報のみを保存し、タスクの要約、進捗、コマンド出力、テスト結果は保存しないでください。

SDK 実行パス

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

開始時または再開時には、現在有効な結果のagent.continuation／data.nextActionと、割り当てられた変更、ワークスペース、フェーズ、Run のリビジョンを再利用してください。既知のdata.runtimeFormatに基づいてルートを選択してください。comet state next <change-name> --jsonを実行するのは、コールド再開時、外部で状態が変更された後、またはこれらの情報が不足している場合に限ります。sdkの場合、状態の変更にはこのセクションを使用してください。SDK 実行メソッドに定められた適用条件、再現、根本原因の修正、エスカレーション、ファイル数の承認に関するルールが適用されます。状態と証拠はこのセクションを通じて提出してください。nextAction.kind: reconcileの場合は、元の Action を調査するためにcomet state check <change-name> <phase> --recover --jsonを実行してください。結果が不明な間は、実装、チェック、アーカイブを繰り返さないでください。

1. 新しい変更では、ワークスペースの選択に従って分離方法を選択します。comet classic workspace prepare <name> --isolation <selected-isolation> --json を実行し、projectRoot に移動して、エントリーと成果物に従って最初に OpenSpec のベースディレクトリを作成します。次に、comet state init <name> hotfix --isolation <selected-isolation> を実行し、その後 comet state select <name> を実行して Hook のルーティングをバインドします。SDK の実行メソッドに従って、簡潔な OpenSpec 成果物を作成します。comet guard <change-name> open --json でプレビューします。data.approvalHash を保存し、Open の成果物とスコープをユーザーに提示して、comet guard <change-name> open --apply --approval-hash <approvalHash> を実行する前に明示的な承認を得ます。成果物が変更された場合は、再度プレビューして承認を得てください。古いハッシュを再利用してはいけません。Run が Build に入ったときにのみ Open が完了します。状態ファイルは変更ディレクトリ内の comet-state.yaml です。過去の変更では元のファイル名が維持されます。
2. hotfix.build.execute では、同じ変更、ワークスペース、Run を維持し、再初期化や Open の繰り返しを行わず、Build を直接再開します。欠陥を再現し、失敗の証拠を保持し、タスクを完了して、SDK の実行メソッドに従って根本原因を確認します。重大なエスカレーションの兆候がある場合、または有効な承認なしにファイル数が上限を超えた場合は、comet state propose-escalation <change-name> --reason "<reason>" を実行します。理由と、hotfix を続行する場合と full にアップグレードする場合の影響を提示し、data.wait.proposalHash を保存します。明示的な選択を得た後、comet state decide-escalation <change-name> --proposal-hash <proposalHash> --choice <continue|upgrade> を実行します。続行する場合も、SDK の実行メソッドに記載されたスコープ、リスク、判定条件を満たす必要があります。アップグレードすると、同じ Run とワークスペースで full の Design に進みます。標準トリガーに従って、直ちに comet-design を読み込みます。復旧時は保留中の Wait を再利用します。
3. 根本原因の特定とタスクが完了しており、引き続き hotfix の範囲内である場合は、完全なビルドコマンドまたは受け入れコマンドを指定して、comet guard <change-name> build --apply -- <program> [args...] を実行します。ここで新たなユーザー判断は必要ありません。--apply は実行と実際のチェックの記録の前に、現在のタスク、設定、ワークスペース、証拠を再検証します。有効な成功の場合にのみ Verify に進みます。診断が必要な場合に限り、読み取り専用の comet guard <change-name> build プレビューを使用します。失敗した場合は返された現在の状態を使用し、継続処理が返されなかった場合にのみ state next --json を読み取ります。不明な Action を再実行してはいけません。
4. Run が Verify に入ったら、直ちに実行してください： Skill ツールを使用して comet-verify スキルを読み込みます。この手順を省略することは禁止されています。このスキルの SDK パスでは、レポート、独立したレビュー、実際のチェック結果の受領を処理します。Run が Archive に入ったら、直ちに実行してください： Skill ツールを使用して comet-archive スキルを読み込みます。この手順を省略することは禁止されています。Archive と引き渡しにも、現在のユーザー承認が必要です。現在の成功結果で Run の完了が示された場合にのみ、完了を報告します。完了状態が欠けている場合は state next --json を読み取ります。

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

Compat パス

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