to-spec

转化为规范

将任务转化为一份统领实施的契约：必须修改什么、必须保持什么不变、选定的设计如何运作，以及如何验证结果。面向已掌握规范及其所列来源、但不了解本次对话的实施者撰写。交付规范，不要实施。

还原当前任务及其依据

每次调用或继续时，都要重新阅读任务、已确定的用户决策、仓库说明和研究来源。对于现有规范，要通读其完整当前文本及必要的关联部分，包括上次调用后所做的编辑。完整阅读所提供的反馈。利用记忆和旧报告定位来源，切勿据此还原来源当前的内容。

确认检出内容和源版本。检查 Git 状态、相关已提交变更、暂存和未暂存差异，以及未跟踪文件的内容；阅读支撑设计的实际文件。遵循指定的版本，不要混入其他状态。对于 Git 之外等效的当前来源，也要进行检查。工作树干净、HEAD 未变或脏文件列表未变，都不能证明先前的依据仍然成立。

从任务和用户说明中推导所需结果、允许的变更、必须保留的行为、排除项和未决决策。区分预期行为与已观察到的能力。较新的文档或评审建议本身既不会改变已确定的用户决策，也不会改变任务范围。仅将新的用户决策应用于其实际改变的内容，并保留其他约束。

对于路线图任务，重新打开统领任务、相关的早期和后续任务，以及它们关联的决策。确认哪些前置条件确实存在，以及哪些早期契约必须保留。明确后续任务将使用、扩展、替换或迁移哪些内容；这些要求对当前任务意味着什么；哪些工作和决策仍属于后续任务。遵循跨阶段的相关关系。不得根据后续任务的标题或未指定的未来设计臆造需求。对于独立任务，使用现有上下文，不要求必须有路线图或特定的准备技能。

在围绕任务的动因进行设计前，先核实其前提。根据实现、使用方、契约、测试、配置，以及必要时与版本相关的官方文档，检查所依据的既有研究事实。调查候选设计新引入的未知事实和依赖。复用仍然有效的研究，不要重复无关的调查。区分已核实事实、有依据的推断和未解决的假设。路线图复选框或提议的接口，并不能证明某项能力已经存在。

在既定边界内确定设计

根据所需行为、经验证的系统和约束，比较可行方案。选出并说明委托给此阶段的技术设计，包括有实际意义的替代方案及其权衡。明确保留给用户作出的选择和决定，始终以用户的决定为准。即使某个替代方案能保留目标和范围，实施过程中发现某项设计不可行，也不意味着可以擅自接管原本保留给用户的替代方案决策。

结合此前和后续任务的关联说明选择：解释某种方案是否保留了必需的契约、提供了后续任务所需的前置条件、阻碍了计划中的迁移，或重复了后续任务的工作。根据实际任务和证据说明这些影响。尊重已规划的替换，不要把今天的结构永久冻结。不要设计未来任务、提前实现其功能，也不要为假设的需求添加抽象。如果某条路线需要在本任务范围外开展工作，就寻找范围内的替代方案，或提出依赖及其影响。

自行查明可通过研究解决的事实。当目的、产品行为、范围、所有权、对尚未商定的重要风险的接受度，或保留给用户的设计选择需要用户决定时，每次只提出一个具体问题。提供证据和有用的选项；等待回答的同时，继续独立开展工作。如果无法获得证据，就指出缺失的事实以及因此无法作出的决定，不要猜测。

当前提不成立时，在展开设计之前重新审视所有依赖该前提的结论。必要时重做受影响的部分。如果任务的理由或边界不成立，就说明原因以及需要作出的决定；不要通过增加要求来弥补。将行为等效的局部编码选择留给实施者，但要解决那些会决定可观察行为或契约的选择。

构建可实现、可检查的契约

说明目的、所需结果、允许和排除的工作、需保留的行为、起始状态和前置条件、选定的设计、相关路线图约束，以及用户决策的实质。提供足够的理由，以区分有意选择和未解决的问题。

通过以下相互关联的部分，让每项任务义务都可追溯；布局应适合具体任务，而非强制采用固定文档模式：

