@michaelxwb/code-flow 0.6.5 → 1.0.0

package/src/adapters/claude/commands/cf-task/prd.md

@@ -1,162 +0,0 @@
-# cf-task:prd
-
-从一句话需求出发，通过结构化对话产出产品需求文档（PRD），为 `cf-task:align` 提供足够丰富的输入。
-
-## 输入
-
-- `/cf-task:prd "需求描述"` — 从需求描述新建 PRD
-- `/cf-task:prd` — 交互式，先问用户要做什么
-- `/cf-task:prd <.prd.md 路径>` — 恢复已有草稿继续讨论
-
-## 执行步骤
-
-### 1. 确定模式与复杂度
-
-**模式判定**（顺序匹配，优先更具体的后缀）：
-
-| 参数形态 | 模式 | 行为 |
-|---------|------|------|
-| 已存在的 `.prd.md` 文件 | **恢复模式** | 读取文件，展示当前内容，询问要调整哪些部分，进入 Step 3 |
-| 已存在的其他 `.md` 文件 | **新建模式（带参考）** | 提示"非 `.prd.md`，将视为参考材料"，读取后进入 Step 2 |
-| 纯文本字符串 | **新建模式** | 以文本作为初始需求，进入 Step 2 |
-| 无参数 | **交互模式** | 询问"要解决什么问题？"，进入 Step 2 |
-
-> 若参数是 `.design.md` 文件：提示"这是设计稿，PRD 阶段不适用，建议改用 `cf-task:align` 恢复"，不当作参考材料。
-
-**复杂度预判**：若需求已有明确技术方案，或仅是小改动/脚本/Bugfix，则完整 PRD（6 章）偏重——主动提示用户"该需求较轻，可只填核心章（背景/用户故事/功能/范围），或直接用 `cf-task:align` 出设计简报"，由用户决定走精简还是完整流程。
-
-### 2. 快速上下文扫描
-
-了解项目背景，为后续建议提供依据：
-
-1. 用 Glob 检查 `.code-flow/specs/shared/_map.md` 是否存在，若有则 Read 读取（了解模板位置）
-2. 如有相关设计文档或已有 PRD，用 Glob/Read 扫描了解现状
-
-目的：**让 PRD 基于实际业务背景**，而非泛泛的通用描述。本步只读不提问，所有提问统一放到 Step 3。
-
-### 2.1 先解析并绑定 Existing Specs（硬门禁）
-
-在开始写需求内容前，先确定 Step 5 的需求目录和预计涉及路径，再执行：
-
-```bash
-python3 .code-flow/scripts/cf_spec_context.py catalog --stage prd --root "$PWD" --paths <预计路径...> --json
-```
-
-1. 必须检查完整 `candidates`，不得按展示条数截断；只消费 resolver 返回的 `stages` 含 `prd` 的产品、安全、兼容、业务约束，`code-only` Spec 不得进入 PRD。
-2. 对每个适用候选记录 `selected_by` 和具体 `reason`，立即用 `bind --stage prd` 写入需求目录的 `spec-context.yml`（首次 `applications` 为空），然后再进入需求细化。
-3. required Rule 必须进入 PRD 的 `Existing Spec Constraints`，并明确影响哪个范围项、FEAT 验收或 NFR；只复制一句“遵循规范”不算承接。
-4. 不适用的 required Rule 必须逐 Rule 说明具体理由并请求用户确认，再调用 `decision` 保存 `not_applicable`；禁止批量 N/A，**Agent 不得代确认**。
-5. Catalog/Context 失败、同级 required 冲突或 required Rule 尚未决定时 fail-closed：保留草稿并修复，不得绕过后继续产出可批准 PRD。
-
-> 预计路径尚不明确时仍须以空 `--paths` 运行，确保 global/task-stage 规则先进入 Context；后续范围明确时重新 catalog，并补充绑定新增候选。
-
-### 3. 交互式细化
-
-围绕 PRD 各要素逐步推进，**每轮提 2-3 个问题**：
-
-**背景与目标**（必选）
-- 要解决什么问题？影响谁？
-- 当前有什么替代方案？为什么不够用？
-- 期望达成什么目标？（有量化指标就用数据，如"转化率提升5%"；无量化指标则给定性目标，**禁止编造数字**）
-
-**用户与场景**（必选）
-- 谁会用这个功能？用户规模多大？
-- 典型使用场景是什么？
-
-**功能需求**（必选）
-- 核心功能有哪些？（P0 必做，P1 重要）
-- 有什么边界情况需要处理？
-
-**非功能需求**（按需）
-- 有什么性能/安全/兼容性要求？
-- 如果没有明确要求，跳过此节
-
-**范围与边界**（必选）
-- 这次做什么？明确不做的是什么？
-- 有什么前提假设？
-
-**依赖与风险**（按需）
-- 依赖哪些外部因素？
-- 有什么已知风险？
-
-**交互原则**：
-- 基于业务背景**提出具体默认建议**，而非空泛提问
-- **初始需求或已读取的参考材料中已明确的维度不重复提问**，只就缺失或模糊处发问
-- 每轮回答后更新理解，追问细节或推进到下一个维度
-- 用户说"你定"或"随意"时，选择最合理的默认方案，明确告知用户
-- 输出语言默认与用户需求语言保持一致；若用户未明确指定语言，默认使用中文
-- 仅当用户明确要求英文或项目已有强约定要求英文文档时，才输出英文
-
-**中断恢复**：在进入 Step 3 之前**提前确定文件路径**（Step 5 的命名与目录逻辑）。当任意两个维度已有实质内容时，立即写入草稿文件。后续每轮对话更新同一文件，会话中断不会丢失进度。
-
-### 4. 基于模板生成 PRD
-
-收集到足够信息后，读取 PRD 模板生成文档。
-
-**操作步骤**：
-1. 用 Read 读取 `.code-flow/specs/shared/prd-template.md`
-2. 按照模板章节结构，将 Step 3 中收集的内容填入对应位置
-3. **只包含适用的章节**，模板中有但需求不涉及的章节跳过
-4. 用 `{}` 占位符替换为实际内容
-5. 展示生成的 PRD
-
-**章节映射**：
-| 模板章节 | 内容来源 |
-|---------|---------|
-| 1. 文档控制 | 自动生成 |
-| 2. 背景与目标 | Step 3 的"背景与目标" |
-| 3. 用户与场景 | Step 3 的"用户与场景"（**分配 US 编号**） |
-| 4. 功能需求 | Step 3 的"功能需求"（**分配 FEAT 编号 + 回填来源 US**） |
-| 5. 非功能需求 | Step 3 的"非功能需求"（按需，分配 NFR 编号） |
-| 6. 范围与边界 | Step 3 的"范围与边界" |
-| 7. 依赖与风险 | Step 3 的"依赖与风险"（按需） |
-| 8. Existing Spec Constraints | Step 2.1 的 prd-stage Rule；逐条关联范围/FEAT 验收/NFR |
-
-**编号与追溯（硬约束，`cf-task:align` 派生的基础）**：
-- 用户故事按出现顺序分配 `US-01`、`US-02`…，写入 §3.2 用户故事表
-- 功能按出现顺序分配 `FEAT-01`、`FEAT-02`…，写入 §4.1 功能清单表
-- §4.1 功能清单的"来源用户故事"列**必须**填写该功能对应的 `US-XX`；一个功能可关联多个 US（逗号分隔）
-- 每个 US 至少被一个 FEAT 覆盖；每个 P0/P1 FEAT 至少关联一个 US（无来源即视为缺口，需补 US 或降级）
-- 非功能需求按 §5 既有前缀分配 `NFR-PERF/REL/SEC/COMPAT-XX`
-- 编号一旦分配不可复用或跳号；恢复模式下新增项续接当前最大编号
-
-> 这条追溯链（US → FEAT → NFR）是 align 继承上下文、回填 FEAT"来源"列的依据，缺失会导致设计阶段断链。
-
-展示后询问用户：**确认写入？可以调整任何部分。**
-
-### 5. 写入文件
-
-用户确认后：
-
-1. 从目标推导需求名（kebab-case），如 `user-login-flow`
-2. 按当前日期创建**需求目录**：`.code-flow/tasks/<YYYY-MM-DD>/<name>/`
-3. **重名检查**：需求目录已存在且非本次草稿时，目录名追加序号 `<name>-2`、`<name>-3`… 避免覆盖；恢复模式复用原目录、不改名
-4. 用 Write 写入 `.code-flow/tasks/<YYYY-MM-DD>/<name>/<name>.prd.md`
-
-写入后必须完成 Context 回填和 PRD Gate：
-
-1. 再次调用 `bind --stage prd`，`selections` 可为空，`applications` 为每条已承接 Rule 写入 `artifact`、`section_id`、`item_id`；artifact 必须指向本需求目录内 PRD，由脚本计算 `artifact_sha256`。
-2. 执行 `python3 .code-flow/scripts/cf_spec_gate.py --task-dir <需求目录> --stage prd --json`。
-3. 只有 `decision=pass` 才能把 PRD 标为可评审并输出下一步；pending/conflict/stale、缺少范围/验收落点或无有效用户确认的 N/A 均保持阻断。
-
-**文件位置说明**：PRD、设计简报（`<name>.frontend.design.md` / `<name>.backend.design.md`）、任务文件（`<name>.md`）同放**需求目录** `.code-flow/tasks/<日期>/<name>/`，`cf-task:archive` 按整个需求目录归档。
-
-### 6. 输出摘要
-
-```
-已生成 PRD: .code-flow/tasks/<日期>/<name>/<name>.prd.md
-
-内容:
-  - <按实际包含的章节列出>
-  - 用户故事: N 个
-  - 功能: N 个（P0: X, P1: Y）
-  - 追溯自检: FEAT↔US 全部关联 ✓ ｜ 有缺口则列出「未关联 FEAT-XX / 未覆盖 US-XX」
-  - Existing Specs: N 个 / required Rules: N 条 / PRD Gate: pass
-
-> 自检发现缺口（FEAT 无来源 US 或 US 无 FEAT 覆盖）时，在摘要显式标注并提示用户补 US 或降级，不要静默放过。
-
-下一步:
-  - 审阅/编辑: 直接打开 .code-flow/tasks/<日期>/<name>/<name>.prd.md
-  - 推进设计: /cf-task:align .code-flow/tasks/<日期>/<name>/<name>.prd.md
-    （align 将从 PRD 派生设计简报，继承目标/用户/功能/范围，只需补技术维度）
-```

