用途
Comet Preset: Hotfix 是 Comet 的一个预设工作流，用于修复已有功能的局部缺陷。它采用较短的缺陷修复流程：open → build → root cause check → verify → archive，跳过头脑风暴和完整的实现计划，适用于修复现有行为而不设计新功能。
当用户显式调用 /comet-hotfix、选择 hotfix，或恢复 workflow: hotfix 时使用。
适用条件
所有适用条件必须同时成立：
- 修复已有功能的缺陷，不新增功能。
- 无接口变更或架构重设计。
- 范围可估算。文件数量只是触发复核的提示，不是自动升级规则。
当修复遇到“升级决策”中列出的变更时，预设可能不再适用，应让用户决定是否改用完整的 /comet-classic 流程。
使用方式
开始或恢复前，需阅读并遵循 comet-classic/reference/classic-layout.md。所有 OpenSpec CLI 调用必须使用适配器，所有路径必须使用绑定的 <classic-*> 逻辑根。
预设流程共 6 步：
-
设置输出语言：使用 Comet 配置的产物语言。在 .comet.yaml 存在前，先读项目 .comet/config.yaml 的 classic.language，再读全局 ~/.comet/config.yaml；初始化后用 comet state get <name> language 读取。
-
打开最小变更：复用 Comet Open 的 hotfix 默认值，跳过完整 openspec-explore 探索，只创建修复所需产物。必须用 Skill 工具加载 openspec-new-change。外部 OpenSpec 指令需适配：不直接调用官方 CLI、不采用固定 cwd、不读写固定物理 OpenSpec 路径；每个 OpenSpec 命令使用 comet classic openspec -- <args...>，所有变更和产物路径使用本次调用的 <classic-*> 逻辑根。工作区隔离是状态初始化前的用户选择，需在 decision-point 下暂停并给出选项：A. 当前分支（--isolation current）；B. 创建分支 hotfix/YYYYMMDD/<change-name>（--isolation branch）；C. 创建 worktree（--isolation worktree，先加载 Superpowers using-git-worktrees）。随后准备并初始化工作区、选择变更。若 select/check 返回 BLOCKED 或分支绑定 ERROR，需暂停并让用户选择返回绑定分支或显式确认后 rebind，不要自行切换或重绑分支。然后创建精简产物：proposal.md（问题、根因、修复目标）、design.md（修复方案，一个即可）、tasks.md（修复任务）。除非修复改变现有 spec 的验收场景，否则不需要 delta spec。用 comet guard <change-name> open --apply 推进到 build，并用 comet state next <name> 判断自动或手动继续。
-
直接实现：使用 hotfix 默认值 build_mode: direct、tdd_mode: direct、review_mode: off，保持第 1 步确认的隔离方式。direct 跳过完整规划和逐任务 TDD 编排，但仍要求复现、回归测试和验证。跳过 Superpowers brainstorming 和 writing-plans。任务数量本身不触发 /comet-build。开始或恢复编辑前，按 dirty-worktree 处理未提交变更。修改实现前先复现问题并记录失败：确认旧行为确实以最小可重复步骤失败，记录命令、输入和实际结果；能自动化时先添加并运行失败的回归测试，确认其因该缺陷失败；不能自动化时记录原因并提供可重复的手动失败证据。获得 RED 证据后按顺序执行 tasks.md：实现修复、运行格式化、运行回归测试至通过、运行相关测试、将 tasks.md 的 - [ ] 改为 - [x]、用 fix: <repair-summary> 提交。全部任务完成后显式运行相关项目测试和构建。运行程序、测试、构建或手动验证时遇到崩溃、异常行为、失败测试或失败构建，需通过 Skill 工具加载 Superpowers systematic-debugging，完成根因调查前不得提出或实现源码修复。若修复影响现有 spec 验收场景，创建 <classic-change-dir>/specs/<capability>/spec.md 作为 delta spec，仅包含 ## MODIFIED Requirements。
-
确认根因已消除：在 build guard 前进行，读取 proposal.md 中的缺陷描述和根因，搜索相关代码确认错误实现已移除或修正；若根因仍在，返回第 2 步（阶段仍为 build，无需状态回滚）。若检查发现更深层架构问题或修复需要另一处接口变更（如新公共 API），在“升级决策”下暂停让用户决定。确认消除后，用 comet guard <change-name> build --apply 从 build 推进到 verify。
-
验证：复用 /comet-verify，其规模评估选择轻量或完整验证。必须用 Skill 工具加载 comet-verify。无 delta spec 的小型 hotfix 通常满足轻量条件（≤ 3 个任务且变更文件低于规模阈值），遵循 comet-verify 的轻量验证清单。默认 review_mode: off 不派发自动代码审查；用户如需审查，可在验证前设置 comet state set <name> review_mode standard 或 thorough。若 hotfix 创建了 delta spec，按 comet-verify 规模规则进入完整验证。验证及报告完成后，/comet-verify 运行 comet guard <change-name> verify --apply；复用其成功归档状态和 agent.continuation，不要手动设置 verify_result: pass 或重复 Guard。若 Guard 失败，处理其原因，不得声称验收通过。/comet-archive 仍需最终确认后才归档，绝不自动运行 archive。
-
归档：复用 /comet-archive，要求 .comet.yaml verify_result: pass 并等待其最终归档确认。必须用 Skill 工具加载 comet-archive。若有 delta spec，按 comet-archive 规则同步到主 spec，并对关联的 Design Doc 和 Plan 应用归档标注。
升级决策
升级只决定是否用完整流程替换预设。文件数量不会自动升级工作流。comet state scale 推荐轻量/完整验证但不写配置；Verify 根据实际风险选择。
修复过程中需留意：跨模块协同编辑、新功能、数据库 schema 变更、新公共 API、更深层架构问题（常由根因消除检查发现）。出现任一情况，Agent 不得在无用户参与下自行升级或决定留在 hotfix。
文件数量仅提示范围复核，不是实质性升级信号。交付文件超过提示阈值（如 > 4 个文件）时，先统计当前变更的交付文件并检查是否有有效授权。交付文件仅包括实现/源码、测试、用户文档、配置和生成输出；统计确认基线后的已提交变更以及已暂存、未暂存和未跟踪文件，按路径去重。排除当前变更目录中的 OpenSpec 产物、.comet 元数据和无关脏文件。
复用文件数量提示的显式授权：只有当前变更用户明确授权在范围和风险不变、文件数量是唯一触发条件时继续，才能创建或复用授权。普通“开始修复”指令、Skill 调用、历史偏好和 Personal Memory 都不是授权。授权仅存储在 <classic-change-dir>/.comet/rulings.md，使用固定结构（status、workflow、decision、scope、allowed-file-categories、authorization-basis、reason）。首次超过文件数量阈值且无有效裁决时，在 decision-point 下暂停，让用户选择继续 hotfix（A）或升级完整流程（B）。仅在用户明确选择 A 并确认范围和风险不变、文件数量是唯一触发条件后写入裁决；同一范围内后续增长可复用 status: active 而无需再问。有有效授权时不询问，但先报告总文件数、类别细分、与确认范围的映射、裁决位置以及未发现实质性升级信号的证据，然后继续 hotfix。验证深度仍按实际风险和 comet state scale 建议。
恢复任务时，先读取当前变更的裁决。
适用场景与限制
适用于修复已有功能的局部缺陷，不新增功能、不改接口、不做架构重设计、范围可估算。限制包括：遇到跨模块协同、新功能、数据库 schema 变更、新公共 API 或更深层架构问题时需用户决定是否升级；文件数量超过阈值需范围复核或显式授权；验证深度按实际风险选择；归档需最终确认，不自动执行。