Coroid在处理任务时会做出诸多决策：判断某个请求是否应转化为实际工作、如何构建该任务成果，以及该成果是否足够优质可供展示。少数决策始终无法脱离人的干预，其中合并操作是最典型的一类。
Coroid做出的决策
- 判断某个请求是否转化为实际工作。 资格审核检查是否存在重复内容、已修复的问题以及无法复现的缺陷。对于无人提交的请求，则由准入机制在您的授权下决定其处理方式。 授权确定工作是否可以立即启动、延后启动或根本不启动。
- 任务的构建与验证方式。计划、代码、测试、质量关卡、QA及审核流程。详见 Coroid如何验证自身的工作成果。
- 关于合并操作它会做出怎样的决策。Coroid会对它审核的每个pull request记录一份判断，但不会依据该判断采取任何行动。详见 Coroid如何核验自身的判断。
需由人确认的决策
| 决策 | 决策者 |
|---|---|
| 将pull request合并到您的分支中 | 由GitHub或GitLab中的人员，或相关负责人执行审核并合并在Coroid中操作 |
| 发布并部署 | 由人员通过您的流水线或Coroid中的发布流程执行 |
| 说明无人值守工作的用途及预算 | 所有者或管理员通过发布一条授权来设定相关内容授权 |
| 说明某项工作的完成标准 | 提出该需求的人员，在其成果约定中明确相关内容成果约定 |
| 创建工作，资格审核终止 | 拥有权限的人员，通过以下方式操作强行创建工作并说明相关理由 |
Coroid绝不会自行执行合并操作，也没有任何设置可以更改这一规则。详见合并操作。
授权不会改变合并操作的决策者。
授权令允许无需逐个请求即可启动工作。但它不会让结果未经人工决策就直接落地。通过授权令准入的工作会与其他任务接受同样的验证流程，最终同样生成等待人工审核的拉取请求。
授权令的作用是为无人值守的工作明确责任边界：它可涉及哪些项目、可花费多少资源，以及针对该工作的所有决策记录。
Coroid如何校验自身的判断
对于每一项由pull request发起、需经Coroid审核的任务，以及所有准备合并的任务，Coroid都会记录下若获准合并时它会做出的决策：
- 将会批准。所需的一切条件均已满足且达标：包括针对pull request最新提交的质量校验、Coroid的审核结果、供应商的校验结果、干净的合并流程，以及任务的QA结论和审核人意见。
- 将会驳回。至少存在一项上述驳回条件。
- 无法判定。缺少必要的依据。缺失的证据绝不能视为批准。
该判断绝不会被同步至pull request，不会改变任务状态，也不会触发任何合并操作。目前它也不会在Coroid中展示。
随后，Coroid会将每项判断与合并后实际发生的情况进行对比：
- 后续创建的、标题为“pull request回滚…会将前者标记为已回滚；
- 后续创建的、内容为“pull request修复 #n会将pull requestn标记为 热修复；
- 在任务的审核界面中，位于合并后发生的情况，组织内的任何人都可以将已合并的pull request标记为已回滚、已热修复或 缺陷已上报。
对于后续被回滚或修复的pull request而言，其对应的批准属于错误批准。在其自身的代码库中，Coroid还会刻意输入与实际变更内容一致的损坏副本，用以测试其识别能力。
为何保留此记录
这样，“Coroid能否被信任来合并此类变更？”这一问题就能有依据作答——即它的批准出错的频率、针对哪类变更、有多少实例佐证——而非仅凭主观信心判断。目前该记录不会触发任何实际操作。若未来发生变化，那将是所有者明确做出的选择，而此记录正是该决策的依据。