package/src/adapters/claude/commands/cf-task/start.md

@@ -1,304 +0,0 @@
-# cf-task:start
-
-激活子任务并开始编码。支持单任务模式和整文件模式。
-
-## 输入
-
-- `/cf-task:start <file> TASK-001` — 激活指定文件中的单个子任务
-- `/cf-task:start <file>` — 激活文件内所有可执行的 draft 子任务；批次内独立任务默认并行派发子 agent
-- `/cf-task:start <file> --serial` — 整文件模式强制串行执行，不建 worktree
-
-其中 `<file>` 为 `.code-flow/tasks/` 下的文件名，可省略日期目录前缀和 `.md` 后缀。
-
-查找逻辑：用 Glob 搜索 `.code-flow/tasks/**/<file>.md`，从结果中排除包含 `archived/` 的路径。如果匹配到多个结果，输出警告列出所有匹配项，让用户指定完整路径；如果只有一个结果，直接使用。
-
-示例：
-- `/cf-task:start auth-module TASK-002`
-- `/cf-task:start auth-module`
-
-## 单任务模式
-
-### 1. 前置检查
-
-用 Read 读取任务文件，定位 `## TASK-xxx` 段落：
-
-**状态检查**：Status 必须为 `draft`。若为其他状态：
-- `in-progress` → 校验现有 marker 的需求目录、TASK-ID 与 Context；匹配且为 active 才继续步骤 2，跳过重复 Start。paused/blocked 先解除原因并调用 resume；marker 缺失或不匹配先 doctor，不能仅改 Markdown。
-- `done` / `verified` → 实现已完成；done 的 E2E 可为 e2e_deferred，转 verify-e2e 终验。发现缺口时报告并显式重新规划修复任务，不直接把终态改成 in-progress。
-- `blocked` → 提示"任务被阻塞"，列出 Notes 中的阻塞原因，结束
-
-**#NOTES 检查**：扫描该子任务段落全文（Description、Checklist 等）
-- 如果存在 `#NOTES` 标记，说明用户 review 时留下了未讨论的问题，拒绝启动
-- 输出：`前置检查失败：以下 #NOTES 未解决\n- 密码加密存储  #NOTES 用 bcrypt 还是 argon2？\n- ...\n请先运行 /project:cf-task:note <file> TASK-xxx 讨论并解决`
-
-**依赖检查**：读取 `Depends` 字段
-- 对每个依赖的 TASK-ID，在同文件中查找其 Status
-- 所有依赖必须为 `done` 或 `verified`
-- 未满足 → 输出：`前置检查失败：以下依赖未完成\n- TASK-001: in-progress\n- TASK-003: draft`
-
-**验收契约检查**：
-- 如果 task 含 `## Acceptance Coverage`，当前子任务必须有 `Acceptance-Refs`、`Acceptance Contract` 和 `Acceptance Evidence`
-- `Acceptance-Refs` 中每个 S-/E-/B- 都必须出现在全局覆盖表和当前契约中，测试层级与关键真实边界必须和 design 一致
-- 旧 task 没有覆盖表但来源 design 含结构化验收场景时，先从 design 回填覆盖表与契约；回填完成前不得修改生产代码
-- 非行为类任务可显式写 `Acceptance-Refs: N/A`；不得用 N/A 跳过已有设计场景
-
-### 2. 加载详设上下文
-
-前置检查通过后，**编码前先加载关联的详设文档章节**：
-
-1. 读取子任务的 `Source` 字段，解析章节引用
-   - 格式：`docs/xxx.md#§3.1 数据模型(L83-L110)`
-   - 提取：文件路径 + 行号范围
-2. 用 Read 按行号范围读取详设文档的对应章节（使用 offset/limit 参数）
-3. 将读取的章节内容作为编码上下文，与 Checklist 一起指导实现
-4. 按 `Acceptance-Refs` 精确读取验收场景及其关联 RULE/RISK；不得只依赖摘要，也不得遗漏场景的测试层级、关键真实边界和预期结果
-
-示例：Source 为 `docs/auth.md#§3.2 API 接口(L111-L155), docs/auth.md#§3.5 错误码(L201-L220)`
-→ Read `docs/auth.md` offset=111 limit=45
-→ Read `docs/auth.md` offset=201 limit=20
-
-### 3. 激活并准备验收测试
-
-在改状态或生产代码前，顺序固定且不得跳步：
-
-1. 调用 `cf_spec_context.py start --task-dir ... --root ... --task ... --task-file ... --json`，由单个进程按 refresh → active start → session 顺序执行 Start Gate；stdin JSON 传入逐路径确认的 `owned_paths`。stale/conflict、依赖未闭合、已有/损坏 marker、未归属 diff 或 hash 不一致立即阻断。禁止先 start 再 refresh，避免 active marker 在编码前自行漂移。前置硬门禁（blocked / #NOTES / 依赖）由 workflow service 在改状态前强制执行。用户已确认内容时，Design/Plan 的 pending 不单独阻止激活；不新增阶段状态门禁。
-2. 从命令返回值读取 refresh 后的 Context hash、active 状态和 session 输出路径；该命令只根据当前 TASK 的 `Spec-Refs`、Source 与 Acceptance Contract 覆盖写入 `.code-flow/specs/_session/task-<name>.md`，禁止重新 catalog 或猜测规则。
-3. Start 返回成功时，workflow service 已通过可恢复事务同步 Status、started log 和 active marker；不要再手动改状态。失败保留原状态，按返回原因恢复。
-4. 在修改任何生产代码前，为每个 Acceptance-Ref 填写测试文件、包含场景 ID 的测试用例名和可单独执行的命令（E2E 只登记，不在本阶段执行）
-5. 先编写验收测试（E2E 只编写并登记）。E2E 测试必须经过契约声明的真实边界，不得用 mock 绕过 Store、Resolver、Builder、Renderer、Browser 等指定组件
-6. 新功能或缺陷修复先执行一次测试并记录 RED：失败命令、失败用例和与预期缺陷对应的失败原因。纯重构或已有行为补测无法 RED 时，记录原因，不得伪造失败。E2E 场景不执行 RED，登记为 e2e_deferred 留给 verify-e2e
-
-RED 证据写入 `Acceptance Evidence`：
-
-```markdown
-| 场景ID | RED | GREEN | 断言位置 | 真实边界证据 | 状态 |
-|--------|-----|-------|---------|-------------|------|
-| S-01 | FAIL: generation 未递增 | pending | pending | real Store + Renderer fixture | test-written |
-```
-
-### 3.1 实现与逐项更新
-
-1. RED 证据就绪后，结合详设上下文、Acceptance Contract 与 Checklist 修改生产代码
-2. 每完成一个 checklist 项，用 Edit 将 `- [ ]` 改为 `- [x]`
-3. 如果实现中发现必须改变测试层级或真实边界，停止编码并记录 `#NOTES`，经用户确认并同步 design 后才能继续；agent 不得自行降级
-
-### 3.2 GREEN 与验收证据
-
-1. 执行 functional 验收和受影响范围的回归测试；E2E 只登记场景、断言、真实边界和命令，RED/GREEN 都不在编码阶段执行，统一留给 verify-e2e。
-2. 对每个预期结果记录断言位置与 fixture/构造路径；环境未就绪的错误不得冒充有效 RED，明确记录尚未验证。
-3. 由 runner 写入最新状态和运行历史；不要覆盖原契约、RED 证据或历史失败。functional 必须 verified，已登记的 E2E 在实现阶段允许 e2e_deferred。
-4. 测试未收集、命令未实际执行或缺少关键断言，都不算验证完成。失败重跑必须使旧 verified 失效。
-
-### 3.5 TASK-bound Spec Session
-
-激活后，若任务文件头 Source 指向的 design 文档含验收条件章节（如 §2.5 验收条件 / 验收标准）：
-
-1. 只提取当前任务 `Spec-Refs` 与 `Acceptance-Refs` 对应的 Rule hash、verifier、artifact refs、场景、测试层级和真实边界，生成 `.code-flow/specs/_session/task-<name>.md`：
-   - frontmatter：`description: 当前任务 <name> 的验收约束（cf-task:start 生成，archive 清理）`
-   - 正文：验收场景与约束的精简列表（≤300 token）；必须保留全部引用 ID、层级、边界和预期结果，不能为压缩而删除场景
-2. 任务模式直接读取这个投影，禁止经 Spec Catalog 二次选择；同名文件已存在则原子覆盖。
-3. 50 Rule 等超预算任务按 required/当前阶段优先输出受控摘要，完整 Context 保留不丢失，并明确提示拆 TASK；不得用截断隐藏 required 缺口。
-
-> `_session/` 不入库（.gitignore 模板已覆盖）、不参与规范审计与预算。
-
-### 4. 自动完成
-
-只有同时满足以下条件才能自动完成：
-- 所有 checklist 项均为 `[x]`
-- functional/manual 在契约、证据和覆盖表中均为 `verified`；仅 E2E 可为 `e2e_deferred`，仍不得遗留未登记的 `planned` / `pending` / `TBD`
-- 测试层级未低于 design，关键真实边界没有被 mock 绕过
-- 每个预期结果都有具体断言位置，functional 验收命令和回归测试均已实际通过；E2E 留到终验执行
-- `manual` 场景已有用户确认和可复核记录
-
-满足后，执行唯一收尾入口：
-
-```bash
-python3 .code-flow/scripts/cf_task_workflow.py finish --root "$PWD" --task-dir "<需求目录>" --task TASK-001 --json
-```
-
-该命令先校验完整任务身份与锁定 manifest，再执行 Done Gate（acceptance 场景 + spec verifiers + 全量 validation.yml，含 heavy）；通过后以可恢复事务更新 done、Log、Updated 并清理 marker。只有 `decision=pass` 才输出完成并启动下一 TASK。禁止手动设置 done 或传入自报的 gate_passed 绕过验证。
-
-任一验收条件不满足时保持 `in-progress`，明确列出缺口，不能标记为 `done`。
-
-### 5. 文档同步检查
-
-子任务完成后，轻量检查本次编码是否引入了需要同步到 specs 或导航地图的内容：
-
-1. 回顾本次编码的变更（新增/修改了哪些文件和模式）
-2. 快速对照 `.code-flow/specs/` 下对应领域的规范文件和 `<map-file>.md`
-3. 如果发现以下情况，输出同步提示：
-   - 新增了 specs 未记录的编码模式（如新的错误处理方式、新的中间件）
-   - 新增了目录或入口文件，但 `<map-file>.md` 中未体现
-   - 修改了数据流或模块关系
-
-```
-Spec 同步提示:
-  本次编码引入了以下变更，建议同步到规范:
-  - 新增 <模式描述> → <spec-path>/
-  - 新增 <文件路径> → <map-file>.md Key Files
-
-  运行 /cf-learn --map 可自动更新导航地图。
-```
-
-如果无需同步，跳过此步骤，不输出任何提示。
-
-> 注：此检查是轻量级的建议，不阻塞流程。完整的三维校验在 archive 阶段执行。
-
-## 整文件模式
-
-### 1. 扫描所有子任务
-
-用 Read 读取整个 task 文件，提取所有 `## TASK-xxx` 段落的 ID、Status、Depends。
-
-### 2. 加载详设文档
-
-1. 读取文件头的 `Source` 字段，提取设计文档路径（文件头 Source 只有路径，无行号范围）
-2. 用 Read 加载详设文档作为全局上下文
-   - 如果文档 ≤ 500 行：全文加载（不使用 offset/limit）
-   - 如果文档 > 500 行：仅加载各子任务 Source 中引用的章节（合并行号范围，去重后按 offset/limit 加载）
-   - 这样避免大型详设文档一次性消耗过多 token
-
-> 注：整文件模式尽量加载完整详设（给全局视角），但对超长文档降级为章节加载。单任务模式始终只加载引用章节。
-
-### 3. 构建执行计划
-
-按依赖关系拓扑排序：
-1. 筛选所有 `draft` 状态的子任务
-2. 按依赖关系排序：先无依赖的，再逐层解锁
-3. 逐个检查 Notes 前置条件
-
-输出执行计划：
-```
-执行计划（共 N 个可激活子任务）：
-
-批次 1（可并行）：
-  - TASK-001: xxx
-  - TASK-003: xxx
-
-批次 2（依赖批次 1）：
-  - TASK-002: xxx (依赖 TASK-001)
-
-跳过（前置条件未满足）：
-  - TASK-004: #NOTES 未解决
-  - TASK-005: 依赖 TASK-004 (blocked)
-
-开始执行（批次内默认并行派发子 agent，预检失败自动回退串行）...
-```
-
-### 4. 执行批次
-
-对每个批次执行；批次内仅 1 个 TASK、传入 `--serial`、或并行预检失败时，走 4.6 串行回退。
-
-#### 4.1 并行预检与 worktree 准备
-
-```bash
-python3 .code-flow/scripts/cf_task_parallel.py prepare --root "$PWD" \
-  --task-file "<任务文件相对路径>" --tasks TASK-001,TASK-003 --json
-```
-
-- 返回 `{"ok": true, "run_id": ..., "worktrees": [...]}` 才可并行；`ok: false` 时打印 `code`/`message` 并回退串行，禁止手工建 worktree/分支。
-- 预检内容：git 仓库、`.code-flow/.gitignore` 含 `worktrees/`、主 worktree 无 active marker、tracked 工作区干净。命令会自动提交仅位于当前需求目录内的流程产物（任务文件等）；需求目录以外存在未提交改动时拒绝并行，提示用户先提交或收起。
-
-#### 4.2 派发子 agent（平台自适应）
-
-若当前平台提供子 agent/Task 派发能力，为本批次每个 TASK 各派发一个子 agent（同一批并发不超过 3，超出时按 TASK 顺序拆成多轮）。子 agent prompt 必须包含 worktree 绝对路径、TASK-ID、任务文件相对路径，并声明以下硬性要求：
-
-1. 进入 worktree：所有命令 `cd <worktree>` 执行，文件读写使用该 worktree 内路径。
-2. 按本命令"单任务模式"步骤 1-4 完成该 TASK：`cf_spec_context.py start` → functional RED → 实现 → functional GREEN（E2E 只登记）→ `cf_task_workflow.py finish --root "<worktree>"`。
-3. 平台 hook 注入绑定主工作区；子 agent 必须显式读取 Spec Session（`.code-flow/specs/_session/task-*.md`）与详设章节，不得依赖自动注入。
-4. 完成时在 worktree 内提交全部改动（含任务文件 Checklist/Evidence/Status 更新），提交信息 `cf-task(<TASK-ID>): <标题>`。
-5. 返回摘要：TASK-ID、Status、验收命令及结果、提交 SHA、遗留问题。
-
-标准 worker prompt 模板（替换占位符后派发）：
-
-```
-你在隔离 worktree 中执行 <TASK-ID>：<worktree 绝对路径>。
-1) cd 到 worktree；先读 Spec Session（.code-flow/specs/_session/task-<name>.md）、任务文件的当前 TASK 段落与 design 来源章节；
-2) cf_spec_context.py start → 写验收测试记录 RED → 实现 → GREEN；
-3) 运行 cf_task_workflow.py finish --root "$PWD" --task <TASK-ID> --json；decision=pass 后【再】提交全部改动（含 finish 回写的 Evidence/状态）：git add -A && git commit -m "cf-task(<TASK-ID>): <标题>"；
-4) 返回摘要：TASK-ID、Status、验收命令与结果、commit SHA、遗留问题。
-```
-
-> 提交必须在 finish 之后：finish 通过后会回写 Evidence/状态；collect 默认会自动提交这些回写，但显式提交更清晰。
-
-子 agent 中断（取消/超时）时不要重新 prepare：检查该 worktree 的 `git status`、`git log <base>..HEAD` 与 marker——
-- 无改动且无 marker：直接接管，按单任务模式继续；
-- 有未提交改动或已有提交但未 done：在 worktree 内接管收尾（补实现/测试并 finish），再走 4.3 collect；
-- 已 done 且 marker 已清理：直接进入 4.3。
-
-平台不支持子 agent 时，不建 worktree，直接走 4.6 串行回退。
-
-#### 4.3 收集与校验
-
-```bash
-python3 .code-flow/scripts/cf_task_parallel.py collect --root "$PWD" --run-id <run_id> --json
-```
-
-- 每个任务必须 `ok: true`（改动已提交、Status 为 done/verified、marker 已清理、有提交）。
-- `collect` 在任务 done/verified 且 marker 已清理后，会自动提交 finish 回写的 Evidence/状态（`--no-commit` 关闭并回到严格模式）；finish 之外的未提交改动仍应人工确认。
-- 任一任务失败：停止本批次，不合并；保留 worktree 并列出失败原因。修复后重跑 collect；确认放弃时执行 4.5 cleanup。
-
-#### 4.4 回并主分支
-
-按 TASK-ID 先后顺序逐个回并；先 rebase 再合并，让冲突只在任务自己的 worktree 内解决。
-
-1. 取主工作区当前分支名（主工作区执行 `git rev-parse --abbrev-ref HEAD`，记为 <主分支>），在任务 worktree 内对齐：
-
-```bash
-cd <worktree> && git rebase <主分支>
-```
-
-- rebase 冲突：读取冲突现场 + 本任务详设章节与 Acceptance Contract，合并双方意图（不是二选一）；无法调和（设计要求互斥）→ `git rebase --abort`，保留现场与分支，列出矛盾点叫停交用户决策，不得擅自删除一方实现。
-- rebase 成功后重跑该任务的 functional 验收命令（E2E 留给 verify-e2e）；失败则在 worktree 内修复并提交，再执行 4.3 collect 复核。
-
-2. 回到主工作区合并（此时应无冲突）：
-
-```bash
-git merge --no-ff -m "merge cf-task <TASK-ID>" <branch>
-```
-
-- 仍出现冲突（主区期间有新合并）：按双方意图解决并重跑双方 functional 验收；通过后提交 merge。
-- 状态文件冲突（`spec-context.yml` / 任务 md 的覆盖状态列 / `.acceptance-manifest.json`）按确定性优先级解决：覆盖状态列取并集（两边各自 verified 的行保留 verified）；`spec-context.yml` 取已包含全量规则证据的一侧；manifest 多数情况按行自动合并，冲突时以任务文件为准重建后重跑 functional 场景。解决后必须 `cf_spec_context.py refresh` 收敛 hash，并重跑合并双方的 functional 验收与 `cf_spec_gate --stage code --json`，通过后提交 merge。
-- 合并后验收失败：记录合并前 HEAD 并 `git reset --hard <合并前HEAD>`（分支与 worktree 原样保留），回到 4.2 让对应子 agent 修复后重新 collect / rebase / 合并。
-
-3. 全部任务合并完成后进入 4.5 清理。
-
-- E2E 验收留给 verify-e2e，不在本步骤执行。
-
-#### 4.5 清理
-
-```bash
-python3 .code-flow/scripts/cf_task_parallel.py cleanup --root "$PWD" --run-id <run_id> --json
-```
-
-清理 worktree；已合入的分支自动删除，未合入的保留供排查。worktree 存在未提交改动时 cleanup 会拒绝，先人工确认再决定处理方式。全部批次完成后进入步骤 5。
-
-#### 4.6 串行回退
-
-未启用并行、批次仅 1 个任务或预检失败时，对批次内可激活子任务执行单任务模式步骤 3-4（详设已在步骤 2 加载，无需重复读取），完成一个后再解锁下一个。
-
-### 5. 输出摘要与文档同步检查
-
-所有子任务执行完毕后：
-
-1. 输出执行摘要：
-
-```
-执行完成：
-  - 完成: TASK-001, TASK-003, TASK-002
-  - 跳过: TASK-004 (Notes 未解决)
-  - 剩余 draft: 1 个
-```
-
-2. 对本轮所有完成的子任务，统一执行一次文档同步检查（同单任务模式步骤 5），汇总输出建议：
-
-```
-Spec 同步提示:
-  本轮编码引入了以下变更，建议同步到规范:
-  - [<任务ID>] 新增 <模式描述> → <spec-path>/
-  - [<任务ID>] 新增 <文件路径> → <map-file>.md Module Map
-
-  运行 /cf-learn --map 可自动更新导航地图。
-```
-
-3. 若需求目录已无 `draft` / `in-progress` / `blocked` 子任务，提示：运行 `/cf-task:verify-e2e <需求目录>` 执行延迟的 E2E 终验。

