vibe-plan-execution

Vibe Plan Execution

概述

逐个切片执行具体的实施计划，不得臆造行为；如果当前证据与计划相矛盾，则停止。计划决定范围和意图，而非已知有问题的实现细节。如果不存在具体计划，应先回到规划阶段，再开始编码；此技能不会创建或评审计划。

效果与写入边界

写入内容不得超出该阶段声明的效果类别和边界所允许的范围。

• 应用该阶段文本中声明的效果类别；如果此软件包规定了更严格的限制，则以更严格的限制为准。
• 只读：在聊天中报告；不得编辑任何文件、运行会修改状态的命令，也不得暂存、提交、打标签、推送、更改版本、删除数据或启动服务。只有当用户明确要求保存产物时，才可写入文件。
• 仅限产物：只能创建或更新该阶段负责的产物，以及其文本中声明的支持路径，例如已确认的计划反思或决策记录，并将其留在工作树中。
• 仅限产物阶段不得实施可执行行为、不得作为实现而编辑代码或测试、不得生成其他阶段的产物、不得执行发布工作，也不得将该阶段产物视为同轮实施的授权。
• 修改状态：只能在声明的范围内编辑并运行命令，且应以最小、经过验证的单元进行；除非用户选择，否则不得触碰其他路径、已有更改以及运行时或外部状态。
• 这些限制同样适用于 Shell 命令（重定向、sed -i、tee、mv、cp、rm、git checkout --）以及文件工具；应将被拒绝的写入报告为边界停止，不得改用其他工具重试。
• 每项不可逆或面向外部的操作都必须单独征得同意。

此阶段声明的范围是绑定计划授权的当前切片，按最小且连贯、可测试的单元实施，另外包括“持久化记录”中列出的决策记录和发现报告。范围还包括该切片创建的一次性根目录：在所需内容已保留的情况下，移除这类目录属于范围之内，不属于破坏性清理。

聊天语言

按以下顺序，分别确定面向用户的聊天文本语言和产物语言：

1. 用户在当前请求中对聊天、回复或输出语言的明确指示。
2. VIBE_CHAT_LANGUAGE：可读取的语言名称或 BCP47 标签，例如 ja 或 pt-BR；若用户为本次请求设置了该值，则使用该值；空值或无效值视为未设置。
3. 用户当前使用的对话语言；若无法确定，则使用此工作流中最近明确使用的语言。
4. 英语。

• 不得根据产物、文件内容、路径、命令、代码、技能调用或宿主包装文本推断聊天语言，除非用户明确指定它们为语言依据。
• 除非用户要求翻译，否则路径、命令、标识符、环境变量、区域标签、消息键、产品名称和代码均须保持原样。

证据标签和计划标题也须保持原样。

持久化记录

在阶段开始时，检查 docs/decisions/README.md 和 docs/reports/findings/README.md（或仓库现有索引），查找路径、标签或主题与本单元匹配的条目。在应用此类条目、记录已确定的决策、推迟发现或移交任何一项之前，先阅读 references/durable-records.md。此阶段可以写入 docs/decisions/ 和 docs/reports/findings/（或仓库现有的记录目录）。

计划来源

在编辑前绑定一份计划，并在第一条进度说明中注明其名称：如果是文件，则注明路径；否则注明标题。如果存在本地计划文档，请阅读该文档；聊天摘要仅用于导航，应以计划文档为准，并指出摘要中新增或矛盾的内容。阅读当前阶段的范围、验收标准、非目标、验证方式、风险和继续条件。行为清单、等效性分析、恢复证据或选定故障模式检查等高风险部分同样属于约定；如果其前置条件仍适用，而此类部分已过时或缺失，这是计划问题，绝不能据此降低验证要求。将用户的说法视为意图，直到核实为止。

• 仅在计划规定的载体范围内完成计划编写的 Reserved decisions 行；绝不能借此更改范围、标准、测试、风险或步骤。
• 首先满足受阻或有条件的继续条件；要求无论如何都要实施，并不能满足该条件。
• 一个阶段只有具备目标、范围、验收检查、验证路径和实现方向，才算具体。如果缺失的要素可能改变行为、验证、数据、权限、约定或用户体验，请返回规划阶段，而不是自行臆定，并报告计划项、缺失的证据以及恢复工作所需的内容。
• 如果自上次审阅或绑定以来，计划约定发生了变化，仅当变更具有明确的用户授权或修订授权时，才重新绑定该变更；并在此之后重新阅读受影响的章节。否则，暂停并要求修订计划。进度台账的编辑仅表示状态，不能作为约定变更的授权。
• 如果找不到指定项，仅当恰有一份计划拥有该项时才重新绑定，例如指定计划的台账指向的计划，并同时说明两个路径。

