unity-to-tasks

拆分为任务

将计划、规格说明或对话拆分为一组任务：每个任务都是一条纵向贯穿的示踪切片，并声明阻塞它的任务。

流程

1. 收集上下文

基于对话中已有的上下文开展工作。如果用户将规格说明路径作为参数传入，请获取该文件并阅读其完整正文和注释。

2. 探索代码库（可选）

如果你还没有探索代码库，请先了解代码当前状态。任务标题和描述应使用项目领域词汇表中的术语，并遵循你要修改部分的 ADR。

寻找提前重构代码的机会，以便让实现更容易。“先让改动变得容易，再进行容易的改动。”

3. 起草纵向切片

将工作拆分为示踪子弹任务。

• 每个切片都要贯穿各层（架构、API、UI、测试），形成一条范围狭窄但完整的路径；这是纵向切片，而不是针对单一层的横向切片
• 每个切片完成后都能独立演示或验证
• 每个切片的规模都应适合在一个全新的上下文窗口中完成
• 任何提前重构都应先完成

为每项任务标明其阻塞关系：必须先完成哪些其他任务，它才能开始。没有阻塞项的任务可以立即开始。

大范围重构是纵向切片的例外。大范围重构是指一项机械性改动（例如重命名列、重新定义共享符号类型），其影响范围遍及整个代码库，因此一次编辑就会导致成千上万个调用点同时出错，无法通过任何纵向切片保持绿色。不要强行把它拆成示踪子弹，而应按扩展–收缩的方式排序。首先扩展：在旧形式旁边增加新形式，确保不破坏现有内容。然后分批迁移调用点，每批的规模应与影响范围相称（按包、按目录）；每批作为一项独立任务，并依赖扩展阶段完成。由于旧形式仍然存在，各批次之间应保持 CI 通过。最后收缩：在所有调用方都迁移后，删除旧形式；这项任务依赖所有迁移批次。如果连每个批次都无法单独保持绿色，则仍按此顺序推进，但让这些批次共用一个集成分支，并全部依赖最后的集成与验证任务；只有在最后一步才能保证绿色。

4. 向用户确认

以编号列表的形式展示拟议的任务拆分。对每项任务，展示：

• 标题：简短、明确的名称
• 阻塞于：必须先完成的其他任务（如有）
• 交付内容：此任务实现的端到端行为

询问用户：

• 任务粒度是否合适？（太粗 / 太细）
• 阻塞关系是否正确：每项任务是否只依赖真正构成其前置条件的任务？
• 是否需要合并某些任务，或进一步拆分？

反复调整，直到用户批准任务拆分。

5. 创建任务

每项任务在 docs/<feature-slug>/tasks/<NN>-<slug>.md 下创建一个文件，按依赖顺序从 01 开始编号（先列阻塞任务）。使用以下单任务文件模板；每个文件仅包含一项任务，不要将多项任务合并到同一文件中。

执行前沿任务：所有阻塞项都已完成的任务。若是纯线性链条，则按从上到下的顺序执行。

：

构建内容： 从用户角度描述此任务实现的端到端行为，而不是逐层罗列实现内容。

阻塞于： 阻塞此任务的任务编号/标题，或“无（可立即开始）”。

• 验收标准 1
• 验收标准 2

避免使用具体文件路径或代码片段：它们很快就会过时。例外：如果原型产生的代码片段比文字更精确地表达了某项决策（状态机、归约器、架构、类型形状），可以将其内联，并简要说明该片段来自原型。只保留对决策有用的部分，不要附上可运行的演示，只保留重要内容。