在您看到 Coroid 中的 pull request 之前，它已经过验证。本节将介绍其含义及配置方法。
各层级
验证并非单一流程，共包含四个层级，每个层级解答不同的问题。
您的测试套件。这是最可靠的信号，因为它已体现团队认定的关键要求。Coroid 会在每个任务中于干净的工作空间内运行该测试套件。
质量门控。由策略定义的检查项——覆盖率、代码规范检查、浏览器测试，以及全球化检查项用于多语言项目。阻断型门控会阻止任务继续；建议型门控仅记录结果并允许任务继续执行。详情请参阅质量策略与门控。安全扫描有独立模块：详见安全。
审核。审核代理会读取完成的代码差异并生成检查结果。可修复的结果会退回给开发者重新处理；其余结果会附加到 pull request 上。
佐证材料。预览部署、扫描结果及覆盖率差异均会附加在 pull request 本身上，因此验证结果会与代码一同呈现。详情请参阅审核佐证材料。
- 您的测试套件该变更会破坏现有功能吗？
- 质量关卡它符合既定规范的要求吗？
- 评审细心的代码审阅者会接受它吗？
- 佐证材料相关证明已附在代码旁了吗？
- 您的评审这是应当做出的正确变更吗？
每个自动化层级都会在pull request生成前运行，因此失败结果会作为返工内容反馈到运行流程中。
验证所能证明及无法证明的内容
验证可确认变更符合预期功能、不会破坏现有功能，且满足设定的标准。
但它无法证明该变更是值得开发的。这正是需求说明中规定的验收标准以及审核环节的作用所在。
即便通过所有层级验证，变更仍可能是错误的。明确区分这一点才能确保整个流程的可信度——一旦将验证等同于最终判定，人们便会停止审核。
提前运行验证的意义
在 pull request 生成前，各层级便会先运行验证，这样失败结果会作为返工任务返回，而非生成您最终会拒绝的 pull request。
在工作空间内失败的成本远低于在屏幕上发现问题时付出的成本。您的审核应是首次人工审阅，而非首次查看。
入门指南
如果您是首次配置该功能：
- 确保您的测试套件能正常运行——详见 构建与测试配置。若此项配置有误，其他设置均无关紧要。
- 在您的标准层级设置组织默认策略，无需采用最严格的标准。
- 关联您已在使用的佐证材料提供方。
- 逐一添加门控，优先添加建议型门控。