crank-execute

执行

目标

交付计划。将计划视为事实依据——直接执行，不要重新设计。

硬性规则

这些规则在每一步都适用；约束某一步的规则由该步骤承载。

• 先有证据，再下结论。 本轮未运行验证并阅读输出前，绝不报告任务已完成。
• 为分阶段计划中的任务标注阶段。 回复用户时，凡是提及分阶段计划中的任务编号，都必须标注其所属阶段，例如 Task 14 (stage 2 of 3)。关闭某个阶段的任务还必须标注其关卡以及该阶段行的退出状态，例如 Task 18 (stage 2 of 3, gate): <exit state>。台账条目、简报和提交消息保留不带阶段的任务编号。
• 目标已定，路径灵活。 计划要交付的内容——每项任务的目标、契约和架构——均已确定，不可更改。通往目标的路径则不受此限：当错误、过时信息（符号已重命名、文件已移动）或假设不成立阻碍任务时，将其作为绕行方案处理——只做仍能准确交付任务承诺内容的最小改动，并将其记录在台账条目中。任何会改变交付内容的修复都属于改道方案：停止执行，并连同你的建议一起向用户说明。不影响当前任务的意外问题（任务未涉及的既存错误）只记为事后记录，绝不可作为额外任务处理。
• 评审者独立判断。 每次评审派发都必须是冷启动：评审者自行获取事实——运行 diff、阅读计划中的任务、阅读报告文件中的实现者证据，并应用固定的评分标准文件。派发时只提供指针和 BASE SHA；任何额外内容——对 diff 的描述或辩护、复现或注释过的评分标准——都会预先影响你所要求的评审。
• 验证一次；信任证据。 任务的 RED→GREEN 证据（实现者按行为提供的输出）是该任务的权威运行记录；最终关卡对计划和覆盖情况的检查，是对整个 diff 唯一一次权威复跑。
• 声明要派发，就必须启动子 Agent。 一旦你的输出表示某项任务将由子 Agent 执行——或本次运行选定的执行方式要求如此——你的下一步操作就必须是启动该子 Agent，绝不可转而直接执行任务（事前人员安排本身不算派发）。如果适合在主线程中执行，就明确说明将留在主线程处理及原因（若执行方式有变，还要重申调整后的执行方式），不要宣布派发任务。
• 派发即阻塞调用。 从启动到返回期间，子 Agent 负责该项工作：启动后立即结束本轮，等待其返回通知恢复执行，并将阅读返回内容作为恢复后的下一步操作。其他所有事项——下一项任务、对其文件附近的编辑、查看其进度——都必须等到它返回后再处理。并行模式下，所有子 Agent 的启动消息须一次性发出，并作为一个整体阻塞；所有返回内容均须先于其他操作阅读。如果子 Agent 超出预期仍未返回，应根据持久化状态进行核对——自 BASE 以来的 git log、台账、磁盘上的报告文件——然后恢复该 Agent，或向用户说明停滞情况并给出建议。
• 出现意见摇摆，就停止循环。 如果某轮评审要求推翻此前一轮的要求，这属于意见摇摆，而非进展——绝不可盲目反转代码；应停止并向用户说明两种评审结论及你的建议。
• 绝不可强制推送、修改先前的提交、重写历史记录，或未经明确批准删除分支。

参考资料

子 Agent

此技能会在两个层级启动子 Agent——请根据 SUBAGENT-TIERS.md 确定各自层级：优先遵循已加载指令文件中的偏好，只有在没有偏好时才采用其框架所支持的模型。standard = 探索、实现、逐任务评审、最终评审的各个视角；heavy = 对只有一个阶段或没有 Stages 表的计划进行最终跨任务评审、最终评审中的合并及其修复轮复审（以及对 BLOCKED 任务的一次性升级）。该文件中的 Dispatch or main thread 默认规则适用于计划外调查；执行方式（Flow 步骤 1）适用于实现与评审。

词汇表

请在步骤 2 前阅读 VOCABULARY.md；其中的术语在下文各处均采用相应含义。在步骤 3 和步骤 5 对审查者的发现作出裁定时，误用其中术语的发现应予以驳回。

审查裁定

每项任务的审查关卡（流程步骤 3）和最终审查关卡（流程步骤 5）都按相同方式作出裁定：

