workflow-execute

工作流执行

完成已批准的工单，直到每项都通过验证，然后审查整个功能。

从同级目录 ../workflow/ 读取共享策略，包括其中的“始终”列表。若缺失则停止；绝不能用其他已安装副本替代。

开始之前，请检查：

• 规则涵盖下一个工单（workflow/RULES.md）；
• 检查点 Approval 已批准、属于旧版，或有明确豁免涵盖这些工单。仅达成一致绝不允许编写代码：转到 workflow-specify；
• 工单包含依赖项、验收标准、接口和范围（否则转到 workflow-specify）；
• 工单指定的任何可选专家（workflow/SPECIALISTS.md）均已安装；缺少专家只会阻止该工单；
• 已记录 git status 和差异（workflow/TASK-FOLDER.md）；
• UI 工单已记录其 ui-design 权限来源；否则暂缓处理。构建 UI 工单前，阅读 ../ui-design/SKILL.md 第 4 步。

仅在权限来源缺失、发生重大变更或存在阻塞时重新确认。

循环

只要有就绪的工单，且负责人没有要求停止、暂停或取消，就重复执行（然后参阅 workflow/TASK-FOLDER.md 中的“Stop, pause and cancel”）。遵守已批准的工作者数量和检查预算；付费评估也须遵守 VISUAL-REVIEW.md 的明确预算规则。并行工作需要彼此独立的工单和不同的文件；说明并行运行的数量。不要填满未使用的名额。

1. 选择。 当工单的依赖项已在当前文件中通过带 V-ID 的验证时，该工单即为就绪状态。被阻塞的工单只会阻塞其依赖工单。
2. 检查点。 保存工单、其文件及其检查结果。在更改任何内容前运行计划中的基线检查，或复用输入仍然匹配的基线（TASK-FOLDER“Baseline before this change”）。记录每个失败测试的名称和第一行错误信息，而不仅是数量。
3. 选择路径。 小型路径：单个工单，仅限列出的文件，不涉及接口、依赖项、数据或安全性变更。在此处完成，并明确说明；没有子 Agent 时，所有工单都在此处完成。否则，将每个工单交给一名新工作者，并向其说明工单、验收标准、衔接点、允许使用的文件、规则、UI 权威依据、输出文件夹和起始 git status；工作者返回证据，由你填写记录。出现未列出的文件、第二个调用方、接口或数据变更、无关失败、重大问题或用户决策时，工单应退出小型路径，重新评估。将所有“需要人工处理”的步骤汇总为一次请求。
4. 构建。 TDD 工单：首次运行测试前阅读 ../tdd/SKILL.md，并在约定的衔接点遵循其中的流程；红绿循环由该文件负责。文档或配置工单：检查指定的约定；绝不声称发生了实际未发生的红绿过程。让行为归其所有者负责，应用 AUDIT.md 的必要性检查，更新指定文档，并删除工单要替换的内容。
5. 验证。 运行工单的检查并记录 V-ID：命令、结果、限制。UI 工单还要运行 ui-design VERIFY.md；设计验收需单独处理。长输出只保存一次，按需查询，并根据 ARTIFACTS.md 将必要的失败证据保留下来；不要无限期保留每次重试的记录。使用 workflow/scripts/compare_failures.py 按名称比较失败（每行一条 id<TAB>first error line）：只有同一测试以相同方式失败，才算已有失败；环境导致的失败要明确标注。绝不要削弱测试来让它通过。
6. 审查。 根据审查者在 workflow/AUDIT.md 中的选择，分别审查标准和规范：代码使用 ../code-review/SKILL.md（绝不使用主机同名的内置工具）；技能、说明或文档使用 ../writing-for-agents/SKILL.md 及 AUDIT 中的类别。主机支持子 Agent 时，由一名新的子 Agent 阅读该文件并审查这两个方面；仅在没有子 Agent 时进行自审，并注明是自审。自上次审查后未发生变更的差异，不要再次审查。
7. 修复。 在范围内修复问题。代码或测试的修复，只将修复后的差异交给同一位审查者；记录或措辞的修复则自行检查并注明。若审查者认为问题需要用户决策，或修复会改变已批准的方案或任何用户可察觉的内容，发货前先交由用户处理；其他工单继续推进。若问题需要新的授权、连续两轮修复没有进展，或审查者连续两次未能通过审查，则将工单标记为受阻并说明原因。
8. 关闭。 最后一次修复后，验证所有当前验收检查，包括必要的设备检查和人工检查。缺少证明时，状态保持为待验证。状态说明务求简洁并链接证据；移除的工作需要决策记录，绝不能标记为测试通过。
9. 集成。 在其依赖工单开始前，运行已验证工单组的集成检查。

整体功能审查

当所有工单都已验证或明确关闭且未通过时，按照约定审查整个变更，使用相同的审查人员选择方式，并加上 AUDIT 对其他调用方、失败场景、清理和记录的检查。按照循环流程修复并重新检查。工单审查不能替代这项审查；如果最后一个工单的审查已纳入这些检查，且该工单审查后没有其他工单发生变更，则这次审查可同时满足两者。

没有任何获批内容可运行时，应交付部分结果并注明阻碍因素。等待不算验证通过；不要重新启动审查／修复循环。

中途发现的变更

行为、范围、接口、依赖、风险或受保护区域发生实质性变更时，仅暂停受影响的工单：行为退回 workflow-clarify，工单退回 workflow-specify。其他工单继续处理。缺少基础设施属于阻碍因素；切勿自行安装。

下一步

然后调用 workflow-deliver，并提供工单列表、V-ID、审查结果和受阻工单。停止、暂停或取消的情况也交由它处理，并标记为部分结果；除非负责人要求继续，否则不得返回此处。只有运行过 deliver，执行才算完成。

仅在本地适配 Implement Spec，不改变其调用方式。未经单独授权，不得执行 Git／tracker 操作或由专家进行编辑。