@michaelxwb/code-flow 0.8.1 → 1.0.0

package/src/adapters/opencode/commands/cf-task/align.md

@@ -1,331 +0,0 @@
-# cf-task:align
-
-从需求出发，通过结构化对话产出设计简报（`.design.md`），为 `cf-task:plan` 提供足够丰富的输入。支持三种输入：纯文本需求、`.prd.md` 产品需求文档、`.design.md` 草稿。
-
-## Scenario-First（0.9）
-
-全栈用户场景统一写入 `<需求>.scenarios.md`，作为验收场景唯一源；design 文档只写实现逻辑并引用场景 ID。场景文件不存在时，新需求不得进入 plan。
-
-设计简报 frontmatter 写明实际选择的 `design_template: lite`、`full` 或 `frontend`。FEAT/API/NFR 定义与场景引用必须闭合；每个范围内功能关联验收场景。生成后执行 `code-flow design lint --file "<需求>.design.md" --scenarios-file "<需求>.scenarios.md" --json`，多份设计重复传 `--file`。按模板保留必填章节，不适用的可选章节按模板删除。
-
-场景区分浏览器 E2E 与 API/CLI 的 system/integration；capacity 可使用独立层级或 tags。expected 必须具体，并通过 expected_refs 关联步骤或已声明断言；延后场景保留原因、责任人及目标阶段。详细可执行格式见 `docs/acceptance-contract.md`。
-
-## 输入
-
-- `/cf-task:align "需求描述"` — 从需求描述新建设计简报
-- `/cf-task:align <.prd.md 路径>` — 基于已有 PRD 派生设计简报（推荐路径）
-- `/cf-task:align <.design.md 路径>` — 恢复已有草稿继续讨论
-- `/cf-task:align` — 交互式，先问用户要做什么
-
-## 执行步骤
-
-### 1. 确定模式
-
-按参数类型识别（顺序判断，优先匹配更具体的后缀）：
-
-| 参数形态 | 模式 | 行为 |
-|---------|------|------|
-| 已存在的 `.design.md` 文件 | **恢复模式** | Read 读取，展示当前内容，询问调整点，进入 Step 3 |
-| 已存在的 `.prd.md` 文件 | **PRD 派生模式** | Read PRD，执行 Step 2.6 预填充维度，Step 3 只补技术维度 |
-| 已存在的其他 `.md` 文件 | **新建模式（带上下文）** | Read 作为参考材料，进入 Step 2 |
-| 纯文本字符串 | **新建模式** | 以文本作为初始需求，进入 Step 2 |
-| 无参数 | **交互模式** | 询问"要实现什么功能？"，进入 Step 2 |
-
-### 2. 代码库上下文扫描
-
-快速了解项目现状，为后续建议提供依据：
-
-1. 用 Glob 检查 `.code-flow/specs/*/_map.md` 是否存在，若有则 Read 读取（了解项目结构）
-2. 检测技术栈：Read `package.json` / `requirements.txt` / `go.mod` / `pyproject.toml` 等（取存在的）
-3. 用 Glob 扫描与需求相关的现有代码目录，了解已有模式
-
-目的：**让后续建议基于实际代码库**，而非泛泛的通用建议。
-
-### 2.5. 识别需求类型，选择维度
-
-根据需求描述和代码库上下文，判断本次工作的性质，选择适用的讨论维度。
-
-**模板选择规则**：
-- **design-lite.md** — 后端/通用，简单：功能开发(简单) | CLI/脚本 | Bug修复 | 小型重构
-- **design-full.md** — 后端/通用，复杂：跨系统集成 | 性能优化 | 架构演进 | 中大型功能开发
-- **design-frontend.md** — 前端：页面/组件/交互/UI 功能开发
-
-**域识别（依 Step 2 代码库扫描自动判断，不需用户指定）**：
-- 涉前端（检测到 frontend 域 / `.tsx`·`.jsx`·`.vue`·`.svelte` 源码 / UI·组件·页面·样式类需求）→ 用 design-frontend.md 产出前端设计
-- 涉后端/通用 → 按复杂度用 design-lite / design-full（默认 lite，复杂或用户要求时 full）
-- **全栈需求** → 前后端各产出一份（见 Step 5 按域后缀命名）
-
-**模板路径**：
-- Lite: `.code-flow/specs/shared/design/design-lite.md`
-- Full: `.code-flow/specs/shared/design/design-full.md`
-- Frontend: `.code-flow/specs/shared/design/design-frontend.md`
-
-先读取对应模板文件作为生成基准。
-
-**核心维度（所有类型必选）**：
-- 目标与边界
-- 技术方案
-- 约束条件
-- 验收标准
-
-**扩展维度（按需选择，不适用则跳过）**：
-- 数据模型 — 涉及数据库/存储变更时
-- 接口设计 — 涉及 API / CLI / 函数入口变更时
-- 性能与容量 — 命中性能敏感信号时（写路径 / 高频调用 / 大数据量或列表查询 / 循环内 IO / 外部依赖 / 并发）
-
-常见需求类型与维度匹配：
-
-| 需求类型 | 数据模型 | 接口设计 | 技术方案侧重 |
-|----------|---------|---------|-------------|
-| 功能开发（含 API） | ✓ | ✓ API | 组件设计、第三方库选型 |
-| 功能开发（纯后台） | 视情况 | 视情况 | 模块结构、算法/流程、数据流 |
-| CLI 命令/脚本 | — | ✓ CLI | 命令结构、参数、输出格式 |
-| 重构 | — | — | 变更范围、迁移路径、兼容性 |
-| 性能优化 | — | — | 瓶颈分析、优化策略、度量指标 |
-| 定时任务/队列 | 视情况 | — | 调度策略、失败处理、幂等性 |
-| 日志/监控 | — | — | 采集点、指标定义、告警规则 |
-| 构建/CI | — | — | 流水线设计、触发条件、产物 |
-| 缺陷修复 | 视情况 | 视情况 | 根因分析、修复方案、回归范围 |
-
-> 上表仅供参考，AI 应根据实际需求灵活判断，不机械套用。
-
-### 2.6. PRD 派生处理（仅 PRD 派生模式）
-
-从 PRD 各章节提取结构化信息，映射到设计维度作为 Step 3 的预填充上下文：
-
-| PRD 章节 | 映射到设计维度 | 处理方式 |
-|---------|--------------|---------|
-| §2 背景与目标 | 目标与边界（问题/目标） | 直接继承 |
-| §3 用户与场景（含 US-XX） | 目标与边界（用户） | 继承用户画像；US 列表用于 FEAT 追溯 |
-| §4 功能需求（FEAT-XX） | 功能方案（FEAT 清单） | 继承 FEAT 清单与优先级；保留 US→FEAT 来源映射 |
-| §5 非功能需求 | 约束条件（性能/安全/兼容） | 直接继承 |
-| §6 范围与边界 | 目标与边界（In/Out Scope） | 直接继承 |
-| §7 依赖与风险 | 风险与依赖 | 直接继承 |
-
-**需向用户呈现的摘要**：
-```
-已从 PRD 解析：
-  - 功能 N 个（P0: X, P1: Y）
-  - 用户故事 M 个
-  - 非功能约束 K 条
-  - 范围内/外清单已继承
-
-本轮将聚焦技术维度：数据模型 / 接口设计 / 技术方案
-PRD 已覆盖的维度如无需调整，将直接使用。
-```
-
-**关键约束**：
-- Step 3 中已从 PRD 获得充分信息的维度**不重复提问**，除非用户主动修改
-- design 中 FEAT 的"来源"列必须引用 PRD 中对应的 US-XX
-
-### 2.7. 继承并刷新 Spec Context（硬门禁）
-
-进入技术讨论前先定位需求目录中的 `spec-context.yml`：
-
-1. PRD 派生/恢复模式必须执行 `code-flow spec refresh --task-dir <需求目录> --root "$PWD" --json`；missing/stale/conflict 必须先处理。
-2. 已有 binding 必须从 PRD Context 原样继承，**不得重新选择**、降级 enforcement 或清空 PRD 阶段 refs/decision/evidence。根据预计实现路径运行 `catalog --stage design`，只对新增 design-stage 候选做增量 bind，并记录 reason。
-3. 为每条 design-stage required Rule 预建 `Spec Compliance Matrix` 行：`Spec/Rule`、enforcement、设计影响、具体设计落点、验证场景/verifier、状态或 N/A 理由。
-4. required Rule 没有具体 heading/item 和验证方式时不得进入可评审状态；只写“遵循规范”无效。
-5. N/A/waiver 必须逐 Rule 请求用户确认并调用 `decision`；`batch` 必须为 false，Agent 不得代确认。无有效确认来源时 fail-closed。
-
-> 无 PRD 的新建模式也必须先 catalog/bind 并创建 Context，再写 Design；不能因为缺 PRD 跳过 Specs。
-
-### 3. 交互式细化
-
-围绕选中的维度逐步推进，**每轮提 2-3 个问题**（不要一次性抛 10 个问题）：
-
-**目标与边界**（必选；PRD 派生模式下已覆盖，只需用户确认）
-- 解决什么问题？为谁？
-- 做什么？（核心功能列表）
-- 不做什么？（明确排除项）
-
-**数据模型**（涉及数据库/存储变更时）
-- 需要哪些表/集合？
-- 字段、类型、约束、索引？
-- 与现有模型的关系？（外键、关联）
-- 性能敏感时：高频查询的索引、分页/游标、避免全表扫描、读写热点
-
-**接口设计**（涉及 API / CLI / 函数入口时）
-
-API 场景：
-- 哪些 endpoint？请求/响应格式？错误码？
-
-CLI 场景：
-- 命令名称和子命令？参数和 flag？输出格式？
-
-内部函数入口场景：
-- 公开接口签名？输入输出类型？错误处理约定？
-
-性能敏感时：批量接口优先于循环单调、分页/游标、避免 over-fetch、可缓存性
-
-**技术方案**（必选，内容随需求类型变化）
-- 性能敏感路径：正确性满足后按最优性能取向选型——算法/数据结构复杂度、IO/查询次数（杜绝 N+1）、能否批量/缓存/异步、同步阻塞点；记录所选方案的性能依据与放弃的较慢方案
-- 功能开发：关键组件、模块结构、第三方库选型、与现有架构集成方式
-- 重构：变更范围、分步迁移路径、向后兼容策略
-- 性能优化：瓶颈定位、优化策略、性能度量方式
-- 定时任务：调度策略、失败重试、幂等性保证
-- 日志/监控：采集点、指标定义、告警阈值
-- 构建/CI：流水线阶段、触发条件、产物和部署
-- 缺陷修复：根因分析、修复方案、回归测试范围
-
-**性能与容量**（命中性能敏感信号时；否则一句"无性能敏感点，跳过"）
-- 负载量级？（QPS / 数据规模 / 并发；有实测用数据，无则给量级估计，禁止编造）
-- 延迟 / 吞吐目标？热点路径在哪？
-- 潜在瓶颈与应对策略？（索引 / 分页 / 缓存 / 批量 / 异步 / 连接池 / 算法复杂度）
-- 选定方案为什么最优？放弃了哪个更慢的方案？
-
-**约束条件**（必选；PRD 派生模式下已从 NFR 继承）
-- 技术栈、性能要求、兼容性、时间线等
-
-**验收标准**（必选）
-- 怎么判断做完了？正常 / 异常场景各列至少一条
-- 可验证、可转为自动化测试断言的条件（明确输入与可观测输出）；场景 ID（S-/E-/B-）即测试用例来源
-- 为每个场景指定测试层级（unit / component / contract / integration / E2E / manual）和关键真实边界；按最低可覆盖层选择：UI/表单/布局用 component，DTO/错误码用 contract，鉴权/事务/模块边界用 integration，只有真实浏览器 + 真实后端 + 鉴权/DB 才能暴露的 P0/P1 关键旅程才用 E2E
-- ✅ CAS 冲突由 contract + component + 真实存储 integration 共同证明；聚合补零用数据 contract + component，关系绑定用真实存储 integration。Cookie 身份隔离和 SSE 恢复可保留对应关键 E2E。❌ 按用户可见结果机械增加 E2E 或用固定比例决定层级；描述独特故障、低层覆盖和剩余接线风险，由设计评审判断。
-- E2E 场景必须同时给出 `why_e2e`（低层为什么不够）、`trigger_paths`（哪些源码变化触发）和 `smoke`（是否发布冒烟）；缺少时不得进入 plan
-- RULE 与高影响 RISK 必须映射到至少一个 S/E/B 场景；manual 仅限无法自动化的外部条件，必须写明原因
-
-**妥协与技术债**（按需）
-- 本次有意接受的取舍或欠债？后续偿还设想？
-
-**交互原则**：
-- 基于 Step 2 扫描到的代码库上下文**提出具体默认建议**，而非空泛提问
-- **性能敏感路径上方案按最优性能设计**：择优于更低复杂度、更少 IO/查询、可批量/缓存/异步的方案，并记录"为什么更快、放弃了哪个更慢方案"；非敏感路径不过早优化
-- **初始需求、PRD 或参考材料中已明确的维度不重复提问**，只就缺失或模糊处发问
-- 每轮回答后更新理解，追问细节或推进到下一个维度
-- 涉及数据库和接口的维度**必须具体到表结构和请求/响应 schema**
-- 不涉及数据库和接口时，**不要强制展开这些维度**
-- PRD 派生模式下，已从 PRD 覆盖的维度不再提问；用户主动要求调整除外
-- 用户说"你定"或"随意"时，根据代码库上下文选择最合理的默认方案，明确告知用户采用了什么
-- 输出语言默认与用户需求语言保持一致；若用户未明确指定语言，默认使用中文生成完整设计简报（标题、正文、表头均为中文）
-- 仅当用户明确要求英文或项目已有强约定要求英文文档时，才输出英文；避免中英混杂
-
-**中断恢复**：在进入 Step 3 之前**提前确定文件路径**（Step 5 的命名与目录逻辑）。当任意两个维度已有实质内容时，立即写入草稿文件。后续每轮对话更新同一文件。这样即使会话中断，进度不会丢失。
-
-### 4. 基于模板生成设计简报
-
-选中的维度都有实质内容后，基于 Step 2.5 选择的模板文件生成设计简报。
-
-**操作步骤**：
-1. 用 Read 读取选定的模板文件（design-lite.md 或 design-full.md）
-2. 按照模板章节结构，将 Step 3 中收集的内容填入对应位置
-3. **只包含适用的章节**，模板中有但需求不涉及的章节跳过
-4. 用 `{}` 占位符替换为实际内容
-5. PRD 派生模式：功能清单的"来源"列填 PRD 中对应的 US-XX
-6. 生成 `Spec Compliance Matrix`，每条 required Rule 的验证场景必须引用 S-/E-/B- 或说明仅可人工验证的外部边界
-7. 展示生成的设计简报
-
-**章节映射**（Lite 模板，对应 `design-lite.md` 实际章节）：
-
-| 模板章节 | 内容来源 |
-|---------|---------|
-| 1. 文档控制 | 自动生成（修订历史 v0.1） |
-| 2.1 需求概述 | Step 3 的"目标与边界"（PRD 派生时继承自 PRD §2） |
-| 2.2 功能方案 | Step 3 的功能清单 + 字段约束（FEAT 继承自 PRD §4，"来源"列填 US-XX） |
-| 2.3 范围与边界 | Step 3 的 In/Out Scope（PRD 派生时继承自 PRD §6） |
-| 2.4 验收条件 | Step 3 的"验收标准"（正常/异常场景 + 非功能指标） |
-| 3.1 技术选型 | Step 3 的"技术方案"（语言/框架/数据库选型） |
-| 3.2 架构设计 | Step 3 的"技术方案"（分层与组件，按需） |
-| 3.3 接口设计 | Step 3 的"接口设计"（API/CLI/函数签名，按需） |
-| 3.4 性能与容量考量 | Step 3 的"性能与容量"（热点/瓶颈/策略/目标，按需） |
-| 4. 风险与依赖 | Step 3 的依赖与风险（PRD 派生时继承自 PRD §7） |
-
-**章节映射**（Full 模板，对应 `design-full.md` 实际章节）：
-
-| 模板章节 | 内容来源 |
-|---------|---------|
-| 1. 文档控制 | 自动生成 |
-| 2.1 需求概述 | PRD §2 模块/背景/核心目标 |
-| 2.2 痛点与价值 | PRD §2 + §3（目标用户、当前问题、业务影响、预期价值、US 清单） |
-| 2.3 功能方案 | Step 3 的功能清单 + 字段约束（FEAT 继承自 PRD §4，"来源"列填 US-XX） |
-| 2.4 范围与边界 | Step 3 的范围（继承自 PRD §6） |
-| 2.5 验收条件 | Step 3 的"验收标准"（业务规则 RULE + 场景 S/E/B + NFR） |
-| 3.1 方案选型 | Step 3 的"技术方案"（备选对比含性能预期权重 + 技术栈 + ADR 记录性能依据/被否决项） |
-| 3.2 架构设计 | Step 3 的"技术方案"（架构图 + 分层 + 外部依赖） |
-| 3.3 数据设计 | Step 3 的"数据模型"（表 + 索引 + ER + 容量） |
-| 3.4 接口设计 | Step 3 的"接口设计" |
-| 3.5 质量实现方案 | Step 3 的"约束条件 + 性能与容量"（性能设计含热点路径 + 可靠性/安全/可观测性落地） |
-| 4. 部署与运维 | 按需（发布回滚、监控告警、数据迁移） |
-| 5. 风险与依赖 | Step 3 的依赖与风险（继承自 PRD §7） |
-| 6. 需求追溯矩阵 | 自动生成（US→FEAT→API→TC 关联） |
-
-**章节映射（Frontend 模板，对应 `design-frontend.md` 实际章节）**：
-
-| 模板章节 | 内容来源 |
-|---------|---------|
-| 2.1–2.4 需求概述/功能方案/范围/验收 | Step 3 的目标/功能/范围 + 交互验收场景（S/E/B） |
-| 3.1 技术选型 | 框架 / 状态库 / 路由 / 样式方案 / 数据请求选型 |
-| 3.2 页面与路由结构 | 页面清单与路由层级 |
-| 3.3 组件设计 | 组件树 + 容器/展示分离 + 复用 |
-| 3.4 组件接口契约 | Props / Events |
-| 3.5 状态与数据流 | 状态划分 + 数据流 + services 数据获取层 |
-| 3.6 UI 状态 | loading / empty / error / success |
-| 3.7 样式方案 | 设计 token / 响应式 / 样式与逻辑分离 |
-
-**追溯硬约束（plan 拆解与质量门的基础）**：
-- 功能清单每个 FEAT 保留"来源"列（PRD 派生填 US-XX；无 PRD 填需求描述）
-- 接口（API/CLI/函数）与验收场景标注其实现 / 覆盖的 FEAT-XX
-- 每个验收场景写明测试层级、关键真实边界和最终可观测结果；编码阶段不得把 E2E 自行降级为 mock 后的 unit/integration 测试
-- 每个 RULE 与高影响 RISK 映射到 S/E/B 场景；只能手动验证时记录原因
-- Full 模板 §6 需求追溯矩阵必须闭合：US → FEAT → API → TC 不留断点，TC 引用 §2.5.2 场景 ID
-- 任一缺口（FEAT 无来源 / FEAT 无验收 / 场景无测试层级或真实边界 / RULE·RISK 无验证场景 / 矩阵断点）在展示时显式列出并提示补全
-
-展示后询问用户：**确认写入？可以调整任何部分。**
-
-### 5. 写入文件
-
-用户确认后：
-
-1. **确定需求名**：
-   - **PRD 派生模式**：继承 PRD 需求名（去 `.prd` 后缀）。例：`user-login-flow.prd.md` → `user-login-flow`
-   - **恢复模式**：保持原需求名
-   - **新建/交互模式**：从目标推导 kebab-case，如 `user-auth`
-2. **确定需求目录**：
-   - **PRD 派生模式**：使用 PRD 所在的需求目录 `.code-flow/tasks/<日期>/<需求>/`（PRD 与 design 同目录，便于 `cf-task:archive` 整目录归档）
-   - **恢复模式**：保持原目录
-   - **新建/交互模式**：按当前日期创建需求目录 `.code-flow/tasks/<YYYY-MM-DD>/<需求>/`；目录已存在且非本次草稿时目录名追加序号 `<需求>-2`…
-3. **按域后缀命名**（同一需求目录内）：
-   - 前端设计（design-frontend）→ `<需求>.frontend.design.md`
-   - 后端/通用设计（design-lite/full）→ 全栈时 `<需求>.backend.design.md`；纯后端/通用单域时 `<需求>.design.md`
-   - **全栈需求**：前后端各写一份到同一需求目录
-4. 用 Write 写入最终路径
-
-写入后，对 Matrix 每一行调用 `bind --stage design` 的 `applications` 回填 design artifact、`section_id`、稳定 `item_id` 和脚本计算的 hash；随后执行：
-
-```bash
-code-flow spec gate --task-dir <需求目录> --stage design --json
-```
-
-只有 Design Gate `decision=pass` 才能输出 Plan 下一步。缺 Matrix 行、artifact ref、验证方式、用户确认或发生 drift 时保留草稿并修复，不得推迟到 Coding/Done 才发现。
-
-### 6. 输出摘要
-
-```
-已生成设计简报: <完整路径>
-模板类型: Lite / Full
-来源: <PRD 派生 / 新建 / 恢复>
-
-内容:
-  - <按实际包含的章节列出>
-  - 验收标准: N 项
-  - 追溯自检: 每个 FEAT 有来源(US/需求)✓、有验收场景✓；每个场景有测试层级和关键真实边界✓；RULE/高影响 RISK 有验证场景✓；Full 模板 §6 矩阵闭合
-  - Spec Compliance: required Rules N/N 已落点；Design Gate: pass
-  - 性能自检: 标记性能敏感则方案须体现最优性能设计依据（§3.1/§3.5 或 lite §3.4），否则提示补全或显式声明"无性能敏感点"
-
-下一步:
-  - 审阅/编辑: 直接打开设计简报文件
-  - 标注问题: 在文件中添加 #NOTES，然后 /cf-task:note <name>.design
-  - 生成任务: /cf-task:plan <完整路径>
-```
-
-<!-- code-flow:runtime-commands start -->
-
-运行时命令示例（由命令契约生成；实际参数见各命令 --help）：
-
-```bash
-code-flow spec refresh --task-dir "<需求目录>" --root "$PWD" --json
-code-flow spec gate --help
-code-flow design lint --file "<需求>.design.md" --scenarios-file "<需求>.scenarios.md" --json
-```
-
-<!-- code-flow:runtime-commands end -->

