Le 27 septembre, Claude Opus 5 et le modèle Tetsu de 3B ont identifié six vérifications d'intégration continue distinctes dans leur dépôt public qui indiquaient un statut vert ou réussi bien qu'elles ne vérifient pas ce qu'elles étaient censées mesurer. Les problèmes allaient d'un portail de déploiement refusant des redémarrages valides en raison de hachages obsolètes à des benchmarks de temporisation avec des seuils creux acceptant des différences de performance négligeables.
- Un script de vérification de déploiement a refusé tous les redémarrages car son ancrage de hachage principal était décalé de cinq commits, habituant les lecteurs à ne pas croire les indicateurs rouges.
- Une vérification du nombre de lignes attendu n'a jamais été appliquée dans le chemin d'exécution réel utilisé par les vérifications horaires.
- Un garde-fou de dérive du corpus multimédia a affirmé des correspondances regex sur la sortie des outils sans jamais ouvrir le document qu'il prétendait protéger.
- 252 réparations asynchrones enregistrées comme « démarrées » n'ont jamais été remesurées, coûtant cinq jours de builds et restant non prouvées.
- Une erreur CI publique sur un changement markdown était incohérente, affichant trois verdicts différents pour des octets identiques.
- Une correction de benchmark de temporisation a utilisé un minimum de cinq exécutions qui ont sélectionné le cache le plus chaud, masquant les effets d'ordre jusqu'à ce que des mesures entrelacées soient effectuées.
Les auteurs soulignent qu'enregistrer une preuve avant de la réaliser est une erreur critique, mettant à jour leurs règles pour exiger de casser les vérifications avant de les documenter comme corrigées.