docs: rename target repository split

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;