docs: consolidate product roadmap and source docs
This commit is contained in:
a.tolmachev
@@ -0,0 +1,192 @@
|
||||
# Редакции продукта
|
||||
|
||||
## 1. Назначение документа
|
||||
|
||||
Этот документ фиксирует продуктовую модель Crank как open-core платформы и определяет, какие возможности входят в открытую редакцию, а какие относятся к коммерческим редакциям.
|
||||
|
||||
Документ нужен для трех целей:
|
||||
|
||||
- не смешивать в одном репозитории открытый и коммерческий контур без явных границ;
|
||||
- синхронизировать продуктовые ограничения с архитектурой, API и UI;
|
||||
- дать реализации четкий ориентир по edition gating и delivery model.
|
||||
|
||||
## 2. Базовая модель
|
||||
|
||||
Crank развивается как три редакции:
|
||||
|
||||
1. `Community` — открытая self-hosted редакция;
|
||||
2. `Enterprise` — коммерческая self-hosted редакция;
|
||||
3. `Cloud` — коммерческая vendor-hosted редакция.
|
||||
|
||||
Принцип:
|
||||
|
||||
- открытая редакция должна быть самодостаточной и полезной сама по себе;
|
||||
- коммерческие редакции должны расширять продукт, а не ломать открытую основу;
|
||||
- различия между редакциями должны быть видны в capability model, документации, UI и delivery pipeline.
|
||||
|
||||
## 3. Community
|
||||
|
||||
### 3.1. Целевая аудитория
|
||||
|
||||
`Community` предназначена для:
|
||||
|
||||
- индивидуального пользователя;
|
||||
- AI-энтузиаста;
|
||||
- небольшой команды, которой нужен один рабочий MCP endpoint без enterprise-функций.
|
||||
|
||||
### 3.2. Что входит
|
||||
|
||||
- self-hosted развертывание;
|
||||
- одна рабочая область;
|
||||
- один пользователь;
|
||||
- один AI-агент;
|
||||
- протоколы:
|
||||
- `REST / HTTP`
|
||||
- `GraphQL`
|
||||
- `gRPC unary`
|
||||
- создание и публикация операций;
|
||||
- журналы вызовов и метрики использования;
|
||||
- секреты и профили аутентификации для внешних сервисов;
|
||||
- статический ключ AI-агента;
|
||||
- только `security_level = standard`;
|
||||
- контейнерное развертывание;
|
||||
- документация, демо-сценарий и базовый CI.
|
||||
|
||||
### 3.3. Что не входит
|
||||
|
||||
- несколько рабочих областей;
|
||||
- несколько пользователей;
|
||||
- `SSO`, `2FA`, развитая `RBAC`, `audit log`;
|
||||
- короткоживущие и одноразовые машинные токены;
|
||||
- `WebSocket`, `SOAP`, `gRPC streaming`;
|
||||
- режимы `window`, `session`, `async_job`;
|
||||
- биллинг и usage metering для SaaS;
|
||||
- cloud control plane.
|
||||
|
||||
## 4. Enterprise
|
||||
|
||||
### 4.1. Целевая аудитория
|
||||
|
||||
`Enterprise` предназначена для компаний, которые:
|
||||
|
||||
- разворачивают Crank на своей инфраструктуре;
|
||||
- хотят полный набор протоколов;
|
||||
- требуют усиленную безопасность, командный доступ и аудит;
|
||||
- готовы платить за сопровождение и коммерческие расширения.
|
||||
|
||||
### 4.2. Что добавляется к Community
|
||||
|
||||
- несколько рабочих областей;
|
||||
- несколько пользователей;
|
||||
- `SSO`, `2FA`, расширенная `RBAC`, `audit log`;
|
||||
- короткоживущие машинные токены;
|
||||
- одноразовые токены для критичных операций;
|
||||
- `security_level = elevated` и `security_level = strict`;
|
||||
- `WebSocket`, `SOAP`, `gRPC streaming`;
|
||||
- streaming execution modes;
|
||||
- расширенные административные и эксплуатационные функции;
|
||||
- поставка через приватные образы и `Helm`-чарты.
|
||||
|
||||
## 5. Cloud
|
||||
|
||||
### 5.1. Целевая аудитория
|
||||
|
||||
`Cloud` предназначена для команд, которым нужна:
|
||||
|
||||
- готовая размещенная платформа;
|
||||
- минимизация собственной эксплуатационной нагрузки;
|
||||
- SaaS-модель с управляемыми обновлениями и платными лимитами.
|
||||
|
||||
### 5.2. Что добавляется к Enterprise
|
||||
|
||||
- vendor-hosted развертывание;
|
||||
- usage metering;
|
||||
- тарифы и лимиты;
|
||||
- cloud control plane;
|
||||
- эксплуатационный мониторинг и обновления со стороны поставщика;
|
||||
- биллинг и tenant-oriented support tooling.
|
||||
|
||||
## 6. Матрица возможностей
|
||||
|
||||
| Возможность | Community | Enterprise | Cloud |
|
||||
| --- | --- | --- | --- |
|
||||
| Hosting | self-hosted | self-hosted | vendor-hosted |
|
||||
| Workspace count | 1 | many | many |
|
||||
| User count | 1 | many | many |
|
||||
| Agent count | 1 | many | many |
|
||||
| REST / GraphQL / gRPC unary | yes | yes | yes |
|
||||
| WebSocket / SOAP / gRPC streaming | no | yes | yes |
|
||||
| Streaming modes | no | yes | yes |
|
||||
| Static agent key | yes | yes | yes |
|
||||
| Short-lived MCP token | no | yes | yes |
|
||||
| One-time MCP token | no | yes | selectively |
|
||||
| `security_level = standard` | yes | yes | yes |
|
||||
| `security_level = elevated` | no | yes | yes |
|
||||
| `security_level = strict` | no | yes | limited by policy |
|
||||
| Logs and usage | yes | yes | yes |
|
||||
| SSO / 2FA / RBAC / audit | no | yes | yes |
|
||||
| Billing / metering | no | no | yes |
|
||||
|
||||
## 7. Правила для реализации
|
||||
|
||||
### 7.1. Community не должен зависеть от private code
|
||||
|
||||
Открытая редакция должна:
|
||||
|
||||
- собираться из этого репозитория полностью;
|
||||
- иметь завершенный сценарий демо и эксплуатации;
|
||||
- не требовать закрытых сервисов для базового машинного доступа.
|
||||
|
||||
### 7.2. Коммерческие возможности должны быть явно отделены
|
||||
|
||||
Коммерческие функции не должны появляться в Community как полурабочие заглушки. Для каждой такой функции требуется одно из двух:
|
||||
|
||||
- capability flag с честным недоступным состоянием;
|
||||
- полное отсутствие функции из open-source сборки.
|
||||
|
||||
### 7.3. Различия по редакциям должны быть зафиксированы в четырех местах
|
||||
|
||||
1. в продуктовой документации;
|
||||
2. в архитектурной декомпозиции;
|
||||
3. в административном API и MCP-контрактах;
|
||||
4. в UI через capability gating и честный copy.
|
||||
|
||||
## 8. Правила для машинной аутентификации
|
||||
|
||||
Продуктовые редакции различаются и по входящему машинному доступу:
|
||||
|
||||
- `Community`:
|
||||
- только статический ключ AI-агента;
|
||||
- только операции уровня `standard`;
|
||||
- `Enterprise`:
|
||||
- статический ключ AI-агента;
|
||||
- короткоживущий токен;
|
||||
- одноразовый токен;
|
||||
- `Cloud`:
|
||||
- статический ключ как режим совместимости;
|
||||
- короткоживущий токен как основной режим;
|
||||
- одноразовый токен — только там, где это поддерживается продуктовой политикой.
|
||||
|
||||
Подробная модель описана в `docs/agent-auth-model.md`.
|
||||
|
||||
## 9. Правила для UI
|
||||
|
||||
Открытый UI не должен:
|
||||
|
||||
- обещать недоступные в Community возможности как почти готовые;
|
||||
- показывать enterprise/cloud controls без capability gating;
|
||||
- использовать ложные CTA для недоступных функций.
|
||||
|
||||
Если функция не входит в текущую редакцию, UI должен делать одно из двух:
|
||||
|
||||
- не показывать ее вовсе;
|
||||
- показывать ее как явно недоступную и документированно требующую другую редакцию.
|
||||
|
||||
## 10. Связанные документы
|
||||
|
||||
- `docs/architecture.md`
|
||||
- `docs/module-decomposition.md`
|
||||
- `docs/agent-auth-model.md`
|
||||
- `docs/frontend-roadmap.md`
|
||||
- `docs/refactoring-roadmap.md`
|
||||
- `docs/implementation-plan.md`
|
||||
Reference in New Issue
Block a user