diff --git a/contracts-flask b/contracts-flask
new file mode 160000
index 0000000..83f5905
--- /dev/null
+++ b/contracts-flask
@@ -0,0 +1 @@
+Subproject commit 83f59053e59aeb6bd882a0f8aa11df104e7f6cc8
diff --git a/hz/univ.md b/hz/univ.md
new file mode 100644
index 0000000..7549f39
--- /dev/null
+++ b/hz/univ.md
@@ -0,0 +1,93 @@
+этот проект - имеет какую то коммерческую ценность ? как универсальный продукт для подобных документов
+
+Список задач обновлен
+
+Честная оценка, на основе того, что я видел в коде и архитектуре.
+
+## Что это по сути
+Движок **сверки спецификаций по цепочке «договор + допсоглашения»**: парсинг → извлечение строк (услуга/цена/кол-во/сумма/дата) → LLM-диф (ADD/UPDATE/DELETE) → event-sourced актуальное состояние с привязкой каждого изменения к документу-источнику. Плюс классификация документов и группировка. Это не «ещё один чат с PDF», а конкретная боль с понятной ценностью.
+
+## Где реальная ценность
+- **Боль настоящая и дорогая.** Ручная сверка договора с десятком допников в закупках/финансах/юридическом — медленно и с ошибками в деньгах. Автоматизация с аудит-следом — это то, за что платят.
+- **Ядро обобщаемо.** Паттерн «базовый документ + поток изменений к таблице позиций» покрывает не только договоры: прайс-листы и их обновления, тарифы, страховые полисы + эндорсменты, аренда + доп.соглашения, SLA. Движок event-sourcing под это годится почти как есть.
+- **Сильные стороны архитектуры под продукт уже заложены:** аудит изменений (`source_document_id`), `UNRESOLVED` как human-in-the-loop, арифметические проверки, генератор тест-кейсов (testgen/), симулятор (sim/). Это редко делают на ранней стадии — хороший знак зрелости.
+
+## Что мешает быть «универсальным продуктом» прямо сейчас
+- **Захардкожено под РФ-спецификацию услуг:** промпты, поля классификации (`own_number`/`parent_number`), понятие «спецификация». Для универсальности нужна **конфигурируемая схема документа + промпты под тип** (договор / прайс / полис), а не один зашитый сценарий.
+- **Точность = главный риск.** Одна неверная сумма/строка → потеря доверия, в финансах это критично. Нужны: обязательный человеческий контроль спорных строк (основа есть), метрики качества на эталонном датасете (заготовка в testgen есть — надо довести до бенчмарка с цифрами «точность X%»).
+- **Робастность и контроль затрат** — ровно то, что обсуждали (тихие провалы парсинга, дубли, лимиты, стоимость LLM на документ). Для внутреннего инструмента терпимо, для продукта — обязательно.
+- **Интеграции:** экспорт в 1С/ERP/учётные системы. Без этого результат сверки «висит в вебе» и ценность ниже.
+
+## Рынок и позиционирование
+- Большие CLM/contract-analytics (Ironclad, Evisort, Luminance, Kira) — это про весь жизненный цикл и поиск рисков, а **узкую задачу «сверка позиций по допникам» они толком не закрывают**. Здесь есть незанятая ниша.
+- На РФ-рынке (СБИС/Контур и т.п.) — локальная специфика и язык как преимущество.
+- **Реалистичное позиционирование:** не «платформа», а **вертикальный SaaS / модуль** для закупок и финансов SMB/mid-market: «загрузи договор и допники — получи актуальную спецификацию с аудитом изменений». Либо как встраиваемый компонент в чужой CLM/документооборот.
+
+## Вердикт
+Да, коммерческая ценность правдоподобна — как **сфокусированный нишевый продукт**, а не платформа. Ядро обобщается на класс «базовый документ + изменения к таблице», но для «универсальности» нужны три вещи по порядку: **(1) конфигурируемые схемы/промпты под тип документа, (2) доказанная точность с метриками + обязательный ревью спорных строк, (3) интеграции/экспорт**. Архитектурно фундамент под это уже правильный — event sourcing с аудитом и заготовки под тестирование/симуляцию дают серьёзное преимущество перед «обёрткой над LLM».
+
+Главный нерешённый вопрос продукта — **не технологии, а доверие к цифрам**: кто несёт ответственность за ошибку в сумме и как это показать клиенту. Кто решит это через прозрачный аудит + ревью — тот и продаёт.
+
+может не именно универсальный, запустил и работает
+а с возможностью перестройки ядра под запросы конкретного заказчика
+
+Список задач обновлен
+
+Хорошо — это другая модель: «настраиваемое ядро + кастомизация под заказчика». Проверю, насколько ядро уже готово к перенастройке (промпты в БД, версионирование). 
+
+Read [](file:///home/naeel/nubes/contracts/contracts-flask/deploy/db/prompts.py#1-1), lines 1 to 80
+
+Подтвердилось важное: **промпты уже вынесены в БД и версионируются** (prompts.py, таблица `prompts` с ролями `extract`/`diff`, `is_active`, выбор активного), а `prompt_version` пишется в каждое событие. То есть значительная часть «перестройки ядра» уже делается **данными, а не кодом**. Это сильно меняет оценку в плюс.
+
+## Почему эта модель — правильная (и лучше «универсальной»)
+«Универсальный, запустил и работает» в B2B-документах почти не существует — у каждого заказчика свои формы, поля, правила. **«Конфигурируемое ядро + настройка под заказчика»** — это проверенная и доминирующая модель корпоративного софта (весь экосистема 1С построена ровно на ней). Заказчик такого ждёт и за это платит. Так что вы целитесь в реалистичную нишу, а не в утопию.
+
+## Что уже играет на вас
+- **Промпты = данные, с версиями.** Перенастроить извлечение/диф под клиента — это правка записи в `prompts`, не релиз. Огромный задел.
+- **Воспроизводимость/аудит:** `prompt_version` и `raw_llm_response` пишутся в события → можно объяснить клиенту любое решение и откатить промпт. Это и тюнинг, и доверие.
+- **Заготовка под качество:** testgen/ + метрики → можно собирать **эталонный датасет под каждого заказчика** и мерить точность его конфигурации.
+- Event sourcing с привязкой к источнику — ядро не зависит от доменной специфики, оно про «база + поток изменений к таблице».
+
+## Где сейчас «настройка = код» (это надо вынести в конфиг)
+- **Схема позиции захардкожена:** поля `name/price/qty/sum/date_start` — в колонках `spec_current` и в spec_events.py. У другого заказчика будут иные поля (артикул, НДС, период, ед.изм.). Сейчас это правка кода/миграции.
+- **Таксономия классификации** (`own_number`/`parent_number`/`counterparty`) — зашита.
+- **Валидаторы** (арифметика `sum=price·qty`) и **экспорт** — под конкретный домен.
+
+Пока это код — каждый новый заказчик тянет за собой разработку. Цель — сделать вариативные точки **конфигурацией («доменный пакет»: схема + промпты + правила + маппинг экспорта)**, чтобы новый клиент = настройка, а не форк.
+
+## Экономика модели — честно
+- **Плюсы:** выше средний чек, выше «прилипчивость» (настроенное ядро не выкинут), естественный апсейл на новые типы документов.
+- **Минусы:** services-heavy — внедрение/настройка тянут маржу вниз и хуже масштабируются, чем чистый SaaS. В РФ-энтерпрайзе это норма (интеграторы на этом и живут).
+- **Ключевая метрика бизнеса:** «время вывода нового заказчика». Если настройка — это **дни конфигурации**, экономика продуктовая. Если **месяцы разработки** — вы консалтинг с кодовой базой, а не продукт.
+
+## Главный риск и как его держать
+**Не плодить ветки под заказчиков.** Один core + набор «доменных пакетов»-конфигов. Как только появляется `if customer == X` в коде ядра — модель сломалась. Дисциплина: всё клиентское — в данные/конфиг, ядро остаётся общим. И второе — **качество промптов под клиента нужно мерить** (testgen как first-class инструмент онбординга), иначе «настройка» превратится в бесконечный ручной тюнинг.
+
+## Вердикт
+Да, **эта модель коммерчески прочнее «универсального продукта»** и реалистичнее. Вы уже на полпути: промпты вынесены и версионируются, аудит и заготовка под тесты есть. Чтобы превратить это в продаваемый «настраиваемый продукт», ключевая инженерная инвестиция одна — **сделать доменную часть (схема позиции, классификация, правила, экспорт) конфигурацией, а не кодом**. Сделаете — получите продукт с услугой внедрения; не сделаете — останетесь разработкой под каждого клиента.
+
+Создано задач: 5
+
+
+есть ли подобные фреймворки или системы
+
+Список задач обновлен
+
+Кратко, по категориям:
+
+**Contract analytics / CLM (готовые продукты):**
+- Evisort, Ironclad, ContractPodAi, Luminance, Kira Systems, DocuSign CLM, Icertis — извлечение полей и рисков из договоров. Но **сверку позиций по цепочке допсоглашений с event-sourcing они напрямую не делают** — это про метаданные и риски, не про «актуальная спецификация после N изменений».
+
+**Document AI / IDP (извлечение таблиц/полей):**
+- AWS Textract, Google Document AI, Azure Document Intelligence, ABBYY FlexiCapture/Vantage, Rossum, Docsumo — парсинг и извлечение структурированных данных. Это «слой парсинга», без вашей логики диффа/состояния.
+
+**LLM-фреймворки «собери сам» (то, на чём строят такое):**
+- LangChain / LlamaIndex, Unstructured.io (парсинг документов), Instructor / Outlines (structured JSON от LLM). Дают кирпичи, но не доменное ядро.
+
+**Российский рынок:**
+- Контур, СБИС, Directum, ЭОС — документооборот/ЭДО с элементами анализа. Локальная специфика, но узкой «сверки спецификаций» как продукта нет.
+
+**Diff / редлайн:**
+- Litera Compare, Draftable, Workshare — сравнение версий документов **текстуально**, не семантически по строкам спецификации.
+
+**Вывод:** компонентов-аналогов много (парсинг, извлечение, CLM, structured-LLM), но **именно вашей связки** — «базовый документ + поток допников → event-sourced актуальная таблица позиций с аудитом» как готового продукта/фреймворка я не знаю. Это и есть незанятая ниша: вы не конкурируете с CLM, а закрываете то, что они оставляют ручным.
\ No newline at end of file