implement

实现 - 实现阶段

不变量

• 修改实现文件之前，必须先有已批准的任务文档。
• 将任务文档视为主要的范围约定。
• 未经用户批准，不得扩大范围。
• 不得依赖特定提供商的模型切换命令。
• implement auto 是唯一的自动化入口。
• 如果任务文档列出了尚未解决的 BLOCKING 决策，不得开始。停止并询问用户，同时引用该决策及其选项。
• 如果项目的 AGENTS.md 定义了自己的认领或跟踪约定（例如“已推送的分支就是认领依据；开始时不要编辑 TASKS.md”），请遵循该约定，而不是执行以下跟踪器变更。
• 在两个阶段转换时都更新 TASKS.md（开始时从 Planned → In Progress，结束时从 In Progress → Testing），并在交接前重新读取跟踪器以确认条目已移动。跟踪器过时会阻塞下游会话和无头会话。

运行时适配器可能会将此阶段呈现为斜杠命令、菜单操作或自然语言技能调用。可移植的阶段名称为 implement。

参数处理

• {ID} 或 {task-name} 用于标识任务文档。
• auto 用于在实现后启用“实现到发布”的自动化链。
• --tier fast|balanced|deep 仅当当前运行时支持层级路由时，才可覆盖任务文档中的建议。

如果用户要求使用特定提供商的模型名称，应将其视为适配器级偏好，而非核心工作流语义。

工作流

1. 阅读 AGENTS.md。
2. 如果 LEARNINGS.md 存在，则阅读。
3. 从 TASKS.md 或直接任务文件名中确定任务 ID。
4. 从最新的集成分支读取 docs/task/{ID}-{task-name}.md（先获取最新内容）。本地副本或较旧副本可能不包含最新决策或范围说明。
5. 确认任务已审核并获准实施，且没有尚未解决的 BLOCKING 决策。如果任一项不明确，请停止并询问。
6. 阅读 Coordination。如果列出的任务正在处理相同文件，请遵循其中规定的规则（等待，或与其分支同步），并在 Implementation Notes 中注明。
7. 仅阅读任务文档中列出的文件，除非缺少依赖项会阻碍实现。
8. 在 TASKS.md 中将任务移至 In Progress，并从 Planned 中移除该条目。
9. 记录基线： 在更改任何内容之前，运行合并前验收检查，并将结果记录在任务文档的 Baseline 中。更改前已通过的检查无法证明此次更改有效。应改写检查，使其最初无法通过，或说明原因。
10. 循环执行实现步骤：每完成一步，就运行受该步骤影响的最小范围检查；只有检查结果符合预期后，才能继续。不要把所有检查都留到最后。
11. 运行完整的合并前验收和无回归检查，并与基线进行比较。
12. 交接前（以及与集成分支同步后），重新读取集成分支中的任务文档。如果其范围或决策自开始后发生变化，请协调一致或停止并询问；不要依据过时的计划结束工作。
13. 在任务文档中追加 Implementation Notes，包括实际变更内容的 Operator Steps（根据你的差异重新计算部署集；不要照搬计划中的列表）。
14. 在 TASKS.md 中将任务移至 Testing，并从 In Progress 中移除该条目。
15. 重新读取 TASKS.md，确认任务条目位于 Testing，且不在 Planned 和 In Progress 中。如果条目不在预期分区，说明遗漏了移动操作，请立即编辑并在交接前修正。
16. 在手动模式下，停止并将任务交接给 simplify。
17. 在自动模式下，继续执行可移植的自动化链。

循环规则

• 绝不要声称自己没有观察到的结果。“应该可以”“看起来没问题”和构建通过，都不能证明某项行为标准已满足。请报告运行的检查及其输出，或者说明未运行该检查。
• **每次重试都必须有所改变。**重试失败的检查之前，先写下这次有哪些不同之处（新假设、修复或更多数据）。如果没有任何变化，就停止并提问，而不是重复尝试。
• 记录失败的尝试（尝试了什么、检查结果如何），并写入 Implementation Notes，以免下次会话重复尝试。
• **不要为了通过检查而降低标准。**如果检查有误，请另设一个步骤进行修正并作出解释，同时引用证据。

阅读规则

默认阅读以下内容：

• AGENTS.md
• LEARNINGS.md（如果存在）
• 任务文档
• File Changes 中列出的文件

避免广泛探索代码库。如果任务文档缺少必要的上下文，请针对具体的符号、文件、路由或命令进行搜索，并在 Implementation Notes 中记录原因。

实施说明

将此部分追加到任务文档：

## Implementation Notes

### What Changed
- {Summary}

### Files Changed
- `{path}` - {reason}

### Deviations From Plan
- {None, or describe with rationale}

### Verification Run
- `{command}` - PASS | FAIL | SKIPPED ({reason}) (baseline: {value} → now: {value})

### Attempts That Failed
- {What was tried, what the check showed, why it was dropped; or "None"}

### Operator Steps
- {Migrations, deploys (incl. importers of changed shared modules), config, or "None: merge is enough"}

自动链

以 implement auto {ID} 的形式调用时，在实施后继续执行：

1. simplify {ID}
2. test {ID}
3. document {ID}
4. ship {ID}

如果运行环境支持后台工作进程或子代理，适配器可以在隔离的工作进程中运行各阶段。如果不支持，则在当前会话中按顺序运行各阶段。每个阶段都必须将持久化的详细信息写入任务文档或报告文件。

对于同一项失败的测试或质量问题，最多进行三轮修复和重试。达到上限后，向用户报告阻碍。每一轮都必须遵循循环规则（有所改变，并记录尝试）。

交接

手动模式输出：

Implementation complete for task {ID}
Task status: Testing
Next stage: simplify {ID}

自动模式输出应概述已完成的最后阶段以及任何阻碍。