• 只驳回你能够证伪的内容，并记录证伪理由。你掌握跨任务上下文、规范以及审查者看不到的覆盖情况表，因此，若某项误报源于正确复用被误认为重复、连贯的单一接缝测试被误认为横向切片，或审查者未读到的文件已满足某项验收标准却被称为缺失，那么应由你证伪，而不是要求审查者扩大搜索范围。驳回时须记录理由：针对单项任务的审查，将理由附加到 task-<N>-review.md 中的 ## Dismissed 标题下；针对最终审查，则记录在复盘文档的最终审查部分。
• 已确认的缺口意味着审查未通过。
• 修复清单条目若附有 Plan decision: 引文，表示该条目指出计划或已记录的用户决策所规定的内容，且其主张已在合并时的检查中得到确认。请修复该问题；若修复会推翻已记录的用户决策，则将其作为开放事项写入复盘文档，并附上你的建议。
• APPROVED 若附有非阻塞性 Notes，仍表示任务已完成：这些 Notes 是延期处理的发现——针对单项任务的审查，从 task-<N>-review.md 中读取；针对最终审查，则记录在复盘文档的最终审查部分。请据此继续推进，切勿进入修复轮次。重新审查中超出范围的观察也按相同方式处理。

交付物

主要交付物是已交付的代码——按任务提交的代码，并记录在进度台账中。复盘文档是次要文档。

进度台账

台账是已交付内容的持久记录：无论采用何种执行方式（包括单人执行），都要在这里跟踪任务完成情况。它首先应位于 git 目录中；如果写入遭拒，则回退到工作树：

1. 打印 git 目录路径，然后创建台账目录——使用两条普通命令，不要写成复合单行命令（限制工作树的沙箱会拒绝复合 shell 命令）：

   git rev-parse --git-path crank
   mkdir -p <the path it printed>
   

   台账路径为 <that dir>/progress-<slug>.md——以 slug 为键，因此多个计划的台账可以共存；slug 是计划的父目录名称。

2. 如果运行环境拒绝向该处写入——工作树隔离会保护共享的 .git 路径——则在工作树根目录使用 .crank/<slug>/progress.md，并记录一次回退情况。

每个计划在每个工作树中对应一份台账。台账以本次运行的锚点和当前运行的 Pre-flight 行（Flow 第 1 步）开头，然后每个计划任务占一行：

# Crank execute — <branch>
Plan: <plan path, normally .crank/<slug>/plan.md>
Base: <the HEAD SHA when the run started>

<the Pre-flight lines>

- [ ] Task 1: <subject>
- [ ] Task 2: <subject>

行格式。 以下每项都追加到任务行的 — 之后：

• <sha> — <verdict>，任务完成时将复选框改为 [x]：填写提交 SHA（可以有多个），然后填写 APPROVED、review skipped (clean return)，或在单人执行时填写 no per-task review。恢复执行时，[x] 行表示已完成：通过 git log 确认后跳过该任务。
• detour: <one line>——记录任务遇到的每一次绕行，不论问题是否已解决，这样复盘中的 Deviations 和最终审查就能在此查阅。
• open: <one line>——记录尚无人解决的任务相关问题；在第 3 步阅读任务正文的人负责解决，步骤、Check: 和 Files 块通常会给出答案。
• note: <one line>——记录该任务必须保留的信息：已交付的接口、路径或约定与计划文本不再一致时，在第 3 步阅读任务时查阅。
• review: <path to task-<N>-review.md>——记录审查发生的位置。该文件保存审查者的 Notes 以及你给出的驳回理由（References → Review verdicts），复盘时也会在此查阅；行中填写审查结论和该文件路径，审查内容保留在文件中。

另有一行不属于任务，位于 Pre-flight 行下方：当运行提前结束时（第 4 步），填写 Stopped: <why> — resume at Task <N>。

零散信息的存放位置。 某个后续任务必须保留的信息，应记录在该任务行的 note: 中。更正后的仓库信息——例如重命名后符号的当前名称、移动后文件的当前路径、测试夹具中的陷阱——应连同证据写入 .crank/<slug>/grounding.md（ARTIFACT-HOME.md → Grounding），该文件会为 orientation.md 提供初始信息。其他所有内容都写入复盘的 Open items。

