# Архитектурный аудит polygon v0.2.5 — ответ Опуса

Дата: 2026-07-31

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

Архитектура здоровая и соразмерная задаче. Blueprint-разбиение, data-driven из STANDS YAML, синхронный run без потоков, единый config/loader — правильные решения.

Но есть **структурный разрыв**: сервис задеплоен как публичный managed-сервис, при этом спроектирован как эксклюзивный однопользовательский in-memory стенд.

---

## Находки

### 🔴 1. Публичный деплой + общий global state → изоляция тестов ломается в параллельном CI

Две параллельные pytest-сессии делят одно состояние. `reset()` одной сессии стирает инстансы другой.

**Решение:** namespace-изоляция по `X-Test-Session: <uuid>` ИЛИ per-session контейнер в CI.

### 🔴 2. Основной API без аутентификации на публичном домене

`MOCK_AUTH_TOKEN` защищает только `/_mock/*`. POST /instances, /instanceOperations, run — открыты полностью.

**Решение:** `before_request` на уровне app (проверка `Authorization: Bearer <любой>`) или сетевое ограничение.

### 🟡 3. Синхронный sleep блокирует весь сервер

При `--workers 1`, `time.sleep(DELAY)` в run сериализует ВСЕ запросы. При `delay=5` сервер заморожен на 5 секунд.

Конфликтует с исходным планом Опуса (решение Q4 — «ленивый dtFinish»). Реализация ушла в синхронный sleep.

### 🟡 4. _extract_subresource_name — хрупкий выбор имени

Берётся первое непустое строковое значение в op_params. Порядок параметров не гарантирует что имя пойдёт раньше пароля.

**Решение:** маппить по коду параметра через cfsParams.

### 🟡 5. Память не ограничена + нет симуляции ошибок

- Операции и op_params не чистятся никогда → медленная утечка
- run всегда `isSuccessful=True` → мок не умеет эмулировать падение
- Нет cap на число инстансов

## Ответы на вопросы

**Q1. In-memory vs Redis.** Persistence не нужен для CI. Рестарт = чистый стенд, это фича.

**Q2. Масштабирование.** Безопасно только при эксклюзивном владении. Рекомендация: polygon per-session в CI (снимает находки 1, 2, 3 разом).

**Q3. Генерация YAML при старте.** Не надо. Оставить offline. Добавить CI-проверку «from_stands.py даёт тот же результат».

**Q4. Мониторинг.** Prometheus избыточен. Достаточно `/_mock/state` + структурные логи.

**Q5. Готовность к CI.** К последовательному CI — готов. Блокеры для параллельного: изоляция сессий (1), auth API (2), симуляция ошибок (5).

## Приоритеты

1. Решить модель владения — per-session контейнер ИЛИ namespace-изоляция
2. Симуляция ошибок операций — для негативных тестов
3. Auth-гейт основного API
4. Маппинг subresource-имён по коду параметра
5. Косметика версии