implement-tasklisted

# 实施任务 根据已批准的技术方案实施任务，并产出 `implementation.md` 或 `implementation-r{N}.md`。 ## 行为边界 / 关键规则 - 严格遵循最新方案产物：`plan.md` 或 `plan-r{N}.md` - 绝不自动执行 `git add` 或 `git commit` - 每轮实现都创建新的实现产物，不覆盖旧文件 - 执行本技能后，你**必须**立即更新 task.md 版本戳规则：创建或更新 `task.md` frontmatter 时，先读取 `.agents/rules/version-stamp.md`，并写入或刷新 `agent_infra_version`。 ## 常见违规借口与反驳 动手实现前，若冒出以下念头，先停下——它们都是违规借口： | 借口 | 反驳 | |------|------| | 「代码太简单，不需要测试」 | 简单代码也会回归；没有"失败→通过"的用例就没有完成标志，先写验证业务行为的测试。 | | 「先写代码再补测试更高效」 | 后补测试常沦为对实现的镜像；目标驱动应先定义可验证用例再让它通过。 | | 「方案这里不合理，顺手改更好」 | 偏离 `{plan-artifact}` 必须在报告中记录原因；有异议先停下确认，不擅自改方向。 | | 「测试过了，顺便提交一下」 | 本技能绝不执行 `git add`/`git commit`，提交是用户显式发起的独立步骤。 | ## 第 0 步：状态核对（执行前硬约束） 在加载 workflow / skill / rules 指令之后、做任何任务状态判断或用户可见结论之前，必须先执行状态核对。指令类文件读取不算对外动作或结论。 运行以下命令，并把原文粘贴到回复正文和本轮产物的 `## 状态核对` 段： ```bash git status -s ls -la .agents/workspace/active/{task-id}/ tail .agents/workspace/active/{task-id}/task.md ``` 状态核对完成前，禁止任何关于外部状态的断言（例如“代码没变”“测试已通过”“没有其他引用”），包括思考阶段。本门禁只提供结构下限；逐条证据配对和真实性仍需按报告模板与审查要求核对。 ## 执行步骤 ### 1. 验证前置条件 先检查： - `.agents/workspace/active/{task-id}/task.md` - 至少一个技术方案产物：`plan.md` 或 `plan-r{N}.md` 如果缺少任一文件，立即停止并提示用户先完成前置步骤。 ### 2. 确保任务分支 先读取 `task.md` 中 `## 上下文` 的分支字段，并检查当前 Git 分支是否匹配。 - 已记录任务分支：当前分支不匹配时切换到该分支 - 未记录任务分支：判断当前分支是否符合命名规范且属于当前任务 - 符合：记录当前分支并继续 - 不符合：按规范创建并切换到新的任务分支 完成后，把最终使用的分支名回写到 `task.md`。 > 分支命名规则、Git 命令和边界处理见 `reference/branch-management.md`。执行此步骤前，先读取 `reference/branch-management.md`。 ### 3. 收窄里程碑 如果 task.md 中存在有效的 `issue_number`，执行前先读取 `.a