doc: сага с LLM — HTTP/2, ddos-guard, httpx→curl

Задокументированы все 4 попытки, хеш-анализ, находка с Node.js fetch, хронология 12 коммитов за 14.06.2026.
2026-06-14 07:42:54 +04:00
parent 879e016754
commit e05af2b6ce
3 changed files with 355 additions and 1 deletions
@@ -0,0 +1,81 @@
+# Запрос к 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.
+Мост к БД извне для отладки.
+
+## Ожидаемый формат ответа
+
+Структурированный план архитектуры с пояснениями по каждому пункту вопроса.