“Naeel”
e05af2b6ce
Задокументированы все 4 попытки, хеш-анализ, находка с Node.js fetch, хронология 12 коммитов за 14.06.2026.
82 lines
5.1 KiB
Markdown
82 lines
5.1 KiB
Markdown
# Запрос к 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.
|
|
Мост к БД извне для отладки.
|
|
|
|
## Ожидаемый формат ответа
|
|
|
|
Структурированный план архитектуры с пояснениями по каждому пункту вопроса.
|