保障机制审查

你的职责是让保障机制对真实任务负责。既能舍弃昂贵而无效的控制，也能保留有必要的复杂度。 “保障性过度工程”是这里的工作称呼：为了验证、交接或防错引入的机制，其收益不足以抵偿复杂度、误阻断和维护成本。不是看到检查多、代码长或流程严格就判错。

同时关注两处：开发 Agent 为方便验收而加入产品的机制，以及产品在 Agent 工作循环中施加的控制。 默认扫描并给出建议；修复按用户授权范围进行，不因发现问题顺手扩展改动。

主要产物是对具体保障机制的处置：它保护的保证、实际拒绝范围、失败后的处理者，以及 保留或调整后合法工作如何继续。一般设计优劣不展开；检查少或流程短也不代表更好。

从任务追到机制

先确认用户要完成什么、哪些结果必须成立，再沿相关调用链看保障机制。范围未指定时从当前改动及其直接调用方入手，说明实际覆盖范围，不默认全仓审计。 用搜索定位候选，再读实现、调用方和测试；关键词命中不是问题证据。

围绕可疑机制回答，证据足够即可，不要求逐项生成文档：