审批权限边界管理 是做什么的？
触发条件
当请求的操作明确跨越人类决策边界时使用；不要用于创建新的不必要检查点。
流程
- 确定确切提议的操作、决策所有者以及需要批准的规则或授权。区分新审批与已授予的审批。
- 捕获带版本控制的提案和一个决策包：当前行为、提议的变更、目的、受影响的资源、风险、可逆/不可逆影响、不采取行动的替代方案，以及请求的精确授权。
- 命名边界：实施、实验调用、生产激活、发布、支出或数据/安全。对其中一个的批准并不代表对其他项的批准。
- 一次性征求决策，并提供具体的“是/否”或有限选项集。避免将广泛的一揽子同意作为唯一选项。
- 将受影响的工作标记为等待决策而阻塞。不要反复请求相同批准、将沉默重新解释为同意，或重试已阻塞的操作。
- 如果独立工作仍被授权，则将其队列移交给自主执行连续性流程。项目范围的安全事件不是本地阻塞因素。
- 收到明确响应后，保留决策记录、范围、时间戳和参考；在执行前验证提议的操作是否仍与之匹配。
反模式
绝不要因为技术上看起来合理而悄悄修改评分规则、解锁防护、更改计费、发布私有来源的工件或扩宽代理工具权限。
输出
一份可审计的决策记录，包含确切允许的后续操作和单独列出的未授权操作。参见审批记录。
完成定义
所有者能够在无需逆向工程冗长调试记录的情况下，批准或拒绝一个明确版本控制的变更。