# Редакции продукта

## 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`