复盘

由完成最后一个计划任务的运行写入 .crank/<slug>/retro.md（Flow 第 7 步）；运行提前结束时，则将台账留待后续运行接手（Flow 第 4 步）。包含以下章节：

• Summary——交付内容，以及 <branch> 上从 <first> 到 <last> 的提交。
• Deviations——记录所有绕行（遇到的阻碍及解决方法），以及差异中其他与计划明显不符的地方和原因。没有则填写“None”。
• Final review——审查结论、已修复的问题（附提交 SHA）、判定为误报而驳回的问题，以及延后处理的问题：分别依据 References → Review verdicts 记录。
• Open items——只记录通过 Flow → Close the loop 后仍未解决的事项，每项都写明该步骤的完成标准。延后处理的问题和驳回项保留在上方的 Final review 章节中。
• Promoted——记录本次运行移交、且在本次工作结束后仍需保留的每项信息：信息内容、证据所在行，以及写入位置的 file:line。若本次运行未移交任何信息，则留空。
• Validation evidence——运行过的命令及其结果。

流程

1. 加载并严格审查

根据 RESOLVE-PLAN.md 确定计划及其 .crank/<slug>/ 目录。 请自行阅读计划的框架，包括其标题（Spec:、Goal:、Gates:）、Global Constraints、Updates since spec、Refactor scope、File structure、Coverage、Stages、Out of scope，以及每项任务的标题。任务正文会逐项提供，请在步骤 3 到达相应任务时再阅读。如果计划标题中列出了规范（Spec: 行），也要阅读该规范——最终审查会以它为依据；计划只是对规范的拆解。如果计划包含 Global Constraints 部分，其中的值对每项任务都具有约束力。

打开进度台账（Deliverables → Progress ledger）；如果当前工作树中已有本计划的进度台账，说明这是一次中断后的运行，应按该部分的说明恢复；否则从头开始。无论是全新运行还是恢复运行，每次都要从下方列表中选择执行形式，不要求使用特定模式。然后将 Pre-flight 行写入台账，填完整的每一行，并放在锚点与任务行之间，替换先前运行留下的行，包括其 Stopped: 行。全新运行时，同一次写入还会创建台账，其中包含锚点和计划中每项任务对应的一条未勾选行。计划解析完成后，此写入是本次运行的第一项文件更改，必须先于任何其他编辑、提交和派发；计划遍历的派发须在同一轮中紧随其后。

Pre-flight: branch <current branch>
Grounding: <.crank/<slug>/grounding.md — N entries | none>
Shape: <solo | sequential | parallel>
Subagents: standard = <model> (implement, per-task review, final review lenses) · heavy = <model> (final review) · resolved from <user CLAUDE.md | project CLAUDE.md/AGENTS.md | harness fallback>
Tasks: <N> (<M> remaining)
Bound: <Task <N>, the plan's last | Task <N>, the user's stop | Task <N>, the stage <S> gate the user named>

行规则：如果工作没有 grounding 文件，或该文件为空，Grounding 行写 none；否则写明文件名及其条目数。Models 填写应用 SUBAGENT-TIERS.md 后解析出的名称，不能填写裸 tier 标签；resolved from 填写将子 Agent 偏好映射到对应层级的指令文件名称；如果没有已加载的指令文件声明偏好，则填写 harness fallback。Solo 模式下，Subagents 行填写 standard = <model> (plan walk) · heavy = <model> (final review) — implementation inline · resolved from <source>。<M> remaining 表示台账中未勾选的方框数；全新运行时，M = N。Bound 行写明本次运行结束后的任务：计划的最后一项任务，或用户要求提前结束的任务（例如 stop after Task 4、stop at the stage 1 gate——根据计划的 Stages 表，关卡对应的最后一项任务）；如果计划只有 Stages 表，Bound 仍设为最后一项任务。

• Solo（在本会话中）——适用于小型计划（约 3 项任务或更少）、共享进行中状态的任务，以及快速修复。不逐项审查：最终关卡是 Solo 模式唯一的一次审查。
• Sequential subagents——默认用于超过 3 项任务的计划：每项任务都使用全新上下文和独立审查者。
• Parallel subagents——仅适用于操作互不相交且没有共享状态的文件的任务。

