@michaelxwb/code-flow 0.6.5 → 1.0.0

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

@@ -1,236 +0,0 @@
-# cf-task:note
-
-与用户协作讨论文件中的 `#NOTES` 标记，对齐最优解后将结论沉淀回原文，删除标记。
-
-支持两种文件类型：
-- **任务文件**（`.md`）：讨论任务中的实现细节问题
-- **设计简报**（`.design.md`）：讨论设计方案中的缺陷或待确认项
-
-## 背景
-
-用户在 review 文件时，直接在有问题的位置**就地标注** `#NOTES`，格式：
-
-任务文件中：
-```markdown
-### Checklist
-- [ ] 实现用户注册接口
-- [ ] 密码加密存储  #NOTES 用 bcrypt 还是 argon2？
-- [ ] 编写单元测试
-
-### Description
-实现 JWT 认证  #NOTES token 过期时间设多少合适？
-```
-
-设计简报中：
-```markdown
-## Database Design
-
-### users 表
-| Column | Type | Constraints | Notes |
-|--------|------|-------------|-------|
-| email | VARCHAR(255) | UNIQUE NOT NULL | 登录凭证 #NOTES 需要支持手机号登录吗？ |
-
-## API Design
-
-### POST /auth/register
-- Request: `{ email: string, password: string }`  #NOTES 需要用户名字段吗？
-```
-
-`#NOTES` 是临时讨论标记，解决后必须消失，结论直接融入原文。
-
-## 输入
-
-- `/cf-task:note <file>` — 讨论指定文件中所有 `#NOTES`
-- `/cf-task:note <file> TASK-001` — 只讨论指定子任务中的 `#NOTES`（仅限任务文件）
-
-其中 `<file>` 可省略日期目录前缀和 `.md` 后缀。
-
-查找逻辑：用 Glob 搜索 `.code-flow/tasks/**/<file>.md` 和 `.code-flow/tasks/**/<file>*.design.md`（`*` 兼容旧 `<file>.design.md` 与域后缀 `<file>.frontend.design.md` / `<file>.backend.design.md`），从结果中排除包含 `archived/` 的路径。如果匹配到多个结果（如全栈需求的前后端 design），输出警告列出所有匹配项，让用户指定要讨论的具体文件；如果只有一个结果，直接使用。
-
-## 执行步骤
-
-### 0. 判断文件类型
-
-Read 读取匹配到的文件后，判断类型：
-- 文件路径以 `.design.md` 结尾 → **设计简报模式**
-- 其他 → **任务文件模式**
-
----
-
-## 任务文件模式
-
-### 1. 扫描 #NOTES 标记
-
-1. 用 Glob 定位任务文件，Read 读取全文
-2. 用正则扫描所有包含 `#NOTES` 的行，记录：
-   - 所在的子任务（`## TASK-xxx`）
-   - 所在的段落（Description / Checklist / 其他）
-   - 原始行内容
-   - `#NOTES` 后的问题描述
-3. 如果没有找到 `#NOTES`，提示"无待讨论的标记"，结束
-
-输出扫描结果：
-```
-找到 3 个 #NOTES 标记:
-
-TASK-001:
-  1. [Checklist] 密码加密存储  #NOTES 用 bcrypt 还是 argon2？
-  2. [Description] 实现 JWT 认证  #NOTES token 过期时间设多少合适？
-
-TASK-002:
-  3. [Checklist] 调用支付 SDK  #NOTES 用哪个版本的 SDK？
-
-开始逐条讨论...
-```
-
-### 2. 加载上下文
-
-1. 读取当前子任务的 `Source` 字段，解析章节引用
-2. 用 Read 按行号范围读取详设文档的对应章节
-3. 将详设上下文作为讨论背景
-
-### 3. 逐条讨论
-
-对每个 `#NOTES`，展示上下文并给出建议方案，与用户对话：
-
-```
---- #NOTES 1/3 ---
-位置: TASK-001 / Checklist
-原文: 密码加密存储  #NOTES 用 bcrypt 还是 argon2？
-
-详设参考 (§3.1 L95-L98):
-  "用户密码必须加密存储，推荐使用行业标准算法"
-
-分析:
-  - bcrypt: 成熟稳定，生态支持好，Node.js 原生支持
-  - argon2: 更现代，抗 GPU 攻击更强，但依赖 C 编译
-
-建议: bcrypt（项目技术栈为 Node.js，无需额外编译依赖）
-
-是否采纳？或提出你的方案:
-```
-
-等待用户回应。
-
-### 4. 沉淀结论并清除标记
-
-用户确认方案后：
-
-1. 用 Edit 将该行中的 `#NOTES xxx` 删除，并将结论融入原文
-   - 修改前：`- [ ] 密码加密存储  #NOTES 用 bcrypt 还是 argon2？`
-   - 修改后：`- [ ] 密码使用 bcrypt 加密存储`
-2. 如果结论需要新增步骤 → 用 Edit 追加 Checklist 条目或补充 Description
-3. 在 `### Log` 追加：`- [<当前日期>] resolved #NOTES: <结论摘要>`
-
-**Edit 边界约束（必须遵守）**：
-- `old_string` 必须严格限定在当前 TASK 段落内，**绝对禁止**匹配到 `---` 分隔线或下一个 `## TASK-xxx` 标题
-- Log 追加时，`old_string` 只匹配 Log 段落的最后一行内容，不要向下延伸到段落外
-- 如果 Log 是当前 TASK 的最后一个段落，其内容到 `---` 分隔线之前结束；`old_string` 不得包含 `---` 及其后的任何内容
-- 示例（正确）：`old_string = "- [2026-03-23] created (draft)"` → 只匹配 Log 末行
-- 示例（错误）：`old_string = "- [2026-03-23] created (draft)\n\n---\n\n## TASK-003"` → 越界，会删除下一个 TASK 标题
-
-### 5. 完成检查
-
-所有 `#NOTES` 讨论完毕后：
-
-1. 再次扫描文件，确认无残留 `#NOTES` 标记
-2. 如果子任务之前因 `#NOTES` 被标记为 `blocked`，清除当前阻塞条目后调用 `python3 .code-flow/scripts/cf_task_workflow.py resume --root "$PWD" --task-dir "<需求目录>" --task TASK-001 --json`。命令检查依赖和残留 Notes，同步 marker 与任务状态；不得从历史 Log 猜测状态后只改 Markdown。失败保留 blocked 并报告原因。
-3. 更新文件头 `Updated` 日期
-
-### 6. 输出摘要
-
-```
-#NOTES 讨论完成: auth-module
-
-已解决:
-  1. TASK-001 密码加密 → 使用 bcrypt
-  2. TASK-001 token 过期 → 设为 7 天，支持 refresh
-  3. TASK-002 SDK 版本 → 使用 v3.2.1
-
-文件已更新，所有 #NOTES 标记已清除。
-可执行 /cf-task:start auth-module 开始编码。
-```
-
----
-
-## 设计简报模式
-
-### 1. 扫描 #NOTES 标记
-
-1. Read 读取 `.design.md` 全文
-2. 用正则扫描所有包含 `#NOTES` 的行，记录：
-   - 所在的章节（`## Goal` / `## Database Design` / `## API Design` 等）
-   - 原始行内容
-   - `#NOTES` 后的问题描述
-3. 如果没有找到 `#NOTES`，提示"无待讨论的标记"，结束
-
-输出扫描结果：
-```
-找到 2 个 #NOTES 标记 (设计简报):
-
-[Database Design]:
-  1. email 字段  #NOTES 需要支持手机号登录吗？
-
-[API Design / POST /auth/register]:
-  2. Request schema  #NOTES 需要用户名字段吗？
-
-开始逐条讨论...
-```
-
-### 2. 加载上下文
-
-设计简报本身就是设计文档，无需加载外部 Source。上下文来自：
-
-1. 读取 `.design.md` 中该 `#NOTES` 所在章节的完整内容
-2. 扫描代码库中与该问题相关的现有实现（如 Glob 搜索现有 model/route/middleware）
-3. 将代码库上下文 + 设计文档上下文作为讨论背景
-
-### 3. 逐条讨论
-
-对每个 `#NOTES`，展示上下文并给出建议方案，与用户对话：
-
-```
---- #NOTES 1/2 ---
-位置: Database Design / users 表
-原文: email 字段  #NOTES 需要支持手机号登录吗？
-
-当前设计: users 表仅有 email 字段作为登录凭证
-代码库参考: 现有 User model 无手机号字段，mailer 模块仅支持邮件
-
-分析:
-  - 仅邮箱: 与现有 mailer 模块一致，MVP 足够
-  - 支持手机号: 需新增 phone 字段、SMS 服务依赖、双凭证登录逻辑
-
-建议: 仅邮箱（与 Non-goals 中"保持 MVP 精简"一致，手机号可后续迭代）
-
-是否采纳？或提出你的方案:
-```
-
-### 4. 沉淀结论并清除标记
-
-用户确认方案后：
-
-1. 用 Edit 将该行中的 `#NOTES xxx` 删除，并将结论融入原文
-   - 修改前：`| email | VARCHAR(255) | UNIQUE NOT NULL | 登录凭证 #NOTES 需要支持手机号登录吗？ |`
-   - 修改后：`| email | VARCHAR(255) | UNIQUE NOT NULL | 登录凭证（仅邮箱，手机号后续迭代） |`
-2. 如果结论影响其他章节（如 Database Design 的结论影响 API Design），同步更新相关章节
-
-### 5. 完成检查
-
-所有 `#NOTES` 讨论完毕后：
-
-1. 再次扫描文件，确认无残留 `#NOTES` 标记
-2. 无 Log 段落需更新（设计简报没有 Log）
-
-### 6. 输出摘要
-
-```
-#NOTES 讨论完成: user-auth.design.md
-
-已解决:
-  1. [Database Design] 登录凭证 → 仅邮箱，手机号后续迭代
-  2. [API Design] 注册接口 → 不加 username 字段，保持 email + password
-
-文件已更新，所有 #NOTES 标记已清除。
-可执行 /cf-task:plan .code-flow/tasks/2026-04-06/user-auth.design.md 拆解任务。
-```

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

