IoT/doc/thinking/opus-review-prompt.md

Промпт для ревью (Opus) — IoT готовность к production

Ты ревьюишь Go-проект IoT. Цель — выявить блокеры, мешающие назвать сервис production-ready. Дай ответ МАКСИМАЛЬНО сжато, без воды: списком, короткими строками, с точными ссылками на файл и строку. Никаких пояснений-простыней.

Запрещено:

• Не читай память, историю сессий, заметки, предыдущие анализы, HISTORY/, LEGACY.md, ничего в legacy/. Только код и документация из списка ниже.
• Не читай старые k8s-манифесты, CRD, оператор — это легаси, не актуально.
• Не предлагай рефакторинг ради рефакторинга — только то, что блокирует прод.

Компоненты продукта (актуально): монолит iot-service (API + MQTT-bridge + SQS-consumer в одном бинарнике) + EMQX + shared-SQS + managed PostgreSQL. Конвейер: устройство → wss → EMQX → бридж → SQS → consumer → PG → REST API.

Смотри ТОЛЬКО эти файлы (актуальный код):

Конфигурация и точка входа:

• cmd/iot-service/main.go
• internal/service/config/config.go
• internal/service/config/defaults.go

HTTP API:

• internal/service/api/router.go
• internal/service/api/middleware/auth.go
• internal/service/api/middleware/logging.go
• internal/service/api/handler/handler.go
• internal/service/api/handler/devices.go
• internal/service/api/handler/mqtt_auth.go
• internal/service/api/handler/telemetry.go
• internal/service/api/handler/admin.go
• internal/service/api/handler/sqsstats.go

Хранение:

• internal/service/store/open.go
• internal/service/store/device.go
• internal/service/store/devices.go
• internal/service/store/bridge.go
• internal/storage/iotpg/iot_telemetry_store.go

Бридж и consumer:

• internal/service/bridge/bridge.go
• internal/service/bridge/handler.go
• internal/service/bridge/sender.go
• internal/service/consumer/consumer.go
• internal/service/consumer/processor.go
• internal/service/sqsclient/sqsclient.go

Инфраструктура:

• Dockerfile
• Makefile
• go.mod
• emqx/emqx.conf
• loadtests/README.md (только для понимания критериев, не весь код)

Вопросы (ответь строго по пунктам, каждому — вердикт + файл:строка):

1. Tenant-изоляция: как sub из JWT связывается с {namespace} в URL? Есть ли путь доступа к чужому namespace валидным токеном?
2. Гарантии доставки: есть ли окно потери сообщения между буфером записи, ответом об успехе и удалением из SQS? Где именно?
3. Идемпотентность: защищён ли вход от дублей при at-least-once SQS?
4. /health: отражает ли реальную работоспособность bridge/consumer или всегда ok?
5. Auth JWT: валидация sub/exp/подписи — что при пустом JWT_HMAC_SECRET?
6. Пароли устройств: как хранятся, как отдаются через API.
7. /internal/mqtt/auth и /internal/mqtt/acl: нужны ли ещё, защищены ли?
8. Ошибки записи в PG: что происходит с сообщением при сбое flush-батча?
9. Есть ли тесты (*_test.go), CI, rate-limiting, метрики, TLS-верификация PG?

Формат ответа: по каждому пункту — 1 строка вердикт (OK / ПРОБЛЕМА) + файл:строка + при проблеме — 1 строка суть. В конце — список «блокеры для прода» (только критические, без ранжирования по вкусу).