@rpamis/comet 0.3.6 → 0.3.8

package/assets/skills-zh/comet/reference/comet-yaml-fields.md

@@ -0,0 +1,68 @@
+# .comet.yaml 字段说明
+
+规范路径：`comet/reference/comet-yaml-fields.md`
+
+本文件是 `.comet.yaml` 状态文件的字段参考。按需查阅，不随 skill 一次性加载。
+
+## 示例
+
+```yaml
+workflow: full
+phase: build
+design_doc: docs/superpowers/specs/YYYY-MM-DD-topic-design.md
+plan: docs/superpowers/plans/YYYY-MM-DD-feature.md
+base_ref: a1b2c3d4e5f6...
+build_mode: subagent-driven-development
+build_pause: null
+subagent_dispatch: confirmed
+tdd_mode: tdd
+isolation: branch
+verify_mode: light
+verify_result: pending
+verification_report: null
+branch_status: pending
+created_at: 2026-05-26
+verified_at: null
+archived: false
+```
+
+## 必需字段
+
+| 字段 | 含义 |
+|------|------|
+| `workflow` | `full`、`hotfix` 或 `tweak` |
+| `phase` | 当前阶段：`open`、`design`、`build`、`verify`、`archive`（init 统一设为 `open`，guard 负责过渡） |
+| `design_doc` | 关联的 Superpowers Design Doc 路径，可为空 |
+| `plan` | 关联的 Superpowers Plan 路径，可为空 |
+| `base_ref` | init 时记录的 git commit SHA，用于 scale 评估。无 plan 时作为改动文件数统计基准 |
+| `build_mode` | 已选择的执行方式，可为空 |
+| `build_pause` | build 阶段内部暂停点。`null` 表示无暂停，`plan-ready` 表示 plan 已生成，用户选择切换模型后暂停 |
+| `subagent_dispatch` | `null` 或 `confirmed`。仅当已确认当前平台存在真实后台 subagent / Task / multi-agent 调度能力时，`build_mode: subagent-driven-development` 才能写入并用于离开 build 阶段 |
+| `tdd_mode` | `tdd` 或 `direct`。full workflow 离开 build 阶段前必须已选择。`tdd` 强制每个任务先写失败测试再实现；`direct` 不强制 TDD。hotfix/tweak 默认 `direct` |
+| `isolation` | `branch` 或 `worktree`，工作区隔离方式。full 初始化可为 `null`，但只允许持续到 `/comet-build` Step 3 前；hotfix/tweak 默认 `branch` |
+| `verify_mode` | `light` 或 `full`，可为空 |
+| `auto_transition` | `true` 或 `false`。只控制阶段守卫推进 phase 后是否自动调用下一个 skill；`false` 时由 `comet-state next` 输出 `manual`，暂停下一 skill 调用，但不阻止 phase 字段更新 |
+| `verify_result` | `pending`、`pass` 或 `fail` |
+| `verification_report` | 验证报告文件路径，verify 通过前必须指向已存在文件 |
+| `branch_status` | `pending` 或 `handled`，分支处理完成后设为 `handled` |
+| `created_at` | change 创建日期（init 时自动写入），格式 `YYYY-MM-DD` |
+| `verified_at` | 验证通过时间，可为空 |
+| `archived` | change 是否已归档 |
+
+## 可选字段
+
+| 字段 | 含义 |
+|------|------|
+| `direct_override` | `true`/`false`。full workflow 如需使用 `build_mode: direct`，必须显式设为 `true` |
+| `build_command` | 项目构建命令。guard 优先运行该命令，失败时打印命令输出 |
+| `verify_command` | 项目验证命令。verify guard 优先运行该命令，未配置时回退到构建命令 |
+
+## 状态机硬约束
+
+- `build → verify` 前，`isolation` 必须是 `branch` 或 `worktree`
+- `build → verify` 前，`build_mode` 必须已选择
+- `build_mode: subagent-driven-development` 必须同时有 `subagent_dispatch: confirmed`
+- full workflow 离开 build 阶段前 `tdd_mode` 必须已选择为 `tdd` 或 `direct`
+- `build_mode: direct` 默认只允许 `hotfix` / `tweak`；full workflow 需要 `direct_override: true`
+- `build_pause` 不是执行方式，不得写入 `build_mode`
+- 这些约束同时存在于 `comet-guard.sh build --apply` 和 `comet-state.sh transition <name> build-complete`

