a.tolmachev
190 lines
6.3 KiB
Markdown
190 lines
6.3 KiB
Markdown
# План реализации
|
||
|
||
## 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 работают так же, как для остальных протоколов.
|
||
|
||
## 15. Этап 14. Detailed streaming specs
|
||
|
||
Цель:
|
||
|
||
- довести streaming-docs до function-level и field-level design спецификации.
|
||
|
||
DoD:
|
||
|
||
- есть отдельные docs для streaming admin-api, runtime, UI и capability matrix;
|
||
- protocol docs не противоречат общей execution model;
|
||
- roadmap и `TASKS.md` синхронизированы с full-detail architecture.
|