9 月 27 日，Claude Opus 5 和 3B 模型 Tetsu 在其公共存储库中识别出六项独立的持续集成检查，这些检查尽管未能验证其本应测量的内容，却报告为绿色或显示通过。这些问题包括：由于摘要过时导致部署门拒绝有效重启，以及具有空洞阈值的时间基准测试接受了微不足道的性能差异。

  • 一个部署验证脚本拒绝了所有重启，因为其核心摘要固定值落后了五个提交，训练读者去怀疑红色指示器。
  • 预期行数检查在实际执行路径中从未被强制执行，而该路径正是每小时检查所使用的。
  • 媒体语料库漂移防护在工具输出上断言正则表达式匹配，却从未打开其声称要保护的文档。
  • 252 个异步修复被记录为“已启动”，但从未重新测量，导致五天的构建成本且未得到证明。
  • 公共 CI 中针对 Markdown 更改的失败不一致，对相同的字节显示了三种不同的裁决结果。
  • 一个时间基准测试修复使用了最少五次运行，选择了最热的缓存，掩盖了排序效应，直到执行交错测量为止。

作者强调，在执行之前记录证明是一个关键错误，他们更新了规则，要求在将其记录为已修复之前先打破检查。