diff --git a/TASKS.md b/TASKS.md
index ab42975..a5bd74b 100644
--- a/TASKS.md
+++ b/TASKS.md
@@ -185,11 +185,16 @@ Implementation slices:
 2. Подготовить отдельные delivery manifests для Community.
 3. Убрать из public repo assumptions о размещении private code рядом с Community logic.
 4. Подготовить naming и packaging strategy для private repositories.
+5. После завершения seams и capability split остановиться на управленческом gate и создать:
+   - private repository `crank-enterprise`
+   - private repository `crank-cloud`
+   Только после этого начинать физическое вынесение commercial code из public repo.
 
 DoD:
 - можно объяснить, что именно публикуется как OSS, а что уходит в private delivery;
 - Community release path отделен от commercial release path;
 - документация не ссылается на удаленные review files.
+- момент создания `2` private repositories зафиксирован в плане как отдельный обязательный шаг, а не подразумевается неявно.
 
 Verification:
 - docs consistency pass;
diff --git a/docs/commercial-boundaries.md b/docs/commercial-boundaries.md
index 95bc4a9..f6fcd09 100644
--- a/docs/commercial-boundaries.md
+++ b/docs/commercial-boundaries.md
@@ -71,6 +71,12 @@
 - `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.
+
 ## 6. Техническая стратегия разделения
 
 ### 6.1. Capability-first design
diff --git a/docs/implementation-plan.md b/docs/implementation-plan.md
index 90956a0..e1af836 100644
--- a/docs/implementation-plan.md
+++ b/docs/implementation-plan.md
@@ -119,7 +119,36 @@
 - есть `audit log`;
 - существует private delivery path для self-hosted customers.
 
-## 10. Этап 8. Cloud control plane
+## 10. Управленческий рубеж: физическое разделение репозиториев
+
+### Цель
+
+Не начинать вынос private functionality хаотично, пока не завершены public seams и capability split.
+
+### Условие входа
+
+К этому рубежу можно переходить только после того, как завершены:
+
+- open-core product boundary;
+- edition capability model;
+- private auth-service seam;
+- documentation sync по Community / Enterprise / Cloud.
+
+### Действие
+
+На этом этапе нужно создать `2` новых private repositories:
+
+- `crank-enterprise`
+- `crank-cloud`
+
+### Результат
+
+- `crank` остается public Community repository;
+- `crank-enterprise` становится private self-hosted commercial repository;
+- `crank-cloud` становится private hosted/control-plane repository;
+- только после этого начинается физическое вынесение коммерческого кода из public repo.
+
+## 11. Этап 8. Cloud control plane
 
 ### Цель
 
@@ -133,7 +162,7 @@
 - есть cloud deployment and support tooling;
 - capability model синхронизирована с hosted plans.
 
-## 11. Этап 9. Release and distribution hardening
+## 12. Этап 9. Release and distribution hardening
 
 ### Цель
 
@@ -147,7 +176,7 @@
 - build provenance и подпись артефактов документированы;
 - коммерческий код не требуется публиковать в public repository.
 
-## 12. Этап 10. Live staging and demo readiness
+## 13. Этап 10. Live staging and demo readiness
 
 ### Цель
 
@@ -160,7 +189,7 @@
 - demo user flow подтвержден на реальном окружении;
 - регрессии в publish/call/auth flow ловятся до релиза.
 
-## 13. Связанные документы
+## 14. Связанные документы
 
 - `docs/product-editions.md`
 - `docs/commercial-boundaries.md`