一旦声明执行形式，该形式便约束整个运行（Hard Rules → 声明派发形式后，必须启动子 Agent）。如果对下方停止条件问题或阶段关卡问题的回答导致 Bound 发生变化或计划任务发生变化，或者之后更改执行形式并替换 Shape，则必须在下一次编辑或派发之前，先在台账中重写每一条变更的行。 随后，以 standard 层级（SUBAGENT-TIERS.md → Dispatch 或主线程）派发计划走查，将计划路径、存在时该工作项的 .crank/<slug>/grounding.md、走查涵盖的任务，以及以下三个类别原文交给它。走查只覆盖一个阶段：包含第一个未勾选任务的阶段（没有 Stages 表的计划则覆盖其中每个未勾选任务），并以 HEAD 为依据进行核对——后续阶段会固定引用较早阶段尚未写入的文件，因此要在各自的关卡进行走查（步骤 3，Stage gate）。它会在计划旁的 .crank/<slug>/plan-walk-<stage>.md 中记录发现（无阶段时为 plan-walk.md）——逐项任务记录每条发现所属的类别、证据，以及找到时的更正后锚点——并为每项任务返回一行，列出每条发现及其类别；若无发现则写 none。走查核实计划引用的内容：带有证据的断言——锚点（`<path>` → `<symbol>`）、 `<path>:<line>`（无符号） 这种回退形式、命令及其输出，或 searched <scope>, none found——均按照 ARTIFACT-HOME.md → Grounding 的先验证后信任规则，通过一次读取或重新运行，在引用位置进行核实；涵盖同一事实的 grounding 条目也以同样方式核实；不带引用的断言则需完整推导。只有走查实际执行过的检查，并附上证据（path:line，或返回空结果的搜索），才能作为发现叫停流程。

走查只报告；更正由你落实。若引用在其他行或符号处得到确认，就要在步骤 2 填充简报目录之前，将其连同新锚点在计划中对应章节原位改写，以确保每位实现者阅读的那一个章节准确无误。未能确认的引用与其他发现一样，按类别处理，并将更正后的事实记入 grounding。两个类别会叫停流程；第三个类别则随流程带入：

• 阻塞项 — 计划提及了走查通过 grep 搜索却未找到的符号，引用了已不存在的路径，或陈述了与另一项任务相矛盾的前置条件。
• 计划强制要求的缺陷 — 计划本身的措辞要求执行审查标准不认可的内容：不验证任何内容的测试、逐字重复代码库已提供的辅助函数，或用类型转换或 any 掩盖契约问题。引用该指示。覆盖计划明确要求的内容属于重新规划，绝非绕行——应指出该问题，让用户决定以何者为准。
• 随流程带入 — 走查读到的是尚未明确而非有误的内容：一种步骤存在两种解读、名称使用不严谨、无法定位的符号，或任务正文中没有任何 Behavior 行固定下来的要求。每条都随其任务的 ledger 行带入，写成仅包含问题的一条 open: 行；若任务自身的步骤、Check: 行或 Files 块已能回答某个问题，就将答案写入计划对应章节作为定论，无须带入其他位置。走查过程中核实的事实——重命名符号的现用名称、移动文件的路径——记入 grounding。

将两个叫停类别合并成一个批量提问提出，不要每发现一项就中断一次；提问后暂停，直至得到答复。然后检查 git status --short 和当前分支；若当前分支为 main/master 且改动并非微不足道，提交前只询问一次。

完成标准：走查阶段中的每项任务均已判断，并将发现归入相应类别或标为 none；其中每条带引用的断言均已在其引用处确认，或已归入相应类别；叫停类别已通过一个问题提出并得到答复；每项随流程带入的内容均已写在对应 ledger 行中或记录到 grounding；分支和 git status --short 均已检查；ledger 已打开并填写本次运行的 Pre-flight 行，这些行须作为本次运行的首个文件更改写入，且每项计划任务各占一行。

2. 简报目录

无论采用哪种形式，都要在仓库根目录下的 .crank/<slug>/exec/ 创建本次运行的简报目录——用于存放简报、报告和评审标准——并说明一次该路径；进度台账有自己的存放位置。开始第一个任务前备齐文件。所有副本都必须逐字节一致——直接复制文件，绝不重新输入。

