engineering-loop

工程循环

以最少的监督交付经过验证的变更，并进行适度检查。 从一个 Agent 开始。只有在获得授权，且独立工作或审查覆盖足以证明额外开销合理时，才进行委派。遵循适用的仓库和团队要求；此技能不会引入工单或强制使用多个 Agent 的流程。

建立基线

1. 阅读适用的 AGENTS.md 文件和仓库文档。
2. 记录所需行为、约束和可观察的完成条件。
3. 检查分支和工作区；保留与任务无关且属于用户的变更。
4. 更改共享行为前，通过有针对性的搜索或可用的代码图追踪受影响的调用方、使用方和测试。沿相关路径继续扩展。
5. 找出仓库原生的验证方式，并运行最小且安全的基线检查，以区分既有故障与任务回归。

根据证据解决常规选择。仅在缺少授权或存在重大决策时提问：验收标准不明确、公开行为不兼容，或尚未获得授权的破坏性／数据变更副作用。等待答复期间，继续已获授权的独立工作。

仅加载所需的参考资料：

• 长期、跨技术栈或高风险工作：loop-contract.md。
• 重复迭代或明确的预算：loop-policy.md。
• 间歇性、性能或尚未解决的缺陷：hard-debugging.md。
• 已请求或经风险评估认为有必要的独立审查：independent-review.md。

执行循环

1. 复现缺陷，或记录功能当前的行为。
2. 选择最小且完整的变更，以及能够证明其正确性的证据。
3. 可行时，先添加一个会失败的回归测试。
4. 实施一项范围明确的变更，并运行范围最窄的相关检查。
5. 如需采用未计划的路径，记录原因并更新范围和检查项。
6. 将故障归类为产品、测试、环境、假设或外部阻碍。不要更改产品代码来掩盖环境故障。
7. 运行受影响使用方的检查，以及仓库要求的更全面检查。
8. 先审查完整差异，确认符合任务约定，再检查代码质量、回归、安全性和可维护性。
9. 修复重大问题，并重新运行受这些修复影响的检查。

验收证据和必需检查通过后，只有出现新变更、故障或未解决的问题时，才扩大或重复检查。仅在测试能够证明行为或有意义的不变量时添加测试，不要只为反映影响较小的编辑而添加测试。

如果不存在测试工具链，则使用小型、可重复的脚本或有记录的手动检查，并注明输入、预期行为和实际结果。记录自动化覆盖的缺失；仅构建成功不能证明运行时行为。不要仅为满足循环而引入庞大的测试框架。

简要记录事实、变更文件、命令、结果和下一步决策，无需保存完整日志。

停止条件

• 连续两次出现相同故障后，停止盲目重试并重新判断原因。 只有相关状态发生变化，或探测能产生证据时，才继续。
• 如果发现或审查过程反复进行却没有新证据，应记录差异、未解决的问题和下一步有用的探测。不要重新开始相同的循环。
• 如果进展需要缺失的授权、密钥、不可用的基础设施、未经授权的破坏性操作，或尚未解决的重要产品决策，应停止并报告阻碍因素。
• 达到明确规定的循环次数上限后，应根据最新的评审证据停止，而不是悄悄扩大上限。 如果没有明确的上限，则仅在有界的下一步操作能够产生新证据时继续；富有成效的迭代次数不受任意固定数量限制。
• 绝不能通过弱化断言、删除覆盖、隐藏错误或悄悄更改验收标准，让失败的检查通过。
• 除非用户明确授权，否则不要查询生产环境、部署、迁移、合并或发布。

用证据收尾

报告行为和文件的变更、回归或验收证明、精确的检查命令及结果、审查结论，以及尚存的限制。若使用了独立审查，请注明最终经过审查的版本。绝不能将受阻的验证或尚未解决的重大问题标记为已完成。请参阅 evidence-example.md，了解填写好的交接示例。