@@ -1,363 +0,0 @@
-# cf-task:plan
-
-从设计文档或设计简报拆解需求，生成结构化任务文件。
-
-## 输入
-
-- `/cf-task:plan <设计文档路径>` — 指定文档路径
-- `/cf-task:plan` — 交互式选择（从 `docs/` 目录列出候选）
-- `/cf-task:plan <设计文档路径> --explore` — 仅输出分析报告，不生成文件
-- `/cf-task:plan <设计文档路径> --quick` — 跳过缺口分析，直接拆解（保持原有行为）
-- `/cf-task:plan <设计文档路径> --draft` — 仅生成任务草案，必须经过 `--verify-plan` 后才能启动
-- `/cf-task:plan <任务文件> --verify-plan` — 执行完整 Acceptance Coverage 与 Spec Rule 门禁
-- `/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.4.1. Draft / Verify Plan 模式
-
-`--draft` 只生成任务结构、依赖、Source 和初步验收映射，产物状态必须保持 `draft`，不得直接进入 `start`。用户确认拆分后执行 `--verify-plan`，完成全部场景覆盖、唯一 Rule owner、verifier、测试层级和真实边界校验；默认模式仍执行完整校验。
-
-`--verify-plan` 的执行命令为：
-
-```bash
-python3 .code-flow/scripts/cf_acceptance_manifest.py \
-  --verify-plan --task-dir <需求目录> --task-file <任务文件>
-```
-
-### 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 接口设计` 等（章节名须与模板真实标题一致）。
-
-**验收契约拆解（硬约束）**：
-
-1. 从全部 design 提取 P0/P1 的 S-/E-/B- 场景，以及 RULE 和高影响 RISK 到场景的映射。
-2. 优先沿用 design 指定的测试层级与关键真实边界。旧 design 未填写时，跨 API、存储、运行时生成、渲染或最终用户可见结果的场景推断为 `E2E`，局部模块协作推断为 `integration`，纯函数约束才可用 `unit`。
-3. 每个场景必须分配给一个负责的 TASK，并写入 `Acceptance-Refs`；同一场景可被多个任务引用，但必须有且仅有一个最终验收负责人。
-4. `manual` 只允许用于无法自动化的外部条件，必须记录原因并经用户明确确认。agent 不得把 design 的 E2E 自行降级为 unit/integration。
-5. Checklist 禁止使用泛化的“编写测试”。必须写成 `[场景ID][测试层级] + 真实边界 + 关键断言`，并为新功能/缺陷修复安排先写测试和 RED 记录。
-6. 如果场景缺测试层级、真实边界或 RULE/高影响 RISK 没有验证场景，先以 `#NOTES` 列为设计缺口；未解决前不得开始编码。
-
-**Spec 责任拆解（硬约束）**：
-
-1. 先执行 Context `refresh`，读取 Design `Spec Compliance Matrix` 与每个 design-stage/plan-stage Rule 的 `verifier_ref`，继承已有 applied refs，禁止重新选择或降级。
-2. 每条 plan-stage required Rule 必须有且仅有一个责任 TASK；该 TASK 的 `Spec-Refs` 写完整 `{spec-id}#{rule-ref}`，Checklist 写具体 verifier 命令/输入，Acceptance Contract 写测试层级、不得 Mock 的真实边界和关键断言。
-3. Rule 可被其他 TASK 引用为依赖，但 Acceptance Coverage 只能有一个最终负责人。E2E 层级**不得降级**；manual 仍仅限经用户确认的外部边界。
-4. 缺 `verifier_ref`、责任 TASK 为 0/多个、Checklist/Contract 不含 Rule-specific 验证责任时，任务文件只能保留为缺口草稿，不能启动。
-
-### 4. 生成任务文件方案
-
-将拆解结果按以下格式组织，展示给用户确认：
-
-```markdown
-# Tasks: <功能/模块名称>
-
-- **Source**: <设计文档或设计简报路径；多份 design 合并时填需求目录，或逗号分隔的多个 design 路径>
-- **Created**: <当前日期>
-- **Updated**: <当前日期>
-
-## Proposal
-
-<2-3 句话说明变更意图：为什么做这个变更？解决什么问题？期望达成什么效果？>
-
-这段由 AI 从设计文档中提炼生成，帮助编码阶段快速理解全局意图，而不必重读整篇详设。
-
-### Alignment
-
-（仅在执行了缺口分析时出现此子节）
-
-- **Scope**: <纳入和排除的范围>
-- **Decisions**:
-  - <决策 1>
-  - <决策 2>
-- **Non-goals**: <排除项>
-- **Acceptance**: <验收标准>
-
----
-
-## Acceptance Coverage
-
-| 场景ID | 来源设计 | 测试层级 | 关键真实边界 | 负责任务 | 状态 |
-|--------|---------|---------|-------------|---------|------|
-| S-01 | xxx.design.md#2.5 验收条件 | E2E | API → Store → Renderer | TASK-001 | planned |
-| E-01 | xxx.design.md#2.5 验收条件 | integration | Service → Store | TASK-001 | planned |
-
-> 本表必须覆盖 design 中全部 P0/P1 场景，以及 RULE/高影响 RISK 映射的场景；存在缺口时不生成可启动任务。
-
----
-
-## TASK-001: <子任务标题>
-
-- **Status**: draft
-- **Priority**: P0
-- **Depends**:
-- **Source**: docs/xxx.md#§3.1 数据模型(L83-L110)
-- **Spec-Refs**: product-rules#RULE-product-001
-- **Acceptance-Refs**: S-01, E-01, RULE-01
-
-### Description
-<从设计文档提取的需求重点，不必复制全文>
-
-### Checklist
-- [ ] <具体实现步骤1>
-- [ ] <具体实现步骤2>
-- [ ] [S-01][E2E] 编写 E2E 验收测试并登记可单独执行的命令（真实边界：API → Store → Renderer）；不在编码期执行 RED/GREEN，统一留给 verify-e2e
-- [ ] [S-01] 断言 <最终可观测结果 1> 与 <最终可观测结果 2>
-- [ ] [E-01][integration] 覆盖 <异常输入> 与 <可观测失败行为>
-- [ ] 运行验收命令并填写 Acceptance Evidence
-
-### Acceptance Contract
-
-| 场景ID | 测试层级 | 不得 Mock 的真实边界 | 关键断言 | 测试文件 / 用例 | 执行命令 | 状态 |
-|--------|---------|--------------------|---------|----------------|---------|------|
-| S-01 | E2E | API、Store、Renderer | <断言列表> | planned | planned | planned |
-| E-01 | integration | Service、Store | <断言列表> | planned | planned | planned |
-
-### Acceptance Evidence
-
-> `cf-task-start` 在编码期填写 functional/manual 的 RED/GREEN 结果、每个关键断言的位置和真实组件证据；E2E 仅登记测试与命令，执行统一留给 verify-e2e。全部 functional 状态 verified 后任务才可 done。
-
-### 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)
-  验收: S-01(E2E), E-01(integration)
-  描述: ...
-  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 写入
-
-写入后用 `bind --stage plan` 的 `applications` 将每条 required Rule 指向任务文件内唯一 TASK item，并执行：
-
-```bash
-python3 .code-flow/scripts/cf_spec_gate.py --task-dir <需求目录> --stage plan --artifact <任务文件> --json
-```
-
-通过 Plan Gate 后，锁定验收基线：
-
-```bash
-python3 .code-flow/scripts/cf_acceptance_manifest.py \
-  --task-file <任务文件> \
-  --output <需求目录>/.acceptance-manifest.json
-```
-
-Manifest 锁定场景 ID、来源、测试层级、真实边界和责任 TASK。编码阶段不得静默修改这些字段；如发生范围变化，必须重新执行 plan 验证。
-
-验收类型按测试层级归类：
-- `unit/integration` → `functional`（Done Gate 自动执行）
-- `E2E` → `e2e`（延迟至所有任务完成后，需 `--include-e2e` 显式执行）
-- `manual` → `manual`（用户手动验证，永不自动执行）
-
-E2E 场景依赖外部环境（数据库、API、浏览器），在编码阶段默认跳过（状态 `e2e_deferred`），不阻断 Done Gate。所有子任务完成后，执行：
-
-```bash
-python3 .code-flow/scripts/cf_acceptance_runner.py \
-  --manifest <需求目录>/.acceptance-manifest.json \
-  --root . \
-  --include-e2e \
-  --write-evidence
-```
-
-不得为了提速降低 design 指定的 E2E 层级。
-
-只有 Context Plan 状态与任务结构校验都 `decision=pass` 才输出 Start 下一步；缺唯一 owner、`verifier_ref`、测试层级或真实边界时必须回到拆解修复。
-
-### 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 个章节)
-- 验收覆盖: P0/P1 场景 x/x，RULE/高影响 RISK 映射 y/y，E2E 场景 z 个
-
-建议执行顺序:
-  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
-```