package/src/adapters/opencode/commands/cf-task/archive.md

@@ -1,160 +0,0 @@
----
-description: 归档已完成的 task 文件
----
-
-
-# cf-task:archive
-
-归档已完成的整个 task 文件。归档前执行四维校验，归档后提示更新 specs。
-
-## 输入
-
-- `/cf-task:archive <需求目录或任务文件>` — 定位需求，通过运行时归档整个需求目录
-
-其中 `<file>` 可省略日期目录前缀和 `.md` 后缀。
-
-查找逻辑：用 Glob 搜索 `.code-flow/tasks/**/<file>.md`，从结果中排除包含 `archived/` 的路径。如果匹配到多个结果，输出警告列出所有匹配项，让用户指定完整路径；如果只有一个结果，直接使用。
-
-## 执行步骤
-
-### 1. 完成度检查
-
-1. 用 Read 读取匹配到的 task 文件
-2. 提取所有 `## TASK-xxx` 段落的 Status
-3. 若 active marker 指向本需求，读取其中真实 TASK ID；满足 finish 条件后先执行 `code-flow task finish --root "$PWD" --task-dir "<需求目录>" --task <实际TASK-ID> --json`。失败按原因修复，禁止手动改状态。
-4. 检查所有子任务均为 `done` 或 `verified`。`done` 由下一步需求级终验提升为 `verified`；其他状态不能归档。
-
-若有未完成子任务，拒绝归档并输出：
-
-```
-无法归档: 以下子任务未完成
-
-  - TASK-002: in-progress (进度 1/4)
-  - TASK-004: blocked ([BLOCKED] 等待 SDK)
-
-请先完成所有子任务后再归档。
-当前完成度: 2/4 (50%)
-```
-
-### 2. 归档前校验（Verify）
-
-**Spec Context / 终验与 Gate（先于四维校验）**：
-
-- 需求目录必须存在 `spec-context.yml`；执行 `code-flow spec refresh --task-dir <需求目录> --root "$PWD" --json`
-- 不单独运行 verify-e2e 或重复 Spec Gate：步骤 3 的 archive 一次执行 required verifier、项目 validators 和 acceptance，并在移动前校验证据与输入快照。
-- Context 与 Evidence 随需求目录一并归档，`_session` 仅是可重建投影，不是事实源
-
-先执行静态四维校验；运行结果在步骤 3 的 archive 返回后核对：
-
-**完整性**：
-- 所有 Checklist 项已勾选
-- 全文无残留的 `#NOTES` 标记
-
-**正确性**：
-- 步骤 3 核对 archive 返回的 `verify.layers.validators`：全量 validation（含 heavy）必须通过；失败按具体命令与输出修复后重跑 archive。
-- 失败时按具体 validator 的命令、输出和修复建议处理，再重跑终验；通过记录按内容指纹复用。
-
-**验收追溯**：
-- 来源 design 含结构化 S-/E-/B- 场景时，逐项对照 `## Acceptance Coverage`，P0/P1 场景以及 RULE/高影响 RISK 映射场景必须全部存在；步骤 3 终验后确认状态为 `verified`
-- 每个负责任务的 `Acceptance-Refs`、`Acceptance Contract`、`Acceptance Evidence` 必须闭合；待运行或待人工确认的条目由步骤 3 终验处理，成功后不得残留 `planned` / `pending` / `TBD`
-- 测试层级不得低于 design；E2E 的真实边界和关键断言必须有文件/用例位置与 fixture/构造证据
-- 步骤 3 核对 archive 返回的 `verify.layers.e2e` 与逐 check 证据：多 check 场景全部必要成员必须有效；缺失或失败时修复后重跑 archive。
-- `manual` 场景必须有用户确认和可复核记录。旧 design 没有结构化场景时注明“不适用”，不得伪造覆盖
-
-**一致性**：
-- 读取 task 文件的 `## Proposal`，对照实际代码变更，检查意图是否已实现
-
-校验结果输出：
-
-```
-归档前校验:
-  [PASS] 完整性: 所有 Checklist 已完成，无未解决 Notes
-  [PASS] 正确性: layers.validators 通过
-  [PASS] 验收追溯: 6/6 场景 verified，2 条 E2E 命令通过
-  [FAIL] 一致性: Proposal 要求"支持 OAuth 登录"，但缺少对应实现与验收证据
-```
-
-全部 PASS → 继续。FAIL → 列出具体缺口，修复后重新验证。只有涉及需求取舍或人工验收时请求用户确认。
-
-### 3. 执行归档
-
-**A. 需求目录布局**（任务文件位于 `.code-flow/tasks/<日期>/<需求>/<需求>.md`）——**整个需求目录一并归档**。先完成临时约束清理，再调用唯一移动入口：
-
-```bash
-code-flow task cleanup-session --task-dir "<需求目录>" --root "$PWD" --json
-code-flow task archive --task-dir "<需求目录>" --root "$PWD" --json
-```
-
-cleanup-session 逐任务删除 `specs/_session/task-<任务文件stem>.md` 投影，必须在源目录仍存在时执行。archive 内置 full verify；内容未变时复用有效证据，失败返回 `archive_verify_failed` 与具体 `verify` 结果，源目录保留。只有 `decision=pass` 才完成移动，目标路径使用返回的 `archived_to`，不得自行推算日期或同名后缀，不得手工 `mv` 绕过门禁。 返回 `manual_confirmation_required` 时，按 verify-e2e 的人工验收确认流程取得用户确认，执行 `confirm-manual` 后重跑 archive。
-
-**B. 旧扁平布局**（任务文件直接位于 `.code-flow/tasks/<日期>/<file>.md`）——保留向后兼容的文件查找。当前归档运行时以独立需求目录为边界；旧文件缺少该边界时，报告“先完成需求目录迁移”，保留原文件。不得把包含其他需求的日期目录作为 `--task-dir`，也不得逐文件归档绕过 Context、manifest 和 full verify。
-
-**归档后统一收尾（布局 A/B 都必须执行）**：
-
-1. 保存源日期目录为 `.code-flow/tasks/<日期>/`，完成移动后检查该目录是否还有其他需求或任务。
-2. 如果目录为空，必须执行安全删除；非空则保留并在摘要中列出剩余条目：
-   ```bash
-   source_date_dir=".code-flow/tasks/<日期>"
-   if [ -d "$source_date_dir" ] && [ -z "$(find "$source_date_dir" -mindepth 1 -maxdepth 1 -print -quit)" ]; then
-     rmdir "$source_date_dir"
-   fi
-   ```
-3. 复查归档目标存在、原任务/需求路径不存在；如果源日期目录仍存在但为空，视为归档未完成，立即删除后再继续。
-4. 源日期目录包含其他条目时不得删除，摘要明确写“保留（仍有 N 个条目）”。
-
-### 4. Spec 更新提示
-
-归档完成后，检查本次变更是否引入了新的规范约束需要同步到 specs：
-
-1. 读取 task 文件中所有子任务的 Description 和 Checklist
-2. 对照 `.code-flow/specs/` 下的现有规范
-3. 如果发现新增的模式或约束未被 specs 覆盖，提示用户：
-
-```
-Spec 同步建议:
-  本次变更引入了以下尚未记录的规范:
-  - 所有 API handler 增加了 rate limiting 中间件
-  - 新增 AppError 统一错误处理模式
-
-  建议更新:
-  - .code-flow/specs/backend/platform-rules.md — 补充 rate limiting 规则
-  - .code-flow/specs/backend/code-quality-performance.md — 补充错误处理模式
-
-  运行 /cf-learn 可自动扫描并补充。
-```
-
-如果无新规范需同步，跳过此步骤。
-
-### 5. 归档摘要
-
-需求目录布局（A）：
-```
-已归档需求目录: <需求>/ → <archived_to>
-  含: <需求>.prd.md、<需求>.frontend.design.md / <需求>.backend.design.md（按实际）、<需求>.md
-```
-
-旧扁平布局（B）尚未迁移时，报告原路径与缺少的需求边界，不输出“已归档”。
-
-```
-摘要:
-  - 来源: docs/xxx设计说明书.md
-  - 子任务数: N 个
-  - 创建日期: 2026-03-15
-  - 归档日期: 2026-03-20
-  - 历时: 5 天
-  - 校验: 4/4 PASS
-  - 源日期目录: 已删除（为空）/ 已保留（仍有 N 个条目）
-```
-
-<!-- code-flow:runtime-commands start -->
-
-运行时命令示例（由命令契约生成；实际参数见各命令 --help）：
-
-```bash
-code-flow spec refresh --task-dir "<需求目录>" --root "$PWD" --json
-code-flow task finish --task-dir "<需求目录>" --task TASK-001 --root "$PWD" --json
-code-flow task cleanup-session --help
-code-flow task archive --task-dir "<需求目录>" --root "$PWD" --json
-```
-
-<!-- code-flow:runtime-commands end -->

