docs: align community repo as source of truth
This commit is contained in:
github-ops
@@ -2,190 +2,105 @@
|
||||
|
||||
## Current
|
||||
|
||||
### `feat/open-core-repo-boundary`
|
||||
### `feat/community-finalization`
|
||||
|
||||
Status: in_progress
|
||||
|
||||
Goal:
|
||||
- закрепить техническую границу между `crank-community`, `crank-enterprise` и `crank-cloud`.
|
||||
- довести `crank-community` до окончательного самостоятельного состояния как открытой `REST-only` редакции;
|
||||
- убрать transitional split-логику, legacy premium ballast и скрытые assumptions из эпохи общего репозитория.
|
||||
|
||||
Main code areas:
|
||||
- `docs/commercial-boundaries.md`
|
||||
- `docs/module-decomposition.md`
|
||||
- `docs/development-rules.md`
|
||||
- `TASKS.md`
|
||||
- `docs/community-source-whitelist.md`
|
||||
- `docs/implementation-plan.md`
|
||||
- release scripts / Docker manifests / future packaging files
|
||||
- `docs/repository-split-map.md`
|
||||
- `docs/community-release-checklist.md`
|
||||
- `docs/commercial-boundaries.md`
|
||||
- workspace manifests
|
||||
- Community backend/UI tests and fixtures
|
||||
- Community UI copy and localization
|
||||
|
||||
Implementation slices:
|
||||
1. Определить extension seams в public code.
|
||||
2. Подготовить отдельные delivery manifests для Community.
|
||||
3. Убрать из Community repo assumptions о размещении private code рядом с Community logic.
|
||||
4. Подготовить naming и packaging strategy для private repositories.
|
||||
5. После завершения seams и capability split остановиться на управленческом gate и создать:
|
||||
- public repository `crank-community`
|
||||
- private repository `crank-enterprise`
|
||||
- private repository `crank-cloud`
|
||||
Только после этого начинать физическое вынесение commercial code из текущего monorepo.
|
||||
1. привести документацию и backlog к реальному состоянию `crank-community`;
|
||||
2. убрать premium зависимости из Community workspace manifests;
|
||||
3. очистить Community test boundary и убрать зависимость от `test = false` как способа скрывать legacy tests;
|
||||
4. удалить premium backend ballast, который больше не относится к Community;
|
||||
5. дочистить UI, локализацию и e2e fixtures до честного Community surface;
|
||||
6. пройти финальную верификацию Community release path.
|
||||
|
||||
DoD:
|
||||
- можно объяснить, что именно публикуется как OSS, а что уходит в private delivery;
|
||||
- Community release path отделен от commercial release path;
|
||||
- документация не ссылается на удаленные review files.
|
||||
- момент создания `3` целевых repositories зафиксирован в плане как отдельный обязательный шаг, а не подразумевается неявно.
|
||||
- `crank-community` описывает себя как самостоятельный public repository, а не как промежуточный этап split;
|
||||
- Community manifests и workspace dependencies соответствуют `REST-only` product boundary;
|
||||
- Community tests и fixtures проверяют только Community functionality;
|
||||
- UI и docs не содержат рабочих premium flows и misleading copy;
|
||||
- Community release path воспроизводим и проверяем без ссылок на transitional import procedure.
|
||||
|
||||
Verification:
|
||||
- docs consistency pass;
|
||||
- release checklist review.
|
||||
- `cargo metadata --no-deps`;
|
||||
- `just fmt`
|
||||
- `just check`
|
||||
- `just test`
|
||||
- UI build and Community-targeted smoke/e2e pass.
|
||||
|
||||
Progress:
|
||||
- done:
|
||||
- `crank-community` baseline-import was removed from history; the repository is back to bootstrap-only state until a clean whitelist-based import is ready
|
||||
- the first baseline import was used only as a private split rehearsal and must not be treated as the final public source state
|
||||
- bootstrap templates have been pushed into:
|
||||
- `crank-community`
|
||||
- `crank-enterprise`
|
||||
- `crank-cloud`
|
||||
- all `3` target repositories now exist:
|
||||
- `crank-community`
|
||||
- `crank-enterprise`
|
||||
- `crank-cloud`
|
||||
- public target repository `crank-community` now exists and can receive bootstrap templates once the remaining private repositories are created
|
||||
- gate for creating `3` target repositories is already documented before any physical commercial split
|
||||
- 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`
|
||||
- `Community` is now fixed as `REST-only` in product docs, capability model, backend validation, demo seed, and UI protocol expectations
|
||||
- bootstrap templates now exist for `crank-community`, `crank-enterprise`, and `crank-cloud`, including initial README and workflow skeletons
|
||||
- `crank-runtime` now has protocol feature seams, and the runtime crate compiles with `--no-default-features` as a `REST-only` base
|
||||
- `deploy/community/*` already acts as the canonical Community delivery contour
|
||||
- Community capability model is already constrained to:
|
||||
- `REST`
|
||||
- static agent key
|
||||
- `security_level = standard`
|
||||
- public wizard HTML surface is already reduced to the Community `REST` flow
|
||||
- pending:
|
||||
- implement the whitelist from `docs/community-source-whitelist.md`
|
||||
- make Community copy/docs pass finish the remaining premium string cleanup in `catalog`, `agents`, `settings`, `workspace-setup`, and `i18n`
|
||||
- decide whether legacy streaming internals in `admin-api` stay dormant until `enterprise/cloud` extraction or move out before the next Community release cut
|
||||
- continue physical split by isolating `enterprise/cloud` delta away from the extracted Community base
|
||||
- only after that, perform a clean whitelist-based force-push into `crank-community`
|
||||
- rewrite transitional docs and backlog so they describe the current Community repository
|
||||
- remove premium protocol toolchain dependencies from Community manifests
|
||||
- replace disabled test targets with a real Community-only test surface
|
||||
- remove premium protocol and streaming ballast from backend test/dev code
|
||||
- remove dormant premium UI modules, fixtures, and translation strings
|
||||
- run a final Community verification pass
|
||||
|
||||
## Planned
|
||||
|
||||
### `feat/commercial-machine-token-flow`
|
||||
### `feat/community-release-hardening`
|
||||
|
||||
Status: ready
|
||||
|
||||
Goal:
|
||||
- реализовать короткоживущие и одноразовые машинные токены как коммерческий auth contour, а не как Community stub.
|
||||
- закрепить воспроизводимый Community release path и release checklist без скрытых переходных допущений.
|
||||
|
||||
Main code areas:
|
||||
- private `enterprise/cloud` token services
|
||||
- public contracts already fixed in:
|
||||
- `crates/crank-core`
|
||||
- `apps/admin-api`
|
||||
- `apps/mcp-server`
|
||||
- `docs/agent-auth-model.md`
|
||||
|
||||
Implementation slices:
|
||||
1. short-lived token issuance
|
||||
2. one-time token issuance
|
||||
3. replay guard / nonce coordination on top of cache layer
|
||||
4. runtime verification and policy enforcement by `security_level`
|
||||
5. capability-gated UI/admin flows for commercial editions
|
||||
|
||||
DoD:
|
||||
- replay guard is no longer a stub abstraction and is wired into a real token flow;
|
||||
- `elevated/strict` machine access works end-to-end in commercial contours;
|
||||
- Community remains on static agent keys only.
|
||||
|
||||
### `feat/enterprise-access-governance`
|
||||
|
||||
Status: ready
|
||||
|
||||
Goal:
|
||||
- реализовать enterprise access layer вне Community scope.
|
||||
|
||||
Main code areas:
|
||||
- private `enterprise` services and crates
|
||||
- public contracts in:
|
||||
- `docs/admin-api.md`
|
||||
- `docs/agent-auth-model.md`
|
||||
- `docs/product-editions.md`
|
||||
|
||||
Implementation slices:
|
||||
1. `SSO`
|
||||
2. `2FA`
|
||||
3. extended `RBAC`
|
||||
4. `audit log`
|
||||
5. enterprise admin flows in UI through capability gating
|
||||
|
||||
DoD:
|
||||
- governance features не живут как полумеры в Community;
|
||||
- enterprise access model согласован с public contracts.
|
||||
|
||||
### `feat/cloud-metering-control-plane`
|
||||
|
||||
Status: ready
|
||||
|
||||
Goal:
|
||||
- подготовить hosted-редакцию как отдельный продуктовый контур.
|
||||
|
||||
Main code areas:
|
||||
- private cloud services
|
||||
- usage/metering integration points
|
||||
- `docs/product-editions.md`
|
||||
- `docs/commercial-boundaries.md`
|
||||
|
||||
Implementation slices:
|
||||
1. usage metering by workspace / agent / token;
|
||||
2. billing integration;
|
||||
3. hosted tenant controls;
|
||||
4. cloud operational tooling.
|
||||
|
||||
DoD:
|
||||
- Cloud edition не зависит от ручного учета usage;
|
||||
- hosted product surface согласован с feature matrix.
|
||||
|
||||
### `feat/release-protection-distribution`
|
||||
|
||||
Status: ready
|
||||
|
||||
Goal:
|
||||
- подготовить безопасную поставку Community и коммерческих редакций.
|
||||
|
||||
Main code areas:
|
||||
- CI workflows
|
||||
- Dockerfiles
|
||||
- deployment manifests
|
||||
- release docs
|
||||
|
||||
Implementation slices:
|
||||
1. public GitHub release flow for Community;
|
||||
2. private registry flow for Enterprise;
|
||||
3. signed artifacts and provenance;
|
||||
4. release checklist for edition-specific packaging.
|
||||
|
||||
DoD:
|
||||
- Community публикуется из `crank-community`;
|
||||
- Enterprise и Cloud используют private delivery path;
|
||||
- коммерческий код не требуется публиковать в open source ради поставки.
|
||||
|
||||
### `feat/live-authenticated-staging-entry`
|
||||
|
||||
Status: ready
|
||||
|
||||
Goal:
|
||||
- держать реальный staging/demo контур в состоянии, пригодном для демонстрации и регрессии.
|
||||
|
||||
Main code areas:
|
||||
- `docs/demo-runbook.md`
|
||||
- `.github/workflows/ci.yml`
|
||||
- `.github/workflows/deploy.yml`
|
||||
- `deploy/community/*`
|
||||
- `docs/community-release-checklist.md`
|
||||
- `docs/deploy-and-staging-smoke.md`
|
||||
- `docs/authenticated-staging-pass.md`
|
||||
- deployment workflows
|
||||
|
||||
Implementation slices:
|
||||
1. актуализировать demo user flow;
|
||||
2. прогнать authenticated staging pass;
|
||||
3. зафиксировать regressions и manual checks;
|
||||
4. синхронизировать deploy docs с реальным окружением.
|
||||
1. проверить соответствие CI Community manifests;
|
||||
2. зафиксировать Community-only smoke baseline;
|
||||
3. обновить release checklist после финальной cleanup-фазы.
|
||||
|
||||
DoD:
|
||||
- staging validation не зависит от локальных фикстур;
|
||||
- documentation matches deployed behavior;
|
||||
- demo flow reproducible on real environment.
|
||||
- Community release path не зависит от private repositories;
|
||||
- checklist соответствует реальному Community deploy surface;
|
||||
- пост-деплойная проверка повторяема.
|
||||
|
||||
### `feat/common-public-improvements`
|
||||
|
||||
Status: ready
|
||||
|
||||
Goal:
|
||||
- вносить общие улучшения в публичную базу, которые потом синхронно переносятся в `enterprise` и `cloud`.
|
||||
|
||||
Main code areas:
|
||||
- общий Community runtime/UI/API surface
|
||||
|
||||
Implementation slices:
|
||||
1. делать изменение в `crank-community`;
|
||||
2. переносить тот же change set в `crank-enterprise`;
|
||||
3. переносить тот же change set в `crank-cloud`.
|
||||
|
||||
DoD:
|
||||
- общий функционал не расходится между тремя редакциями без необходимости;
|
||||
- Community остается source base для общей open-core логики.
|
||||
|
||||
@@ -76,13 +76,11 @@
|
||||
|
||||
Важно:
|
||||
|
||||
- создание `crank-community`, `crank-enterprise` и `crank-cloud` должно быть отдельным осознанным шагом;
|
||||
- до этого момента в текущем репозитории нужно завершить capability model, extension seams и public contracts;
|
||||
- физическое вынесение private code нельзя начинать раньше, чем эти три целевых repositories созданы и для них определены delivery boundaries.
|
||||
- все три целевых repositories уже созданы;
|
||||
- bootstrap templates уже перенесены в целевые repositories;
|
||||
- baseline-import в `crank-community` уже откачен и не считается финальным public state;
|
||||
- следующий шаг — сделать whitelist-based Community import и только после этого продолжать physical split, не оставляя текущий monorepo source of truth для всех трех редакций.
|
||||
- `crank-community`, `crank-enterprise` и `crank-cloud` уже существуют как отдельные repositories;
|
||||
- `crank-community` больше не рассматривается как промежуточный baseline import, а является public source base;
|
||||
- дальнейшая работа делится на два типа:
|
||||
- общие open-core улучшения сначала делаются в `crank-community`, затем переносятся в private repositories;
|
||||
- cleanup и ограничение Community делаются только в `crank-community`.
|
||||
|
||||
## 6. Техническая стратегия разделения
|
||||
|
||||
@@ -212,12 +210,8 @@ Private code должен подключаться как реализация
|
||||
- Community release path должен опираться на `deploy/community/*`;
|
||||
- private `Enterprise` и `Cloud` manifests не должны проектироваться как вариации того же root compose-файла.
|
||||
|
||||
Подготовительные bootstrap artifacts для будущих репозиториев должны храниться отдельно от production manifests.
|
||||
В текущем репозитории для этого используются:
|
||||
|
||||
- `templates/repositories/crank-community/*`
|
||||
- `templates/repositories/crank-enterprise/*`
|
||||
- `templates/repositories/crank-cloud/*`
|
||||
Подготовительные bootstrap artifacts уже перестали быть центральной частью Community workflow.
|
||||
Для `crank-community` source of truth теперь находится в самом репозитории, а не в transitional templates.
|
||||
|
||||
## 10. Связанные документы
|
||||
|
||||
|
||||
@@ -87,20 +87,17 @@ Community release должен поставлять:
|
||||
- отдельные release pipelines;
|
||||
- отдельные operator docs.
|
||||
|
||||
До создания:
|
||||
Разделение репозиториев уже выполнено:
|
||||
|
||||
- `crank-community`
|
||||
- `crank-enterprise`
|
||||
- `crank-cloud`
|
||||
|
||||
нельзя считать physical packaging split завершенным.
|
||||
Для Community это означает:
|
||||
|
||||
Для технического baseline-export внутри private split rehearsal используется:
|
||||
|
||||
- `scripts/export-community.sh`
|
||||
|
||||
Этот helper не считается финальным public export path.
|
||||
Финальный импорт в `crank-community` должен выполняться только после приведения кода к whitelist из `docs/community-source-whitelist.md`.
|
||||
- release checklist больше не зависит от transitional export procedure;
|
||||
- `crank-community` сам является source of truth для своей поставки;
|
||||
- все требования этого checklist относятся к текущему состоянию репозитория, а не к будущему импорту.
|
||||
|
||||
## 7. Минимальный operator checklist
|
||||
|
||||
|
||||
@@ -2,23 +2,23 @@
|
||||
|
||||
## 1. Назначение документа
|
||||
|
||||
Этот документ фиксирует, что именно допустимо в публичном репозитории `crank-community`, а что должно оставаться за его пределами.
|
||||
Этот документ фиксирует, что именно допустимо в публичном репозитории `crank-community`, а что должно оставаться вне него.
|
||||
|
||||
Документ нужен по двум причинам:
|
||||
Документ нужен для трех задач:
|
||||
|
||||
- исключить повторный baseline-import без фильтрации;
|
||||
- перевести split в режим explicit whitelist, а не последующего удаления лишнего.
|
||||
- держать `crank-community` в рамках честной открытой редакции;
|
||||
- не допускать обратного затекания premium surface после split;
|
||||
- использовать explicit whitelist как правило для дальнейших изменений и синхронизации с private repositories.
|
||||
|
||||
## 2. Текущий статус
|
||||
|
||||
Состояние на текущий момент:
|
||||
`crank-community` уже является самостоятельным public repository и должен рассматриваться как source base для открытой редакции.
|
||||
|
||||
- `crank-community` уже создан;
|
||||
- bootstrap commit в нем сохранен;
|
||||
- baseline-import был выполнен ошибочно и уже удален из истории force-push;
|
||||
- текущий `main` в `crank-community` снова указывает на bootstrap-only состояние.
|
||||
Следствие:
|
||||
|
||||
Это означает, что финальный public import еще не выполнен.
|
||||
- этот репозиторий описывается как действующая открытая кодовая база, а не как временная заготовка;
|
||||
- cleanup выполняется прямо в `crank-community`, а не как подготовка к будущему импорту;
|
||||
- любые общие улучшения сначала оформляются здесь, а затем переносятся в `crank-enterprise` и `crank-cloud`.
|
||||
|
||||
## 3. Разрешенный состав `crank-community`
|
||||
|
||||
@@ -41,8 +41,8 @@
|
||||
|
||||
С оговоркой:
|
||||
|
||||
- `Cargo.toml` и `Cargo.lock` должны быть community-specific и не включать premium crates;
|
||||
- `TASKS.md` после split должен описывать backlog уже для `crank-community`, а не для старого transitional monorepo.
|
||||
- `Cargo.toml` и `Cargo.lock` должны оставаться Community-specific;
|
||||
- `TASKS.md` должен описывать backlog именно для `crank-community`.
|
||||
|
||||
### 3.2. Backend и core crates
|
||||
|
||||
@@ -75,7 +75,7 @@
|
||||
Допустимо сохранять:
|
||||
|
||||
- public capability model;
|
||||
- честные тексты про существование `Enterprise` и `Cloud`.
|
||||
- честные тексты про существование `Enterprise` и `Cloud`, если они не превращаются в рабочий premium UX.
|
||||
|
||||
### 3.4. Deployment и scripts
|
||||
|
||||
@@ -83,7 +83,7 @@
|
||||
|
||||
- `deploy/community/*`
|
||||
- public GitHub workflows для Community
|
||||
- community release docs
|
||||
- Community release docs
|
||||
- public smoke scripts
|
||||
|
||||
### 3.5. Documentation
|
||||
@@ -112,7 +112,7 @@
|
||||
- private release workflows
|
||||
- private operator tooling
|
||||
|
||||
Также не должны оставаться public artifacts, которые реально включают premium-only flows как рабочий Community surface:
|
||||
Также в Community не должны оставаться рабочие premium-only flows:
|
||||
|
||||
- `GraphQL` wizard path
|
||||
- `gRPC` wizard path
|
||||
@@ -122,33 +122,27 @@
|
||||
- Community demo data для premium protocols
|
||||
- premium protocol examples
|
||||
|
||||
## 5. Блокеры для чистого public import
|
||||
## 5. Текущие cleanup-задачи
|
||||
|
||||
Сейчас чистый whitelist export еще нельзя считать готовым, потому что в текущем коде есть смешанные зависимости.
|
||||
На данный момент `crank-community` уже отделен как репозиторий, но еще требует final cleanup.
|
||||
|
||||
Основные блокеры:
|
||||
Основные хвосты:
|
||||
|
||||
1. `admin-api` и `mcp-server` test/dev wiring еще не полностью очищены от legacy streaming/premium references.
|
||||
2. `workspace-setup`, `settings`, `catalog`, `usage`, `agents` и `i18n` все еще содержат отдельные premium protocol strings и copy.
|
||||
3. часть docs все еще требует final Community pass после физического удаления premium crates и standalone streaming pages.
|
||||
1. workspace manifests все еще содержат часть premium protocol toolchain dependencies;
|
||||
2. Community test/dev wiring еще не полностью очищен от legacy streaming и premium protocol references;
|
||||
3. `workspace-setup`, `settings`, `catalog`, `usage`, `agents` и `i18n` все еще содержат отдельные premium strings и dormant UI modules;
|
||||
4. часть docs все еще описывает переходный split-state вместо текущего Community repository.
|
||||
|
||||
## 6. Порядок очистки перед public import
|
||||
## 6. Правило на будущее
|
||||
|
||||
Чистый перенос в `crank-community` должен идти только так:
|
||||
Для `crank-community` действует whitelist-first правило:
|
||||
|
||||
1. Переписать Community workspace так, чтобы он не включал premium crates.
|
||||
2. Удалить premium protocol dependencies из Community backend wiring.
|
||||
3. Сделать отдельный Community UI surface без premium wizard/templates/modules.
|
||||
4. Удалить premium examples и demo fixtures из Community export.
|
||||
5. Перепроверить docs и release artifacts.
|
||||
6. Только после этого делать новый force-push чистой истории в `crank-community`.
|
||||
- сначала определяется, допустима ли возможность в Community;
|
||||
- потом код и документация приводятся к этой границе;
|
||||
- и только после этого изменение попадает в `main`.
|
||||
|
||||
## 7. Правило на будущее
|
||||
Запрещено:
|
||||
|
||||
Для `crank-community` допустим только whitelist-first подход:
|
||||
|
||||
- сначала фиксируется разрешенный состав;
|
||||
- потом код приводится к нему;
|
||||
- и только потом выполняется push.
|
||||
|
||||
Подход “сначала импортировать baseline, потом удалять лишнее” запрещен.
|
||||
- возвращать premium functionality в Community как dormant или half-wired path;
|
||||
- хранить в Community “на будущее” private operator/runtime flows без прямой необходимости для общей базы;
|
||||
- вести backlog так, будто `crank-community` все еще лишь промежуточная стадия split.
|
||||
|
||||
+16
-35
@@ -122,53 +122,34 @@
|
||||
- есть `audit log`;
|
||||
- существует private delivery path для self-hosted customers.
|
||||
|
||||
## 10. Управленческий рубеж: физическое разделение репозиториев
|
||||
## 10. Разделение репозиториев
|
||||
|
||||
### Цель
|
||||
|
||||
Не начинать вынос private functionality хаотично, пока не завершены public seams и capability split.
|
||||
Вести развитие продукта уже в трех отдельных repositories без возврата к модели общего source of truth.
|
||||
|
||||
### Условие входа
|
||||
### Текущий статус
|
||||
|
||||
К этому рубежу можно переходить только после того, как завершены:
|
||||
Разделение репозиториев уже выполнено:
|
||||
|
||||
- open-core product boundary;
|
||||
- edition capability model;
|
||||
- private auth-service seam;
|
||||
- documentation sync по Community / Enterprise / Cloud.
|
||||
- `crank-community` — public Community repository;
|
||||
- `crank-enterprise` — private self-hosted commercial repository;
|
||||
- `crank-cloud` — private hosted/control-plane repository.
|
||||
|
||||
### Действие
|
||||
### Следствие
|
||||
|
||||
На этом этапе нужно создать `3` целевых repositories:
|
||||
Дальнейшая работа строится так:
|
||||
|
||||
- `crank-community`
|
||||
- `crank-enterprise`
|
||||
- `crank-cloud`
|
||||
|
||||
Текущий статус:
|
||||
|
||||
- `crank-community` уже создан;
|
||||
- `crank-enterprise` уже создан;
|
||||
- `crank-cloud` уже создан;
|
||||
- bootstrap templates уже перенесены в новые repositories;
|
||||
- baseline-import в `crank-community` уже откачен и не считается финальным public state;
|
||||
- следующий шаг уже не организационный, а технический:
|
||||
- привести код к whitelist из `docs/community-source-whitelist.md`;
|
||||
- затем выполнить чистый whitelist-based import в `crank-community`;
|
||||
- затем продолжить вынос `enterprise/cloud` delta.
|
||||
|
||||
Bootstrap templates для этого шага уже должны быть подготовлены заранее в текущем репозитории:
|
||||
|
||||
- `templates/repositories/crank-community/*`
|
||||
- `templates/repositories/crank-enterprise/*`
|
||||
- `templates/repositories/crank-cloud/*`
|
||||
1. общие open-core улучшения сначала оформляются в `crank-community`;
|
||||
2. затем тот же change set переносится в `crank-enterprise`;
|
||||
3. затем переносится в `crank-cloud`;
|
||||
4. cleanup и ограничение Community выполняются только в `crank-community`.
|
||||
|
||||
### Результат
|
||||
|
||||
- `crank-community` становится public Community repository;
|
||||
- `crank-enterprise` становится private self-hosted commercial repository;
|
||||
- `crank-cloud` становится private hosted/control-plane repository;
|
||||
- только после этого начинается физическое вынесение Community и коммерческого кода из текущего репозитория по новым delivery boundaries.
|
||||
- `crank-community` остается source base для общей открытой логики;
|
||||
- private repositories держат только свой delta и коммерческие расширения;
|
||||
- старый общий репозиторий больше не рассматривается как главный источник изменений.
|
||||
|
||||
## 11. Этап 8. Cloud control plane
|
||||
|
||||
|
||||
@@ -16,17 +16,17 @@
|
||||
|
||||
## 2. Текущее состояние
|
||||
|
||||
Сейчас код и документация еще живут в одном репозитории.
|
||||
Разделение уже выполнено на уровне репозиториев:
|
||||
|
||||
Это допустимо только как переходное состояние, пока:
|
||||
- `crank-community` — public base;
|
||||
- `crank-enterprise` — private self-hosted delta;
|
||||
- `crank-cloud` — private hosted delta.
|
||||
|
||||
- не зафиксированы capability boundaries;
|
||||
- не подготовлены extension seams;
|
||||
- не собраны отдельные Community delivery artifacts;
|
||||
- не определен physical split plan.
|
||||
Дальнейшая задача не в создании split, а в его дисциплинированном поддержании:
|
||||
|
||||
После завершения этого этапа текущий репозиторий не должен оставаться source of truth сразу для
|
||||
всех трех редакций.
|
||||
- общее улучшение идет сначала в `crank-community`;
|
||||
- затем переносится в `crank-enterprise` и `crank-cloud`;
|
||||
- cleanup Community делается только в `crank-community`.
|
||||
|
||||
## 3. Целевой результат
|
||||
|
||||
@@ -193,42 +193,20 @@ Private repository.
|
||||
4. Public contracts должны остаться в Community и не зависеть от private кодовой базы.
|
||||
5. Private repos не должны требовать обратного копирования логики в Community.
|
||||
|
||||
## 6. Что должно произойти перед физическим split
|
||||
## 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/*`
|
||||
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. Практический вывод
|
||||
|
||||
Следующий управленческий шаг после завершения текущего boundary-трека:
|
||||
Для текущего этапа это означает:
|
||||
|
||||
- начать physical split с `crank-community`
|
||||
- сделать whitelist-based import для `crank-community` и только его считать финальным public source of truth
|
||||
- создать `crank-enterprise`
|
||||
- создать `crank-cloud`
|
||||
|
||||
После этого уже можно планировать фактическое разнесение кода и delivery files.
|
||||
- `crank-community` нужно дочистить до окончательного public состояния;
|
||||
- затем использовать его как source base для общих улучшений;
|
||||
- коммерческие возможности продолжать развивать только в `crank-enterprise` и `crank-cloud`.
|
||||
|
||||
Reference in New Issue
Block a user