- 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
Этот документ фиксирует целевую карту физического разделения текущего репозитория на:
-`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.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
a.tolmachev