简报目录中的文件	来源	子代理模式	单人模式
implementer-rules.md	IMPLEMENTER-BRIEF.md 中的区块	复制	复制——其中的常设缺陷规则和 RED→GREEN→REFACTOR 部分适用于第 3 步的内联实现；这些规则要求提交给实现者报告的内容，则记入你的复盘
orientation.md	IMPLEMENTER-BRIEF.md 中的模板，按下方的扫描流程填写	编写	跳过
review-rubric.md	PER-TASK-REVIEW-BRIEF.md	复制	复制——最终评审标准中的整体差异质量维度会读取此处针对每个差异的检查项
final-review-rubric.md	FINAL-REVIEW-BRIEF.md	复制	复制
final-merge-rubric.md	FINAL-MERGE-BRIEF.md	复制	复制
re-review-rubric.md	RE-REVIEW-BRIEF.md	复制	跳过

方向说明扫描流程：将模板写入简报目录；从 .crank/<slug>/grounding.md 中已有的条目填入未填写的空位（ARTIFACT-HOME.md → Grounding）；然后派遣一个标准层级的子代理，通过扫描仓库填完其余空位——但 Commands 区块除外，该区块应复制计划中的 Gates: 行。扫描时，即使某行已有填充值，也要在其引用位置核实每一条已填入的内容，而不是跳过，因此 orientation.md 只包含本次运行已核实的事实。

完成标准：.crank/<slug>/exec/ 已创建且其路径说明过一次，并且此形式要求的表格中所有文件都已写入磁盘，副本与其来源逐字节一致，且 orientation.md 已在子代理模式下填写完毕。

3. 每个任务

1. 派遣并实现。 在任何编辑之前，记录任务的 BASE——当前的 HEAD SHA；评审会对比 <BASE>..HEAD，以包含多次提交任务的每个提交。现在只阅读计划中本任务对应的部分——其中的步骤、Check: 和 Stop if: 行、Files 区块、Interfaces 和 Verify: 步骤；不要阅读其他任务的部分。如果台账显示本次运行中较早的任务已改动本节引用的文件，则要根据 HEAD 而不是本次运行的 BASE 核实该引用，并在计划中的本节重写锚点：之后的每个任务都会读取本节，而不是台账。本节留下未决的事项——其 open: 台账条目、一个文件有两个可能的存放位置、行为所依赖但未在任何行中说明的规则——也要以同样方式确定下来：在撰写简报之前写入本节；如果该事项会约束交付内容，则将其写成一条带有判定依据的 Behavior 行。如果规范或计划的 Updates since spec 包含本任务要构建或调整的界面的 Prototype: 判定，而本节没有 Prototype: 行，则要在撰写简报之前将该行确定下来。打开判定中指定路径上的胜出变体，或者阅读 in chat 判定下复制的区块。写一条 Prototype: 行，注明该路径；如果是 in chat，则在其下复制胜出的区块，并说明用户从胜出方案中排除了什么。然后，将判定中每一项已确定、且本节尚无 Behavior 行约束的内容写成带有判定依据的 Behavior 行：胜出方案的布局、信息层级和主要功能，以及用户从其他变体中选取的内容，还有用户排除的每一部分所对应的缺失情况；其判定依据要断言界面已渲染，且该部分不存在。简报不得在本节之外增加任何内容；评审者读取的是本节，而不是简报，因此只在简报中确定事项，就属于偏差。 在子 Agent 模式下，根据 IMPLEMENTER-BRIEF.md 在 brief 目录中编写 task-<N>-brief.md：其中的 Task 块按标题指向任务的计划章节，并包含任务的 - [ ] Behavior N: 行；它还指向 orientation.md 和 implementer-rules.md，并指定报告路径 task-<N>-report.md。派发时将该 brief 文件交给实现者，并要求其简要回复。只有当并行实现者的 Files 块没有重叠时，才能在一条消息中派发。每次启动后都会阻塞（Hard Rules → 派发是阻塞调用）。

   实现本身——单独执行时由你负责，在 brief 目录中受 implementer-rules.md 约束时则由实现者负责——按照该文件定义的 RED→GREEN→REFACTOR 循环逐一处理任务中的每个行为，然后执行任务的 verify 步骤。只有计划明确说明可跳过时才跳过该循环（配置切换、文档编辑、生成的代码）。任务通过后提交一次，提交消息中注明任务，并更新其台账行。若绕道纠正了计划中的事实——例如数量、测试夹具的形状、符号名称——则像修正 walk 中的内容一样，在整个计划中搜索并在后续章节提及该事实的所有位置改写。

   实现者状态：DONE 和 DONE_WITH_CONCERNS → 进入第 2 步的分流；NEEDS_CONTEXT → 提供上下文并重新派发；BLOCKED 且注明需要改道（目标本身必须变更）→ 直接告知用户；其他任何 BLOCKED → 提升至重型层级处理一次（这是标准层级默认规则的唯一例外），然后告知用户。如果适用该循环，但回复缺少 RED→GREEN 证据，或多行为任务只有一组批量测试对，则标记为 CHANGES_REQUESTED。

