loop-engineering

Loop Engineering

通过 plan → approve → execute → verify → independent review → address → ready，推动一项变更从接收到就绪。本技能定义每个阶段的含义，以及阶段交界处需要传递哪些证据。本技能不授权使用工具、发布、排期或委派，也不规定持久化状态的存储位置。

项目策略决定适用哪些变更交付关卡、外部代码审查的独立性要求、分支与交付规则，以及存储形式。策略未明确规定时，采用本技能现有的默认做法：编辑前先取得人工批准的计划、必须进行验证、必须进行独立审查、仅以追加方式恢复，并且只有在问题全部收敛后才能进入就绪状态。

本技能不设定运行时注入的指令与项目要求之间的优先级。宿主入口指南说明如何遵循当前宿主实际采用的指令层级；它不能重新定义该层级。应根据每条指令的实际来源和优先级解决冲突，遵守工具使用条件，并报告无法在这些边界内满足的项目关卡。

循环驱动者是当前负责依据已批准计划和所需证据推进一项变更的参与者。当驱动者委派一项贡献时，它就是该任务的父级。启动一项由其他参与者负责的独立变更，并不会让启动者成为该变更的驱动者。收到结果本身不会转移循环、人工决策权或操作授权。

不会造成任何变化的只读工作无需进入变更关卡。实施委派、阶段交付物审查和实施前检查各自都需要当前有效的资格。先前某条路径可用或不可用，并不能决定其他事项。适用的宿主指南负责参与者和读取路径；本技能负责检查点证据和阶段推进。驱动者执行工作，绝不意味着驱动者可以充当自己的独立审查者。

本文档中的关键词“必须（MUST）”、“绝不能（MUST NOT）”、“必需（REQUIRED）”、“应当（SHALL）”、“不得（SHALL NOT）”、“应该（SHOULD）”、“不应（SHOULD NOT）”、“建议（RECOMMENDED）”、“可以（MAY）”和“可选（OPTIONAL）”，其含义应按照 RFC 2119 中的说明解释。

阶段推进

每项变更都依据当前证据推进，绝不沿用先前阶段的主张。

以下四条规则适用于整个变更过程，且在选择参考文档之前就必须遵守：这是否属于变更工作、由谁负责、检查点资格是否仍然有效，以及授权依据为何。根据无条件范围例外，这些规则保留在此处；检查点专属的证据和流程则保留在相应参考文档中。

其他所有阶段规则都位于其适用的参考文档中，包括计划门槛，以及修订变更后随之产生的过时问题：plan-document.md 说明了编写、批准、修订或比较计划时的这两项规则。

指南：

• MUST 将只读工作视为不受变更门槛约束，除非该工作会产生项目变更。
• MUST 根据分配的工作和已确立的交接识别循环负责人及任何贡献职责，而不是根据执行溯源来判断。
• MUST 在各自检查点、依据当前主机条件，分别确认实施委派、阶段交付物审查和实施前检查的资格；直接实施以及先前角色的可用或不可用，既不能跳过其他检查点，也不能使其获得资格，且不得削弱任何门槛。
• MUST 区分计划批准、操作授权、执行能力和允许使用的工具。应在其原有范围内沿用有效授权，包括人类已采纳到项目指南中的已验证常设授权；这属于实际授权。但绝不可根据工具可用性、未记录任何授权的项目政策、计划批准或先前操作，推断存在授权或授权范围更广。

参见 phase-progression.md，了解：

• 如何在跟踪目标中锚定一项新变更，并进行首次编辑或分支操作，同时遵循接收和默认门槛
• 如何针对已变更的范围运行验证，以及如何创建或处理交付目标，同时遵循项目政策和独立审查
• 验证失败或审查／CI 待处理时，如何选择可执行的操作、识别具体依赖项并进行有界的机器等待
• 获得当前机器结果后，如何重新评估剩余门槛，包括无需修改源文件即可满足就绪条件的情形

参见 plan-document.md，了解：

• 如何编写、批准、修订或比较计划
• 计划的规范章节和批准目标
• 规划期间如何就必要的树外验证及其证据存放位置达成一致
• 修订标识、修订批准和视觉选项

参见 reviewing-phase-deliverables.md，了解：

