To Task

每张卡说明一个完整需求范围，把实现判断留给后续实现过程。只整理需求材料、用户确认和当前适用 RULE 中已有的规则，不把经验、惯例、模板占位或代码现状补写成新规则；未明确的内容保持未决，不自行补全。

流程

1. 加载项目上下文

按项目知识协议使用相关 CONTEXT 与适用 RULE；已有知识足够时复用，知识不可用时说明缺口并继续。

2. 汇总需求来源

使用用户指定的需求来源；没有指定时，从当前对话和仓库中识别与本次需求直接相关的材料。来源可以是 PRD、API 清单、其他需求文档、截图或当前对话。

3. 切分需求

先从全部需求材料中识别角色或系统最终能够感知的业务结果，再围绕这些结果组织任务。文档章节、页面、接口、数据表和技术层次只是理解需求的线索，不直接决定任务边界。

放在同一张卡

共同形成一个业务结果的内容放在一起。例如，同一场景中的查询、操作、状态变化、失败反馈和内部触发，即使分散在 PRD 与 API 清单的不同章节，也可以由一张卡完整承接。

分成不同卡

当内容面向不同业务目标，或其中一个结果脱离另一个仍然能够独立说明和验收时，通常分别成卡。可以结合角色、触发场景、业务状态和最终结果判断，而不是根据改动文件多少判断。

以下迹象可用于校准边界：

• 一张卡需要并列描述多个互不相关的触发场景或最终结果，可能拆得过大。
• 一张卡只剩字段、接口、页面或技术层改动，离开其他卡便无法说明业务价值，可能拆得过碎。
• 多张卡反复描述同一操作和结果，只是分别对应不同接口，可能应当合并。

切分完成后，每项已确认需求都应当能在某张卡中找到归属；每张卡也应当能够独立说明要交付的业务结果。功能规则和验收标准只能来自已确认的需求来源，不为追求卡片完整而增加边界条件、异常处理、权限、状态或接口约束。

4. 写入任务卡

用户指定输出目录时直接使用；已有对应需求目录时在该目录下创建 tasks/。否则创建 docs/scratch/<下一个两位序号>-<中文需求名称>/tasks/。

任务文件使用 NN-<中文任务名称>.md，其中 NN 是从 01 开始的两位任务编号，仅用于标识文件，不表示依赖或实施顺序。

使用以下模板：

# <中文任务标题>

## 需求来源

<链接本卡使用的需求材料并指出相关部分；没有文档时简述需求来自当前对话。>

## 本次做什么

<用一段话概括本卡交付的业务结果；有明确处理过程时，继续使用有序列表写清。>

## 功能规则

1. **<规则主题>**：<会影响业务行为、数据口径、状态、权限或接口契约的规则>

<!-- 没有单独功能规则时删除本章节。 -->

## 验收标准

| 场景 | 操作 | 预期结果 |
| --- | --- | --- |
| <主流程或边界场景> | <用户操作或系统触发> | <可观察结果> |