一个检查项属于单次验证。一个运行记录指针对某变更执行策略中的检查项的一次过程。发现结果是检查项所反馈的内容。
任务的发现结果位于其质量板块中，且每次运行的相关信息都可在设置 → 活动。
解读运行记录
运行记录会展示每个检查项的结果及其输出内容。若某项任务验证未通过，通过运行记录即可查明原因。
请自上而下阅读。首个未通过的检查项往往才是根本原因——后续的失败通常都是其衍生结果。比如构建失败之后出现的12个测试失败，本质上属于同一个问题，而非13个独立问题。
发现结果
发现结果由审核智能体、扫描工具和咨询关卡生成，每条记录都会标注发现的内容、位置及严重程度。属于某个任务的发现结果会与该任务绑定；若某测试失败未关联到任何任务，它会暂存在Factory的审核板块中，供你修复或注明接受理由。无法在项目中运行的检查项，比如缺少测试框架的单元测试，会在质量审核板块的对应行中予以说明。
其生命周期如下：
- 已提出由检查项或审核人员提出。
- 已路由——可修复的发现结果会回传给开发智能体进行返工；其余则关联至pull request。
- 已解决——已修复、已接受或已忽略。
已提出
- 预警关卡
审阅者智能体- 关联的扫描工具
已分配
可修复
退回给开发人员作为返工内容
其他情况
附在pull request中
已解决
已修复
该变更解决了问题
已采纳
确实如此，但此处无需处理。请说明原因。
已忽略
属于误报或不适用的规则。请说明原因。
分类处理
针对每条发现结果，需考虑的问题并非“它是否属实？”，而是“它是否会影响后续流程？”
- 立即修复——涉及正确性、安全性等任何会导致审核不通过的内容。
- 接受——内容属实但当前无需处理。需记录接受原因。
- 忽略——属于误报，或该规则不适用于当前代码。
忽略操作需有明确理由。若无说明的忽略行为，与刻意隐瞒真相无异，六个月后便无人能分辨二者的区别。
当发现结果过多时
数量多少反映的是配置问题，而非代码质量问题。
若多数变更都会触发某检查项，那它并非在发现问题，而是在描述现有代码库的特征。要么是该规则不符合团队规范，要么是你选择容忍的技术债务。无论哪种情况，都说明该检查项的设置并不合理。
发现结果与关卡
来自建议性关卡的发现结果是参考信息；而来自阻断性关卡的同一发现结果则会中止任务流程。二者内容相同，差异在于策略规定的处理方式不同。
当检查项正确但过于严格时，可调整其严重程度而非直接移除它。详见质量策略与关卡。