split-into-tasks

拆分为任务

阅读规格说明

要求存在 docs/specs/<slug>/spec.md；如果该文件缺失，则在提出任务前停止。

阅读规格说明和当前代码，以及相关的项目决策、术语表条目和已批准的原型（如有）。将缺失的实现视为目标差距。若已确定的来源之间存在冲突，则暂停并明确提出需要解决的具体决策。当已批准的行为构成一个连贯的用户工作流时，仅将规格说明作为交接内容；该工作流中的不同操作或状态不构成任务边界。

提出完整的结果映射

对于包含多个可独立交付结果的工作，起草完整且浅层的映射，尽量采用数量最少、可独立使用和验证的结果。除非前置工作本身可独立交付，否则应将其合并到第一个能让该工作发挥作用的结果中。仅声明确实会阻碍依赖结果的阻塞项。

涵盖规格说明中的每项结果。对每个拟议任务，展示其标题、交付的行为、可观察的验收标准、针对性且确定性的验证、任务专属约束、附理由的阻塞项，以及任何评审检查点。实现阶段应根据当时的最新代码库，及时推导当前结果的技术方案，因此省略对文件、函数、代码结构、技术层步骤、上下文边界和内部顺序的预测。在任务的约束中，仅记录适用于该任务的参考资料：该任务要交付的已批准原型屏幕和状态，以及该任务依赖的决策约定。说明每项参考资料的规范范围，并将规则和屏幕构成留在原始资料中。

仅当重大错误可能通过大量依赖工作不断累积，或确定性检查无法充分判定某项重大风险（例如安全、数据、权限、迁移、恢复或外部约定）时，才添加中间评审检查点。明确其累计范围和具体风险。一个检查点仅提供对该范围的一次评审，不会反复评审直至不再发现问题。实现阶段负责对整个差异进行唯一一次最终评审。

展示完整提案，并持续迭代，直至用户批准。批准前不要编写任务文件。

编写已批准的交接内容

获批后，将已确定的共享约束记录在规格说明中，仅将任务专属约束记录在任务文件中。不要臆造尚未确定的行为。

根据 templates/task.md，将每项已批准的任务写入 docs/specs/<slug>/tasks/<NN>-<slug>.md，并确保阻塞项位于依赖项之前。对于已批准的修订，删除从未记录完成情况、且已被替换的任务。若某任务有记录在案的完成历史，即使其后来状态变为 in-progress 或 blocked，也应予以保留；在将其仍需履行的义务和阻塞项引用转移到已批准的替代任务后，将其状态设为 superseded，并附上说明替代任务和原因的修订证据。对于该次已批准的任务拆分，superseded 任务为终态，属于非活动的恢复历史，不属于当前交付映射。不要创建归档。在写完当前任务交接内容后立即结束，不要开始实现。