crank/docs/community-source-whitelist.md

Community source whitelist

1. Назначение документа

Этот документ фиксирует, что именно допустимо в публичном репозитории crank-community, а что должно оставаться вне него.

Документ нужен для трех задач:

• держать crank-community в рамках честной открытой редакции;
• не допускать обратного затекания premium surface после split;
• использовать explicit whitelist как правило для дальнейших изменений и синхронизации с private repositories.

2. Текущий статус

crank-community уже является самостоятельным public repository и должен рассматриваться как source base для открытой редакции.

Следствие:

• этот репозиторий описывается как действующая открытая кодовая база, а не как временная заготовка;
• cleanup выполняется прямо в crank-community, а не как подготовка к будущему импорту;
• любые общие улучшения сначала оформляются здесь, а затем переносятся в crank-enterprise и crank-cloud.

3. Разрешенный состав crank-community

3.1. Верхнеуровневые файлы

Разрешены:

• AGENTS.md
• Cargo.toml
• Cargo.lock
• LICENSE
• README.md
• TASKS.md
• justfile
• rust-toolchain.toml
• .dockerignore
• .env.example
• .gitignore
• .sqlx/*

С оговоркой:

• Cargo.toml и Cargo.lock должны оставаться Community-specific;
• TASKS.md должен описывать backlog именно для crank-community.

3.2. Backend и core crates

Разрешены:

• apps/admin-api
• apps/mcp-server
• crates/crank-core
• crates/crank-schema
• crates/crank-mapping
• crates/crank-registry
• crates/crank-runtime
• crates/crank-adapter-rest

С оговоркой:

• crank-runtime должен собираться как REST-only база;
• Community workspace не должен зависеть от GraphQL, gRPC, SOAP, WebSocket adapter crates;
• server-side capability enforcement должен оставаться честным и не позволять premium protocol paths.

3.3. UI

Разрешены:

• Community UI pages;
• Community wizard для REST;
• capability-gated copy, который честно описывает границы Community;
• Community demo and staging flows.

Допустимо сохранять:

• public capability model;
• честные тексты про существование Enterprise и Cloud, если они не превращаются в рабочий premium UX.

3.4. Deployment и scripts

Разрешены:

• deploy/community/*
• public GitHub workflows для Community
• Community release docs
• public smoke scripts

3.5. Documentation

Разрешены:

• public architecture docs;
• public API/MCP contracts;
• product-editions, commercial-boundaries, repository-split-map;
• Community deployment and smoke docs;
• Community release checklist.

4. Явный blacklist для crank-community

В публичный репозиторий не должны попадать:

• crates/crank-adapter-graphql
• crates/crank-adapter-grpc
• crates/crank-adapter-soap
• crates/crank-adapter-websocket
• private token issuer implementations
• enterprise governance implementations
• metering / billing implementations
• hosted control-plane code
• private delivery manifests
• private release workflows
• private operator tooling

Также в Community не должны оставаться рабочие premium-only flows:

• GraphQL wizard path
• gRPC wizard path
• SOAP wizard path
• WebSocket wizard path
• Community streaming execution UI
• Community demo data для premium protocols
• premium protocol examples

5. Текущие cleanup-задачи

На данный момент crank-community уже отделен как репозиторий, но еще требует final cleanup.

Основные хвосты:

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. Правило на будущее

Для crank-community действует whitelist-first правило:

• сначала определяется, допустима ли возможность в Community;
• потом код и документация приводятся к этой границе;
• и только после этого изменение попадает в main.

Запрещено:

• возвращать premium functionality в Community как dormant или half-wired path;
• хранить в Community “на будущее” private operator/runtime flows без прямой необходимости для общей базы;
• вести backlog так, будто crank-community все еще лишь промежуточная стадия split.