2. 审查（仅子 Agent 模式）。 对简要回复进行分流；报告保留在磁盘上。干净的回复——Status: DONE、Detours: none 或 settled only、Concerns: none，并且每个行为都有一组 RED→GREEN 测试对，或引用计划中跳过该循环的说明——跳过此审查。在台账行中记录 review skipped (clean return)。（根据项目决策：一周的运行显示，每任务审查中有 40/41 次通过，其中大多数是基于观察和已解决的绕道派发的，因此只有未解决的绕道和 Concerns 才需要审查。）已解决的绕道是指 brief、orientation.md、基础信息或你已提前指示的内容，因此其判断在实现者开始前就已作出；仍须在台账行中标记为 detour:。

   未解决的绕道或 Concern 是计划或你尚未作出判断的事项——你自己对回复的疑虑也属于此类，应写在台账行中——因此要冷启动派发一名标准审查者（Hard Rules → 审查者独立判断），并提供：你记录的 BASE SHA；计划路径和此任务编号，以及作为持续审查依据的计划 Global Constraints；实现者的 task-<N>-report.md 路径，用于查看 RED→GREEN 证据；brief 目录中的 review-rubric.md；以及 brief 目录中的 审查路径 task-<N>-review.md，完整审查内容写入此文件。观察事项不触发审查；根据 Deliverables → Progress ledger → Where a loose fact lives 中的说明，逐项处理。

   审查者应为每项评分标准检查返回一行，为每个 Behavior 返回一行并注明锁定该行为的测试，随后给出判定，再列出其 Cannot verify: 项。若某项检查返回 n/a 却未说明原因，或缺少某项检查，则该检查尚未执行——应退回处理，而不是查看判定。每条 unpinned: 都表示计划存在缺陷：在任务的计划章节中写入带有判定依据的 Behavior 行，并将锁定该行为的测试添加到本轮的 findings 中。自行解决每项 Cannot verify:，然后根据 References → Review verdicts 作出判定。

3. 修复轮次，在 CHANGES_REQUESTED 时进行。 在下一个任务开始前运行。记录 FIX_BASE——审查者刚刚评审的 HEAD，并将仍未解决的问题逐字写入简报目录中的 task-<N>-findings.md（后续轮次追加在 ## Round <R> 标题下）；修复者和复审者都要读取该文件。按照 IMPLEMENTER-BRIEF.md 中的 task-<N>-fix-brief.md 模板编写修复者简报——模板包含本轮范围、根据问题引用内容扩大的 Files 区块，以及追加到 task-<N>-report.md 的验证重跑结果，复审者会读取该结果，而不是自行运行测试——然后据此派发标准实现者。

   修复者提交更改后，派发一次复审：采用首次审查的指针格式，但使用 re-review-rubric.md 作为评审标准；用问题文件替代计划任务指针；评审路径相同，即在 task-<N>-review.md 的 ## Round <R> 标题下追加；差异范围为 <FIX_BASE>..HEAD，由复审者自行运行；同时提供该任务的 BASE SHA，以供评审标准中的比较例外使用。若复审结果为 CHANGES_REQUESTED，则从新的 FIX_BASE 开始下一轮。循环直到获得批准——但这不等于“每轮都照办”：出现反复摇摆时停止循环（见 Hard Rules）；若复审结论只是重新调整样式，或重提上一轮已解决的问题，则应在此将其作为问题驳回。

