lite-execute

你负责协调一个计划的执行。在解析或写入任何产物之前，请先阅读 ARTIFACT-HOME.md，该文件规定每项工作的产物都保存在 .crank/<slug>/ 中。

步骤

1. 解析计划。
2. 确认每项已完成的任务（计划状态）。
3. 确定子 Agent 层级。
4. 设置范围上限并选择形式（形式）。
5. 编写 Pre-flight 行。
6. 在范围上限内执行任务循环（实施）。
7. 遇到以下第一种情况时结束本次运行：
   • 仍有未勾选的框：作为短程运行结束；
   • .crank/<slug>/retro.md 已存在：报告计划已完成并停止；
   • 所有框均已勾选：执行 Review、Close the loop 和 Retro。

解析计划

按顺序采用第一个符合条件的情形：

1. 明确路径：slug 是计划所在目录的名称。没有任务列表的文件（例如规格说明、PRD 或头脑风暴文档）不是计划：说明这一点，建议进入计划阶段（/crank-lite plan …），然后停止。
2. 单独的 slug：解析为 .crank/<slug>/plan.md。
3. 未提供参数，且对话中有计划：根据计划标题生成 slug，并将计划写入 .crank/<slug>/plan.md。
4. 未提供参数，且磁盘上恰好有一个计划：直接使用，无需询问。
5. 未提供参数，且有多个计划：通过结构化问题询问，并列出每个计划及其状态（计划状态）。缺少 plan.md 的工作目录显示为“尚无计划”，不可执行。
6. 未提供参数，且任何位置都没有计划：说明这一点，并建议进入计划阶段。

计划状态

先阅读计划中的 ## Progress 区块。[x] 行表示已完成：通过其 SHA 在 git log 中确认；若经过 squash 或 rebase 合并，则通过提交主题（git log --grep）确认，且绝不能重复执行。若已完成任务在两处搜索中都找不到，则停止运行并告知用户。

该区块紧接计划标题之后：

## Progress

Base: 9f8e7d6
- [x] Task 1: Add the parser — a1b2c3d
- [ ] Task 2: Wire the CLI flag

• 状态根据该区块判定：未开始（没有区块）、进行中（仍有未勾选框）、已完成（全部为 [x]）。
• 依据是计划 Grounding: 标题所指的文件；若没有该标题，则使用其 ## Grounding 部分，其中每项事实各占一行，格式为 - <claim> | <evidence> | <phase>, <date>（ARTIFACT-HOME.md → Grounding）。

如果计划包含 Stages 表，则发送给用户的消息中每个任务编号都必须标明其阶段，例如 Task 14 (stage 2 of 3)。结束一个阶段的任务还必须注明其 gate 和该阶段行的退出状态，例如 Task 18 (stage 2 of 3, gate): <exit state>。进度行、提交消息和 Pre-flight 行只保留任务编号。

任务的检查项按以下优先顺序取第一个存在的项目：

1. 计划为该任务指定的检查项；
2. 计划指定的 gate 命令：位于其验证检查项、Gates: 标题或 grounding 中；
3. 仓库的类型检查，以及覆盖所改行为的测试文件。若任务没有此类测试，则在其修改的接缝处新增一个测试；若任务没有可测试行为（例如文档），则运行仓库的类型检查或 lint。

运行检查后，必须在同一轮中读取其输出。没有测试接缝的改动需要进行探测，探测通过时的输出即为检查结果。

子 Agent 层级

每次运行只确定一次层级：

1. 若本次会话已加载的用户指令（用户级和项目级 CLAUDE.md / AGENTS.md）中指定了子 Agent 模型偏好，则该偏好具有约束力：即使指定的模型弱于下方的回退选项，也要据此映射各层级。适用于所有子 Agent 工作的偏好也适用于实施者。
2. 否则，使用以下回退选项：

- **标准**回退选项（实施者和评审视角）：Claude Code `model: sonnet` · 高投入度的 Codex Luna · Cursor Composer - **重型**回退选项（对抗式评审及其合并）：Claude Code `model: opus` · 高投入度的 Codex Sol · 高投入度的 Cursor Sol ## 形态

• 边界：本次运行结束的任务：计划中的最后一个任务，或用户要求中指定的更早任务（stop at the stage 1 gate 表示计划「Stages」表中第 1 阶段的最后一个任务）。如果只有「Stages」表，边界就是最后一个任务。
• 本次运行的任务：进度中未勾选的任务行，范围截至边界（含边界）。

选择第一个符合本次运行任务的形态：

