Policy Bot 拉取请求审批策略

要解决的问题

标准 GitHub 的 branch protection 只能做简单的 required reviews 配置，无法表达复杂规则。比如“变更涉及敏感路径时必须由安全团队批准”“数据库迁移必须由 DBA 团队评审”这类逻辑，原生功能无法满足。团队通常靠 reviewer 自觉或 CODEOWNERS 的简单映射，但缺少可追溯的强制机制。

核心能力与工作方式

这个技能围绕 Policy Bot 的 policy.yml 配置展开，核心工作流是：

1. 在仓库根目录维护一份 policy.yml，用声明式语法描述评审规则（谓词 + 要求）
2. Policy Bot 在 PR 上触发评估，根据规则匹配结果给出 approval 状态
3. 将评估结果暴露为必需检查，写入 PR 的 status 并阻止未满足条件的合并

规则评估后有四种状态，其中 approved 表示所有 predicates 和 requirements 都满足；pending 表示 predicates 成立但 requirements 尚未全部满足。

适用边界与注意点

• 需要部署 Policy Bot 实例（Docker 镜像或 Kubernetes），不是纯 GitHub 原生集成
• 规则是“全部通过”模型：一条 PR 必须满足所有启用的规则才会被批准
• 复杂规则的维护成本会转移给团队：规则写松了形同虚设，写严了可能阻塞正常开发
• 建议先在少量仓库试点，确认规则覆盖范围后再推广