package/src/adapters/claude/commands/cf-task/status.md

@@ -1,59 +0,0 @@
-# cf-task:status
-
-显示任务状态总览。
-
-## 输入
-
-- `/cf-task:status` — 显示所有活跃 task 文件的状态
-- `/cf-task:status <file>` — 显示指定文件的详细状态
-
-## 执行步骤
-
-### 1. 读取任务数据
-
-- 用 Glob 搜索 `.code-flow/tasks/**/*.md`，从结果中排除包含 `archived/` 的路径
-- 逐个 Read，提取每个 `## TASK-xxx` 的：ID、标题、Status、Priority、Depends、Checklist 完成度
-
-### 2. 输出总览表格
-
-```
-任务状态总览
-============
-
-📋 auth-module.md (来源: docs/auth-design.md)
-┌──────────┬──────────────────┬────────────┬──────┬──────────────┐
-│ ID       │ 标题             │ 状态       │ 优先 │ 进度         │
-├──────────┼──────────────────┼────────────┼──────┼──────────────┤
-│ TASK-001 │ 用户模型定义     │ done       │ P0   │ 3/3 [100%]   │
-│ TASK-002 │ 注册接口实现     │ in-progress│ P0   │ 1/4 [25%]    │
-│ TASK-003 │ JWT 工具函数     │ draft      │ P1   │ 0/2 [0%]     │
-│ TASK-004 │ 登录接口实现     │ blocked    │ P0   │ 0/3 [0%]     │
-└──────────┴──────────────────┴────────────┴──────┴──────────────┘
-汇总: 4 个子任务 | done: 1 | in-progress: 1 | draft: 1 | blocked: 1
-整体完成度: 25%
-
-📋 payment-api.md (来源: docs/payment-design.md)
-...
-
-═══════════════════════════
-全局汇总: 2 个文件, 8 个子任务
-  done: 3 | in-progress: 2 | draft: 2 | blocked: 1
-```
-
-### 3. 阻塞详情
-
-如果存在 blocked 子任务，额外输出：
-
-```
-⚠ 阻塞任务:
-  - auth-module/TASK-004: [BLOCKED] 等待第三方 SDK 文档
-  - auth-module/TASK-004: [NOTE-2] 接口签名需与前端对齐
-```
-
-### 4. 指定文件模式
-
-当指定 `<file>` 时，输出该文件的详细信息，包括：
-- 完整的子任务表格
-- 每个子任务的 Checklist 明细
-- 未解决的 Notes 列表
-- 依赖关系简图

