# Промпт для Opus — анализ архитектуры shared-sqs (2026-10-05)

> Назначение: дать модели Opus контекст и точный список файлов для чтения,
> чтобы она проанализировала архитектуру shared-sqs и выдала идеи
> архитектуры (в т.ч. «КРАКО» — критический разбор архитектуры) без чтения
> лишних файлов.

---

## ЗАДАЧА

Проанализируй архитектуру сервиса `shared-sqs` (SQS-совместимая очередь, Go,
мультитенантная, форк GoAWS) и выдай:

1. **Критический разбор архитектуры (КРАКО)** — слабые и сильные места,
   риски, узкие места, что мешает назвать сервис готовым к продакшну.
2. **Идеи по архитектуре** — как довести сервис до production-ready:
   приоритизированный список доработок (P0/P1/P2) с обоснованием.

Не меняй код. Только читай и анализируй.

## ЧТО ЧИТАТЬ (allowlist — ТОЛЬКО эти файлы, ничего больше)

**Точка входа и роутинг:**
- `app/cmd/goaws.go`
- `app/cmd/seed.go`
- `app/router/router.go`

**Конфигурация:**
- `app/conf/config.go`
- `app/conf/goaws.yaml`

**SQS-реализация (ядро):**
- `app/gosqs/gosqs.go`
- `app/gosqs/receive_message.go`
- `app/gosqs/send_message.go`
- `app/gosqs/create_queue.go`
- `app/gosqs/validation.go`
- `app/gosqs/tenant_helpers.go`

**Аутентификация / изоляция тенантов:**
- `app/auth/auth_middleware.go`
- `app/auth/jwt.go`
- `app/auth/cache.go`
- `app/tenant/tenant_store.go`

**Модели данных:**
- `app/models/models.go`
- `app/models/constants.go`
- `app/models/globals.go`

**Персистентность:**
- `app/persistence/redis.go`

**Биллинг и метрики:**
- `app/billing/billing.go`
- `app/metrics/metrics.go`

**Admin API:**
- `app/admin/admin.go`

**Интерфейсы:**
- `app/interfaces/interfaces.go`

**Документация (для контекста состояния):**
- `README.md`
- `doc/architecture/tenant-isolation.md`
- `doc/billing-and-metrics.md`
- `doc/byoc-credentials.md`
- `HANDOFF-NEW-CHAT.md`

## ⛔ ГДЕ НЕ ЛАЗИТЬ

- **Не читать** `doc/legacy/**` (исторический план, старые решения — устарели).
- **Не читать** `deployments/**` (легаси k8s/helm).
- **Не читать** `doc/thinking/nubes-*` (сетевые тикеты платформы — отдельная
  задача, не относится к разбору архитектуры кода).
- **Не читать** тесты `*_test.go` — они нужны только как сигнал «что покрыто»;
  для анализа архитектуры достаточно факта наличия из списка `app/gosqs/*`.
- Не искать файлы за пределами перечисленного списка.

## КЛЮЧЕВОЙ КОНТЕКСТ (факты, которые уже установлены — не перепроверять с нуля)

- **Стек**: Go 1.23, gorilla/mux v1.8.0, redis/go-redis/v9, lib/pq,
  prometheus/client_golang. Сервис — один Go-бинарник.
- **Состояние**: прод v0.1.35, все тесты зелёные, нагрузка 168 591 операция
  без сервисных ошибок. НО есть известные открытые вопросы (ниже).
- **Персистентность**: Redis write-through cache. Память — источник правды
  для чтения; Redis — для восстановления после рестарта. Записи в Redis
  асинхронные (кроме DeleteMessagePersist — синхронно).
- **Изоляция тенантов**: очередь хранится по ключу `{AccessKey}:{queueName}`;
  `TenantStore` с тремя индексами (`byID`, `byAccessKey`, `byEmail`).
- **JWT-валидация**: подпись НЕ проверяется (trusted perimeter) — только
  структура + `exp` + `PingNubesAPI()` (проверка token через API Gateway).
- **Биллинг**: асинхронная запись в PostgreSQL (таблица `sqs_usage_records`),
  опционально (включается при `BILLING_PG_HOST`).
- **Внешняя проблема (НЕ код, на анализ кода не влияет)**: периодические
  сетевые таймауты ~31–33с на внешнем шлюзе Nubes + MSS-баг для больших тел.
  Разобрано в тикете — это задача платформы, не кода.

## ИЗВЕСТНЫЕ ОТКРЫТЫЕ ВОПРОСЫ (кандидаты в «доделать» — проверь их актуальность по коду)

1. **BYOC-credentials** — backend `CreateFixed` есть, но Admin API/UI
   (`POST /admin/tenants` с произвольными ключами) помечен TODO.
2. **Подпись JWT не проверяется** — насколько это приемлемо для multi-tenant
   прод-сервиса, или нужно усилить.
3. **Дрейф доков** — версии в README/Makefile/HANDOFF не всегда совпадают.
4. **Легаси** — невычищенные следы старого k8s/helm-деплоя и SNS.

## ФОРМАТ ОТВЕТА

1. **КРАКО** — короткий критический разбор: что хорошо, что плохо, главные
   риски (по коду, а не по платформе).
2. **Приоритизированный план доработок** (P0/P1/P2), с указанием конкретных
   файлов и сути правки.
3. Список **противоречий/несоответствий** между доками и кодом, если найдёшь.