diff --git a/HISTORY/2026-08-16-session-log.md b/HISTORY/2026-08-16-session-log.md
index 040f563..5ffb330 100644
--- a/HISTORY/2026-08-16-session-log.md
+++ b/HISTORY/2026-08-16-session-log.md
@@ -334,3 +334,55 @@ Python 3.10, websocket-client 1.9.0 установлен. Тот же скрип
   (или python websocket-client, ping 25с / echo 10с) — обрыв на 150–173с.
 - Связь с shared-sqs: таймауты 31–33с (~5.5% HTTP-запросов), MSS=1448 при
   MTU 1400 — вероятно, тот же внешний шлюз.
+
+---
+
+## 10. Консультация Sonnet (промпт → ответ) — критическая оценка
+
+**Что сделано:** составлен промпт для Sonnet (жёсткий список файлов: HISTORY
+2026-08-16, migration-to-managed, sqs-integration, architecture/current-v0.2.3,
+deployment-v0.2.3; 9 вопросов; формат «Ответ/Рекомендация/Риски», без кода).
+Ответ получен, оценён ниже.
+
+**Ключевые рекомендации Sonnet (приняты):**
+- Компоновка: EMQX-контейнер + Go-монолит (API+bridge+consumer в одном бинарнике).
+- EMQX оставить (не mochi-mqtt), если настроится на платформе.
+- SQS в середине потока СОХРАНИТЬ (буфер при падении PG, admin-stats).
+- Auth: перенос Secrets→таблица iot_devices ДО переключения; закрыть
+  authTestMode и ADMIN_STATS_TOKEN до прода.
+- 3 фазы миграции; откат — DNS обратно; критерий готовности переключения
+  устройств: wss ≥600с с 3 независимых интернет-точек.
+- Вопросы в техподдержку Nubes: кастомный домен, лимит ~150с, таймауты
+  31–33с, MSS, subprotocol mqtt, multi-port, PVC, latest-pull, лимиты.
+
+**ПОПРАВКИ к ответу Sonnet (важно):**
+1. **PG НЕ меняется.** Managed PostgreSQL уже используется текущим consumer'ом
+   (IOT_PG_DSN → postgresqlk8s…svc.cluster.local). Утверждение Sonnet «новые
+   данные пишутся в новую PG» — ОШИБКА. Телеметрию переносить не нужно вовсе;
+   переносятся только CRD-объекты (устройства+пароли).
+2. **Платформенные контейнеры живут в ТОМ ЖЕ кластере**, что и старый деплой
+   IoT: ноды `iot-naeel-*`, ingress `shturval` — один кластер. Значит старый
+   вход `iot.kube5s.ru` (185.247.187.147), скорее всего, идёт через ТОТ ЖЕ
+   краевой шлюз — вариант Sonnet «EMQX на старом кластере как точка входа»
+   проблему не обходит (и его сомнение в обратную сторону неверно).
+   Проверяемо тестом: держать wss к `wss://iot.kube5s.ru/mqtt` 5+ мин —
+   если stall ~150с есть и там, текущие устройства уже страдают.
+3. **Multi-port** у Sonnet заявлен как факт в п.1 («1883 внутренний для bridge»),
+   но в п.9.6 сам же помечен НЕИЗВЕСТНО — противоречие. Вероятный реальный
+   сценарий: один порт на контейнер → EMQX наружу только 8083 (wss), bridge
+   к EMQX тоже по wss внутри платформы.
+4. **Конфиг EMQX через env — не блокер.** EMQX 5 поддерживает env vars
+   (EMQX_*); плюс можно собрать свой образ на базе emqx/emqx с вшитым
+   emqx.conf (публичный Docker Hub) — снимает ограничение полностью.
+5. **/metrics уже есть** в текущем операторе (порт 8080, controller-runtime)
+   — переносится в монолит, а не «отсутствует» (ошибка Sonnet).
+6. **bcrypt для паролей** — ок для НОВЫХ устройств, но для переноса старых
+   нужен скрипт: прочитать все Secrets `iot-{deviceId}` в ns sless и вставить
+   в таблицу с сохранением работоспособности (хэшировать при вставке).
+7. Дубли при at-least-once: нужен dedup-ключ в InsertTelemetry
+   (например уникальный индекс по (namespace, device_id, received_at) или
+   message-id) — сейчас отсутствует.
+
+**Следующий шаг (предложен, ждёт «делай»):**
+- Тест wss к СТАРОМУ прод-домену `wss://iot.kube5s.ru/mqtt` (5 мин, станция +
+  Vultr) — определить, страдают ли текущие устройства от того же шлюза.