1. 单项：本次运行有三个或更少任务，因此，从第 10 项任务继续的十二任务计划，或第 1 项任务已完成、边界设在第 2 项任务的运行，都属于单项。
2. 并行：各任务涉及互不重叠的文件集，且其检查可以并发运行。
3. 顺序：其他所有运行，包括依赖前面任务输出的任务。

你声明的形态决定本次运行：在顺序或并行运行中，每项任务的第一个操作都必须是派发，而非直接编辑。

派发与等待

每次派发，无论是实现者还是审查者，都是一个阻塞调用：

• 当运行框架提供对子代理的阻塞等待时，等待它。
• 如果运行框架改为通过完成通知恢复你，则在派发时结束本轮，让通知恢复你。
• 如果结果在同一次调用中返回，就在那里阅读。

只有在收到该通知的情况下，派发仍在进行时结束本轮才是安全的；在其他任何运行框架下，这都会结束本次运行。若等待在子代理返回之前就结束，例如超时，那就不算返回，应再次等待。在继续任何其他操作之前，先阅读返回结果；派发的工作交由派发对象处理：它尚未完成时，不要休眠、轮询或自行执行其任务。

停滞循环

• 开始条件：当用户消息或子代理结束但未返回的通知恢复你，而某次派发仍未完成时，该派发即为停滞。
• 每轮：
  1. 对该任务的文件运行一次 git status 和 git diff。
  2. 如果运行框架仍能联系该子代理，就恢复它；否则，使用其 Settled: 行中已更改的文件重新派发该任务。
• **结束条件：**派发返回。
• **升级条件：**同一任务第二次停滞时，按「绕行与停止」作出决定。

预检

每次调用（包括恢复的运行）都要写入以下各行，并填完所有内容。这次编辑是本次运行的首次文件更改；在长时间运行前，用户可通过这次差异查看模型、形态和边界。

1. 将这些行放在计划的 ## Progress 区块顶部，位于标题和 Base: 之间，替换之前运行留下的行。
2. 如果计划尚无 Progress 区块，这次编辑要添加该区块，并包含 Base: 和每项任务各一条未勾选的行。
3. 然后在同一轮中继续。

## Progress

Pre-flight: branch <current branch>
Shape: <sequential | parallel | solo>
Subagents: standard = <model> (implementers, review lenses) · heavy = <model> (adversarial review) · resolved from <user CLAUDE.md | project CLAUDE.md/AGENTS.md | harness fallback>
Tasks: <N> (<M> remaining, <R> this run)
Bound: <Task <N>, the plan's last | Task <N>, the user's stop | Task <N>, the stage <S> gate the user named>
Base: <HEAD before the first task>

在 Subagents 行中填写解析后的模型名称，绝不能只写层级标签；resolved from 后填写你将层级映射到的指令文件名称，或 harness fallback。单项运行的该行应写为：Subagents: heavy = <model> (adversarial review) — implementation inline · resolved from <source>；如果审查的是含两个或更多阶段的计划，则以 standard = <model> (review lenses) · 开头。

完成标准：计划的 Progress 区块以本次运行填写完整的预检行开头，并且这些行是在任何其他编辑、提交或派发之前写入的。

实现

开始第一个任务前：

• 阅读 VOCABULARY.md 的 ## Verification language 部分，以及它上方的 seam 条目；如果计划中有 Global Constraints 部分，也要阅读。Global Constraints 与任务本身的要求一同约束每个任务。
• 阅读 IMPLEMENTER-BRIEF.md 的 While implementing 和 Detours and stops 部分。单人执行时，按这些要求完成内联工作，并在下方的 Detours and stops 中处理其中要求实现者反馈的每个发现；无论哪种执行方式，你自己的修复都必须遵守这些要求。
• 在计划中，以及其 Spec: 标题所指的规范中，找到每一行指定获胜方案的 Prototype:，并阅读该方案指定路径中的内容，或其下方复制的代码块。每个构建或重塑某一行表层内容的任务，都要在其派发内容的 Prototype: 栏中指定该行；单人执行时，你要自行依据该方案构建相应表层内容。
• 运行 git status --porcelain 并保留其文件列表：这些文件包含用户尚未提交的工作。

任务循环

• 开始条件： 完成上述步骤。