• 规划之前的调查结论、批准之前的计划，以及每轮低保真和高保真视觉选项在人类选择或开展依赖工作之前的审查
• 当前产物和所需材料的标识、可复用的未变更审查，以及如何通过现有交接状态恢复已消耗的轮次
• 由 conduct 负责的完成边界；即使已安装的旧版 conduct 技能也缺少这种审查惯例时的后备做法；以及与实施前检查和外部代码审查的区分

执行交接

有关以下内容，请参阅 implementation-package.md：

• 通过五种兼容自然语言的约定分配工作，或接受执行结果或审查结果
• 仓库身份、材料保真度、授权和结果状态

有关以下内容，请参阅 subagent-delegation.md：

• 判定实现任务分配或选定的审查检查点是否符合条件，包括直接执行和此前不可用的途径
• 特定任务的依据、相关的重新判定条件，以及有条件的宿主指导默认设置
• 材料访问预检，以及整合返回的证据而不转移整体变更责任

有关以下内容，请参阅 writer-ownership-and-recovery.md：

• 协调并发写入、重试操作，或恢复中断的运行，包括计划变更导致的中断和结果未知时的恢复
• 只追加历史记录和完成证据比较

审查与就绪状态

有关以下内容，请参阅 finding-response.md：

• 通过反馈判断和因果修正方案选择，决定作者方如何回应预检或独立审查中的建议性发现
• 缺少行为或开发能力时的有限回应方式
• 将回应推理与发现处置及新一轮审查输入区分开来

有关以下内容，请参阅 pre-flight-review.md：

• 运行或恢复建议性预检审查
• 建议性审查发现、终止状态、延后的人工交接、驳回权限和持久搁置
• 初始实现以及三轮自主审查与修复

有关以下内容，请参阅 independent-review.md：

• 请求、处理或评估独立审查，或发布就绪状态转换
• 强制外部独立性、新一轮审查，以及四轮处理上限
• 在项目采用的呈现与报告范围内，可识别的已发布完成情况；不要求对每项检查作出肯定声明，且与明确限制和贡献者证据相区分
• 外部固定、人工驳回和未解决的处置状态，且不改写审查者历史记录
• 将收敛与对话结束区分开来，包括实质性元数据变更
• 冲突修复、受影响的验证、超时和就绪条件

恢复与报告

请参阅 resuming-and-handoff.md，了解如何：

• 通过重建实际状态并恢复一个待处理阶段，继续或接手一次运行
• 处理过时、不完整和未知的结果

请参阅 run-state-and-reporting.md，了解如何：

• 持久化可恢复的语义运行状态，而不依赖存储格式，其中包括单独的检查点资格认定、实际审查覆盖范围及其依据
• 跨阶段和会话，根据拟议影响评估已恢复或仍有效的操作授权
• 撰写有证据支持的可合并就绪简报，并将衍生角色的模型和工作量报告为 verified、declared 或 unknown

以下内容就是规则本身，而不是进一步阅读的要求。这条规则约束此循环执行的每一轮，而非某个更狭窄的情形，因此它适用《阶段推进》所援引的同一无条件范围例外，而不是放在 Agent 可能尚未打开的链接之后。观察结果及其所支持的行动必须发生在同一轮中。只发送文本而不调用工具的轮次，并不算是在工作仍继续时采取了行动——运行尚未停止，因此先报告、再采取行动，只是把一轮的工作拆成两轮来做，而不是在已经有机会做这项工作的那一轮中完成它。

指南：

• MUST 在同一轮中对运行继续期间任何具有后续步骤的观察采取行动——还有工作要做时，不要以只报告而不调用工具的轮次结束。
• MUST 将以下三种情况严格视为该规则的例外，而非违规：在必须设置人工关卡时结束该轮（包括升级至人工关卡的机器事件）；在等待达到上限前记录状态；以及用于结束运行的完成报告。
• MUST NOT 将此规则应用于异步机器事件仍未完成时发布的进度说明（例如必要检查、独立审查或受委派执行者的运行），前提是没有可独立采取的后续行动；仅有未完成事件并不足以满足该条件。
• MUST NOT 将此规则解读为禁止在调用工具的同时进行推理：它禁止的是把一轮拆成只发送文本、随后再用下一轮采取行动，而不是禁止在同一轮中撰写文字并调用工具。