From 89761ec1e53a924d8b5bcb9b298e58fac734a089 Mon Sep 17 00:00:00 2001 From: "a.tolmachev" Date: Sun, 3 May 2026 19:49:51 +0000 Subject: [PATCH] docs: add repository split map --- TASKS.md | 2 + docs/commercial-boundaries.md | 1 + docs/community-release-checklist.md | 1 + docs/implementation-plan.md | 1 + docs/repository-split-map.md | 200 ++++++++++++++++++++++++++++ 5 files changed, 205 insertions(+) create mode 100644 docs/repository-split-map.md diff --git a/TASKS.md b/TASKS.md index c071ab4..d5f1612 100644 --- a/TASKS.md +++ b/TASKS.md @@ -43,8 +43,10 @@ Progress: - canonical Community deployment manifest and env template now live under `deploy/community/*`, and public deploy uses that manifest instead of the root compose file - CI, README, runtime/deploy smoke docs now point to `deploy/community/*` as the Community delivery source of truth - separate `Community` release checklist now exists and explicitly forbids treating future `Enterprise/Cloud` delivery as just another env on the same public manifest + - explicit repository split map now defines what goes to `crank-community`, `crank-enterprise`, and `crank-cloud` - pending: - remaining extension seams and packaging split still need to move from planning into concrete `crank-community` / `crank-enterprise` / `crank-cloud` manifests + - next management gate is to actually create the `3` target repositories before physical split starts ## Planned diff --git a/docs/commercial-boundaries.md b/docs/commercial-boundaries.md index 438fc95..03bcd02 100644 --- a/docs/commercial-boundaries.md +++ b/docs/commercial-boundaries.md @@ -202,6 +202,7 @@ Private code должен подключаться как реализация - `docs/product-editions.md` - `docs/community-release-checklist.md` +- `docs/repository-split-map.md` - `docs/agent-auth-model.md` - `docs/module-decomposition.md` - `docs/frontend-roadmap.md` diff --git a/docs/community-release-checklist.md b/docs/community-release-checklist.md index 6697cdd..8081ef7 100644 --- a/docs/community-release-checklist.md +++ b/docs/community-release-checklist.md @@ -107,6 +107,7 @@ Community release должен поставлять: - `docs/product-editions.md` - `docs/commercial-boundaries.md` +- `docs/repository-split-map.md` - `docs/deployment.md` - `docs/deploy-and-staging-smoke.md` - `docs/authenticated-staging-pass.md` diff --git a/docs/implementation-plan.md b/docs/implementation-plan.md index bad45aa..ae79be2 100644 --- a/docs/implementation-plan.md +++ b/docs/implementation-plan.md @@ -197,6 +197,7 @@ - `docs/product-editions.md` - `docs/commercial-boundaries.md` - `docs/community-release-checklist.md` +- `docs/repository-split-map.md` - `docs/frontend-roadmap.md` - `docs/refactoring-roadmap.md` - `docs/agent-auth-model.md` diff --git a/docs/repository-split-map.md b/docs/repository-split-map.md new file mode 100644 index 0000000..7169585 --- /dev/null +++ b/docs/repository-split-map.md @@ -0,0 +1,200 @@ +# 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`, adapters, schema and mapping crates; +- capability model; +- Community auth model: + - static AI-agent key; + - only `security_level = standard`; +- `deploy/community/*`; +- 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; +- 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; +- private container/release packaging; +- enterprise operator docs. + +### 3.3. `crank-cloud` + +Private repository. + +В нем должны жить: + +- cloud control plane; +- metering; +- billing; +- hosted tenant management; +- hosted operational tooling; +- 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 + +Уходит в `crank-enterprise`: + +- 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 не начинается. + +## 7. Практический вывод + +Следующий управленческий шаг после завершения текущего boundary-трека: + +- создать `crank-community` +- создать `crank-enterprise` +- создать `crank-cloud` + +После этого уже можно планировать фактическое разнесение кода и delivery files.