crank/docs/product-editions.md

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

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