# Repository split map

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

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

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

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

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

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

Сейчас код и документация еще живут в одном репозитории.

Это допустимо только как переходное состояние, пока:

- не зафиксированы capability boundaries;
- не подготовлены extension seams;
- не собраны отдельные Community delivery artifacts;
- не определен physical split plan.

После завершения этого этапа текущий репозиторий не должен оставаться source of truth сразу для
всех трех редакций.

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

Перед началом physical split нужно выполнить отдельно:

1. Создать репозитории:
   - `crank-community`
   - `crank-enterprise`
   - `crank-cloud`
2. Определить owners и access policy для private repositories.
3. Зафиксировать отдельные package/release names.
4. Подготовить начальные README и baseline workflows для всех трех репозиториев.

Текущий статус:

- `crank-community` уже создан;
- `crank-enterprise` уже создан;
- `crank-cloud` уже создан;
- bootstrap templates уже перенесены в целевые repositories;
- baseline-import в `crank-community` уже был откачен из истории и не считается финальным public source state;
- management gate закрыт, следующий шаг — начать physical split.

Пока эти четыре пункта не выполнены, physical split не начинается.

Техническая заготовка для этого шага уже живет в:

- `templates/repositories/crank-community/*`
- `templates/repositories/crank-enterprise/*`
- `templates/repositories/crank-cloud/*`

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

Следующий управленческий шаг после завершения текущего boundary-трека:

- начать physical split с `crank-community`
- сделать whitelist-based import для `crank-community` и только его считать финальным public source of truth
- создать `crank-enterprise`
- создать `crank-cloud`

После этого уже можно планировать фактическое разнесение кода и delivery files.