package/assets/skills-zh/comet/reference/context-recovery.md

@@ -0,0 +1,35 @@
+# 上下文压缩恢复协议
+
+规范路径：`comet/reference/context-recovery.md`
+
+本协议由所有可能触发上下文压缩的 comet 子 skill 共享。当 agent 怀疑发生上下文压缩（之前对话被摘要、找不到之前讨论的内容）时，按本协议恢复。
+
+## 恢复步骤
+
+```bash
+"$COMET_BASH" "$COMET_STATE" check <change-name> <phase> --recover
+```
+
+脚本输出结构化恢复上下文（phase、已完成字段、待完成字段、恢复动作）。按 **Recovery action** 决定下一步。
+
+## build 阶段特殊恢复
+
+若恢复脚本输出 `build_mode: subagent-driven-development`：
+
+1. 使用 Skill 工具重新加载 Superpowers `subagent-driven-development` 技能
+2. 重新阅读 `comet/reference/subagent-dispatch.md` 获取 Comet 专属扩展
+3. 读取 `openspec/changes/<name>/.comet/subagent-progress.md`，恢复当前 task 或 final review、实现提交、RED/GREEN 证据、已通过审查、未解决反馈和审查-修复轮次
+4. 禁止在主会话中直接执行 task
+5. 按检查点记录的精确阶段恢复；检查点缺失或不匹配时才从第一个未勾选 task 的 implementer 派发开始
+6. task 通过双审查并完成定向勾选验证后，立即继续下一个 task，不得总结或询问是否继续
+
+## design 阶段特殊恢复
+
+- 若用户尚未确认设计方案，回到 brainstorming 继续
+- 若用户已确认，继续创建 Design Doc
+- 恢复时重新加载 `brainstorm-summary.md` + handoff 上下文文件
+
+## verify/archive 阶段恢复
+
+- verify：脚本输出验证状态、分支状态和恢复动作
+- archive：若 `archived: true` 且归档目录存在，归档已完成，无需再次执行

package/assets/skills-zh/comet/reference/debug-gate.md

@@ -0,0 +1,17 @@
+# Debug Gate 协议
+
+规范路径：`comet/reference/debug-gate.md`
+
+本协议由 build、hotfix、tweak 等会直接修改代码的 comet 子 skill 共享。当运行程序、测试、构建或手动验证时出现崩溃、异常行为、测试失败或构建失败，必须进入 Debug Gate。
+
+## 核心规则
+
+- 立即使用 Skill 工具加载 Superpowers `systematic-debugging` 技能
+- 在完成根因调查前，不得提出或实施源码修复
+
+## 四阶段流程
+
+1. 先复现并定位根因，读取完整错误、检查近期变更、追踪数据流
+2. 若根因指向源码 bug，先补充能复现该崩溃/异常的最小失败测试，再修改源码
+3. 修复后运行该失败测试、相关测试和项目构建/验证命令，确认全部通过
+4. 将测试、源码修复和 tasks.md 勾选保留在当前 change 内；不得通过另起一个“写测试用例”的 change 来替代当前 change 的验证闭环

package/assets/skills-zh/comet/reference/decision-point.md

@@ -0,0 +1,20 @@
+# 用户决策点协议
+
+规范路径：`comet/reference/decision-point.md`
+
+本协议由所有包含用户决策点的 comet 子 skill 共享。凡标注为“阻塞点”或“用户决策点”的步骤，都必须按本协议处理。
+
+## 核心规则
+
+- 决策点是阻塞点。到达决策点时必须暂停，等待用户明确选择后才能继续
+- 必须使用当前平台可用的用户输入/确认机制获取选择
+- 若当前平台没有结构化提问工具，则必须在对话中提出明确选项并停止流程，等待用户回复
+- 不得用推荐规则、默认值、历史偏好或“用户应该会同意”的推断代替当前确认
+- 用户明确选择前，不得写入对应状态字段、执行对应分支操作或自动继续下一阶段
+
+## 最低呈现要求
+
+- 说明当前决策点正在决定什么
+- 给出清晰可选项；需要用户单选时，选项必须互斥且可执行
+- 如有推荐，只能作为说明，不能替代用户确认
+- 用户选择后，再执行对应命令或状态更新

