docs: align community repo as source of truth

This commit is contained in:
github-ops
2026-05-10 16:46:50 +00:00
parent ca9b86aada
commit ef007a4a21
6 changed files with 148 additions and 289 deletions
+70 -155
View File
@@ -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 логики.