open → build → verify → archive 四步，但仍保留 OpenSpec 状态、根因消除检查、验证和归档。
hotfix 不是“无流程”。它减少前期设计成本，同时保留恢复、验证和归档。
tweak 与 hotfix 同为轻量预设，共享升级判定、连续执行和必停点等机制。两者的差异见 tweak 预设。
hotfix 快在前期设计成本更低，但根因、验证和归档仍然保留
怎么触发
hotfix 通常不是手动输入的命令。用户调用/comet 并进入 Classic 后，内部 /comet-classic 会在 Step 0 先做预设检测：
你也可以直接输入
/comet-hotfix。
正常恢复仍使用 /comet。配置进入 Classic 后，内部 /comet-classic 会读取 .comet.yaml 的 workflow 字段，并在 phase: build 时路由回 /comet-hotfix。
适合什么场景
以下条件必须同时满足：- 修复已有功能的 bug，不新增 capability
- 不涉及接口变更或架构调整
- 改动范围可预估（文件数仅作提示，不是硬性升级条件）
和 full、tweak 的关系
无法判断时，直接调用
/comet 并描述修改范围。路由证据不足或与风险信号冲突时，Comet 会请求确认。
你会经历什么
Step 1：快速开启（预设 open）
加载openspec-new-change（不做 openspec-explore 长探索），创建精简版产物：
初始化 hotfix 状态（
init 写入的默认值见下表）：
design.md（只对 full 要求），所以 open 完成后直接跳到 build，跳过 design 阶段。
hotfix 初始化的默认值
init <name> hotfix 写入 .comet.yaml 的默认值（和 tweak 完全一样，都跳过设计阶段）：
hotfix 会在入口暂停一次，让你显式选择当前分支、创建分支或创建 worktree，不会静默选择隔离模式。
确认后，
isolation 和 bound_branch 会记录实际执行工作区，后续意外切换分支会被阻止。
其余 build 字段使用预设值，guard 对预设工作流豁免 review_mode/tdd_mode 选择检查。
build_mode: direct 默认只允许 hotfix/tweak。full 必须显式设 direct_override: true。
Step 2：直接构建（预设 build）
使用默认值build_mode: direct、tdd_mode: direct、review_mode: off，并沿用入口时已确认的 isolation。跳过 brainstorming 和 writing-plans。逐任务执行：
- 先复现、后修复：改代码前先复现 bug 并记录失败证据。可以自动化时，先添加一个会失败的回归测试。没有复现证据不得修改代码。无法自动化复现时，把手动复现步骤和结果写入 proposal 或验证报告。
- 读 tasks.md 未完成任务
- 每个任务：改代码 → 格式化 → 跑测试 → 勾选
- [x]→ 提交（fix: <简述修复>） - 全部完成后显式运行项目测试和构建命令
## MODIFIED Requirements）。
Step 3：根因消除检查（hotfix 专属）
这是 hotfix 独有的步骤（tweak 没有），在 build guard 之前执行，确保修复确实消除了问题根因：- 读 proposal.md 的 bug 描述和根因
- 搜索验证问题代码不再存在
- 根因未消除 → 回 Step 2 继续修复（仍在 build 阶段，无需状态回退）
Step 4：验证（预设 verify）
复用/comet-verify，由规模评估决定 light 或 full：
想增加审查可在验证前手动设置：
Step 5：归档（预设 archive）
复用/comet-archive。要求 verify_result: pass，并等待归档前最终确认。如有 delta spec，同步到 main spec。
调用的 skill
brainstorming和writing-plans默认跳过：build_mode: direct直接实现，不生成实施计划。- Step 4 / Step 5 复用 verify、archive 阶段流程，Skill 加载与对应阶段页一致；默认
review_mode: off，light 验证不派代码审查。
升级判定（三层分工）
hotfix 的范围判定采用三层分工，避免“用纯文件数当硬性升级条件”误杀正常 bug 修复：1. 质变信号（命中任一即暂停）
2. 文件数阈值（用户拍板）
改动文件数超过提示阈值（如超过 4 个）时会暂停并交你决定。 文件数是提示触发器，不是硬性升级条件。文件多不等于有质变。3. 验证级别（scale 脚本判定）
comet-state scale 只决定 verify_mode，不卡流程、不触发升级。
升级决策（停顿点）
命中升级信号或文件数阈值时，Comet 暂停让你二选一（不能自行升级或自行判定可继续）：
选 B 后用合法升级通道（不能手工编辑
.comet.yaml）：
workflow: full、classic_profile: full、把 phase 回退到 design 并清空 design_doc，然后加载 /comet-design 补 Design Doc。
已完成的代码、tasks 和 OpenSpec 产物都会保留。你只需补一个 Design Doc，不需要从头开始。
preset-escalate 只能从 phase: build 的 hotfix/tweak 触发，其他情况会报错。
连续执行和必停点
hotfix 默认一次性连续执行。调用后自动推进，不主动停顿。 但无论auto_transition 取何值，以下情况都必须暂停并等待你确认：
- 命中升级判定信号或文件数阈值
- 验证阶段的验证失败决策
- 归档与交付最终确认（含仅本地归档选项）
auto_transition: false 时降级为逐阶段手动推进（每个 phase 边界停下，由你手动运行下一阶段命令）。
退出条件
- Bug 已修复，测试通过
- change 已归档
- 如有 spec 变更，已同步到 main spec
- 阶段守卫：build→verify 前
comet-guard <name> build --apply，verify→archive 前comet-guard <name> verify --apply
恢复
hotfix 幂等。中断后用/comet 恢复。
配置进入 Classic 后，内部 /comet-classic 会读取 .comet.yaml 的 workflow 字段，并在 phase: build 时路由回 /comet-hotfix。
comet-state check <name> build --recover 会给出恢复上下文，从 tasks.md 第一个未完成任务继续。
下一步
- tweak 预设 — 另一个轻量预设（调整行为或内容）
- 自动推进机制 — 预设的连续执行、升级和
preset-escalate - 五阶段停顿点和用户选择点 — hotfix 的停顿点
- verify 阶段 — hotfix 复用的验证流程