docs: rename target repository split

TASKS.md

@@ -7,7 +7,7 @@
 Status: in_progress
 
 Goal:
-- закрепить техническую границу между public Community repo и private commercial delivery.
+- закрепить техническую границу между `crank-community`, `crank-enterprise` и `crank-cloud`.
 
 Main code areas:
 - `docs/commercial-boundaries.md`
@@ -19,18 +19,19 @@ Main code areas:
 Implementation slices:
 1. Определить extension seams в public code.
 2. Подготовить отдельные delivery manifests для Community.
-3. Убрать из public repo assumptions о размещении private code рядом с Community logic.
+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 из public repo.
+   Только после этого начинать физическое вынесение commercial code из текущего monorepo.
 
 DoD:
 - можно объяснить, что именно публикуется как OSS, а что уходит в private delivery;
 - Community release path отделен от commercial release path;
 - документация не ссылается на удаленные review files.
-- момент создания `2` private repositories зафиксирован в плане как отдельный обязательный шаг, а не подразумевается неявно.
+- момент создания `3` целевых repositories зафиксирован в плане как отдельный обязательный шаг, а не подразумевается неявно.
 
 Verification:
 - docs consistency pass;
@@ -38,12 +39,12 @@ Verification:
 
 Progress:
 - done:
-  - gate for creating `2` private repositories is already documented before any physical commercial split
+  - 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
 - pending:
-  - remaining extension seams and packaging split still need to move from planning into concrete public/private manifests
+  - remaining extension seams and packaging split still need to move from planning into concrete `crank-community` / `crank-enterprise` / `crank-cloud` manifests
 
 ## Planned
 
@@ -115,7 +116,7 @@ Implementation slices:
 4. release checklist for edition-specific packaging.
 
 DoD:
-- Community публикуется из public repo;
+- Community публикуется из `crank-community`;
 - Enterprise и Cloud используют private delivery path;
 - коммерческий код не требуется публиковать в open source ради поставки.
 

docs/architecture.md

@@ -235,7 +235,7 @@ Crank развивается как open-core продукт.
 
 Коммерческий контур не должен защищаться "скрытием" уже опубликованного исходного кода. Правильная архитектурная граница выглядит так:
 
-- в public repo остается Community runtime и extension seams;
+- в `crank-community` остается Community runtime и extension seams;
 - коммерческие реализации поставляются из private repositories или private artifacts;
 - критичные правила лицензирования, metering и token issuance исполняются на серверной стороне.
 

docs/commercial-boundaries.md

@@ -67,15 +67,15 @@
 
 Рекомендуемая схема:
 
-- `crank` — public Community repo;
+- `crank-community` — public Community repo;
 - `crank-enterprise` — private self-hosted extensions;
 - `crank-cloud` — private cloud control plane и hosted-only logic.
 
 Важно:
 
-- создание `crank-enterprise` и `crank-cloud` должно быть отдельным осознанным шагом;
-- до этого момента в public repo нужно завершить capability model, extension seams и public contracts;
-- физическое вынесение private code нельзя начинать раньше, чем эти два private repositories созданы и для них определены delivery boundaries.
+- создание `crank-community`, `crank-enterprise` и `crank-cloud` должно быть отдельным осознанным шагом;
+- до этого момента в текущем репозитории нужно завершить capability model, extension seams и public contracts;
+- физическое вынесение private code нельзя начинать раньше, чем эти три целевых repositories созданы и для них определены delivery boundaries.
 
 ## 6. Техническая стратегия разделения
 

docs/community-release-checklist.md

@@ -79,6 +79,7 @@ Community release должен поставлять:
 
 Они должны иметь:
 
+- отдельный public repository `crank-community`;
 - отдельные private repositories;
 - отдельные manifests;
 - отдельные release pipelines;
@@ -86,6 +87,7 @@ Community release должен поставлять:
 
 До создания:
 
+- `crank-community`
 - `crank-enterprise`
 - `crank-cloud`
 

docs/development-rules.md

@@ -178,7 +178,7 @@
 
 Для проекта фиксируется дополнительное правило:
 
-- код `Community` живет в public repository;
+- код `Community` в целевой split-модели живет в `crank-community`;
 - коммерческий код не должен попадать в public repository "на будущее";
 - в public code допустимы только extension seams, capability flags и контракты для private implementations;
 - edition gating должно проверяться на серверной стороне, а не только в UI.

docs/implementation-plan.md

@@ -138,17 +138,18 @@
 
 ### Действие
 
-На этом этапе нужно создать `2` новых private repositories:
+На этом этапе нужно создать `3` целевых repositories:
 
+- `crank-community`
 - `crank-enterprise`
 - `crank-cloud`
 
 ### Результат
 
-- `crank` остается public Community repository;
+- `crank-community` становится public Community repository;
 - `crank-enterprise` становится private self-hosted commercial repository;
 - `crank-cloud` становится private hosted/control-plane repository;
-- только после этого начинается физическое вынесение коммерческого кода из public repo.
+- только после этого начинается физическое вынесение Community и коммерческого кода из текущего репозитория по новым delivery boundaries.
 
 ## 11. Этап 8. Cloud control plane
 
@@ -172,7 +173,7 @@
 
 ### DoD
 
-- Community публикуется из public GitHub repository;
+- Community публикуется из `crank-community`;
 - Enterprise поставляется через private container registry и private manifests;
 - Cloud использует отдельный private operational contour;
 - build provenance и подпись артефактов документированы;

docs/module-decomposition.md

@@ -162,7 +162,7 @@
 
 ## 5. Разделение open-source и commercial модулей
 
-### 5.1. Что остается в public repository
+### 5.1. Что остается в `crank-community`
 
 В этом репозитории должны жить:
 
@@ -174,7 +174,7 @@
 
 ### 5.2. Что должно выноситься в private delivery
 
-За пределами public repo должны жить:
+За пределами `crank-community` должны жить:
 
 - short-lived и one-time token issuers;
 - enterprise access services;