• 每一轮都按计划顺序，对本轮的下一个任务执行以下步骤。顺序执行时，只有前一个任务的检查通过且提交已落地后，才派发下一个任务。并行执行时，在同一条消息中派发所有任务；每收到一项返回，就阅读其内容；所有任务均已返回后，再按计划顺序为每个任务执行步骤 2 至 5。

  1. 实现。 单人执行：内联实现任务。顺序执行和并行执行：根据 DISPATCH.md 将任务派发给一名标准级子代理，并等待其返回（派发并等待）。
  2. 检查。 自行运行该任务的检查，并阅读其输出。如果检查失败，将输出发回实现者；单人执行时则自行修复，最多两次。检查仍然失败，或返回内容报告了改道或观察到 Stop if:，则转至下方的 Detours and stops。
  3. 提交。 运行 git status。按路径暂存仅由本任务修改的文件，并且只提交这些路径（git commit -- <paths>）。如果本任务修改的文件在运行前的列表中，说明其中包含用户的编辑内容：提交该文件前先询问用户。
  4. 记录。 勾选该任务的方框，并将提交 SHA 紧跟在主题之后，置于任何 — open: 或 — note: 之前。如果任务经历了改道，在同一步骤中将更正后的事实补充到计划的依据中，或就地重写与之矛盾的条目，以免恢复执行时再次碰到相同的过时信息。
  5. 阶段门槛。 如果此任务结束了计划「Stages」表中的某个阶段，则运行计划指定的所有门槛命令。门槛检查失败时，必须在开始下一个任务前修复；但如果同一命令在 Base（Review 步骤 1）也失败，则记为回顾备注。

• 在两种情况下，循环会将控制权交还用户：

  1. 步骤 3 就运行前文件提出问题。收到用户答复后，循环从步骤 3 继续。
  2. Detours and stops 中需要用户作出的决定，该决定会结束本次执行。

  其他所有情况都会在同一轮中直接进入下一步：子代理返回、检查输出、提交、阶段门槛、改道。任务之间的进度报告不构成暂停点。

• 结束条件： 完成 Bound 之前的所有任务并通过检查，或因需要用户作出决定而结束本次执行。然后执行 Steps 第 7 步。

绕行与停止

计划的目的地已确定，道路却未必如此。处理所有不会改变交付内容的意外，并根据每个意外对交付内容的影响进行分类：

• 绕行：错误、过时信息（重命名的符号、移动的文件），或失败的假设阻碍了任务，而最小修复仍会精确交付计划承诺的内容。修复它，并在回顾中记录为偏离；任务循环步骤 4 会记录修正后的事实。
• 回顾备注：计划路径之外已有的错误。将它记录在回顾中，不要修复。
• 改道：会改变交付内容的修复。这需要作出决策。
• 停止：观察到计划在任务上写明的 Stop if: 条件。停止任何操作前，先处理它：
  1. 阅读该条件指明的代码，寻找代码已经提供的路径，例如现有参数、辅助函数，或其他调用方所用的模式；这条路径必须能精确交付任务承诺的内容，且不编辑任务自身新增内容之外的代码。
  2. 这样的路径会使停止条件变成绕行。单人执行时，直接在当前任务中采用；或者重新派发任务，并将该路径写在其 Settled: 行上（DISPATCH.md），然后将任务送回任务循环步骤 2。
  3. 若没有这样的路径，停止条件就是一项决策。
• 卡住检查：修复两次后仍然失败的检查。自行诊断：
  1. 阅读其输出和输出中指明的代码；若输出不能确定原因，则运行一次探查。只有在能够说出原因，并引用能证明原因的输出行或探查读数时，诊断才算完成。
  2. 如果探查后仍无法确定原因，则卡住的检查就是一项决策。
  3. 如果针对该原因的修复仍会交付计划承诺的内容，则再进行一次包含该诊断的修复；单人执行时在当前任务中完成，或者重新派发任务，并将诊断写在其 Settled: 行上，然后将任务送回任务循环步骤 2。
  4. 如果检查在此修复后仍然失败，就是一项决策。
• 决策：停止本次执行，将任务留为未勾选状态，且不提交其编辑内容，并在报告中列出这些文件。并行执行时，先为其他所有已返回的任务完成任务循环步骤 2 至 5，然后以简短执行结束。

简短执行

简短执行会跳过 Review、Close the loop 和 Retro，因为审查需要将完整差异与完整计划进行比对。应让计划足以为接手者提供简报：

1. 将每个未勾选任务的文本与本次执行的差异逐项对照。在该任务所在行追加 — open: <本次执行引发的一个问题> 或 — note: <其任务文本已不再匹配的接口、路径或契约>，可按需追加多项。本次执行未影响的任务，追加 — note: unaffected，除非该行已有备注。
2. 对本次执行中已完成的每个任务，每项原本应在回顾中记录的观察都追加一行 — note: <一行内容>。
3. 将每条已修正的仓库事实（无论是否为绕行）及其证据加入计划的 grounding：每条事实占一行，或在条目与事实矛盾时直接改写该条目。
4. 在 Progress 块的 Base: 行下方，写入 Stopped: <原因> — resume at Task <N>；恢复执行的那次运行会覆盖它。

