do

Do

只执行当前允许的一个切片，不重新打开已经确认的设计。

开始前

先确定走的是哪一条路径，两条的前置条件不同。

SPEC 路径（经过 capture 与 arrange）

读取 AGENTS.md、.spec-agents/doctrine/docs/WORKFLOW.md、CONTEXT.md、项目 .spec-agents/state/KERNEL.md（若存在）、.spec-agents/state/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、.spec-agents/doctrine/docs/WORKFLOW.md、 CONTEXT.md、项目 .spec-agents/state/KERNEL.md（若存在）、.spec-agents/state/STATUS.md 和必要的 Protocol、 Runbook、Lesson。确认：

• plan 给出的结果允许直接执行：approve；或已获用户明确授权的 plan-only； 或 compatible revise 且该替代方案在当前上下文内可完成；
• 它交出的「保持不变的契约」和那句验收都已知；
• 工作仍然可以在当前上下文内完成。

执行中发现它不再是单上下文的工作，停下回到 plan，不要就地编一个 SPEC。

两条路径都适用：先对权威落点

动手前把这次要写的位置，对照项目 .spec-agents/state/KERNEL.md 的 Architecture boundaries （权威落点地图）。短路径上没有 Slice，就直接拿打算落笔的模块去对。两种结果：

• 图上有这条规则，而目标位置不是它 —— 停下回到 plan。要么落点不对， 要么地图该改，两者都不是 do 能自己决定的。
• 图不存在，或图上没有覆盖这条规则的条目 —— 不要停。记下打算落笔的 位置，产出一个 semantic 发现交给 plan，然后继续执行。

第二种情况刻意不阻断：存量 Kernel 本来就不要求回填这张图（见 .spec-agents/doctrine/START.md）， 把地图缺失变成硬停会让合规项目动不了，而一条动不了的规则一定会被绕过。缺失 是 Kernel 的缺口，不是这次工作的缺陷 —— 交给拥有 Kernel 变更的那道门去补。

do 从不修改这张图。在症状出现的那一层顺手加分支，是功能生效但生效在错误 位置的主要方式。

执行

1. 先追踪真实调用链和既有 seam，选择最小可行改动。
2. 对有分支、循环、解析、金钱或安全影响的逻辑，留下一个可运行的检查。
3. 保持 Action Contract、不变量和数据契约不变，除非 plan 已批准兼容修订。
4. 运行任务要求的测试、类型检查、静态检查或最小手工验证。
5. 把当前 Slice 留在 doing 并写下验证摘要，供 check、learn 使用； 短路径上没有 Slice 可更新，跳过这一步；保持 evidence_ref 为空。 do 不关闭 Slice —— done 与 evidence_ref 由 learn 在 check 之后一起写入。
6. 不写根目录 Evidence，也不回写 Evidence ID。

如果仓库存在 .jj/，本地版本操作遵循 JJ：用 jj new/jj edit 开始上下文、 用 jj describe 记录意图、用 jj status/jj diff 检查。把当前 JJ Change ID 写入 Slice 或交接摘要时，仍然以 SPEC 与 Slice 作为语义来源；不要用 git add、git commit 或 git stash 模拟 JJ。没有 .jj/ 时才沿用项目现有 Git 工作流；不要在 do 中自动初始化或 push。