docs: стратегия Gemini — адаптируемое ядро + доменная конфигурация

This commit is contained in:
2026-06-28 15:01:23 +04:00
parent f0c8599035
commit f53c7bb566
+47
View File
@@ -0,0 +1,47 @@
# Стратегия: превращение в настраиваемый продукт
Источник: Gemini, 28.06.2026
## Главный тезис
Модель **«настраиваемое ядро + доменная конфигурация»** — единственно жизнеспособная в B2B.
Не «коробка для всех», а движок который адаптируется под заказчика без форка кода.
## Что уже хорошо
- Промпты в БД с версионированием и ролями (`extract`/`diff`)
- `prompt_version` в событиях — воспроизводимость
- Event Sourcing, аудит, логирование ответов LLM
- testgen для синтетических данных
- DI: LLM клиент + Repository (Ф1-Ф4)
## Что нужно изменить
### 1. Поля позиции → JSONB
Сейчас `spec_current` имеет жесткие колонки: `name`, `price`, `qty`, `sum`, `date_start`.
Надо: одна колонка `payload JSONB` вместо них.
Для клиента с НДС/артикулом/единицей измерения — БД и миграции не меняются.
### 2. Валидация в плагины
Сейчас арифметика `sum = price*qty` зашита в код.
Надо: интерфейс валидатора. Вход: JSONB от LLM. Выход: bool + ошибки.
Новый заказчик = новый валидатор, ядро не трогаем.
### 3. Экспорт/интеграция через Read Models
Ядро заканчивается на Event Stream. Отчёты, выгрузки в 1С/Excel/ERP — отдельные проекции.
Новый заказчик = новая проекция, те же события.
## Архитектурная цель
```
Неизменяемое ядро (Core):
Приём → Парсинг → LLM → Event Sourcing (JSONB) → Аудит
Адаптационный слой (Домен):
Промпты (БД) + Валидаторы JSONB + Проекции (отчёты/экспорт)
```
Ядро не меняется от клиента к клиенту. Адаптация: новые промпты, правила валидации, форматы выгрузки.
## Текущая коммерческая ценность
Проект закрывает конкретную дорогую боль — сверку цепочек изменений договоров.
Фундамент (Event Sourcing, тесты, промпты в БД) заложен правильно.