# Opus 4.8 Analysis — 2026-06-24 — Auto-classification

## Главный вывод
Текущая модель — «один договор на сессию загрузки». upload.py: первый файл → contracts + supplement initial, остальные → additional к тому же. Связь документ→договор ТОЛЬКО через supplements. Авто-классификация — обратная задача: N файлов → M договоров. Это архитектурное изменение, не промпт.

## Q1: Поля в documents или staging?
**Поля в documents.** + batch_id (привязка к сессии загрузки) + parent_number (отдельно от own_number). 7 колонок:
doc_type, own_number, parent_number, doc_date (TEXT, не DATE), counterparty, classify_status, batch_id.

## Q2: classify в upload или отдельно?
**Отдельно.** Upload быстро (0.5с), классификация async. ThreadPoolExecutor(4-8) внутри /classify-batch. Статусная модель: classify_status='pending' → 'classified'/'failed'.

## Q3: header или весь документ?
**Умная выжимка.** header ~1500 симв + regex-хиты по маркерам (договор, №, от, соглашение) из всего документа + даты. Итого ~3000 симв на вход LLM.

## Q4: parent_contract_number — LLM или regex?
**Двухпроходный гибрид.** Проход 1: LLM извлекает строки per-doc. Проход 2: Python нормализует (regexp uppercase+буквы/цифры) и матчит supplements→contracts по parent_number. LLM не делает fuzzy-match.

## Q5: загрузка 2000 файлов
ZIP через /unzip-upload (переделать: store+parse серверно). Прогресс — polling /api/documents?batch=X, не SSE.

## Q6: группировка — фронт или бэк?
**Бэкенд.** Нормализация требует Python. GET /api/groups?batch=X возвращает готовые группы. apply-groups создаёт contracts+supplements.

## Q7: MVP
6 шагов с новыми файлами, ZIP не нужен. Multi-upload уже работает.
1. Миграция БД (7 колонок)
2. Слой данных (db/documents.py + seed classify prompt)
3. services/classify.py (выжимка + LLM + ThreadPoolExecutor)
4. services/grouping.py (normalize + group + apply)
5. Эндпоинты (/classify-batch, /api/groups, /apply-groups)
6. UI (загрузка → classify → polling → карточки групп → per-group Сравнить)