crank/docs/repository-split-map.md

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.

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

• 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-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 для всех трех репозиториев.

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

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

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

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

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

• создать crank-community
• создать crank-enterprise
• создать crank-cloud

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