comet-hotfix

Comet 预设：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，运行 comet state check <change-name> <phase> --recover --json 以调查原始 Action；在结果未知时，不要重复实施、检查或归档。

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，直接恢复 Build；不要重新初始化或重复 Open。复现缺陷，保留失败证据，完成任务，并按照 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 skill。禁止跳过此步骤。其 SDK 路径负责处理报告、独立审查和实际检查回执。Run 进入 Archive 时，立即执行： 使用 Skill 工具加载 comet-archive skill。禁止跳过此步骤。Archive 和交付仍需获得用户当前授权；只有当前成功结果显示 Run 已完成时才能声称完成；如果缺少完成状态，请读取 state next --json。

每次推进后，使用该结果的 agent.continuation / data.nextAction。状态有效且完整时，不要重复执行 next、select 或 check；仅在冷启动恢复、外部状态变更或信息缺失时重新读取。请在当前 Run 中处理 decision、evidence 或 reconcile；只有对 action 才执行相应步骤。 对于确定性的本地检查，请按照 SDK 执行方法所述，在 -- 之前添加 --local；Runtime 会在复用前验证完整输入并记录日志。外部检查仍须执行。将 SDK Build 关联到稳定的 --session ；如果提供了该参数，full complete-build 已包含此参数。

Compat 路径

剩余的原始 Runtime 步骤仅适用于 runtimeFormat: compat。请阅读 Compat 操作，并继续当前阶段。SDK 不会加载该参考文档。