# Repository split map

## 1. Назначение документа

Этот документ фиксирует целевую карту физического разделения текущего репозитория на:

- `crank-community`
- `crank-enterprise`
- `crank-cloud`

Документ нужен, чтобы:

- не гадать, что именно куда переносится;
- заранее отделить public Community artifacts от private commercial delivery;
- подготовить создание новых репозиториев как управляемый шаг, а не как спонтанный рефакторинг.

## 2. Текущее состояние

Разделение уже выполнено на уровне репозиториев:

- `crank-community` — public base;
- `crank-enterprise` — private self-hosted delta;
- `crank-cloud` — private hosted delta.

Дальнейшая задача не в создании split, а в его дисциплинированном поддержании:

- общее улучшение идет сначала в `crank-community`;
- затем переносится в `crank-enterprise` и `crank-cloud`;
- cleanup Community делается только в `crank-community`.

## 3. Целевой результат

### 3.1. `crank-community`

Public repository.

В нем должны остаться:

- Community runtime;
- Community UI;
- `admin-api`, `mcp-server`, `ui`;
- `crank-core`, `crank-registry`, `crank-runtime`, schema and mapping crates;
- только `REST`-ориентированный Community protocol surface;
- capability model;
- Community auth model:
  - static AI-agent key;
  - only `security_level = standard`;
- `deploy/community/*`;
- optional `Valkey` service definition для Community deployment;
- public CI/CD for Community;
- Community docs, smoke docs и demo flow.

Техническая оговорка:

- `crank-runtime` в Community должен уметь собираться без premium adapter crates;
- `UnsupportedProtocol` и capability model должны оставаться достаточным fallback для disabled protocol families.

В нем не должно остаться:

- private token issuer implementations;
- enterprise auth/governance services;
- cloud control-plane logic;
- private packaging files;
- private operational tooling.

### 3.2. `crank-enterprise`

Private repository.

В нем должны жить:

- self-hosted commercial extensions;
- `GraphQL` и `gRPC unary`, если они окончательно выводятся из Community;
- short-lived token service;
- one-time token service;
- enterprise access/governance:
  - `SSO`
  - `2FA`
  - extended `RBAC`
  - `audit log`
- premium protocol/runtime additions, если они не входят в Community;
- enterprise deployment manifests;
- optional cluster-aware cache integration для self-hosted production;
- private container/release packaging;
- enterprise operator docs.

### 3.3. `crank-cloud`

Private repository.

В нем должны жить:

- cloud control plane;
- metering;
- billing;
- hosted tenant management;
- hosted operational tooling;
- managed shared cache layer defaults and cache operations;
- cloud-only delivery manifests;
- cloud release pipeline;
- hosted support/admin tooling.

## 4. Карта по типам содержимого

### 4.1. Application code

Остается в `crank-community`:

- весь текущий Community runtime и UI
- все public extension seams
- все capability checks
- `REST`-only product surface

Как промежуточный этап до физического переноса:

- `crank-runtime` в общем коде должен иметь feature-gated seams для `GraphQL/gRPC/SOAP/WebSocket`;
- это позволяет потом перенести premium adapters в private repos без полного форка runtime base.

Уходит в `crank-enterprise`:

- `crank-adapter-graphql`
- `crank-adapter-grpc`
- private auth/token/governance services
- enterprise-only runtime additions

Уходит в `crank-cloud`:

- hosted orchestration and control-plane code
- billing/metering integrations

### 4.2. Deployment manifests

Остается в `crank-community`:

- `deploy/community/*`

Уходит в `crank-enterprise`:

- private self-hosted manifests
- private `Helm` charts
- enterprise image references

Уходит в `crank-cloud`:

- hosted deployment manifests
- cloud operational manifests

### 4.3. CI/CD

Остается в `crank-community`:

- public Community `CI`
- public Community `Deploy`

Уходит в `crank-enterprise`:

- private release workflows
- private image publishing

Уходит в `crank-cloud`:

- hosted release workflows
- control-plane rollout workflows

### 4.4. Documentation

Остается в `crank-community`:

- public architecture
- public API/MCP contracts
- Community deployment docs
- Community smoke docs

Уходит в `crank-enterprise`:

- enterprise operator docs
- enterprise packaging docs
- enterprise support runbooks

Уходит в `crank-cloud`:

- hosted operations docs
- tenant control-plane docs
- cloud support runbooks

## 5. Правила переноса

При переносе нужно соблюдать:

1. Сначала переносится Community в `crank-community` как рабочая самостоятельная база.
2. Потом переносится private self-hosted контур в `crank-enterprise`.
3. Потом переносится hosted/control-plane контур в `crank-cloud`.
4. Public contracts должны остаться в Community и не зависеть от private кодовой базы.
5. Private repos не должны требовать обратного копирования логики в Community.

## 6. Правила поддержки split после разделения

После разделения действуют такие правила:

1. `crank-community` остается базой для общей открытой логики.
2. `crank-enterprise` и `crank-cloud` не должны независимо переизобретать общий Community код.
3. Общие исправления и улучшения сначала делаются в `crank-community`, затем переносятся в private repositories.
4. Удаление или ограничение Community functionality делается только в `crank-community`.
5. Private repositories должны хранить только свой product delta, а не полную независимую копию всей эволюции продукта.

## 7. Практический вывод

Для текущего этапа это означает:

- `crank-community` нужно дочистить до окончательного public состояния;
- затем использовать его как source base для общих улучшений;
- коммерческие возможности продолжать развивать только в `crank-enterprise` и `crank-cloud`.