diff --git a/TASKS.md b/TASKS.md index 42ce889..6192e43 100644 --- a/TASKS.md +++ b/TASKS.md @@ -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 логики. diff --git a/docs/commercial-boundaries.md b/docs/commercial-boundaries.md index 97acf43..41c24fe 100644 --- a/docs/commercial-boundaries.md +++ b/docs/commercial-boundaries.md @@ -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. Связанные документы diff --git a/docs/community-release-checklist.md b/docs/community-release-checklist.md index e6044b7..25d9094 100644 --- a/docs/community-release-checklist.md +++ b/docs/community-release-checklist.md @@ -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 diff --git a/docs/community-source-whitelist.md b/docs/community-source-whitelist.md index 8d807cc..6f1480d 100644 --- a/docs/community-source-whitelist.md +++ b/docs/community-source-whitelist.md @@ -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. diff --git a/docs/implementation-plan.md b/docs/implementation-plan.md index c578ca8..c89daf9 100644 --- a/docs/implementation-plan.md +++ b/docs/implementation-plan.md @@ -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 diff --git a/docs/repository-split-map.md b/docs/repository-split-map.md index 77c7d0d..af971ac 100644 --- a/docs/repository-split-map.md +++ b/docs/repository-split-map.md @@ -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`.