package/src/adapters/opencode/commands/cf-task/block.md

@@ -1,54 +0,0 @@
----
-description: 标记子任务为阻塞状态
----
-
-# cf-task:block
-
-
-> **命令面状态（0.8）**：alias — 等价于 `cf-task-status --block`；保留一个 minor，0.9.0 移除。
-
-标记子任务为阻塞状态。
-
-## 输入
-
-- `/cf-task:block <file> TASK-001 "阻塞原因"`
-
-其中 `<file>` 可省略日期目录前缀和 `.md` 后缀。
-
-查找逻辑：用 Glob 搜索 `.code-flow/tasks/**/<file>.md`，从结果中排除包含 `archived/` 的路径。如果匹配到多个结果，输出警告列出所有匹配项，让用户指定完整路径；如果只有一个结果，直接使用。
-
-## 执行步骤
-
-1. 用 Glob 定位任务文件，Read 读取
-2. 定位 `## TASK-001` 段落，检查当前 Status：
-   - `done` / `verified` → 拒绝：`TASK-001 已完成，无法标记阻塞`
-   - `blocked` → 提示：`TASK-001 已处于 blocked 状态`，仍追加新的阻塞原因
-   - `draft` / `in-progress` → 继续
-3. 调用统一 workflow service 入口（与 active block 同一状态机），不要先编辑状态或 marker：
-
-```bash
-code-flow task block --root "$PWD" --task-dir "<需求目录>" --task TASK-001 --reason "<阻塞原因>" --json
-```
-
-命令同时更新 Status、阻塞原因、Log、Updated 和匹配的 marker；无 marker 的 draft 任务只改变任务文档。仅在返回成功后确认阻塞；其他需求的 marker 不得改动。
-
-## 解除阻塞
-
-先解决 Notes 或外部依赖，再执行：
-
-```bash
-code-flow task resume --root "$PWD" --task-dir "<需求目录>" --task TASK-001 --json
-```
-
-resume 会检查未解决的 #NOTES 和依赖，原子同步任务与 marker。未激活的 blocked 任务恢复 draft；已有匹配 marker 的任务恢复 in-progress。失败时保留阻塞状态，不通过手动改 Status 绕过。
-
-<!-- code-flow:runtime-commands start -->
-
-运行时命令示例（由命令契约生成；实际参数见各命令 --help）：
-
-```bash
-code-flow task block --help
-code-flow task resume --help
-```
-
-<!-- code-flow:runtime-commands end -->