Base: 9f8e7d6
Stopped: Task 2's Stop if observed, every route sets JSON — resume at Task 2
- [x] Task 1: Add the parser — a1b2c3d
- [ ] Task 2: Wire the CLI flag — open: may the export route bypass the middleware?
- [ ] Task 3: Document the flag — note: unaffected

5. 报告：
   • 本次执行中已完成的任务及其提交 SHA；如果没有，则说明一个也没有；
   • 剩余任务，以及用于恢复的 /lite-execute <plan path>；
   • 如果因决策而结束执行，则向用户说明该决策：发现了什么、检查的输出（若有），以及带编号的选项，并标明你的建议。

完成标准：每个未勾选任务都已根据本次执行的差异进行审阅，且其所在行带有 — open: 或 — note:；Stopped: 行指明恢复位置；因决策而结束的运行在报告中列出该决策的编号选项。

审查

勾选所有方框后：

1. 完整运行一次测试套件。修复本次运行导致的问题，并按 Task loop 步骤 3 的方式暂存每项修复并提交。只有当同一测试在 Base 上以相同方式失败时，才算预先存在的问题：在 Base 上的临时 git worktree 中安装好仓库依赖后检查，然后移除该 worktree。预先存在的问题应记录为回顾备注。
2. 逐行检查计划的 Coverage 表（如有）。除非某行的验证步骤已在本次会话中、且在最后一次修改其所测试文件的提交之后成功运行，否则重新运行该步骤。标记为仅限人工处理的行，应作为只有人工才能执行的操作列入 Close the loop。
3. 分派审查，每次分派仅附上填写完整的消息：

   • 计划只有一个阶段或没有 Stages 表：向一位 heavy-tier 审查者发送以下消息：

     阅读 <此技能 REVIEW-BRIEF.md 的绝对路径> 并遵照执行。
     Plan: <计划路径>
     Spec: <计划中 Spec: 标题所列的路径，或 none>
     Base: <Progress 区块中的 Base SHA>
     Diff: git diff <Base>..HEAD
     Vocabulary: <此技能 VOCABULARY.md 的绝对路径>
     

   • 计划有两个或更多阶段：在同一轮中分派三位 standard-tier 视角审查者。每位审查者收到上述消息，并附加两行：Lens: <Contract | Coherence | Tests> 和 Findings: <.crank/<slug>/review-<contract | coherence | tests>.md 的绝对路径>。三位审查者全部返回后，分派一位 heavy-tier 汇总审查者，发送单审查者消息，并将首行替换为 阅读 <此技能 MERGE-BRIEF.md 的绝对路径> 并遵照执行。，再附加两行：Review brief: <此技能 REVIEW-BRIEF.md 的绝对路径> 和 Findings: <三个 Findings 路径>

4. 修复审查者或汇总审查者返回的每项 CONFIRMED 发现，并重新运行覆盖它的检查；或者将其及其成立理由记录在回顾的偏差项中。对于 Plan decision: 行引用了已记录用户决策的合并行，应作为决策列入 Close the loop。按步骤 1 的方式提交修复。

完成标准：每项 CONFIRMED 发现都已修复并由同一检查重新验证、连同其成立理由记录在回顾的偏差项中，或作为决策列入 Close the loop。

Close the loop

回顾之前：

1. 通过本次会话中的命令、阅读或测试，解决所有未了事项：Progress 行中先前短时运行留下的内容、审查者发现、计划风险，以及你自己“值得注意”的观察。未解决事项只能是需要用户决定的决策，或只有人工才能执行的操作，并须附上建议。
2. 若某项事实导致本次运行绕道，且下次运行也会因此绕道（例如某个 fixture 会以代码中看不出来的方式导致测试失败、已知的不稳定测试，或工具链命令需要的标志），则应在仓库已有的 AGENTS.md、CLAUDE.md、CONTEXT.md 或 ADR 中追加一行，附上证据，并提交该更改。若没有此类文件，则将其作为决策保留，并注明要添加的内容及目标文件。

回顾

1. 将回顾记录到 .crank/<slug>/retro.md。按需包括：变更内容、运行的验证、审查结果、相对计划的偏差、任何已提升事实的去向，以及仍待决定的事项。
2. 告知用户本次运行产生的提交 SHA 和回顾路径；如果 Close the loop 后没有遗留事项，则说明工作已完成。然后停止。