OPA 策略版本化与灰度回滚

OPA 策略上线的风险，不只是写错判断条件，更是一次策略变更可能同时改变所有合并请求的放行结果。把策略放进版本管理只是起点；真正可回滚的门禁，还需要知道每次检查用了哪个策略版本、输入了哪些事实，以及最终为何阻断或放行。

灰度发布宜从“只观察、不改变门禁”开始。让候选策略与当前策略读取同一份归一化扫描结果，分别生成 deny 和 warn 决策，但仍由当前策略决定合并。比较重点不是两份结果是否完全相同，而是候选策略新增了哪些阻断、取消了哪些阻断，以及差异能否由规则变更解释。对新增阻断应抽样人工复核；如果高误报规则尚未验证，把它留在 warn，比直接扩大 block_rules 更稳妥。

进入实际灰度时，应明确哪些检查使用候选版本，并在检查记录中保留策略版本与决策结果。不要让流水线运行时不受控地取到变化中的策略，否则同一类提交可能因执行时间不同而得到不同结论，排查也难以复现。候选版本扩大适用范围前，可用历史合并请求回放，观察阻断与告警的变化，再结合人工复核决定是否推进。

回滚要按故障类型选择最小动作。单条规则误报，就将其从 block_rules 降到 warn_rules，保留告警以便继续观察；策略逻辑出错，则恢复上一个已知可用的策略提交并重新运行检查。临时放行不应等同于关闭整道门禁，而应限定规则、审批人与有效范围。这样，灰度和回滚改变的是可追溯的策略决策，而不是让安全检查在紧急时刻失去约束。