package/assets/skills-zh/comet/reference/dirty-worktree.md

@@ -2,7 +2,7 @@
 
 规范路径：`comet/reference/dirty-worktree.md`
 
-本协议由所有涉及代码修改的 comet 子 skill 共享。当 agent 恢复上下文或继续执行时，必须按本协议处理未提交的工作区改动。
+本协议由所有涉及代码修改的 comet 子 skill 共享。当 agent 恢复上下文或继续执行时，必须按本协议处理未提交的工作区改动。各子 skill 可在本协议基础上定义阶段特例（如 verify 阶段对实现改动的特殊处理），详见对应子 skill 文件。本文件不重复阶段特例。
 
 ## 1. 检查步骤
 
@@ -20,6 +20,7 @@ git ls-files --others --exclude-standard
 ## 2. 核心规则
 
 - 用户可能不会说明自己改了哪里。只要存在 dirty worktree（包括 Git 状态里显示为 `??` 的新建文件），就先假设改动可能来自用户或混合来源
+- **构建产物排除**：`??` 文件若匹配 `.gitignore` 中的模式（如 `node_modules/`、`dist/`、`__pycache__/`、`*.o`、`target/`、`build/` 等），自动跳过归因，不视为用户改动
 - dirty worktree 只代表代码事实，不会自动推进 `.comet.yaml` 的 `phase` 或勾选 `tasks.md`；只有完成归因、验证、同步必要文档，并通过对应阶段 guard 后，才允许推进 Comet 状态
 
 ## 3. 归因分类

package/assets/skills-zh/comet/reference/file-structure.md

@@ -0,0 +1,28 @@
+# 文件结构参考
+
+规范路径：`comet/reference/file-structure.md`
+
+本文件是 Comet 项目文件结构参考。按需查阅，不随 skill 一次性加载。
+
+```text
+openspec/                              # OpenSpec — WHAT
+├── config.yaml
+├── changes/
+│   ├── <name>/                        # 活跃 change
+│   │   ├── .openspec.yaml
+│   │   ├── .comet.yaml
+│   │   ├── proposal.md                # Why + What
+│   │   ├── design.md                  # 高层架构决策
+│   │   ├── specs/<capability>/spec.md # Delta 能力规格
+│   │   ├── .comet/handoff/            # 脚本生成的阶段交接包
+│   │   └── tasks.md                   # 任务清单
+│   └── archive/YYYY-MM-DD-<name>/     # 已归档
+└── specs/<capability>/spec.md         # 主 specs（归档时按 OpenSpec delta 语义合并）
+
+docs/superpowers/                      # Superpowers — HOW
+├── specs/YYYY-MM-DD-<topic>-design.md # 设计文档（技术 RFC，归档时标注状态）
+└── plans/YYYY-MM-DD-<feature>.md      # 实施计划（文件头含 change 关联元数据）
+
+.comet/
+└── config.yaml                        # Comet 项目配置（context_compression 默认 off，可设 beta）
+```

package/assets/skills-zh/comet/reference/subagent-dispatch.md

