docs: align community repo as source of truth

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.