zuozh11 To Task
每张卡说明一个完整需求范围，把实现判断留给后续实现过程。只整理需求材料、用户确认和当前适用 RULE 中已有的规则，不把经验、惯例、模板占位或代码现状补写成新规则；未明确的内容保持未决，不自行补全。
流程
1. 加载项目上下文
按项目知识协议使用相关 CONTEXT 与适用 RULE；已有知识足够时复用，知识不可用时说明缺口并继续。
2. 汇总需求来源
使用用户指定的需求来源；没有指定时，从当前对话和仓库中识别与本次需求直接相关的材料。来源可以是 PRD、API 清单、其他需求文档、截图或当前对话。
3. 切分需求
先从全部需求材料中识别角色或系统最终能够感知的业务结果，再围绕这些结果组织任务。文档章节、页面、接口、数据表和技术层次只是理解需求的线索，不直接决定任务边界。
放在同一张卡
共同形成一个业务结果的内容放在一起。例如，同一场景中的查询、操作、状态变化、失败反馈和内部触发，即使分散在 PRD 与 API 清单的不同章节，也可以由一张卡完整承接。
分成不同卡
当内容面向不同业务目标，或其中一个结果脱离另一个仍然能够独立说明和验收时，通常分别成卡。可以结合角色、触发场景、业务状态和最终结果判断，而不是根据改动文件多少判断。
以下迹象可用于校准边界：
- 一张卡需要并列描述多个互不相关的触发场景或最终结果，可能拆得过大。
- 一张卡只剩字段、接口、页面或技术层改动，离开其他卡便无法说明业务价值，可能拆得过碎。
- 多张卡反复描述同一操作和结果，只是分别对应不同接口，可能应当合并。
切分完成后，每项已确认需求都应当能在某张卡中找到归属；每张卡也应当能够独立说明要交付的业务结果。功能规则和验收标准只能来自已确认的需求来源，不为追求卡片完整而增加边界条件、异常处理、权限、状态或接口约束。
4. 写入任务卡
用户指定输出目录时直接使用；已有对应需求目录时在该目录下创建 tasks/。否则创建 docs/scratch/<下一个两位序号>-<中文需求名称>/tasks/。
任务文件使用 NN-<中文任务名称>.md，其中 NN 是从 01 开始的两位任务编号，仅用于标识文件，不表示依赖或实施顺序。
使用以下模板：
# <中文任务标题>
## 需求来源
<链接本卡使用的需求材料并指出相关部分；没有文档时简述需求来自当前对话。>
## 本次做什么
<用一段话概括本卡交付的业务结果；有明确处理过程时，继续使用有序列表写清。>
## 功能规则
1. **<规则主题>**：<会影响业务行为、数据口径、状态、权限或接口契约的规则>
<!-- 没有单独功能规则时删除本章节。 -->
## 验收标准
| 场景 | 操作 | 预期结果 |
| --- | --- | --- |
| <主流程或边界场景> | <用户操作或系统触发> | <可观察结果> |