package/src/adapters/claude/commands/cf-task/verify-e2e.md

@@ -1,115 +0,0 @@
----
-description: Execute deferred E2E scenarios after all functional tests pass
-globs: []
----
-
-# cf-task:verify-e2e
-
-执行需求目录下被延迟的 E2E 验收场景。
-
-## 使用场景
-
-本命令是**需求级终验**入口，在所有子任务的 functional 测试通过后统一执行：
-
-1. **review 层 verifier**：绑定规范中 `stage: review` 的 required verifier（e2e/acceptance/构建等重型验证）。遍历需求目录全部 task context，按 spec/rule 去重执行一次，证据写回全部相关 context；输出 `executed` / `reused` / `failed` 计数。
-2. **E2E 验收场景**：依赖外部环境（数据库、API、浏览器等）、编码阶段标记 `e2e_deferred` 的场景。
-
-失败不写 verified、不反转已 done 的任务状态；归档前必须 `decision=pass`。未声明 review verifier 且无 E2E 场景时为空操作（`reason=nothing_to_verify`）。
-
-## 调用方式
-
-```
-/cf-task:verify-e2e <需求目录>
-```
-
-## 执行步骤
-
-### 1. 检查前置条件
-
-确认需求目录下所有子任务状态为 `done`（实现完成）或 `verified`（终验已闭环）：
-
-```bash
-rg "^- \*\*Status\*\*:" <需求目录>/*.md
-```
-
-如有 `in-progress` 或 `blocked` 任务，提示用户先完成。
-
-### 2. 检查环境依赖
-
-读取 `.acceptance-manifest.json` 中的 E2E 场景，提取所需的外部依赖（从 `boundary` 字段推断）：
-
-- `HTTP API` → 提示确认 API 服务运行中
-- `Browser` → 提示确认浏览器驱动已安装
-- `Database` → 提示确认测试数据库可访问
-
-显示清单并询问：
-
-```
-E2E 场景需要以下环境：
-  - 本地 API 服务 (http://localhost:3000)
-  - PostgreSQL 测试数据库
-  - Chrome WebDriver
-
-环境已就绪？(y/N)
-```
-
-### 3. 执行 E2E 场景
-
-用户确认后，执行：
-
-```bash
-python3 .code-flow/scripts/cf_task_workflow.py verify-e2e \
-  --task-dir "<需求目录>" --root "$PWD" --json
-```
-
-该入口重新检查所有 TASK、锁定 manifest 和 functional/manual 最新证据，内部以 `--only-e2e` 调用 runner；只有全通过才把任务提升为 verified。不得手动改状态。
-
-### 4. 报告结果
-
-解析执行结果：
-
-```json
-{
-  "decision": "block",
-  "results": [
-    {"id": "E-01", "kind": "e2e", "status": "passed"},
-    {"id": "E-02", "kind": "e2e", "status": "failed", "exit_code": 1}
-  ]
-}
-```
-
-- `decision=pass`：所有 E2E 场景通过，提示"E2E 验收完成"
-- `decision=block`：有失败场景，列出失败的场景 ID 和错误信息
-
-### 5. 更新任务状态
-
-确认命令已将需求目录下所有任务 Status 更新为 `verified`，并保留原契约与运行历史。无需再次编辑状态。
-
-## 失败处理
-
-E2E 失败时：
-
-1. 显示失败场景的完整命令和退出码
-2. 提示查看 `.acceptance-manifest.json` 中的 `evidence` 字段
-3. 不自动修改任务状态，等待用户修复后重新执行
-
-## 示例
-
-```
-/cf-task:verify-e2e .code-flow/tasks/2026-03-15/auth-module
-
-> 检查子任务状态... 所有任务已完成
-> 
-> E2E 场景需要以下环境：
->   - 本地 API 服务 (http://localhost:3000)
->   - PostgreSQL 测试数据库 (postgresql://localhost:5432/test)
-> 
-> 环境已就绪？(y/N) y
-> 
-> 执行 E2E 场景...
->   ✓ E-01: 用户登录流程 (1.2s)
->   ✓ E-02: 权限验证链路 (0.8s)
-> 
-> E2E 验收完成！2/2 场景通过
-> 已更新任务状态为 verified
-```