---

name: coder-implement-loop description: "实现节点操作手册：读上游规格 → 写代码 → 自测 acceptance → 交付 artifact+log 的四段式细则，含路径坐标与交付边界。" layer: 2 domain: implementation keywords:

• coder
• implement
• acceptance-test

- research-plan-execute-verify

Skill: 实现节点操作手册

何时用

每次收到一个「实现」类任务时，无论大小——改一行配置到实现一个子系统，四段式都不跳。

开工前先定位三类路径（每次任务都做，不要复用上次记忆）

任务描述里有三段绝对路径，本文件和 agent.md 都不写死这些路径，因为它们随任务变化：

1. [上游输入] —— 规格文件（prd/sdd/acceptance 等）在哪，逐个读。标 ⚠️ 的表示还没产出。
2. [写入边界] —— 代码只能写进这个目录，越界判失败。
3. [节点产物目录] —— _research.md / _plan.md / _lessons.md / coder.log 落在这里。

四段式细则

RESEARCH

• 逐份读上游规格，不要只扫标题；有 ⚠️ 缺失的输入立即判断能不能开工，不能就汇报 blocked。
• 读写入边界目录里已有的代码，搞清楚现状（新建前先确认没有同名实现）。
• 确认依赖是否已装好（package.json / requirements 等），装不了的记下来，别假装装好了。
• 写 _research.md：已知事实（带出处路径）+ 空缺与处置方式 + 依赖检查结果。
• 流转：node ../../../../../bin/lemon.js task transition --agentId <你的ID> --phase plan --artifact <_research.md路径>

PLAN

• 只凭 _research.md。列出：要改/新建哪些文件、实现顺序、每一步对应哪条 acceptance。
• 每一步必须能独立验证——"重构一下"这种步骤要拆到能跑一条命令看结果的粒度。
• 写 _plan.md，流转： node ../../../../../bin/lemon.js task transition --agentId <你的ID> --phase execute --artifact <_plan.md路径>

EXECUTE

• 只凭 _plan.md。这是唯一允许写代码的阶段。
• 一步一步来，每写完一步就用对应的 acceptance 命令自查一次，别攒到最后一起测。
• 边写边记 coder.log：改了什么文件、跑了什么命令、输出摘要。
• 计划外发现的问题记下来，不顺手改——顺手改会让 VERIFY 阶段说不清是哪处生效的。
• 完成后流转：node ../../../../../bin/lemon.js task transition --agentId <你的ID> --phase verify

VERIFY

• 逐条跑 acceptance 命令，把真实终端输出（不是复述）贴进 coder.log。
• 反向检查：如果代码是错的，这条 acceptance 会红吗？红不了说明验收写空了，回 PLAN 补。
• 全部通过 → report_task({status:"PASS"})，附 artifact 路径 + 通过的 acceptance 条数。
• 任意一条 fail → 原因写进 _lessons.md，打回上一阶段自己修，不要带着已知 fail 交付。

硬规矩（违反即事故）

• 未走完四段直接写代码或汇报 PASS。
• 交付物（代码）写到写入边界之外，或私有产物写到节点私有目录之外——两头都不报错，但下游读不到。
• 规格有冲突时自己拍板换方案，不汇报 blocked。
• 汇报里写"应该没问题"——没跑过就是没做完，如实报 FAIL 更省事。