@michaelxwb/code-flow 0.5.1

package/src/adapters/costrict/commands/cf-task/plan.md

@@ -0,0 +1,270 @@
+# cf-task:plan
+
+从设计文档或设计简报拆解需求，生成结构化任务文件。
+
+## 输入
+
+- `/cf-task:plan <设计文档路径>` — 指定文档路径
+- `/cf-task:plan` — 交互式选择（从 `docs/` 目录列出候选）
+- `/cf-task:plan <设计文档路径> --explore` — 仅输出分析报告，不生成文件
+- `/cf-task:plan <设计文档路径> --quick` — 跳过缺口分析，直接拆解（保持原有行为）
+- `/cf-task:plan <.design.md 路径>` — 从 cf-task:align 产出的设计简报拆解（自动跳过缺口分析）
+
+## 执行步骤
+
+### 1. 获取输入文件
+
+如果用户提供的是**需求目录**（`.code-flow/tasks/<日期>/<需求>/`）：用 Glob 搜索 `<目录>/*.design.md` 发现目录内**全部设计简报**（前端 + 后端可并存），逐个 Read，合并为本次拆解的输入；各子任务的 Source 指向其来源 design。
+
+如果用户提供的是单个文件路径：直接用 Read 读取。
+
+如果未提供路径：
+1. 用 Glob 搜索 `docs/**/*.md` 列出所有文档
+2. 用 Glob 搜索 `.code-flow/tasks/**/*.design.md` 列出设计简报（排除 `archived/`）
+3. 合并展示列表，让用户选择（同一需求目录的多份 design 可一起选）
+4. Read 读取选中的文件
+
+### 2. 判断输入类型
+
+读取文件后，判断输入类型以决定后续流程：
+
+**设计简报（`.design.md`）**：文件路径以 `.design.md` 结尾，且位于 `.code-flow/tasks/` 目录下。
+→ **先检查有无残留 `#NOTES` 标记**。若有，提示用户先执行 `/cf-task:note` 解决后再拆解，并列出待解决的 `#NOTES` 列表。用户可选择：继续（忽略 `#NOTES`）或中断去处理。
+→ 跳过章节索引和缺口分析，直接进入**步骤 3**拆解子任务。
+→ 从 §2 需求分析 / §3 技术设计（接口设计 / 数据设计）/ 验收条件 推导任务。
+→ Source 字段引用 design 文件的真实中文章节名（如 `<name>.design.md#3.4 接口设计`），无需行号索引；**多 design 合并时，各子任务 Source 标明其来源 design**（如 `<需求>.frontend.design.md#3.3 组件设计` / `<需求>.backend.design.md#3.4 接口设计`）。
+→ 多份 design 合并拆解为**一份**任务文件，写入该需求目录（见步骤 5）。
+
+**设计文档（其他 .md 文件）**：
+→ 继续**步骤 2.1**建立章节索引。
+
+### 2.1. 建立章节索引
+
+Read 设计文档后，**先扫描文档结构**，建立章节索引表：
+
+```
+章节索引:
+  §1 概述 (L1-L25)
+  §2 需求分析 (L26-L80)
+    §2.1 用户故事 (L28-L55)
+    §2.2 非功能需求 (L56-L80)
+  §3 详细设计 (L81-L200)
+    §3.1 数据模型 (L83-L110)
+    §3.2 API 接口 (L111-L155)
+    §3.3 业务逻辑 (L156-L200)
+  ...
+```
+
+此索引用于后续步骤中精确记录每个子任务的来源章节。
+
+### 2.5. Explore 模式（--explore）
+
+如果用户传入 `--explore`，在建立章节索引后，输出以下分析报告，**不生成任务文件**：
+
+```
+探索分析报告
+============
+
+文档: docs/xxx设计说明书.md
+章节数: N | 预估子任务数: M
+
+功能域识别:
+  - 用户认证 (§3.1-§3.3) — 核心功能，建议 P0
+  - 支付集成 (§3.4-§3.6) — 依赖第三方 SDK，存在阻塞风险
+  - 通知系统 (§3.7) — 独立模块，可并行
+
+关键依赖:
+  - §3.2 API 接口依赖 §3.1 数据模型
+  - §3.5 支付回调依赖 §3.4 订单模型
+
+风险点:
+  - §3.4 中提到的第三方 SDK 版本未确定
+  - §3.6 缺少错误码定义
+
+建议: 确认风险点后，运行 /cf-task:plan docs/xxx.md 生成任务文件
+```
+
+输出后结束，不进入后续步骤。
+
+### 2.7. 缺口分析（设计文档模式，--quick 跳过）
+
+> 仅当输入为设计文档（非 .design.md）且未传入 `--quick` 时执行。
+
+AI 从设计文档中识别关键缺口，输出结构化分析并与用户交互讨论：
+
+```
+缺口分析
+========
+文档: docs/auth-design.md
+章节数: 7
+
+1. 目标与非目标
+   目标: 注册、登录、JWT、token 刷新
+   非目标: 社交登录、2FA
+
+2. 范围边界
+   纳入: §3.1-§3.5
+   排除: §3.6 通知系统 (文档标注 Phase 2)
+
+3. 关键决策 (需确认)
+   ? §3.1 数据库: 文档提到 PostgreSQL，当前项目用 SQLite — 是否迁移？
+   ? §3.3 密码哈希: 文档说"行业标准"，未指定算法
+   ? §3.4 JWT 库: 文档未指定
+
+4. 风险与依赖
+   - §3.4 第三方 SDK 版本未确定
+
+5. 验收标准 (从文档推断)
+   - 用户可注册、登录、访问受保护资源
+   - 密码不以明文存储
+
+输入 'ok' 全部采纳 | 编号讨论具体项 | 'skip' 跳过
+```
+
+**交互方式**：
+- `ok` — 采纳所有默认判断，进入拆解
+- 编号（如 `3`）— 讨论具体编号的项，AI 给出分析和建议，用户确认
+- 自由文本 — 如 "保持 SQLite，§3.6 也做"
+- `skip` — 等效 `--quick`，跳过缺口分析直接拆解
+
+缺口分析中做出的决策记录在后续生成的任务文件 Proposal 的 `### Alignment` 子节中。
+
+### 3. 分析文档，拆解子任务
+
+阅读设计文档内容，按以下原则拆解：
+
+**拆解粒度**：
+- 每个子任务应是一个可独立编码和验证的原子单元
+- 一个子任务对应 1-3 个文件的修改
+- 预估编码时间 15-60 分钟
+
+**提取内容**：
+- 功能需求 → 子任务标题 + 描述（提炼重点，不必复制全文）
+- 实现要点 → Checklist 条目
+- 模块依赖 → Depends 字段
+- 紧急程度 → Priority（P0 核心功能 / P1 重要功能 / P2 优化项）
+
+**Source 字段引用**：
+
+设计文档模式：记录**具体章节和行号范围**。
+引用格式：`文件路径#章节标题(L起始-L结束)`，多个章节用逗号分隔。
+验证方法：记录引用后，用 Read 工具按行号范围回读验证，确保引用内容与子任务描述一致。如不一致，修正行号。
+
+设计简报模式：记录**章节名**，无需行号。
+引用格式：`<name>.design.md#3.3 数据设计`, `<name>.design.md#3.4 接口设计` 等（章节名须与模板真实标题一致）。
+
+### 4. 生成任务文件方案
+
+将拆解结果按以下格式组织，展示给用户确认：
+
+```markdown
+# Tasks: <功能/模块名称>
+
+- **Source**: <设计文档或设计简报路径；多份 design 合并时填需求目录，或逗号分隔的多个 design 路径>
+- **Created**: <当前日期>
+- **Updated**: <当前日期>
+
+## Proposal
+
+<2-3 句话说明变更意图：为什么做这个变更？解决什么问题？期望达成什么效果？>
+
+这段由 AI 从设计文档中提炼生成，帮助编码阶段快速理解全局意图，而不必重读整篇详设。
+
+### Alignment
+
+（仅在执行了缺口分析时出现此子节）
+
+- **Scope**: <纳入和排除的范围>
+- **Decisions**:
+  - <决策 1>
+  - <决策 2>
+- **Non-goals**: <排除项>
+- **Acceptance**: <验收标准>
+
+---
+
+## TASK-001: <子任务标题>
+
+- **Status**: draft
+- **Priority**: P0
+- **Depends**:
+- **Source**: docs/xxx.md#§3.1 数据模型(L83-L110)
+
+### Description
+<从设计文档提取的需求重点，不必复制全文>
+
+### Checklist
+- [ ] <具体实现步骤1>
+- [ ] <具体实现步骤2>
+- [ ] <编写测试>
+
+### Log
+- [<当前日期>] created (draft)
+
+---
+
+## TASK-002: <子任务标题>
+
+- **Status**: draft
+- **Priority**: P1
+- **Depends**: TASK-001
+- **Source**: docs/xxx.md#§3.2 API 接口(L111-L155), docs/xxx.md#§3.3 业务逻辑(L156-L180)
+
+### Description
+...
+```
+
+**展示格式**（供用户审阅）：
+
+```
+拆解结果（共 N 个子任务）：
+
+TASK-001: <标题> [P0]
+  来源: §3.1 数据模型 (L83-L110)
+  描述: ...
+  Checklist: N 项
+  依赖: 无
+
+TASK-002: <标题> [P1]
+  来源: §3.2 API 接口 (L111-L155), §3.3 业务逻辑 (L156-L180)
+  描述: ...
+  Checklist: N 项
+  依赖: TASK-001
+
+确认写入？可以调整：
+- 修改某个子任务的内容
+- 删除不需要的子任务
+- 合并过于细碎的子任务
+- 调整依赖关系和章节引用
+```
+
+等待用户确认或调整。
+
+### 5. 写入文件
+
+用户确认后：
+1. 文件名取需求名（kebab-case），如 `auth-module`；多份 design 合并产出**一份** `<需求>.md`
+2. 如果输入为需求目录或其中的 .design.md → 写入**该需求目录** `.code-flow/tasks/<日期>/<需求>/<需求>.md`
+3. 如果输入为 docs/ 设计文档（无需求目录）→ 按当前日期创建需求目录 `.code-flow/tasks/<YYYY-MM-DD>/<需求>/` 并写入其中
+4. 用 Write 写入
+
+### 6. 输出摘要
+
+```
+已生成任务文件: .code-flow/tasks/2026-03-15/auth-module.md
+- 子任务数: N
+- P0: x 个, P1: y 个, P2: z 个
+- 依赖链深度: N 层
+- 详设引用覆盖: §3.1, §3.2, §3.3, §3.5 (共 4 个章节)
+
+建议执行顺序:
+  1. TASK-001 (无依赖)
+  2. TASK-003 (无依赖) ← 可与 TASK-001 并行
+  3. TASK-002 (依赖: TASK-001)
+  ...
+
+下一步:
+  - 审阅任务: 直接阅读 .code-flow/tasks/2026-03-15/auth-module.md
+  - 添加批注: /cf-task:note auth-module TASK-001 "批注内容"
+  - 开始编码: /cf-task:start auth-module
+```

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

