工程案例
Rootloom：让编码智能体的工程变更可检查
把风险路由、根因定位、范围约束和实际验证组织成可检查的 Codex 工程工作流。
角色
我的角色与范围
产品设计、工程实现、文档与验证，2026.07 · v4.1.0。
问题
要解决什么
编码智能体可以快速修改代码，但“为什么在这里改、是否触及真正的不变量、范围是否漂移、验证是否真的运行”经常散落在提示词和日志中，难以复查。
Rootloom 是面向 OpenAI Codex 的本地工程工作流插件。4.1.0 将公开入口收束为 Change、Review、Project Guidance 与 Setup，并让严格合同只在风险或显式证据要求出现时加载。
范围
目标与不做事项
目标
- 让目标、授权、修改范围和完成声明保持一致
- 对缺陷追到行为所有者边界和被破坏不变量
- 让验证记录实际运行的检查、结果与剩余风险
不做事项
- 替代仓库规格、测试、Lint、安全扫描、持续集成或人工审查
- 让所有任务都运行同一套深度治理流程
约束
现实边界
- 需要遵循 Codex 插件、Skill、AGENTS.md 与平台授权边界
- 普通任务必须保持轻量，高风险或证据模式才加载严格合同
- 命令通过不能自动成为正确性、安全性或任务完成证明
决策
真正影响结果的取舍
用一个 Change 入口承载风险路由
Direct、Scoped、Governed、Evidence 与 External Action 由同一实现入口根据任务事实选择，用户不需要先理解内部流程，也避免多个相似工作流相互漂移。
在行为所有者边界处理根因
缺陷先建立现象、触发状态、所有权边界、被破坏不变量与根因的链路，减少下游特判、吞异常和放宽断言造成的伪修复。
把命令结果与完成判断分开
验证从主路径、不变量和相邻路径派生；命令结束后继续检查最终 diff、工作区与最强反例，只有实际观察到的结果才能进入完成报告。
主流程
架构与实现
主流程：任务意图与授权 → 仓库事实与风险 → 根因或目标边界 → 最小一致变更 → 比例化验证 → 最终 diff、工作区与剩余风险复核。
公开入口：Change / Review / Project Guidance / Setup。Governed、Evidence 与 External Action 是 Change 按风险显式加载的模式，不成为日常强制门禁。
证据
如何确认它真的工作
结果
已经产生的影响
- 将公开使用面收束为四个稳定入口，普通变更路径不加载额外合同
- 完成 4.1.0 发布，并保留可检查的正式评估、契约与持续集成记录
- 明确区分机器观察、人工语义判断和证据能力边界
边界
限制与后续
当前限制
- 当前核心工作流面向单个 Codex Agent，不提供通用多智能体编排
- 它让工程过程更可检查，但不会让模型变得不会出错
- Evidence Bundle 是本地审查记录，不是安全证明或不可变审计系统
后续
- 继续用真实仓库任务校准风险路由、验证强度与令牌开销
- 在不增加日常负担的前提下扩充兼容性和失败模式证据