证据类别

每项承载关键结论的主张都必须标注四种证据类别之一。

• 如果某项主张会影响范围、可行性、行为、验证、风险、工作顺序、提交授权或工作能否继续，则它是承载关键结论的主张。
• Primary source：官方或上游文档、规范或源代码；用户提供的源材料；已知良好的既往实现。
• Local investigation：当前工作区所呈现的内容——文件、配置、模式、日志、现有测试、非变更型命令输出、复现的行为。
• Unproven：记忆、推断、转述或未经核实的说法、过时文档、访问受限、假设。
• Accepted risk：用户在了解影响后明确选择继续采用的 Unproven 项，或绑定计划记录为已接受的风险。
• 绝不能重命名或重新定义这些类别；软件包可以在自身文本中添加互不重叠的标签或时效限定词。

此阶段增加两个标签：Plan（绑定计划、规范、验收标准或任务清单中所述内容）和 Local evidence（通过阅读代码、测试、配置、模式或日志，或运行检查，在当前工作区核实的内容）。实施只能依据 Plan、Local evidence、Primary source 和 Accepted risk，并遵守 Accepted-Risk Semantics。即使回复中没有编辑任何内容，也要为承载关键结论的主张标注类别。

执行循环

1. 绑定 Plan Sources 下的计划；如果计划或指令涉及需征得同意的工作，请在首次编辑前运行 Startup Consent Preflight，并在执行受其约束的操作前，询问每项尚未确认的同意决定。

2. 编辑前先验证。 检查当前工作切片涉及的文件、测试、配置和架构；重新核对所依赖的计划事实和能力依赖；依据官方文档或上游源代码核查外部 API 和其他不稳定事实。如果无法进行必要的检查，就在该阻碍处停止，不为此工作切片编写代码或测试。如果证据与计划步骤相冲突，请运行 Plan Validity Gate。

3. 仅实现当前工作切片，沿用本地惯例，不纳入未来阶段或相邻清理；除非某项功能、选项、防护或修复能消除正常使用中可能出现的故障，或数据丢失、安全、权限或核心路径风险，否则不要加入任何无约束要求的内容，并在报告中注明省略了哪些内容；审查者的建议不构成约束要求。要求新增、跳过、缩小或替换计划工作（包括将计划内测试称为冗余并要求删除）都属于偏离：在据此行动前运行 Plan Deviation Gate。只有在有足够的会话和上下文余量达到验证关卡时，才开始计划标记为原子性的工作切片（内部状态可以未通过，结束时必须通过）；否则，停在前一个已验证的检查点，在那里记录不开始的决定，并且不要为适应会话而拆分该工作切片。

4. 证明结果：执行计划规定的验证，以及仓库相关的 lint、类型和构建检查。只有当指标能区分所需结果与已知的不良基线时，它才算证据：先记录基线；如果基线已经通过，就停止并通过 Plan Validity Gate 修正证明策略。广泛测试套件通过，并不意味着缺少或尚未运行计划验收检查的工作切片已完成。对于计划内的运行时验收检查，优先使用已验证能测试同一标准、且不会夺取焦点、注入输入或捕获被测应用之外内容的方式，例如无头运行。否则，按计划运行，不要仅因这些影响而询问或推迟；现有的同意和范围边界仍然适用。

   • 独立保留每个关卡的退出状态；绝不能让会截断输出的筛选器承载关卡状态，也不能让后续成功的关卡掩盖失败。
   • 对所有列出的冻结基线类别逐一核实，并将其记录为：现在已验证、推迟至指定的后续关卡，或仅能手动检查的缺口（需注明负责人和剩余风险）。如果经验性运行之后又进行了有意编辑，请对最终文件重新运行受影响的经验性关卡，或记录具体差异；重新运行静态检查不会扩展经验性验证范围。

5. 在摘要、下一个切片或任何提交之前，按照实施后审查关卡审查已验证的切片。

6. 关闭检查点：在不再需要时，删除该切片创建的工作树、克隆、副本和私有构建根目录（计划安排稍后切片使用的仍需要保留；仅仅可能会用到的则不需要），保留工作所需内容，并保留内容尚未核对一致的副本；更新现有的 Implementation progress 进度记录，然后按照提交选择规则为该单元选择提交。当现有行为中的缺陷不属于计划范围，却阻碍验证时，按照现有功能修复交接流程，将受影响的切片标记为受阻并停止。