@@ -0,0 +1,138 @@
+# 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。
+
+### 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 的"依赖与风险"（按需） |
+
+**编号与追溯（硬约束，`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`
+
+**文件位置说明**：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」
+
+> 自检发现缺口（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/costrict/commands/cf-task/start.md

@@ -0,0 +1,173 @@
+# cf-task:start
+
+激活子任务并开始编码。支持单任务模式和整文件模式。
+
+## 输入
+
+- `/cf-task:start <file> TASK-001` — 激活指定文件中的单个子任务
+- `/cf-task:start <file>` — 激活文件内所有可执行的 draft 子任务
+
+其中 `<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` → 提示"任务已在进行中，继续编码"（不阻塞，直接跳到步骤 2）
+- `done` → 提示"任务已完成"，结束
+- `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`
+- 未满足 → 输出：`前置检查失败：以下依赖未完成\n- TASK-001: in-progress\n- TASK-003: draft`
+
+### 2. 加载详设上下文
+
+前置检查通过后，**编码前先加载关联的详设文档章节**：
+
+1. 读取子任务的 `Source` 字段，解析章节引用
+   - 格式：`docs/xxx.md#§3.1 数据模型(L83-L110)`
+   - 提取：文件路径 + 行号范围
+2. 用 Read 按行号范围读取详设文档的对应章节（使用 offset/limit 参数）
+3. 将读取的章节内容作为编码上下文，与 Checklist 一起指导实现
+
+示例：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. 用 Edit 更新子任务 Status 为 `in-progress`
+2. 在 `### Log` 追加：`- [<当前日期>] started (in-progress)`
+3. 更新文件头 `Updated` 日期
+4. 结合详设上下文 + Checklist，逐项执行编码工作
+5. 每完成一个 checklist 项 → 用 Edit 将 `- [ ]` 改为 `- [x]`
+
+### 3.5 会话级临时约束（FEAT-08）
+
+激活后，若任务文件头 Source 指向的 design 文档含验收条件章节（如 §2.5 验收条件 / 验收标准）：
+
+1. 提取该章节的场景与 RULE 约束，生成 `.code-flow/specs/_session/task-<name>.md`：
+   - frontmatter：`description: 当前任务 <name> 的验收约束（cf-task:start 生成，archive 清理）`
+   - 正文：验收场景与约束的精简列表（≤300 token）
+2. Spec Catalog 目录扫描自动纳入该文件，无需配置；编辑代码时的自动注入同样生效
+3. design 无验收章节时静默跳过；同名文件已存在则覆盖（同任务重复 start）
+
+> `_session/` 不入库（.gitignore 模板已覆盖）、不参与规范审计与预算。
+
+### 4. 自动完成
+
+当所有 checklist 项都勾选为 `[x]` 后：
+1. 用 Edit 更新 Status 为 `done`
+2. 在 `### Log` 追加：`- [<当前日期>] completed (done)`
+3. 更新文件头 `Updated` 日期
+4. 输出：`TASK-xxx 已完成`
+
+### 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)
+
+开始执行...
+```
+
+### 4. 按序执行
+
+对每个可激活的子任务，执行单任务模式的步骤 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 可自动更新导航地图。
+```

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

@@ -0,0 +1,59 @@
+# 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 列表
+- 依赖关系简图