crank/docs/implementation-plan.md

План реализации

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

Этот документ фиксирует порядок перехода от текущего состояния проекта к целевой product-ready integration platform модели.

Принцип:

• сначала перепроектирование as is -> to be;
• потом foundation под workspace/agent model;
• потом возврат к end-to-end UI сценариям;
• потом observability и access layer;
• потом polish и demo readiness;
• потом расширение до полного protocol platform scope.

2. Этап 1. Перепроектирование As Is -> To Be

Цель:

• зафиксировать новую доменную модель и page-driven backend contract.

DoD:

• зафиксирован as is -> to be план;
• page-by-page gap analysis покрывает все целевые экраны;
• разобраны все архитектурные конфликты UI vs current backend;
• документы architecture, data-model, database-schema, admin-api, mcp-interface синхронизированы.

3. Этап 2. Workspace foundation

Цель:

• перевести хранение и API на workspace-scoped модель.

DoD:

• операции и auth profiles принадлежат workspace;
• registry умеет фильтровать данные по workspace;
• есть default workspace migration path.

4. Этап 3. Agent publishing foundation

Цель:

• ввести Agent и agent-scoped MCP publishing.

DoD:

• можно создать agent и привязать к нему published operations;
• mcp-server выдает tools в контексте конкретного agent;
• один agent видит только свой curated toolset.

5. Этап 4. Operations and wizard integration

Цель:

• посадить operations catalog и wizard на реальные backend contracts.

DoD:

• каталог операций и wizard работают без localStorage overrides;
• operation edit/delete/publish/test выполняются через backend;
• все протоколы работают в рамках одного UI flow.

6. Этап 5. Agents UI and backend

Цель:

• реализовать agent-centric слой.

DoD:

• agent CRUD работает;
• binding operations к agent работает;
• published agent появляется в MCP runtime.

7. Этап 6. Platform access

Цель:

• реализовать workspace access и platform API keys.

DoD:

• UI screens API Keys, Settings, Workspace имеют backend-контракт;
• platform API keys не смешиваются с upstream auth profiles;
• tenant boundary выражен в access layer.

8. Этап 7. Observability

Цель:

• реализовать логи и usage.

DoD:

• Logs page и Usage page работают на реальных данных;
• есть продуктовые endpoints, а не только application logs;
• rollups и detail views согласованы с UI.

9. Этап 8. Alpine UI integration

Цель:

• довести apps/ui до полной работы на реальном backend.

DoD:

• apps/ui содержит целевой Alpine.js UI;
• mock JSON больше не используется на критическом пути;
• UI, backend и docs синхронизированы.

10. Этап 9. Secret store and upstream auth

Цель:

• заменить UI placeholder-модель ${secrets.*} на рабочий backend/runtime слой secrets.

DoD:

• есть workspace-scoped Secrets resource;
• secret values хранятся только в зашифрованном виде;
• AuthProfile ссылается на secret_id, а не на строковый placeholder;
• runtime умеет применять bearer/basic/api-key auth к реальному upstream request;
• wizard имеет auth selector и quick-create flow для secrets/auth profiles.

11. Этап 10. Hardening and demo readiness

Цель:

• довести продукт до стабильного демо-сценария.

DoD:

• end-to-end demo воспроизводим;
• deployment и healthchecks стабильно зелёные;
• документация и продуктовый сценарий совпадают.

12. Этап 11. MCP streaming proxy support

Цель:

• довести Crank до controlled streaming model поверх MCP Streamable HTTP.

DoD:

• mcp-server соответствует transport semantics 2025-06-18;
• execution modes window, session, async_job формально описаны и реализованы;
• REST SSE и gRPC server-streaming поддерживаются в bounded форме;
• UI умеет конфигурировать streaming limits, aggregation и lifecycle;
• e2e сценарии покрывают window/session/job calls.

13. Этап 12. WebSocket upstream support

Цель:

• добавить полноценный WebSocket upstream adapter в общую execution model.

DoD:

• есть WebSocket target model;
• runtime поддерживает bounded window, session и async_job;
• heartbeat, reconnect и subscription lifecycle конфигурируются явно;
• docs, UI и e2e синхронизированы.

14. Этап 13. SOAP support

Цель:

• добавить SOAP как enterprise-oriented protocol family.

DoD:

• есть WSDL/XSD-driven target model;
• runtime умеет строить SOAP envelopes и нормализовать SOAP Faults;
• operator может выбрать service, port и operation;
• test-run, publish и observability работают так же, как для остальных протоколов.