缺陷修复编排 是做什么的?
行为体 · 动作 · 目标:orch · fix · defect。对共享引擎 orch-pipeline 的薄包装。
使用时机
- 某些东西 坏了:输出错误、报错、崩溃、回归。
- 与同类技能区分:
- 行为正确但希望变更 →
orch-change-feature。 - 该能力尚不存在 →
orch-add-feature。
- 行为正确但希望变更 →
操作设置
- 默认规模下限: 小(通常较简单)。
- 阶段屏蔽: 0 →(仅当根本原因不明显或标准及以上时才启用轻量阶段2)→ 4 → 5 → 6。研究阶段(1)通常跳过。
- 第一步(阶段4): 将 bug 重现为一个 新的失败 测试(回归测试),然后修复直到测试通过。先证明 bug 存在,这是将修复与微调区分开的关键。
工作原理
- 使用上述设置运行
orch-pipeline引擎。 - 如果根本原因不明确,在红色测试之前先用
code-explorer进行范围界定;构建失败则升级给build-error-resolver//build-fix处理。 - 在 门控1(仅在生成计划后)和 门控2(预提交)停止。
- 如果缺陷位于安全敏感路径中,则附加
security-reviewer。
示例
缺陷修复编排:轮询器在空NWS响应时崩溃
→ 编写失败的测试重现崩溃 → 修复直到测试通过
→ 代码审查 → 提交 [门控2:确认] (提交信息:fix:)