• 行为： 定义输入、前置条件、可达分支、可观察结果、状态变更和副作用。说明调用方和下游使用者会观察到什么，包括操作无法完成时的情况。
• 集成： 明确组件职责并规定生产者和使用者契约：根据需要说明数据形状、验证、转换、持久化以及跨边界的身份信息。确认生产者能够提供使用者所需的内容。指出现有和拟议的位置，以及使各条路径可达的连接方式。
• 工作： 按依赖关系排列可实现的工作项，从一个连贯的切片开始，并覆盖完整结果。为每项工作列出其位置、前置条件、预期变更和检查方式。纳入必要的使用者、配置、数据和测试变更，但不要将清理工作或其他任务的职责并入其中。
• 验证： 将每项义务关联到一个可观察的检查，并说明设置、预期结果和观察点。既覆盖行为保留，也覆盖行为变更。依据需求和独立证据推导预期，而不只是依据选定设计本身的计算或清单。当示例本身可能让错误实现蒙混过关时，加入一个有区分度的反例。

沿生产者和使用者跟踪完整路径，包括使用变更后契约的替代入口。明确相关的拒绝和失败结果、缺失或无效输入、部分影响、重试、重复、并发以及可达情况下的恢复方式。指出哪些分支复用已经验证的现有行为，哪些需要新增工作。只有在此变更确有需要时，才纳入兼容性、迁移或发布计划。不要罗列不可能发生的情况，也不要为相邻功能臆造策略；遇到缺失的产品决策时，应向用户确认。普遍性声明的范围应限于证据和检查所覆盖的路径。

将所有实现关键规则写入规范，或写入明确链接且可访问的必需规范部分。用实际规则替换“如前所述”或“选项 B”之类的表述，定义任务专用术语，并在相关声明旁引用具体源码位置或文档章节及版本。确保所需的辅助资料无需访问会话即可查找。聊天记录、研究简报或审查报告可以解释某项选择，但不能成为其唯一的权威出处。区分计划中的验证和已执行的检查，并记录重要的环境限制。

在修订过程中保持规范的一致性

使用提供的目标位置或仓库中的规范位置。否则，先检查是否已有任务规范；若是新规范，则使用 specs/<task-slug>/spec.md。 优先使用一份文档；如果拆分有帮助，请从入口文档链接到所有必需部分。 每条规则都应有唯一的权威出处。修订时保留现有任务产物，除非用户要求另一个版本。

针对当前规范、任务和证据核查每条反馈。指出已解决或缺乏依据的问题，而不是自动采纳。 对于接受的修正，替换或删除错误规则，并更新其对行为、接口、示例、图表、有序工作项和验收的影响。 在前提改变后，重新评估依赖该前提的决定。保留有效要求，同时在上述约束范围内替换无效设计。

确保最终文档作为一份当前设计清晰易读。不要追加多轮评审内容、重复规则、推测性机制或例外，仅仅为了保留旧文本。确有遗漏时，可能需要补充细节；每项新增内容都必须服务于此任务。范围之外的改进仍应留在范围之外。每次用户决定得到落实后，都要重新检查整份文档中的相关要求。

宣布就绪前，核实已保存的交接材料

写入前，将目标位置的内容与已读取的版本进行比较，纳入兼容的新编辑，并依据具有约束力的决策解决重大冲突。保存并重新打开完整规范及所有必需部分。根据原始任务义务和路线图约束进行比较，而不只是检查你编写的工作清单：每项范围内义务都必须有一致的行为、归属、已排序的工作或经核实的复用方案，以及验收标准。保留明确排除项；不要为了让计划看起来完整而删去必需结果。 沿着边界检查相关的成功与失败路径，并从验收检查反向追溯预期结果。修正文案、示例、接口、图表和计划之间的冲突。

以新实施者的视角阅读：找出任何仍依赖对话记忆、无法访问的参考资料、臆测的契约或缺失决策之处。明确写出这些答案，同时保留合理的本地编码自由度。检查源代码位置和链接。将相关源内容（包括路线图决策和依赖项）与设计依据进行比较；在声称设计与该状态相符之前，若期间发生变更，应重新验证受影响的选择。

只有在整个任务都可执行，且不存在尚未解决的重大事实、行为、可行性问题或必需的用户决策时，才宣布就绪。说明为何任何遗留的不确定性都不会改变契约。部分草稿、中断的检查或有限范围的修订，都不足以证明整份规范已就绪。说明仍有哪些事项待解决，以及如何解决；之后还会进行评审，并不是留下已知缺口的理由。

返回已保存位置、所选方案、相关反馈的处理情况，以及就绪状态或阻塞项。报告实际执行过的检查，不要将计划中的测试说成已执行。除非用户的请求也授权进入下一阶段，否则请在此交付内容处结束。