# Sonnet Analysis — 2026-06-24 — Auto-classification

## 1. Архитектура: отдельный /api/classify
Не встраивать в upload. Отдельный эндпоинт → фоновая классификация → SSE прогресс → UI подтверждение.

## 2. Промпт classify
Только header (первые 50 элементов / 2000 символов). Экономия токенов в 5-10 раз.
Поля: doc_type, contract_number, doc_date, counterparty, parent_contract_number.

## 3. Группировка
Новая таблица doc_classifications (staging). Группировка по (contract_number, counterparty) + fuzzy match.
Существующих contracts + supplements достаточно для хранения итога.

## 4. Схема БД
- ALTER supplements ADD sort_order
- CREATE TABLE doc_classifications (staging)

## 5. UI
Карточки групп (contract), внутри — сортированный список документов.
Действия: перенести, изменить тип, подтвердить, запустить сравнение.

## 6. Массовая загрузка
ZIP → batch upload → 5 параллельных воркеров (threading.Thread + queue.Queue).
2000 файлов × 6s / 5 воркеров ≈ 40 минут.
Память: BYTEA в PG для пилота ОК, для прода нужен S3.

## 7. Приоритеты
1. doc_classifications + промпт classify — низкая сложность, критично
2. /api/classify (один doc_id) — низкая, критично
3. Batch ZIP + workers + SSE — высокая, критично
4. Алгоритм группировки — средняя, критично
5. UI review — средняя, важно
6. /process-v2 per group — низкая, важно
7. Артикул→каталог — высокая, отложить

## Риски
- threading в http.server: на пилоте ОК, для прода нужен gunicorn
- Промпт classify надо обкатать на реальных документах ДО реализации