a.tolmachev
201 lines
9.3 KiB
Markdown
201 lines
9.3 KiB
Markdown
# Редакции продукта
|
|
|
|
## 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`
|
|
- создание и публикация операций;
|
|
- журналы вызовов и метрики использования;
|
|
- секреты и профили аутентификации для внешних сервисов;
|
|
- статический ключ AI-агента;
|
|
- только `security_level = standard`;
|
|
- контейнерное развертывание;
|
|
- optional cache layer на базе `Valkey`, если оператор хочет снизить нагрузку;
|
|
- документация, демо-сценарий и базовый CI.
|
|
|
|
### 3.3. Что не входит
|
|
|
|
- несколько рабочих областей;
|
|
- несколько пользователей;
|
|
- `SSO`, `2FA`, развитая `RBAC`, `audit log`;
|
|
- короткоживущие и одноразовые машинные токены;
|
|
- `GraphQL`;
|
|
- `gRPC unary`;
|
|
- `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`;
|
|
- `GraphQL`;
|
|
- `gRPC unary`;
|
|
- shared cache layer, если он нужен для self-hosted production load;
|
|
- короткоживущие машинные токены;
|
|
- одноразовые токены для критичных операций;
|
|
- `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;
|
|
- shared cache layer по умолчанию для снижения нагрузки и хранения ephemeral coordination state;
|
|
- эксплуатационный мониторинг и обновления со стороны поставщика;
|
|
- биллинг и 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 / HTTP | yes | yes | yes |
|
|
| GraphQL / gRPC unary | no | yes | yes |
|
|
| WebSocket / SOAP / gRPC streaming | no | yes | yes |
|
|
| Streaming modes | no | yes | yes |
|
|
| Static agent key | yes | yes | yes |
|
|
| Optional Valkey/Redis cache backend | 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/community-release-checklist.md`
|
|
- `docs/frontend-roadmap.md`
|
|
- `docs/refactoring-roadmap.md`
|
|
- `docs/implementation-plan.md`
|