package/src/adapters/opencode/commands/cf-task/graph.md

@@ -1,97 +0,0 @@
----
-description: 可视化子任务依赖关系 DAG
----
-
-# cf-task:graph
-
-
-> **命令面状态（0.8）**：alias — 等价于 `cf-task-status --graph`；保留一个 minor，0.9.0 移除。
-
-可视化子任务的依赖关系 DAG，识别可并行执行的任务组。
-
-## 输入
-
-- `/cf-task:graph <file>` — 显示指定文件的依赖图
-- `/cf-task:graph` — 显示所有活跃 task 文件的依赖图
-
-其中 `<file>` 可省略日期目录前缀和 `.md` 后缀。
-
-查找逻辑：用 Glob 搜索 `.code-flow/tasks/**/<file>.md`，从结果中排除包含 `archived/` 的路径。如果匹配到多个结果，输出警告列出所有匹配项，让用户指定完整路径；如果只有一个结果，直接使用。
-
-## 执行步骤
-
-### 0. 程序计算（推荐）
-
-用 `code-flow task index --task-file <file> --dag --json` 直接输出拓扑批次与独立分组，不要全文手算。单 worktree 一次仅激活一个 TASK；批次内的独立任务由 cf-task:start 在各自 worktree 中并行派发子 agent（预检失败自动回退串行），详见 cf-task:start 步骤 4。
-
-`batches` 是组内可独立开发的拓扑批次；`dependency_components` 是依赖连通分组，只保证组与组之间独立，组内仍有先后依赖。`independent_groups` 仅为后者的兼容别名，不要把它显示成组内并行。
-
-### 1. 读取任务数据
-
-- 指定文件：Glob 定位后 Read
-- 全部文件：Glob `.code-flow/tasks/**/*.md`，从结果中排除包含 `archived/` 的路径，逐个 Read
-
-从每个 `## TASK-xxx` 段落提取：ID、标题、Status、Depends。
-
-### 2. 构建依赖 DAG
-
-按依赖关系构建有向无环图。检测循环依赖，若存在则报错。
-
-### 3. 输出可视化
-
-用 ASCII art 渲染 DAG，格式示例：
-
-```
-依赖关系图: auth-module
-
-Layer 0 (无依赖):
-  ┌──────────────────────┐   ┌──────────────────────┐
-  │ TASK-001 [draft]     │   │ TASK-003 [draft]     │
-  │ 用户模型定义         │   │ JWT 工具函数         │
-  └──────────┬───────────┘   └──────────┬───────────┘
-             │                          │
-             ▼                          │
-Layer 1:     │                          │
-  ┌──────────┴───────────┐              │
-  │ TASK-002 [draft]     │◄─────────────┘
-  │ 注册接口实现         │
-  └──────────┬───────────┘
-             │
-             ▼
-Layer 2:
-  ┌──────────┴───────────┐
-  │ TASK-004 [draft]     │
-  │ 登录接口实现         │
-  └──────────────────────┘
-
-可并行执行组:
-  - 组 1: TASK-001, TASK-003 (无依赖，可同时开始)
-  - 组 2: TASK-002 (需等待组 1 完成)
-  - 组 3: TASK-004 (需等待组 2 完成)
-
-建议执行顺序: TASK-001 → TASK-003 → TASK-002 → TASK-004
-关键路径: TASK-001 → TASK-002 → TASK-004
-```
-
-### 4. 状态标注
-
-按子任务状态标注：
-- `[draft]` — 待启动
-- `[in-progress]` — 进行中
-- `[done]` — 实现完成，E2E 可能仍待终验
-- `[verified]` — 终验完成
-- `[blocked]` — 被阻塞（附原因）
-
-### 5. 多文件模式
-
-当显示所有文件时，按文件分组输出，每个文件一个独立的 DAG。
-
-<!-- code-flow:runtime-commands start -->
-
-运行时命令示例（由命令契约生成；实际参数见各命令 --help）：
-
-```bash
-code-flow task index --help
-```
-
-<!-- code-flow:runtime-commands end -->