7. 报告绑定的计划、切片、验证及结果（分别说明测试套件状态和验收覆盖情况；说明跳过的检查及其原因和残余风险）、审查模式及各项发现的处理情况、偏差或阻碍、所做的提交、保留的临时根目录及其大小和原因、该切片未创建但已成为孤立目录或发现未使用的任何构建输出根目录及其大小和删除命令，供用户决定是否删除（未经询问，绝不删除；工作不等待用户回复），以及计划中剩余的步骤。对于已提交的检查点，列出每个检查点在提交前通过的验证，并记录该切片所依赖的、仍未验证的任何已接受假设及其重新审视的触发条件。

提交选择

只有明确的用户请求、绑定计划项或工作流自身经过验证的检查点，才能选择提交。

• 提交前说明依据：当前用户的请求、已批准的绑定计划检查点，或此工作流为其已验证单元设定的默认检查点。若没有依据，则不要提交；将更改留在工作区中并说明情况。
• 绝不要将路由、调用、编辑权限、方便的停止点、已跟踪的更改或可用的提交工作流视为依据。提交执行本身没有默认检查点。
• 默认检查点：一个独立完整的单元实现、验证、审查完毕，且其重要发现均已处理后，立即仅在本地提交该单元，不必等待单独指示；绝不要让多个单元堆积着未提交。
• 不要从仅限探索、受阻、未更改、失败、未经验证或进行中的状态中选择提交内容。
• 只暂存该单元：排除工作流未造成的既有更改和单元范围外的路径；如果无法将单元与其他更改分开，则报告混杂状态并询问。
• 单元创建且必需的新文件（例如源文件或测试文件）属于该单元，除非其中包含凭据或秘密；只有明确要跟踪，或存在强制依赖关系时，才纳入生成的输出、临时文件和报告。
• 将每个选定的提交交由提交执行流程处理，并提供其范围、测试与审查证据、排除项和拟定的提交消息；该工作流负责暂存、差异审查、提交消息传递和提交后验证。
• 如果为先前提交自身缺陷选定的修复可纳入该提交，且远程跟踪引用、标签、其他分支或工作树中均不存在该提交，则无需询问即可合并进去；否则，或合并失败时，单独提交并说明原因。
• 除上述合并情况外，执行推送、修订提交、变基、移动 HEAD 的重置（软、混合或硬）、filter-* 重写或脚本化多提交重放前，必须取得用户的明确授权；提交请求或检查点绝不代表已获授权，已发布的历史记录是共享的。
• 绝不要将提交请求或检查点视为同意发布、变更版本、创建标签、存入暂存区、除上述合并外进行压缩、破坏性清理、强制添加、跟踪单元范围外的新产物或执行外部副作用；这些操作各自都需要单独授权。

示例：“用户本轮要求提交”明确说明了依据；“这是个不错的停止点”则不算。

例外：若当前指示要求不提交、绑定计划禁止提交，或项目政策暂停默认规则，则将已验证的更改留在工作区中，并说明原因。

若计划设有 Commit checkpoints，则按其关闭单元；否则，按自然形成且可独立验证的切片边界关闭单元。如果运行时测试或用户对已构建／部署产物的测试是检查点的前置条件，则在提交交接信息中注明测试所用的产物及其构建输入，以便将部分暂存的检查点与之对应。

接受风险的语义

只有 Accepted risk 才能让 Unproven 项支撑依赖于它的工作。

• 只有在影响得到说明后由人类用户明确选择接受，或绑定计划中记录了针对本请求的接受决定时，才能接受；绝不能由代理、委托方、AI 选定的默认选项或低风险判断代为接受。
• 记录假设、接受者及原因、影响范围、最快的验证路径和重新审视的触发条件，并将其与所支撑的条件步骤关联；该项始终保持 Accepted risk 状态，绝不能视为已验证事实。
• 将所有其他会阻碍当前工作的 Unproven 项转化为验证工作、问题或阻塞项；推迟当前工作不需要的决策。
• 绝不要将其用于不可逆、破坏性、不安全、违法或会暴露凭据的操作；这些操作必须经过验证、采用更安全的替代方案，或由用户明确作出人为风险决定。

如果接受决定仅在对话中给出，则在实现该决定所支撑的切片前，将其记录到绑定计划中。

参考资料

• references/execution-workflow-and-quality.md（证明规则、 实施后审查关卡、进度账本）：在证明、审查或结束一个工作切片时阅读。
• references/execution-gates-and-delegation.md（计划偏离关卡、计划有效性关卡、现有功能修复交接、启动同意预检、 委派）：在偏离或纠正计划、处理现有行为中的缺陷、跨越同意边界或委派工作之前阅读。