crank/docs/repository-split-map.md

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.