检查项所发现的内容会依附于对应的任务，每次运行记录都会存入同一份日志中。每类内容都有固定的存放位置：
- 任务的发现结果。它们会被列在Factory中对应任务的“质量”板块下，标注每项结果的状态：仍未解决、正在修复、已修复或已认可。
- 没有归属任务的测试失败情况。比如，一次出错的定时浏览器测试会暂存在Factory的“审核”板块下。修复后可将其转为任务，或说明原因后直接认可。
- 无法运行的检查项。比如，当项目没有单元测试框架时，“质量管控”板块中的“单元测试”行会提示该情况，点击其“修复”按钮即可生成对应任务来搭建相关框架。
- 运行记录。每次运行的时长与消耗成本等信息都会列在“设置”下的“活动”板块中。
跨任务的工作模式
单个任务上的发现结果只是细节，若同一发现结果出现在三十个任务中则形成了模式，而正是这些模式能辅助做出有价值的决策。
需重点关注的内容：
- 重复出现的发现结果。同一问题在多个任务中反复出现，要么是值得专门处理的真实技术债务，要么是检查项不符合现有规范。
- 无人解决的发现结果。若某类结果一直被认可，说明对应的检查项并未发挥应有作用。
- 集中性。某个项目产生的发现结果最多，就说明应优先排查该项目。
运行记录
“活动”板块会列出组织内的所有运行记录：包括智能体、任务、质量检查和测试。可按结果、类型、项目和时间段筛选，还能打开对应运行记录查看其检查项、结果与输出内容。
此处的有用模式是：无关任务在相同阶段反复出现失败情况——这属于项目配置问题而非代码问题，重新运行任务也无法解决。详见构建与测试配置。
将模式转化为工作任务
重复出现的发现结果可转化为任务。这正是识别它的意义所在：“该模式出现在四十个文件中”属于需要处理的工作，而非代码库的永久状态。
若某情况需要持续监控而非人工检查，则可自动化自动监测该情况并开启修复任务。
调整而非容忍
若发现结果过多，说明检查项校准不当，而非代码本身存在特殊问题。
若大多数变更都会触发某检查项，说明它反映的是代码库的特性，而非发现了问题。要么是该规则不符合现有规范，要么是你选择容忍的技术债务，两种情况都意味着需要调整该检查项——详见质量策略与关卡。