| name | do |
| description | 执行一个已经批准且未阻塞的工作切片,完成最小代码变更、测试和状态交接。适用于已有 SPEC 与 Slice 的实现,或 plan 直接 approve 的单上下文改动。 |
Do
只执行当前允许的一个切片,不重新打开已经确认的设计。
开始前
先确定走的是哪一条路径,两条的前置条件不同。
SPEC 路径(经过 capture 与 arrange)
读取 AGENTS.md、docs/spec-agents/WORKFLOW.md、CONTEXT.md、项目
KERNEL.md(若存在)、STATUS.md、相关 SPEC.md、一个目标 Slice 和必要的
Protocol、Runbook、Lesson。确认:
- Slice 状态是
ready 或已明确授权的 doing;
- 所有
blocked_by 已完成;
- SPEC 没有
stale;
- Slice 未声明
writer:,或声明的就是 do;
- Slice 的
authority: 已对照过 Kernel 的 Architecture boundaries(见下);
- 当前代码、测试和配置与任务范围一致。
短路径(plan 直接给出 approve)
这条路径上没有 SPEC 也没有 Slice。不要为它创建一个 —— 那正是这套流程
拒绝的 ticket。读取 AGENTS.md、docs/spec-agents/WORKFLOW.md、
CONTEXT.md、项目 KERNEL.md(若存在)、STATUS.md 和必要的 Protocol、
Runbook、Lesson。确认:
plan 给出的结果允许直接执行:approve;或已获用户明确授权的 plan-only;
或 compatible revise 且该替代方案在当前上下文内可完成;
- 它交出的「保持不变的契约」和那句验收都已知;
- 工作仍然可以在当前上下文内完成。
执行中发现它不再是单上下文的工作,停下回到 plan,不要就地编一个 SPEC。
两条路径都适用:先对权威落点
动手前把这次要写的位置,对照项目 KERNEL.md 的 Architecture boundaries
(权威落点地图)。短路径上没有 Slice,就直接拿打算落笔的模块去对。两种结果: