# Запрос к Claude Sonnet: архитектура сервиса "Сверка договоров"

## Контекст

Мы строим Flask-сервис для автоматизированной обработки договоров и допников.

Исходная постановка задачи (от заказчика):
1. Спецификации договоров разобрать до структурированного вида
2. Собрать из **цепочки допников кумулятивный статус договора** — состояние во времени.
   Важно: иногда в допнике **новое состояние** договора целиком, иногда — **только изменения**,
   и нужно идентифицировать изменённую строку.
3. (опционально, малый процент случаев) сопоставить артикул по описанию с каталогом услуг
   (кодов в спецификациях нет)

Критичные ограничения:
- Данные строго конфиденциальны → LLM только своя (aillm.ru 120B), данные не покидают облако
- На каждом этапе возможны исключения — **не фантазировать**, а отметить конкретную
  элементарную подзадачу как нерешаемую
- Рассматриваем как задачку для ИИ

## Ключевое требование заказчика

**НЕ МОНОЛИТИТЬ.** Всё делать небольшими НЕЗАВИСИМЫМИ слоями.
Каждый слой — отдельный Python-файл, своя зона ответственности.
Слои не должны зависеть друг от друга (или минимально).

## Что уже сделано

```
site/
├── app.py          ← Flask-приложение, класс ContractsApp, только сборка слоёв
├── db.py            ← слой БД: connect(), query(), _pg_connect()
├── test_routes.py   ← Blueprint /test (статус БД, список таблиц, SQL, createdb)
├── parser.py        ← слой парсера: parse(bytes, mime) → полный слепок docx/pdf
├── textify.py       ← слой: elements JSON → линейный текст для LLM
├── static/
└── templates/
```

База: PostgreSQL, всё внутри облачного кластера.
LLM: aillm.ru (120B модель).

## Что предстоит сделать

1. **Слой загрузки** — приём файлов через API, сохранение в БД (original_bytes + parsed_text)
2. **Слой LLM** — отправка текста → модель → структурированные строки спецификации
3. **Слой хранения** — таблицы contracts, supplements, spec_rows, spec_history
4. **Слой сравнения (diff)** — сравнение строк между допниками, выявление изменений
5. **Слой API** — отдача истории договора, списка, etc.

## Вопрос

Разъясни план архитектуры:

1. Правильно ли разбиты слои? Может что-то объединить или наоборот — разделить?
2. В каком порядке их создавать?
3. Как организовать поток данных между слоями, чтобы они оставались независимыми?
4. Как должен выглядеть основной оркестратор (app.py) — без бизнес-логики?
5. Какие потенциальные проблемы ты видишь с таким подходом?

## Текущий код для ознакомления

### parser.py (bytes → JSON elements)
Использует python-docx для docx, libreoffice для .doc, pdfplumber для PDF, zipfile для zip.
Возвращает полный слепок: все абзацы (со стилями) + все таблицы (все строки).
Ничего не фильтрует, не теряет.

### textify.py (JSON elements → текст)
Форматирует elements в линейный текст: параграфы как `[Style] text`, таблицы как `| cell | cell |`.
Тоже не фильтрует, только форматирует.

### db.py (БД)
connect() в целевую БД, _pg_connect(dbname) в любую, query(sql) — выполнить произвольный запрос.

### test_routes.py (/test Blueprint)
GET /test — статус БД, POST /test с действиями: status, tables, sql, createdb.
Мост к БД извне для отладки.

## Ожидаемый формат ответа

Структурированный план архитектуры с пояснениями по каждому пункту вопроса.