# Критический анализ отчёта Opus (мой разбор, 2026-10-05)

> Кем: я (DeepSeek). Что: критический разбор отчёта Opus
> (`opus-report-2026-10-05.md`) по архитектуре shared-sqs.
> Метод: ключевые утверждения Опуса перепроверялись по коду напрямую, а не
> принимались на веру. Источники — «файл:строка».

---

## Что я перепроверил по коду (факты)

| Утверждение Опуса | Вердикт | Источник в коде |
|---|---|---|
| P0.1: SecretKey детерминирован из email + соль в исходнике | ✅ подтверждено | `tenant_store.go:289-292` `secretKeyFromEmail` = `SHA256(lower(email)+":shared-sqs:secret-key:v1")`; соль — константа `secretKeySalt` (`tenant_store.go:286`); `accessKeyFromEmail` = `SHA256(email)[:12]` |
| P0.2: JWT без проверки подписи, доверие на PingNubesAPI | ✅ подтверждено | `jwt.go` — парсинг структуры + `exp`; `PingNubesAPI` принимает, если хоть один стенд не 401/403 |
| Кэш: отозванный токен живёт до ~7 мин | ✅ подтверждено | `cache.go`: `cacheTTL=5m`, `cacheGraceTTL=2m` |
| Глобальный мьютекс на весь сервис | ✅ подтверждено | `globals.go:20-23` — один `SyncQueues.RWMutex` + `Queues map[string]*Queue` |
| Сиротство очередей при пересчёте legacy-тенанта | ✅ подтверждено | `tenant_store.go:202-205` — комментарий в коде сам это описывает |
| MessageRetentionPeriod не реализован | ✅ подтверждено | `models.go` — `// TODO - not used` |

Ложных утверждений не найдено.

---

## Сильные стороны отчёта

1. **P0.1 — самая ценная находка.** Детерминированный вывод SecretKey из
   публичного email — реальный, доказуемый по коду дефект. Указан не только
   механизм, но и точные функции. Именно это реально блокирует «готовность SQS».
2. **Верно разделены SigV4 и JWT.** SigV4 проверяется полноценно
   (`auth_middleware.go`: canonical request, `subtle.ConstantTimeCompare`,
   clock skew, presigned); JWT — нет. Большинство поверхностных ревью их путают.
3. **Классификация P0/P1/P2 адекватна** — безопасность+durability отделены от
   масштабируемости и гигиены.
4. **Пункты 3–7** (глобальный лок, SPOF, async-Redis, нет RetentionPeriod,
   плоский слайс) — архитектурно точны.
5. **Раздел «противоречия док↔код» конкретен** (особенно №1: док про
   `sub`/`bySub`/`sless-`, код про `email`/`byEmail`/`t-`).

---

## Слабые места и оговорки

1. **P0.2 переоценён как самостоятельный «критичный».** Вектор «подмена email
   → доступ» опасен **только в связке с P0.1**: неверный email даёт чужие креды,
   потому что креды детерминированы из email. Исправь P0.1 (случайные креды в
   Redis) — и неверный email из JWT уже не даст чужих ключей, только
   провиженинг под чужим именем (менее критично). Опус не связал P0.1 и P0.2
   явно, хотя атака работает попарно. Стоит оформить как один инцидент.

2. **П.4 «SPOF/нет горизонтального масштабирования»** — справедливо
   архитектурно, но сервис и проектировался single-instance managed
   HTTP-контейнером (README). Это осознанное ограничение, а не баг. В разряд
   «высокого риска сейчас» ставить преждевременно — это долгосрочная
   архитектурная развилка, а не текущий блокер.

3. **П.5 (async-Redis = потеря подтверждённых сообщений) — полуверно.**
   Сообщение в памяти уже есть (клиент получил 200 = сообщение в памяти,
   источнике правды). Теряется только при краше пода **до** async-`HSet`, и
   только это узкое окно. Окно реально, но «нарушение durability» подано
   сильнее, чем есть: теряются не все сообщения, а только при краше в окне.

4. **П.10 (timing side-channel admin-токена)** — технически верно, но admin-токен
   приходит как высокоэнтропийный bearer; практическая эксплуатируемость timing-атаки
   через сеть у одного короткого сравнения ничтожна. Формально в P2 и есть, но
   вес в подаче чуть завышен.

5. **П.14 (`/metrics` публичен)** — стоит оговорка: лейбл `tenant` = tenantID
   (`t-...`), а НЕ SecretKey. Утечка реальна (число очередей/сообщений по
   тенанту), но это не утечка кредов. Формулировка корректна, но без оговорки
   читается страшнее.

6. **Пробел контекста (не ошибка Опуса, а следствие моего allowlist-запрета):**
   отчёт не отделяет «код-блокировку» от «платформенной блокировки» — периодические
   таймауты ~31–33с и MSS-баг для тел >~1400 байт (разобрано в
   `doc/thinking/nubes-ticket.md`). Даже идеальный код их не уберёт. Итоговый
   вывод о «готовности SQS» надо читать с этой поправкой.

---

## Итоговая оценка

Отчёт — **добротный, по фактам точный**. Из 16 пунктов рисков ложных нет;
спорные — только **вес/приоритет**:
- P0.2 связать с P0.1 (один инцидент);
- п.4 (SPOF) и п.10 (timing) слегка переоценены для текущей single-instance роли.

Главная ценность: **P0.1 (детерминированный SecretKey)** — подтверждённый по
коду блокер готовности, который до этого так жёстко не формулировался.
Единственный реальный пробел — платформенный контекст (таймауты/MSS), но он
возник из моего же allowlist и устраняется дополнением, не исправлением.