crank/docs/module-decomposition.md

Декомпозиция модулей

1. Цель документа

Этот документ фиксирует детальную структуру проекта под целевую модель workspace -> agent -> operations.

Основной принцип: каждый crate отвечает за один слой системы. Внутри crate модули маленькие, тематические и с минимальным количеством публичных сущностей.

2. Общие архитектурные правила

• core содержит только базовую доменную модель, идентификаторы, типы ошибок и общие контракты.
• registry отвечает только за хранение и загрузку workspace-scoped конфигурации.
• runtime исполняет операции, но не знает о способе их хранения.
• адаптеры знают только свой протокол и общий контракт runtime.
• admin-api оркестрирует use case для UI, но не содержит протокольной логики.
• mcp-server публикует agent-scoped tools и вызывает runtime.
• ui работает только через HTTP API.

3. Workspace-структура

  crank/
  apps/
    admin-api/
    mcp-server/
    ui/
  crates/
    crank-core/
    crank-registry/
    crank-runtime/
    crank-adapter-rest/
    crank-adapter-graphql/
    crank-adapter-grpc/
    crank-adapter-websocket/
    crank-adapter-soap/
    crank-mapping/
    crank-schema/
    crank-proto/

Поверх существующих crates должны появиться новые логические поддомены:

• workspace/access domain;
• secret management domain;
• agent publishing domain;
• observability domain.
• streaming execution domain.

4. Детальная декомпозиция по crate

4.1. crank-core

Назначение:

• базовые доменные типы;
• идентификаторы;
• метаданные workspace, operation и agent;
• общие контракты и ошибки.

Внутренние модули:

• ids
• protocol
• workspace
• operation
• agent
• auth
• secret
• observability
• streaming
• errors

4.2. crank-schema

Назначение:

• внутренняя модель схем;
• нормализация входа и выхода;
• представление полей для UI и runtime.

4.3. crank-mapping

Назначение:

• mapping DSL;
• JSONPath parsing;
• input/output mapping;
• draft inference из samples.

4.4. crank-proto

Назначение:

• работа с .proto и descriptor set;
• извлечение services, methods и message schemas;
• преобразование protobuf metadata во внутренние типы.

4.5. crank-registry

Назначение:

• хранение workspace-scoped operations и version snapshots;
• хранение workspace-scoped secrets и secret versions;
• хранение agents и agent versions;
• хранение agent keys и выданных agent tokens;
• хранение stream sessions и async jobs;
• auth profiles;
• platform client credentials;
• logs и usage aggregates;
• metadata по sample artifacts и descriptors.

4.6. crank-runtime

Назначение:

• исполнение published operation;
• резолв auth_profile_ref -> secret -> request auth;
• orchestration window/session/job execution;
• запись invocation events;
• возврат нормализованного результата.

4.7. Protocol adapters

• crank-adapter-rest
• crank-adapter-graphql
• crank-adapter-grpc
• crank-adapter-websocket
• crank-adapter-soap

Каждый adapter знает только свой протокол.

4.8. apps/admin-api

Должен содержать сервисные группы:

• workspaces
• secrets
• memberships
• operations
• auth_profiles
• agents
• agent_keys
• platform_clients
• logs
• usage
• streaming

4.9. apps/mcp-server

Назначение:

• публикация published agent bindings как MCP tools;
• transport handling;
• JSON-RPC lifecycle;
• SSE lifecycle и Mcp-Session-Id;
• tool-family generation для session и async_job;
• вызов runtime.

Антипаттерн:

не превращать mcp-server во второй admin-api.

5. Разделение open-source и commercial модулей

5.1. Что остается в crank-community

В этом репозитории должны жить:

• Community domain model;
• Community runtime;
• Community UI;
• extension seams для коммерческих возможностей;
• capability model по редакциям.

5.2. Что должно выноситься в private delivery

За пределами crank-community должны жить:

• short-lived и one-time token issuers;
• enterprise access services;
• SSO, 2FA, RBAC, audit log;
• metering и billing;
• cloud control plane;
• premium protocol families, если они не входят в Community edition.

5.3. Техническое правило

Public code не должен содержать скрытую private business logic.

Допустимо:

• trait boundaries;
• capability flags;
• edition-aware service contracts.

Недопустимо:

• полноценная коммерческая реализация в open-source исходниках;
• UI, который реально включает premium flow без server-side gating.