@@ -0,0 +1,113 @@
+# Subagent 驱动开发的 Comet 扩展
+
+规范路径：`comet/reference/subagent-dispatch.md`
+
+本文档提供在 Superpowers `subagent-driven-development` 技能**之上**应用的 Comet 专属扩展。该技能负责核心派发循环（每个 task 派发全新 implementer → spec compliance review → code quality review → 下一个 task）并强制连续执行。本文档添加 Comet 特有的真实后台调度、任务追踪、状态验证和上下文恢复。若 Superpowers 技能与本文档发生冲突时，以本文档中更具体的 Comet 约束为准。
+
+> **⚠️ 关键约束 — 任务之间禁止暂停**
+>
+> 当一个 task 通过双审查并被勾选后，**立即派发下一个 task**，不得停止、总结或询问用户是否继续。用户期望所有 task 按顺序自动执行，无需手动干预。任务之间暂停会中断工作流，导致用户每次都需要手动恢复。
+>
+> 仅在以下情况才停止并等待用户输入：
+> - 任务处于 **BLOCKED** 状态（3 轮审查-修复仍未通过）
+> - 存在无法从仓库、计划或既有上下文消除的真实歧义
+> - 平台没有真实后台 agent 调度能力，需要用户改选 `executing-plans`
+> - 用户**明确**要求暂停
+>
+> 此规则适用于整个派发循环，而非单个任务。
+
+## 开始前
+
+1. 读取计划一次，按顺序提取所有未勾选 task 的完整文本。
+2. 为每个 task 保存唯一标识：plan 中 checkbox 后的完整任务文本，以及它映射的 OpenSpec task 完整文本（若存在）。若文本不唯一，停止并先修正计划，禁止依赖"第一个匹配项"。
+3. 尊重依赖关系；依赖尚未完成的 task 不得提前派发。
+
+## 每个 Task 的 Comet 扩展
+
+在每个 task 上应用这些扩展，叠加在 Superpowers 技能的派发循环之上：
+
+### 0. 派发强制约束（关键）
+
+主会话**仅负责协调**，禁止直接执行 task。主会话禁止修改源代码。协调者唯一允许的文件修改是 plan、OpenSpec task 和 subagent 进度检查点的持久化更新。不得把多个 task 打包给同一个 agent。每个 task 派发一个全新的后台 implementer agent，spec reviewer、code quality reviewer、修复 agent 和 final reviewer 也必须分别使用全新的后台 agent：
+
+- **Claude Code**：对每个 implementer、spec reviewer、code quality reviewer、修复 agent 和 final reviewer 使用 `Agent` 工具并设置 `run_in_background: true`。禁止内联执行 task，禁止错误进入需要预先创建 team 的团队模式。
+- **其他平台**：使用平台等效的后台 agent / Task / 多 agent 派发机制。
+- **禁止**跨 task 或角色复用 implementer、reviewer 或修复 agent。每个 agent 拥有全新的隔离上下文，并且只接收当前角色所需的单个 task 上下文。
+- 若平台无真实后台派发能力，不得继续；暂停并等待用户改选 `build_mode: executing-plans`。
+
+### 1. 派发 Prompt 与回报契约
+
+每个 implementer 或修复 agent prompt 必须包含：
+
+- 当前单个 task 的完整文本、架构背景和依赖上下文
+- `Language: 使用触发本次工作流的用户请求语言输出`
+- 允许修改的文件范围和禁止修改的范围
+- 必须执行的测试命令和提交要求
+- 修复 agent 还必须收到对应 reviewer 的完整反馈
+
+agent 回报状态必须为 `DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT`，并包含实现内容、测试结果、提交哈希、变更文件和顾虑。进入审查前，主会话必须确认提交和文件在当前工作树可见；若平台使用隔离副本，先拉取或合并变更。
+
+每个 reviewer prompt 必须包含完整 task、实现提交或差异以及 RED/GREEN 证据（`tdd_mode: tdd` 时）。reviewer 不得只依据 implementer 的总结进行审查。
+
+### 2. Implementer 范围限制
+
+implementer 只负责实现、测试和提交代码。**implementer 不得勾选 plan 或 OpenSpec task**，也不得只更新内置 Todo 或对话 checklist。
+
+### 3. TDD 硬约束
+
+若 `tdd_mode: tdd`，每个 implementer 和修复 agent 必须先使用 Skill 工具加载 Superpowers `test-driven-development` 技能，并在 prompt 中同时注入：
+
+```text
+You MUST follow TDD: write a failing test first, watch it fail, then write minimal code to pass. No production code without a failing test first.
+```
+
+implementer 或修复 agent 回报必须提供 **RED 失败命令与失败摘要**、**GREEN 通过命令与通过摘要**；缺少任一证据不得进入审查。spec compliance reviewer 和 code quality reviewer 都必须核验 RED/GREEN 证据与测试覆盖。
+
+### 4. 持久进度检查点
+
+主会话必须维护 `openspec/changes/<name>/.comet/subagent-progress.md`，并在每次派发、agent 回报、审查结果、修复轮次变化和 task 勾选后立即更新。检查点至少记录：
+
+- 当前 plan task 唯一文本及映射的 OpenSpec task 文本
+- 当前阶段：`implementing | spec-review | quality-review | checkoff | done | blocked | final-review | final-fix`
+- 实现提交哈希、变更文件和 RED/GREEN 证据
+- 已通过的审查阶段及尚未解决的 reviewer 反馈
+- 当前 task 或 final review 的审查-修复轮次（最多 3 轮）
+
+该文件只保存恢复所需的协调状态，不替代 plan 或 OpenSpec checkbox。当前 task 完成后保留其最终记录，开始下一个 task 时用下一 task 的记录替换。
+
+### 5. 审查-修复轮次限制
+
+每个 task 最多 3 轮审查-修复。任一 reviewer 发现问题时，派发全新的后台修复 agent，并从对应审查重新开始。3 轮后仍未通过则将 task 标记为 **BLOCKED**，暂停并把累计反馈交给用户。
+
+### 6. Task 勾选与验证
+
+**两个审查都通过后**，主会话：
+
+1. 将 plan 中保存的唯一 task 文本从 `- [ ]` 改为 `- [x]`
+2. 若存在映射，再同步勾选 OpenSpec task
+3. 提交这次进度更新
+4. 运行定向验证：
+
+```bash
+"$COMET_BASH" "$COMET_STATE" task-checkoff "$PLAN_FILE" "$PLAN_TASK_TEXT"
+"$COMET_BASH" "$COMET_STATE" task-checkoff "openspec/changes/<name>/tasks.md" "$OPENSPEC_TASK_TEXT"
+```
+
+仅在对应映射存在时运行第二条。脚本会要求任务文本恰好出现一次且该项已勾选；验证失败时不得进入下一个 task。
+
+## 收尾
+
+- **自动继续**：双审查通过并勾选 task 后，立即派发下一个未勾选的 task。禁止总结、禁止询问用户是否继续、禁止在任务之间等待用户输入。这是不可协商的 —— Superpowers 技能强制连续执行，文档顶部的关键约束进一步强化此规则。
+- 所有 task 完成后，将检查点切换为 `final-review`，然后派发全新的后台 final code quality reviewer 审查整体实现。CRITICAL 问题必须将检查点切换为 `final-fix`，记录反馈和轮次，派发新的后台修复 agent 并重新审查；final review 同样最多 3 轮，耗尽后标记 `blocked` 并暂停。接受非 CRITICAL 发现时，在 tasks.md 中记录理由。
+- final review 通过后，结束的只是 subagent 派发循环，不是 Comet workflow。不得加载 `finishing-a-development-branch`，不得停下来询问用户下一步；必须返回 `comet-build` 继续执行退出条件、阶段守卫和后续阶段衔接。
+
+## 上下文恢复
+
+重新加载 Superpowers `subagent-driven-development` 技能并重新阅读本文档。先读取 `openspec/changes/<name>/.comet/subagent-progress.md`，再与第一个未勾选 task 和当前工作树核对：
+
+- 检查点与未勾选 task 匹配时，从记录的精确阶段恢复，保留实现提交、RED/GREEN 证据、已通过的审查阶段、未解决反馈和当前审查-修复轮次；不得重置轮次或重复已经通过的阶段。
+- 检查点缺失或与未勾选 task 不匹配时，为第一个未勾选 task 创建新检查点并从 implementer 派发开始。
+- 检查点中的提交或文件在当前工作树不可见时，先拉取、合并或恢复对应变更；不得假定实现已存在。
+- 所有 task 已勾选且检查点处于 `final-review` 或 `final-fix` 时，从最终审查的精确阶段恢复，并保留最终反馈和审查-修复轮次；不得重新进入已完成的 task。
+
+已提交但未通过双审查的 task 保持未勾选，并按检查点重新进入审查或修复循环。

