验证门控与自动化
概述
验证在哪里执行以及什么使其成为真正的门控。CI是真理的源头；本地钩子只是一个便捷的镜像。 一个未被不可绕过的门控强制执行的规则只是一个建议（原则7）——因此，当平台无法提供这样的门控时，项目声明为advisory（建议）模式，并有意地遵循规则，而不是假设它不具备的机制。
规则
- 一个任务运行器是每个日常操作的规范入口——测试、构建、开发、部署都是命名的配方。只存在于某人脑海中的流程无法可靠地执行，也无法交给代理。
- CI是真理的源头——权威、共享，并且在平台允许的地方不可绕过。 Lint、类型检查、合约检查、测试、安全扫描、提交验证都在这里运行，并且在
enforced（强制）模式下必须在合并前通过。CI说了算。在advisory模式下，相同的检查运行并报告；门控依靠纪律，这绝不是减少检查数量的理由。 - pre-push钩子是一个提交前镜像，而不是一堵墙。 它本地运行相同的快速检查，这样你可能在推送前就通过了CI。它明确是可绕过的（
--no-verify），并且只在安装了工具链的地方运行。它的职责是速度和早期反馈，而不是强制执行。钩子从不门控；只要平台允许，CI门控。 - 通过分层而不是移除检查来保持CI快速。 当完整套件超出每个PR的负荷时，将presubmit（快速子集，阻塞PR）与postsubmit（完整套件，合并后运行，阻塞提升）分开——永远不要将权威检查移回可绕过的钩子。
- 容器镜像在CI中构建，通过内容摘要标识，并附带来源证明发布。通过注册表层缓存或自托管运行器保持成本可控——永远不要将构建移回笔记本电脑，在那里其他人无法验证产物的来源。
- 声明强制模式。
enforced（强制）——CI通过分支保护阻塞合并；CI说了算。advisory（建议）——CI运行并报告，门控依靠纪律，因为分支保护不可用（例如私有仓库的免费计划）。建议是合法的；声称拥有你并不具备的强制能力则是不合理的。在项目的第一个决策记录中声明模式，以及什么条件会使其变为强制。
命名的张力
一个可绕过的本地提交前检查快速但不可强制执行；权威的CI可强制执行但较慢。通过赋予它们不同的职责来解决——钩子优化内部循环，CI优化记录的正确性——并且让CI，而不是钩子，成为阻塞合并的因素。
常见合理化
| 借口 | 现实 |
|---|---|
| “pre-push钩子运行了测试，所以CI可以最小化” | 钩子是可绕过的且依赖工具链。它不能作为真理的源头。CI必须重新运行所有内容。 |
“我就这一次用 --no-verify 绕过” | 没关系——因为CI仍然会抓住它。这正是CI而不是钩子作为门控的原因。 |
| “CI太慢了，把测试移到钩子里吧” | 分层CI（presubmit/postsubmit）；永远不要将权威检查迁移到可绕过的门控。 |
| “CI构建太慢了，我本地构建镜像吧” | 笔记本电脑构建的产物携带无人能验证的来源。使用层缓存或自托管运行器解决延迟问题。 |
| “分支保护要花钱，所以规则不适用” | 规则适用；执行方式不同。声明建议模式并保持纪律，或者将仓库设为公开以免费获得保护。 |
红旗——立即停止
- 权威检查仅存在于本地钩子中
- CI不重新运行钩子已运行的检查
- 在CI为红色时允许合并
- 镜像在CI以外的任何地方构建，或者通过标签而非摘要进行提升
- 项目表现得像CI门控了合并，但实际上不存在分支保护
完整理由：章程第八章，捆绑在 engineering-constitution/references/engineering-constitution.md 中。部署/kubernetes 细节：cloud-delivery-aks。