to-tasks

转为任务

与当前协调者和直接仓库工具一起起草。此工作不需要完整模型预览或额外的工作者。调度设计或安全工作者之前，针对所需路由使用一次 shared/references/model-preview.md。嵌套工作使用父级不可变的已批准快照。

将一份已批准的 PRD 转为可执行队列。每个切片都足够小，可由一次专注的实现运行完成，并且有可检查的验收契约。

使用 shared/references/workflow-measurement.md 记录功能测量信息并调用捕获 API。保留每个阶段的执行日志和不可变计划。起草前，为 to-tasks 捕获 stage-start；捕获实际的队列审批等待；晋级后捕获 stage-end。任务与模型的合并响应算作一次观测等待。必需检查的身份确定后立即绑定；未知值保持缺失。

边界

接收状态为 approved 的 .ai-workflow/work/<feature-slug>/prd.md。每个规范的 tasks/T<N>-<slug>.md 仅写入一次，初始状态为 draft。将 tasks-draft.md 保留为精简的审批与依赖索引。审批会将这些相同文件晋级为 ready-for-agent，而不是创建第二份契约副本。任务字段、索引、审批绑定和旧版队列请阅读 references/task-contract.md。

起草前阅读 shared/references/workflow-stage-routing.md。一次性评估共享设计、安全、接口和验收决策。任务复用这些决策时，遵循 shared/references/planning-reuse.md 检查源修订版本，并根据共享结论与任务差异生成完整的关卡记录。每个切片仍须自行对设计风险和安全触发条件进行分类。仅对尚未解决或发生变化的边界应用 design-gate；与已确定决策一致的部分无需重复进行视角审查。已发布切片必须包含 shared/references/gate-result.md 中的规范关卡结果，包括发现和审查重点，且 verdict: proceed、decision_required: none。仅在确有测试设计决策时使用 test-lens，例如集成边界、模拟边界、并发情形或脆弱的现有测试。

不要直接调用单独的设计视角、评审面板、运行器或 models-consensus。如果结果包含 decision_required，或存在未获答复的重要要求，必须在任务审批前交由用户处理。如果用户明确希望征求更多意见，请引导其调用 models-consensus；该工具自身的工作流会在运行前向用户展示拟议席位以供审批。

规划请求默认仅进行任务审批。请求包含执行时，使用具体预览提供一次合并的任务与模型审批。如果用户要求合并任务与模型审批，则在请求用户一次性对这两项决策作出答复前，通过 implement-tasks 准备具体执行预览。仅任务审批绝不等同于模型审批。交付权限与评审委员会权限仍然彼此独立。

选择入口

对于一个已经接受且具有完整验收契约的任务，使用 shared/references/workflow-stage-routing.md 中的独立 implement-and-review 路径。不要为该路径另行编造 PRD 和队列。此技能用于分解已批准的 PRD。无论选择哪种入口，都不得绕过尚未解决的重要产品、安全、公共契约、数据或依赖决策、必需检查或独立审查。

工作

1. 确认 PRD 状态为 approved。草稿或未展开的计划应返回 to-prd。阅读相关代码，并确定能够验证每个切片的仓库命令。绝不要编造命令。

2. 起草纵向切片。每个切片都提供一条可观察的路径，贯穿所需层级。优先采用可独立验证的 tracer bullet。仅当行为保持不变的前置任务能消除共同阻塞项时，才将其置于首位，并记录其特征测试或可提供保障的现有测试套件。对于影响整个代码库的机械性更改，应使用扩展、迁移和收缩切片，而不是将其伪装成纵向切片。

3. 分配稳定 ID：T1、T2，依此类推。ID 一经分配便不得更改，因为审批会引用这些 ID。拆分时分配新 ID；删除时保留编号空缺；重排时保留现有 ID。依赖项必须引用已有 ID；依赖图决定执行顺序。通过共享队列控制器拒绝自我阻塞和循环依赖。仅当仍需人工授权或决策时，才将切片标记为 HITL。其他所有切片均标记为 AFK。

4. 为每份草案附上切片契约。

   1. 描述端到端行为，不含文件路径。
   2. 列出已验证的命令和可观察的验收行为。对于有状态的工作，根据其状态机推导有意义的失败序列，并纳入早期切片中的相关缺陷。指出哪些主机适配器需要真实的已存储值或集成检查；合成的成功路径测试夹具并不足够。功能切片必须注明行为。非功能切片可以写明 Test expectation: none; <reason>。绝不能为了让此契约通过而删除、跳过、弱化、缩小测试或验收检查，或通过模拟将其规避。若契约有误，应在审批前退回。
   3. 将每个设计界面与已敲定的共享决策对应，或通过 design-gate 评估尚未解决或已变更的边界。使用共享结论时，填写所有重复字段；任务中保留完整的规范 gate。审批前解决所有必须更改的问题。仅对存在阻塞性发现的检查维度重新检查，并保留其 ID、先前证据和解决方案。decision_required 非空时，必须暂停晋级，直到用户作出决定。
   4. 应用 security-gate，并将安全标记与匹配的触发条件一并保留。
   5. 仅当 test-lens 的结论解决了实际的测试设计选择时，才记录该结论。
   6. 分别说明回滚方案、审查重点、产品阻塞项和写入冲突。指出每项共享契约的负责人，以及解除其消费者阻塞的条件。除非草案说明了合并计划，否则共享迁移、契约、安全界面或可能的写入范围的切片必须串行执行。只有在先敲定范围狭窄的共享接口确实能消除阻塞项时才这样做；不要仅为创造并行工作而虚构基础阶段。

5. 对于新的功能执行计划，使用 shared/references/feature-review.md，以确定一项核心检查计划，并对延期的常规工作或关键依赖进行分类。在每项任务中注明针对性的回归检查和依赖契约测试。宽泛的简化和合并审查应放在最终功能 gate 中。现有计划和明确采用的旧版任务模式应保留其记录的审查顺序。按照参考文档编写规范的任务文件和精简索引。将机器调度输入保存在 queue.json 中。在该文件中记录依赖项和负责人，但完整的验收和 gate 字段仍应保留在每项任务中。使用 shared/scripts/gate_contract.py 验证带版本的 gate 记录，然后在审批前通过只读共享队列控制器验证依赖图和绑定。

6. 展示每个 ID、标题、规范路径、依赖项、类型、验收摘要、gate 结果、安全级别和负责人。在请求审批前解决重大变更。申请合并审批时，应在同一预览中列出确切且已解决的路由、源共享、隐私、收据、能力、工具和预算。仅面向协调员的草案无需提供执行预览，除非用户请求此选项或后续请求执行。

7. 记录实际响应、时间戳、已批准的输入身份和决策。仅将每个已批准规范任务的状态提升为 ready-for-agent；所有关卡都必须已满足 verdict: proceed 且 decision_required: none。将索引标记为已批准，并链接到其不可变的批准记录。不要重写父 PRD。绝不要重写或删除已开始、状态为 done 或 blocked 的契约。对其范围、验收标准、关卡或所有权的任何更改，都需要新的任务 ID 和批准。在现有清单和台账中记录进度。

验收契约

每个就绪任务都必须有已批准的父 PRD、稳定的 ID、经过验证的依赖项、可核查的验收契约、完整的关卡和安全字段、回滚指南、审查重点以及明确的所有权。索引链接到规范任务和实际批准记录。下一步是 implement-tasks；该步骤会复用完全匹配的批准记录，或在分派前获取模型批准。现有旧版队列仍可读取，且无需重写已开始的契约。