implement-work

实施工作

执行已授权的结果，不要把基于 Plan 的流程强加到其他输入上。

使用 engineering-discipline.md。对于由 Plan 支持的工作，还要使用 workflow-language.md、document-conventions.md 和 phase-review-template.md。

确定工作范围

1. 阅读仓库说明、主导输入、相关的现有文档、源代码、测试以及任何引用的材料。
2. 确定已授权的结果、边界、验收证据、文档影响和未解决的决策。只针对可能实质性改变实现的空白进行调查。
3. 如果工作受 Plan 约束，选择指定的 Phase，或在被要求继续时选择下一个未勾选的 Phase，并记录其评审检查点和 Doc Delta。
4. 仅针对确实存在的歧义、凭据、产品判断、高风险授权或明确的人为检查点提问。其他情况直接继续。

除非输入或已授权的工作流要求，否则不要创建 Plan、进行访谈循环、交接、工作树、提交或 PR。

执行和验证

• 在限定范围内完成工作，不要顺带处理相邻的清理事项。
• 使用最快且有意义的反馈循环：对于成本低的行为，进行有针对性的红绿测试；对于设置开销大的行为，进行同范围检查；对于缓慢的端到端、全套测试或视觉行为，使用验收关卡。只有在自动化不切实际时才使用人工证据，并记录剩余风险。
• 在可行时，通过公开或有意保持稳定的接口进行验证。宣称成功前，先读取最新的命令或观察结果。
• 随着行为落地，及时更新规范文档。保留无关的未提交修改以及已有的草稿或原型。
• 遵循 Plan 定义的高影响评审检查点。低影响的 Task 可以等到 Phase 结束时评审。
• 对于由 Plan 支持的工作，只有在证据充分时才检查 Task 和验收标准；仅应用所选 Phase 的 Doc Delta，并将非必需工作归入 Discovered Follow-ups。
• 不使用 Plan 时，不要凭空添加 Plan 记录。将已授权的工作视为一个评审范围，只保留其他工作者或评审者需要的状态。

收尾

1. 对照输入、文档、测试、实际差异和持久化产物边界，自查整个已授权范围。
2. 运行相关验证并读取输出。
3. 通过 review-work 将整个工作范围（而非仅最新补丁）交给独立的全新上下文评审者；根据一手证据核实已采纳的结论，修复已授权的阻塞问题，并重新运行受影响的检查。
4. 仅根据变更范围或剩余风险所需的评审覆盖范围重复评审。
5. 更新主导产物。对于由 Plan 支持的工作，使用 phase-review-template.md，完成所选 Phase 的 Plan 和文档更新，然后才将其标记为完成。

不要递归评审评审结果。只有在跨 Phase 的验收或风险值得进行时，才增加 Milestone 级别的集成评审。将 Plan 或 Roadmap 的清理留到最终评审。