2.2 KiB
2.2 KiB
Моё мнение — сравнение аудитов Опуса и 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 → Опус. Сначала закрыть риски эксплуатации, потом архитектурные улучшения.