docs: архитектурный анализ + History + gitignore (2026-06-27)

History/opus-classify-async-question.md

@@ -0,0 +1,28 @@
+# Вопрос к Опусу — фоновая классификация при 50+ файлах
+
+## Что сделано
+
+`POST /api/classify-batch` получает `{batch_id}`, запускает `classify_worker.py`
+через `subprocess.Popen` и сразу возвращает `202 {total: N}`.
+Фронтенд поллит `/api/batch-progress` каждые 2с пока `done >= total`.
+
+`classify_worker.py` — отдельный питон-процесс, импортирует `services/classify.py`,
+у которого внутри `ThreadPoolExecutor(max_workers=4)` для параллельных
+LLM-вызовов (один файл = один LLM-запрос к api.aillm.ru).
+
+## Проблема
+
+С 4 файлами полный цикл работает. С 69 файлами:
+- HTTP-сервер жив, `/health` отвечает
+- `classify_worker` работает
+- Симулятор с внешней машины не дожидается конца — на 5+ минутах рвётся сеть/nginx
+
+## Вопросы
+
+1. Архитектурно `subprocess.Popen` норм для прода? Или что-то более надёжное (очередь, systemd-таймер, воркер-пул)?
+
+2. Что делать с nginx при долгих запросах? `batch-progress` — короткий поллинг, он не должен рваться. Но сам classify через фронтенд не идёт — только через воркер. Где узкое место?
+
+3. При двух быстрых классификациях подряд — второй `Popen` создаст второй процесс. Старый ещё не умер. Надо проверять и убивать предыдущий? Или пусть оба работают (разные batch_id)?
+
+4. Как правильно мониторить/логировать фоновый процесс? Сейчас stdout/stderr в `/dev/null`.