package/assets/skills-zh/comet-archive/SKILL.md

@@ -1,73 +1,100 @@
----
-name: comet-archive
-description: "Comet 阶段 5：归档。用 /comet-archive 调用。同步 delta spec 到主 spec，归档 change。"
----
-
-# Comet 阶段 5：归档（Archive）
-
-## 前置条件
-
-- 验证已通过（阶段 4 完成）
-- 分支已处理
-- `openspec/changes/<name>/.comet.yaml` 中 `verify_result: pass`
-
-## 步骤
-
-### 0. 入口状态验证（Entry Check）
-
-执行入口验证：
-
-```bash
-COMET_ENV="${COMET_ENV:-$(find . "$HOME"/.*/skills "$HOME/.config" "$HOME/.gemini" -path '*/comet/scripts/comet-env.sh' -type f -print -quit 2>/dev/null)}"
-if [ -z "$COMET_ENV" ]; then
-  echo "ERROR: comet-env.sh not found. Ensure the comet skill is installed." >&2
-  return 1
-fi
-. "$COMET_ENV"
-"$COMET_BASH" "$COMET_STATE" check <name> archive
-```
-
-验证通过后继续 Step 1。验证失败时脚本会输出具体失败原因。
-
-### 1. 执行归档
-
-运行归档脚本，自动完成以下全部步骤：
-
-```bash
-"$COMET_BASH" "$COMET_ARCHIVE" "<change-name>"
-```
-
-脚本自动执行：
-1. 入口状态验证（phase=archive, verify_result=pass, archived=false）
-2. Delta spec 同步到主 spec
-3. Design doc 前置元数据标注（archived-with, status）
-4. Plan 前置元数据标注（archived-with）
-5. 移动 change 到归档目录
-6. 通过 `comet-state transition <archive-name> archived` 更新 `archived: true`
-
-如脚本返回非零退出码，报告错误并停止。
-如脚本返回零退出码，归档完成。
-脚本摘要中的 `X/Y steps succeeded` 以真实执行步骤计数，不会因 delta spec 同步或文档标注重复累计。
-
-当待同步的 delta spec 与已有主 spec 不一致时，脚本会在覆盖前打印 unified diff 预览，帮助确认归档同步内容。
-
-如需预览而不实际执行，使用 `--dry-run` 参数。
-
-### 2. 生命周期闭环
-
-Spec 生命周期在此完成：
-```
-brainstorming → delta spec → 实施 → 验证 → 主 spec 覆盖 → design doc 标注 → 归档
-```
-
-## 退出条件
-
-- 归档脚本执行成功（退出码 0）
-- 归档目录 `openspec/changes/archive/YYYY-MM-DD-<change-name>/` 存在
-- 归档后的 `.comet.yaml` 中 `archived: true`
-
-归档脚本会把 `openspec/changes/<name>/` 移动到 `openspec/changes/archive/YYYY-MM-DD-<name>/`。归档成功后**不要再对原 change 名运行** `"$COMET_BASH" "$COMET_GUARD" <change-name> archive`，因为原活跃目录已经不存在。归档完整性以脚本退出码和归档目录状态为准。
-
-## 完成
-
-Comet 流程全部完成。如需开始新工作，调用 `/comet` 或 `/comet-open`。
+---
+name: comet-archive
+description: "Comet 阶段 5：归档。用 /comet-archive 调用。按 OpenSpec delta 语义合并主 spec，归档 change。"
+---
+
+# Comet 阶段 5：归档（Archive）
+
+## 前置条件
+
+- 验证已通过（阶段 4 完成）
+- 分支已处理
+- `openspec/changes/<name>/.comet.yaml` 中 `verify_result: pass`
+
+## 步骤
+
+### 0. 输出语言约束
+
+归档摘要和生命周期闭环说明必须使用触发本次工作流的用户请求语言。
+
+### 0b. 入口状态验证（Entry Check）
+
+执行入口验证：
+
+```bash
+COMET_ENV="${COMET_ENV:-$(find . "$HOME"/.*/skills "$HOME/.config" "$HOME/.gemini" -path '*/comet/scripts/comet-env.sh' -type f -print -quit 2>/dev/null)}"
+if [ -z "$COMET_ENV" ]; then
+  echo "ERROR: comet-env.sh not found. Ensure the comet skill is installed." >&2
+  return 1
+fi
+. "$COMET_ENV"
+"$COMET_BASH" "$COMET_STATE" check <name> archive
+```
+
+验证通过后继续 Step 1。验证失败时脚本会输出具体失败原因。
+
+### 1. 归档前最终确认（阻塞点）
+
+入口验证通过后，**必须按 `comet/reference/decision-point.md` 的协议暂停并等待用户确认是否立即归档**。不得在用户确认前运行 `"$COMET_BASH" "$COMET_ARCHIVE" "<change-name>"`。
+
+确认前必须向用户展示简短摘要：
+- change 名称
+- 验证报告路径和结论
+- 分支处理状态
+- 本次归档将执行的不可逆动作：按 OpenSpec delta 语义合并主 spec、标注 design doc / plan、移动 change 到 archive 目录
+
+用户确认问题必须以单选题形式呈现，包含以下选项：
+- 「确认归档」— 立即执行归档脚本，完成 spec 合并和 change 移动
+- 「需要调整或重新验证」— 不执行归档；运行 `"$COMET_BASH" "$COMET_STATE" transition <change-name> archive-reopen` 回到 `phase: verify`，再调用 `/comet-verify`。若验证阶段确认需要修复，再按 `/comet-verify` 的验证失败决策回到 `/comet-build`
+- 「暂不归档」— 不执行归档，保留当前 `phase: archive` 状态，等待用户稍后再次调用 `/comet-archive`
+
+只有用户选择「确认归档」后，才允许继续 Step 2。用户选择「需要调整或重新验证」后，必须先执行 `archive-reopen` 状态回退，不得手动编辑 `.comet.yaml`。
+
+### 2. 执行归档
+
+运行归档脚本，自动完成以下全部步骤：
+
+```bash
+"$COMET_BASH" "$COMET_ARCHIVE" "<change-name>"
+```
+
+脚本自动执行：
+1. 入口状态验证（phase=archive, verify_result=pass, archived=false）
+2. Design doc 前置元数据标注（archived-with, status）
+3. Plan 前置元数据标注（archived-with）
+4. 调用 OpenSpec archive 按 delta 语义合并主 spec 并移动 change 到归档目录
+5. 校验主 spec 未残留 delta-only section 标题
+6. 通过 `comet-state transition <archive-name> archived` 更新 `archived: true`
+
+如脚本返回非零退出码，报告错误并停止。
+如脚本返回零退出码，归档完成。
+脚本摘要中的 `X/Y steps succeeded` 以真实执行步骤计数，不会因 delta spec 同步或文档标注重复累计。
+
+脚本会调用 OpenSpec 归档能力按 `ADDED/MODIFIED/REMOVED/RENAMED` 语义合并主 spec，并在归档后校验主 spec 中没有残留 delta-only section 标题。
+
+如需预览而不实际执行，使用 `--dry-run` 参数。
+
+### 3. 生命周期闭环
+
+Spec 生命周期在此完成：
+```
+brainstorming → delta spec → 实施 → 验证 → 主 spec 合并 → design doc 标注 → 归档
+```
+
+## 退出条件
+
+- 归档脚本执行成功（退出码 0）
+- 归档目录 `openspec/changes/archive/YYYY-MM-DD-<change-name>/` 存在
+- 归档后的 `.comet.yaml` 中 `archived: true`
+
+归档脚本会把 `openspec/changes/<name>/` 移动到 `openspec/changes/archive/YYYY-MM-DD-<name>/`。
+
+> **WARNING**: 归档成功后**不要再对原 change 名运行** `"$COMET_BASH" "$COMET_GUARD" <change-name> archive`，因为原活跃目录已经不存在。误调会导致 guard 报错"change directory not found"。归档完整性以脚本退出码和归档目录状态为准。
+
+## 完成
+
+Comet 流程全部完成。如需开始新工作，调用 `/comet` 或 `/comet-open`。
+
+## 上下文压缩恢复
+
+按 `comet/reference/context-recovery.md` 执行，phase 参数为 `archive`。若 `archived: true` 且归档目录存在，归档已完成，无需再次执行归档操作。