4. 阶段门禁。 当已提交的任务结束一个阶段，且 Bound 越过该阶段时，在该阶段的首个任务开始前，先检查下一阶段：针对该阶段的任务，按步骤 1 派发一次基于 HEAD 的评审；将需要停止处理的事项归纳为一个问题提出；把修正落到计划中，并在台账中重写回答导致变更的 Pre-flight 行。如果门禁本身就是 Bound，则通过 Short run 结束本次运行：移交台账。

每项任务的完成标准：其台账行标记为 [x]，填写提交 SHA 和符合 Line grammar 的评审结果栏，行内列出所有绕行情况，格式为 detour:；并且——若进行了审查——task-<N>-review.md 已写入磁盘，所有 Cannot verify: 项目均由你解决，你的驳回理由已追加在 ## Dismissed 下，且路径已按 review: 格式写入该行。

4. 短程运行：移交台账

如果任务循环结束时台账上仍有未勾选项，则本次运行属于短程运行——其 Bound（步骤 1）未达到最后一个任务，或因重新规划或 BLOCKED 报告而停止；最终门禁、循环收尾和回顾均属于提交最后一个计划任务的那次运行。Bound 结束的是工作单元，而非阶段：本次运行会在该单元完成验证后结束，无论验证发现什么——新发现的缺陷都应作为附带建议的待解决问题提出，绝不能开启新一轮修复。短程运行到此结束，台账应保持可供接手计划的人继续工作的状态。

对照本次运行实际提交的内容，逐项检查所有未勾选任务，然后按 Deliverables → Progress ledger → Line grammar 记录变更：

• 在每个未勾选任务的行中，写入所需的 open: 和 note: 项；
• 在 .crank/<slug>/grounding.md 中记录每条已更正的仓库事实及其证据——影响范围超过单个任务的事实应记在此处，而非台账行中；
• 在 Pre-flight 行下方添加 Stopped: 行。

然后按步骤 8 移交。

完成标准：每个未勾选任务都已对照本次运行的差异进行检查，并且要么记录了所需内容，要么确认不受影响；Stopped: 行标明恢复处理的位置；git status --short 无输出，或移交说明中已列出遗留内容。

5. 全面验证

此时，计划中的每项任务在清单上都已标记为 [x]——提前停止的运行已完成到第 4 步。宣告完成前，按顺序通过以下三个关卡——任何一项失败都会终止本次运行：

1. 计划核查。 根据实际提交，重新核对计划中的每项任务。运行计划中的关卡命令——即 Gates: 标题行所列的命令；如果计划编写时还没有该项，则运行套件 / lint / 类型检查 / 构建命令——并在本轮重新执行后阅读输出。
2. 覆盖核查。 逐行检查计划的 Coverage 表；对每一行，确认其验证步骤在本次会话中成功运行——如果结果已过时，或此前的任务可能破坏了验证结果，则重新运行。标记为仅需人工验证的行，应列入 retro 的 Open items。如果计划没有 Coverage 表，则逐项核对 spec 的验收标准（如果没有 spec，则核对计划中写明的目标），并自行对照差异进行检查。
3. 最终审查（以全新视角进行）。 每位最终审查者都必须保持独立判断（硬性规则 → 审查者独立评判），并获得以下内容：spec 路径（如果没有 spec，则提供计划路径）、计划路径（包括其 Coverage 表，以及存在时的 Global Constraints）、清单路径（其中的任务行记录了采取的每次变通）、清单在运行开始时记录的 BASE SHA（其差异范围为 <BASE>..HEAD），以及 brief 目录中的 final-review-rubric.md（包含审查维度和返回格式）。
   • 只有一个阶段或没有 Stages 表的计划：派遣一位重度审查者，提供上述路径，并指定 brief 目录中的审查路径 final-review.md，用于存放完整审查结果。
   • 包含两个或更多阶段的计划：在同一轮中派遣三位标准级别的审查者，分别负责一个审查视角（contract、coherence 或 quality），并提供上述路径及各自的审查路径 final-review-<lens>.md（位于 brief 目录中）。三位审查者全部返回后，派遣一位重度合并审查者，并提供上述路径、brief 目录中的 final-merge-rubric.md、三份审查视角的审查路径，以及审查路径 final-review.md。合并审查者的返回结果即为最终审查结果。

