/x-dev

name: x-dev
description: |
  开发任务执行 skill。读取单个 task 的 dev-checklist.md，按行序以"先测试后实现"的方式逐行执行，dev-report 只记验证结论（全绿或 N 个 🔴），全部行验证通过后交付。触发：`x-dev {task-dir}`、用户要求执行/开发某个 task。

x-dev — task 执行

输入与边界

x-dev 的作用域是**单个 task**：`docs/spec/<spec-name>/tasks/<task-name>/`，入口是它的 `dev-checklist.md`，按头部 `spec:` 与 `tech-design:` 指针跟读相关 feat、场景、已确认关键约束和编号测试用例的主定义。一个 spec 下可以有多个 task，x-dev 一次只执行指定 task，不扫描或编排同级 task。

旧 checklist 缺设计指针时查 spec 同目录的 `tech-design.md`；本轮承接的机制或用例主定义仍缺失/未确认时，受影响行阻塞并交来源负责方补齐，不从实现猜设计。既有 spec 未使用 C 或 feat/场景编号时沿用其已确认约束、场景 ID/章节定位，不强制迁移编号；没有新增适用关键约束的旧行仍按原场景和证据核对，不伪造 C。

checklist 的约定（由 x-req 生成）：

• **行序即实现顺序**，无依赖图；从 T1 开始逐行往下做。
• **场景回指定验收**：一行做完的判定标准是它回指的每个场景的 GIVEN/WHEN/THEN 及适用 C 约束的预期/禁止结果全部成立；任务列的“用例 T1”回指 tech-design，不能与任务行 T1 混淆。
• **风险列为 `高:` 的行**，验证必须包含真实链路（smoke 或以上），不允许只写 unit。
• 改动落在「涉及文件」范围内，不"顺便"改别的。

执行

高能力模型按批次执行：独立读取放同一批次；文件只在内容变化后重读；过程更新只报告新进展或阻塞。

1. **取证批次**：一次读完整 checklist、spec 中被回指的 feat 场景与 C 约束、tech-design 的 D 机制及编号用例、涉及的实现与测试文件，建立「场景/C → D/用例 → 代码/证据」的对应关系；发现缺定义、覆盖或确认先报告来源负责方，不从实现补验收标准；顺带确认涉及文件路径真实存在（x-req 留了 glob 的就在此批次定位）。 2. **逐行开发**（适合自动化的新行为先测试后实现）：

• 把当前行状态改为 `[ ] ▶️`。
• 按场景 THEN 与用例的预期/禁止结果写测试，先跑并证实失败来自目标行为缺失或违约（有效红灯）；构建、导入、环境或测试自身错误不是有效红灯，先排除后重跑。不得 mock 掉被验证的 D 机制；其他替身说明边界与局限，故障注入保留真实处理路径。
• 有效红灯后写实现，让测试变绿，改动保持在涉及文件范围内。不能为了通过改低断言、排除项或验收标准；需求/设计有问题交来源负责方澄清，变更后重新对齐用例和证据。
• 不可自动化时记录原因、可复现步骤与实际观察；既有实现已满足时先运行相应用例并保留通过证据，直接补缺失覆盖。集成验证行只验证结果；这些情况不伪造 TDD 或故意破坏实现造红灯。证据不足的行不能标绿。
• 验证通过后行状态改为 `[x] 🟢`。dev-report 记录红灯原因（或未采用 TDD 的理由）、最终结果及可定位证据，不贴大段输出。

3. **行失败时**：读完整输出，按根因一次修完全部关联位置；发现是测试写错就改测试并在 dev-report 未决节记一行原因。同一行失败多次不改目标——回看场景定义，仍不清楚就停下来问用户。失败中的行标 `[!] 🔴`，修复后恢复。 4. **收尾验证**：全部行 🟢 后，跑一次本 task 全量测试 + 一次既有测试回归（确认没有破坏 spec 概述和既有功能里的不变量），把结论（全绿 / N 个 🔴、回归通过与否）记进 dev-report。 5. **交付**：确认 checklist 无 🔴 残留，输出回执，报告下一步（同 spec 的下一个 task，或全部完成）。

dev-report

`docs/spec/<spec-name>/tasks/<task-name>/dev-report.md`，记简短结论与可定位证据、不贴大段测试输出：全绿或 N 个 🔴、回归结果、高风险行验证情况；红色失败一行一条摘要。完整读取 `templates/dev-report.md` 后填充。

自检（交付前）

• checklist 每个非 `None` 场景回指都有对应测试且行状态 🟢？
• 每条适用 C 及分配用例都有实际结果与证据，未把正常路径全绿当成全部约束覆盖？有效红灯/不采用 TDD 的理由可核查，未 mock 掉被验证机制？
• 高风险行有真实链路验证？
• 全部改动都在「涉及文件」范围内？
• 既有测试回归通过？
• 每个 🔴 行都在 dev-report 未决节有一行摘要？

回执

✅ x-dev 完成 · <task-name> · 行 N/N 🟢 · 场景覆盖 M/M · 高风险行 K（已验证）· 回归通过

有阻塞或失败残留时如实列出：行号、失败摘要、已尝试的动作、需要用户决定的问题。