# Моё мнение — сравнение аудитов Опуса и Fable 5

Дата: 2026-07-31

## Кто что нашёл

| Находка | Опус | Fable 5 |
|---------|------|---------|
| Auth на основном API | 🔴 | 🔴 |
| sleep блокирует /health → pod restart | — | 🔴 |
| setdefault не работает (gunicorn timing) | — | 🔴 |
| int(param_id) без try → 500 | — | 🟡 |
| modify на creating-инстансе | — | 🟡 |
| Публичный деплой vs single-user | 🔴 | — |
| _extract_subresource_name хрупкий | 🟡 | 🟡 |
| Память не чистится | 🟡 | 🟢 |
| Нет симуляции ошибок | 🟡 | 🟡 |
| Синхронный sleep vs ленивый dtFinish | 🟡 | — |
| stages: [] всегда пуст | — | 🟢 |

## Оценка

**Опус** — архитектор. Смотрит на систему сверху: «правильно ли спроектировано под задачу?». Нашёл структурный разрыв (публичный деплой vs однопользовательский дизайн), дал стратегические рекомендации (per-session модель).

**Fable 5** — инженер. Смотрит на код снизу: «что сломается при эксплуатации?». Нашёл три бага которые никто не заметил:
- `setdefault("WEB_CONCURRENCY", "1")` — не работает (gunicorn читает env ДО импорта app)
- `sleep(DELAY)` блокирует `/health` → если delay > healthcheck timeout → Nubes рестартит под
- `int(param_id)` без try → 500 на кривом JSON

## Что делать

Приоритет Fable прагматичнее: две строчки кода (cap DELAY + токен) спасут от краша пода. Приоритет Опуса стратегический: per-session модель нужна для параллельного CI, но это потом.

**Порядок:** Fable → Опус. Сначала закрыть риски эксплуатации, потом архитектурные улучшения.