如果结果为 CHANGES_REQUESTED，根据 References → Review verdicts 的要求，在修改代码前先逐项审查发现的问题。只应用审查后保留的修复，不做其他改动；行为修复应先编写失败测试，并分别提交。如果发现的问题涉及横向切片，则通过证明每个切片测试在缺少对应实现时仍会失败来解决；随后将该验证过的切片记录在 retro 的 Final review 部分。之后只重新审查一次：使用一位重度审查者，并确保其保持独立判断；提供上述路径，重新使用 final-review-rubric.md，并将结果追加到 final-review.md 的 ## Round <R> 标题下，同时提供 FIX_BASE（即审查者进行判断时的 HEAD）和保留的问题，以便按 rubric 中的 Fix round 分支进行处理。无法修复的问题应明确写入 retro 的 Open item。若保留的问题要求撤销较早的逐任务审查所要求的改动，即构成反复摇摆——应停止并按硬性规则上报。

完成标准：关卡命令在本次会话中成功运行；每一行 Coverage 都在本次会话中成功运行，或标记为仅需人工验证并列入 retro 的 Open items；final-review.md 中保留最新一轮的审查结论；该轮遗留的每个问题均已单独提交修复、附理由予以驳回，或写入 retro 作为 Open item。

6. 收尾

交付已完成的工作。撰写回顾前，收集计划产生的所有未决事项——早前短运行记录在账本任务行上的事项、账本所指向的每个 task-<N>-review.md 中的 Notes 和驳回事项，以及本次运行的计划风险、仅限人工处理的 Coverage 行和你自己认为「值得记录」的观察——并逐一分类：

1. 解决。 如果本次会话中可以通过命令、读取或测试解决，就现在执行并查看输出——经验证的事实即视为已解决，不会出现在交接内容中。解决是验证，而非返工：若检查发现实际缺陷，则归入下一类；已确认的小问题则作为延期发现记录在回顾中。
2. 修复。 已交付代码中的缺陷会导致最终关卡失败——将其退回「整体验证」流程。若修复不属于计划任务，则需严格限定范围：恰好进行一次调查、一次测试优先的修复、一次审查——通过本技能自身的调度流程进行，然后停止并报告审查结果，无论结果如何。
3. 提升记录。 如果某个事实让本次运行绕了弯路，也会让下次运行遇到同样的问题——例如测试夹具陷阱、已知的不稳定问题、工具链陷阱——就应让它延续下去（ARTIFACT-HOME.md → Grounding）。在仓库已有的 CLAUDE.md、CONTEXT.md 或 ADR 中选择一个，追加一行并附上证据，然后在回顾的 Promoted 部分记录它所在的 file:line。如果仓库中没有这类文件，则将其归入下一类——写明相关行和你会放置的位置的决策，绝不要擅自创建文件。
4. 作为决策升级。 真正需要用户处理的事项必须保留：只有用户才能权衡的取舍，或只有人工才能执行的操作（视觉冒烟测试、你没有的凭据）。

完成标准：每个未决事项都已解决、修复、通过其所在的 file:line 提升记录，或写成附有建议的决策——不得仅仅重述本次会话中本可以检查的事实。

7. 回顾

在仓库根目录的 .crank/<slug>/retro.md 中撰写回顾，包含「交付物 → 回顾」中列出的各个章节。

8. 交接

报告已完成的工作：交付了什么、哪些验证可以证明这一点，以及——仅当有事项在「收尾」后仍未解决时——逐项报告其原有内容。

短运行则改为报告实际完成的内容：已提交的任务及其 commit SHA、剩余任务、停止原因，以及账本路径，并附上用于继续的 Next: /crank-execute .crank/<slug>/plan.md——其余内容均记录在账本中。

采用安全的默认选项，并明确说明；首先给出能持久留存的下一步：

• 回顾保留在 .crank/<slug>/ 路径下；提交保留在 <branch> 上，二者各用一行说明。
• Next: 推进工作的唯一命令或决策——例如，从基础分支运行 git merge <branch>，或列出「收尾」后唯一仍未解决的决策。

最后用一个单独的句子说明可按需选择其他方案（创建 PR、丢弃分支、复制或打印回顾）——使用普通文字，不要列出编号问题。然后停止。