diff --git a/README.md b/README.md index fadbc25..585f993 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ Crank - платформа для публикации внешних API в в - Разработать MCP server на Rust. - Поддержать динамическое добавление интеграций через UI или конфигурацию. -- Обеспечить единый сценарий работы оператора для REST, GraphQL и gRPC. +- Обеспечить единый сценарий работы оператора для REST, GraphQL, gRPC, WebSocket и SOAP. - Нормализовать внешние протоколы в единую внутреннюю модель операции. - Ограничивать набор tools на уровне конкретного агента, а не отдавать один глобальный каталог. - Поддержать workspace-изоляцию, platform access и observability. @@ -21,6 +21,8 @@ Crank - платформа для публикации внешних API в в - Поддержка REST для `GET`, `POST`, `PUT`, `PATCH` и `DELETE`. - Поддержка GraphQL для `query` и `mutation`. - Поддержка unary и bounded server-streaming для gRPC. +- Поддержка WebSocket upstream integrations в bounded execution modes. +- Поддержка SOAP/WSDL enterprise integrations. - Поддержка controlled streaming modes поверх MCP `Streamable HTTP`. - Platform API keys и membership layer. - Observability: invocation logs, usage aggregates, latency/error metrics. @@ -54,6 +56,8 @@ Crank - платформа для публикации внешних API в в - `docs/protocols/rest.md` - требования и ограничения для REST. - `docs/protocols/graphql.md` - требования и ограничения для GraphQL. - `docs/protocols/grpc.md` - требования и ограничения для gRPC. +- `docs/protocols/websocket.md` - требования и ограничения для WebSocket. +- `docs/protocols/soap.md` - требования и ограничения для SOAP. ## Ключевая идея продукта @@ -90,8 +94,10 @@ Crank - платформа для публикации внешних API в в - REST - GraphQL - gRPC +- WebSocket +- SOAP -`SOAP` сознательно не входит в текущий scope. +Все пять протокольных семейств входят в целевой product scope. Разница только в очередности реализации. ## Frontend e2e diff --git a/TASKS.md b/TASKS.md index ad6532e..4685bf3 100644 --- a/TASKS.md +++ b/TASKS.md @@ -2,14 +2,14 @@ ## Current -### `feat/streaming-mcp-architecture` +### `feat/full-protocol-platform-architecture` Status: completed DoD: -- Official MCP transport semantics are reflected in docs -- Streaming modes and protocol support matrix are documented -- Core docs and `TASKS.md` are synchronized around controlled streaming model +- Product scope covers REST, GraphQL, gRPC, WebSocket and SOAP +- Execution model is documented independently from protocol families +- Core docs and protocol docs are synchronized around full protocol platform scope ## Next @@ -25,6 +25,9 @@ DoD: - `feat/rest-sse-adapter` - `feat/grpc-server-streaming-adapter` - `feat/session-and-job-tools` +- `feat/websocket-upstream-adapter` +- `feat/soap-architecture-and-core-model` +- `feat/soap-adapter-foundation` - `feat/streaming-ui-config` - `feat/streaming-e2e` - `feat/auth-profile-secret-resolution` diff --git a/docs/architecture.md b/docs/architecture.md index d43a836..e24c41c 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -124,13 +124,13 @@ Crank - платформа для публикации внешних API в в - изолировать данные команд; - строить logs и usage не глобально, а по tenant boundary. -## 5. Границы целевого MVP +## 5. Границы целевого продукта ### Входит - `Workspace` как tenant boundary. -- Операции `REST`, `GraphQL`, `unary gRPC`. -- Controlled streaming operations поверх `Streamable HTTP`, REST SSE и gRPC server-streaming. +- Операции `REST`, `GraphQL`, `gRPC`, `WebSocket`, `SOAP`. +- Controlled streaming operations поверх `Streamable HTTP`, REST SSE, gRPC server-streaming и WebSocket upstream. - `Agent` и привязка операций к агенту. - Agent-scoped MCP endpoints. - Platform API keys. @@ -140,11 +140,12 @@ Crank - платформа для публикации внешних API в в - Импорт и экспорт operation-конфигураций в `YAML`. - Hot reload опубликованных agents и operations. -### Не входит +### Отложено - GraphQL `subscription`. - gRPC client-streaming и bidirectional streaming. -- SOAP. +- raw infinite stream passthrough. +- полный стек WS-* расширений. - Оркестрация workflow. - Биллинг. - Full RBAC policy engine. @@ -209,12 +210,28 @@ GraphQL в MCP публикуется как фиксированная опер - JSON-oriented schema model поверх protobuf; - без client-streaming и bidi. +### WebSocket + +- upstream-only adapter; +- bounded `window`, `session` и `async_job`; +- subscribe/unsubscribe messages; +- heartbeat и reconnect policy; +- не используется как downstream MCP transport. + +### SOAP + +- WSDL-driven request-response integration; +- service/port/operation selection; +- SOAP envelope и fault normalization; +- request-response first; +- long-running workflows через `async_job`, если upstream это поддерживает. + ### Streaming Платформа поддерживает controlled streaming model: - downstream transport: `Streamable HTTP` с optional SSE; -- upstream streaming: REST SSE и gRPC server-streaming; +- upstream streaming: REST SSE, gRPC server-streaming и WebSocket; - execution modes: `unary`, `window`, `session`, `async_job`; - никакого raw infinite stream passthrough в MCP client. diff --git a/docs/data-model.md b/docs/data-model.md index d5dea27..7567f25 100644 --- a/docs/data-model.md +++ b/docs/data-model.md @@ -64,6 +64,23 @@ Бесконечный passthrough stream не является допустимой моделью `Operation`. +### 2.8. Execution model важнее transport-specific особенностей + +Каждая операция в системе определяется двумя измерениями: + +- `protocol` +- `execution_mode` + +Это позволяет описывать: + +- REST unary; +- REST SSE window; +- gRPC server-stream session; +- WebSocket event feed; +- SOAP request-response; + +в рамках одной общей модели runtime и MCP publishing. + ## 3. Корневые сущности ### 3.1. `Workspace` @@ -400,6 +417,27 @@ - `descriptor_ref` - `descriptor_set_b64` +### 4.4. `WebSocketTarget` + +- `kind` +- `url` +- `subprotocols` +- `subscribe_message_template` +- `unsubscribe_message_template` +- `static_headers` + +### 4.5. `SoapTarget` + +- `kind` +- `wsdl_ref` +- `service_name` +- `port_name` +- `operation_name` +- `endpoint_override` +- `soap_version` +- `soap_action` +- `header_config` + ## 5. `Schema` `Schema` - нормализованное описание входа или выхода. diff --git a/docs/implementation-plan.md b/docs/implementation-plan.md index 84c5400..9568897 100644 --- a/docs/implementation-plan.md +++ b/docs/implementation-plan.md @@ -2,7 +2,7 @@ ## 1. Назначение документа -Этот документ фиксирует порядок перехода от текущего состояния проекта к целевой Alpine UI модели. +Этот документ фиксирует порядок перехода от текущего состояния проекта к целевой product-ready integration platform модели. Принцип: @@ -10,7 +10,8 @@ - потом foundation под workspace/agent model; - потом возврат к end-to-end UI сценариям; - потом observability и access layer; -- потом polish и demo readiness. +- потом polish и demo readiness; +- потом расширение до полного protocol platform scope. ## 2. Этап 1. Перепроектирование `As Is -> To Be` @@ -148,3 +149,29 @@ DoD: - 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 работают так же, как для остальных протоколов. diff --git a/docs/module-decomposition.md b/docs/module-decomposition.md index 41d107a..2bf05cc 100644 --- a/docs/module-decomposition.md +++ b/docs/module-decomposition.md @@ -19,7 +19,7 @@ ## 3. Workspace-структура ```text -crank/ + crank/ apps/ admin-api/ mcp-server/ @@ -31,6 +31,8 @@ crank/ crank-adapter-rest/ crank-adapter-graphql/ crank-adapter-grpc/ + crank-adapter-websocket/ + crank-adapter-soap/ crank-mapping/ crank-schema/ crank-proto/ @@ -121,6 +123,8 @@ crank/ - `crank-adapter-rest` - `crank-adapter-graphql` - `crank-adapter-grpc` +- `crank-adapter-websocket` +- `crank-adapter-soap` Каждый adapter знает только свой протокол. diff --git a/docs/protocols/graphql.md b/docs/protocols/graphql.md index b797cb1..1fdca2d 100644 --- a/docs/protocols/graphql.md +++ b/docs/protocols/graphql.md @@ -4,7 +4,7 @@ GraphQL поддерживается как отдельный тип интеграции, но на слое MCP намеренно ограничивается. Цель платформы не в том, чтобы дать LLM универсальный доступ ко всему GraphQL endpoint, а в том, чтобы превратить конкретный GraphQL-запрос в узкий и предсказуемый MCP tool. -## 2. Что поддерживается в MVP +## 2. Что поддерживается в целевом продукте - `query` - `mutation` @@ -21,7 +21,7 @@ GraphQL поддерживается как отдельный тип интег - ручная донастройка через `JSONPath` - тестовый вызов перед публикацией -## 3. Что не входит в MVP +## 3. Что отложено - `subscription` - универсальный GraphQL explorer для LLM diff --git a/docs/protocols/grpc.md b/docs/protocols/grpc.md index ae8d36f..e54ff5b 100644 --- a/docs/protocols/grpc.md +++ b/docs/protocols/grpc.md @@ -4,7 +4,7 @@ gRPC поддерживается как третий основной протокол платформы в управляемой форме. Цель состоит не в том, чтобы покрыть все возможности gRPC, а в том, чтобы представить unary и bounded server-streaming методы как MCP tools с предсказуемым жизненным циклом. -## 2. Что поддерживается в MVP +## 2. Что поддерживается в целевом продукте - unary RPC - bounded server-streaming через execution modes `window`, `session`, `async_job` @@ -21,7 +21,7 @@ gRPC поддерживается как третий основной прот - auth/transport settings на уровне соединения - тестовый вызов перед публикацией -## 3. Что не входит в MVP +## 3. Что отложено - `client streaming` - `bidirectional streaming` diff --git a/docs/protocols/rest.md b/docs/protocols/rest.md index 1fd05ae..06585ce 100644 --- a/docs/protocols/rest.md +++ b/docs/protocols/rest.md @@ -4,7 +4,7 @@ REST - базовый и первый по очередности реализации протокол платформы. На нем должна быть обкатана общая модель `Operation`, схема входа и выхода, маппинг, тестовый запуск и публикация MCP tool. -## 2. Что поддерживается в MVP +## 2. Что поддерживается в целевом продукте - HTTP methods: `GET`, `POST`, `PUT`, `PATCH`, `DELETE` - загрузка примера входного `JSON` @@ -23,7 +23,7 @@ REST - базовый и первый по очередности реализа - тестовый вызов перед публикацией - optional REST SSE upstream в bounded `window` и `session` режимах -## 3. Что не входит в MVP +## 3. Что отложено - multipart/form-data - file upload/download как отдельный сценарий diff --git a/docs/protocols/soap.md b/docs/protocols/soap.md new file mode 100644 index 0000000..c1d35eb --- /dev/null +++ b/docs/protocols/soap.md @@ -0,0 +1,126 @@ +# SOAP + +## 1. Роль протокола в проекте + +SOAP поддерживается как enterprise-oriented upstream protocol для интеграций с системами, где REST уже не является стандартом де-факто. + +Типичные домены: + +- ERP; +- banking; +- insurance; +- government and B2B gateways; +- legacy enterprise systems; +- ESB-oriented internal APIs. + +## 2. Что поддерживается в целевом продукте + +- SOAP 1.1 и SOAP 1.2; +- WSDL upload/import; +- выбор `service`, `port` и `operation`; +- document/literal first; +- XML schema extraction из WSDL/XSD; +- input/output schema generation; +- mapping `MCP JSON -> SOAP body`; +- mapping `SOAP response -> normalized JSON`; +- SOAP headers config; +- basic auth, bearer auth и auth profiles; +- test run; +- publish as MCP tool. + +## 3. Что не входит в текущий продуктовый scope + +- полный стек WS-* расширений; +- MTOM attachments; +- arbitrary XML transformation engine; +- full schema authoring inside UI; +- server-side SOAP hosting. + +## 4. Ключевое архитектурное ограничение + +SOAP не является просто HTTP POST с XML body. + +Для платформы SOAP operation определяется: + +- WSDL model; +- service/port/operation binding; +- envelope structure; +- namespaces; +- optional SOAPAction; +- fault model; +- XML schema contract. + +Поэтому SOAP должен иметь отдельный adapter и отдельную конфигурационную модель. + +## 5. Типовые use cases + +- enterprise CRM/ERP operations; +- payment and settlement integrations; +- policy and claims systems; +- regulated B2B data exchange; +- legacy internal service contracts. + +## 6. Внутренняя модель SOAP operation + +SOAP operation должна включать: + +- `wsdl_ref` +- `service_name` +- `port_name` +- `operation_name` +- `endpoint_override` +- `soap_version` +- `soap_action` +- `input_schema` +- `output_schema` +- `input_mapping` +- `output_mapping` +- `header_config` +- `execution_config` +- `tool_description` + +## 7. Как оператор настраивает SOAP operation + +1. Загружает WSDL. +2. Система извлекает services, ports, operations и XSD schemas. +3. Оператор выбирает service, port и operation. +4. UI показывает input/output schema в JSON-oriented виде. +5. Оператор настраивает mapping `MCP input -> SOAP body`. +6. При необходимости задает SOAP headers и auth profile. +7. Настраивает output mapping и fault handling. +8. Выполняет test run. +9. Публикует operation как MCP tool. + +## 8. Поведение runtime + +При выполнении SOAP operation runtime должен: + +1. Валидировать MCP input. +2. Построить XML envelope. +3. Подставить namespaces и headers. +4. Выполнить HTTP request. +5. Разобрать SOAP response и SOAP Fault. +6. Нормализовать XML result в JSON. +7. Применить output mapping. +8. Вернуть итоговый результат. + +## 9. Критические нюансы + +- WSDL import должен быть отделен от runtime call; +- XML namespaces должны быть first-class частью конфигурации; +- SOAP Fault нельзя сводить только к HTTP error; +- input/output schema должны отображаться в UI как нормализованные поля, а не как raw XML; +- auth и headers должны настраиваться отдельно от body mapping. + +## 10. Почему SOAP должен входить в product scope + +Если Crank позиционируется как enterprise integration platform, отсутствие SOAP оставляет большую часть legacy и regulated environments вне продукта. + +Поэтому SOAP должен быть частью общей protocol strategy наравне с: + +- REST +- GraphQL +- gRPC +- WebSocket + +Но при этом он должен оставаться request-response oriented adapter, а не ломать общую execution model. diff --git a/docs/protocols/websocket.md b/docs/protocols/websocket.md new file mode 100644 index 0000000..48b92ca --- /dev/null +++ b/docs/protocols/websocket.md @@ -0,0 +1,133 @@ +# WebSocket + +## 1. Роль протокола в проекте + +WebSocket поддерживается как полноценный upstream protocol для realtime, push-oriented и stateful integrations. Он не заменяет downstream MCP transport, а работает за Crank proxy. + +Иными словами: + +- downstream: MCP `Streamable HTTP`; +- upstream: WebSocket; +- Crank нормализует WebSocket lifecycle в bounded MCP tool semantics. + +## 2. Что поддерживается в целевом продукте + +- клиентское WebSocket подключение к внешнему upstream; +- custom headers и auth profiles; +- handshake config; +- optional subprotocol selection; +- subscription payload или start message; +- bounded `window` mode; +- `session` mode с `start/poll/stop`; +- `async_job` mode для control-plane и progress channels; +- JSON message parsing; +- text-frame based event collection; +- mapping `MCP input -> subscribe payload`; +- mapping `WebSocket message -> normalized JSON`; +- heartbeat/keepalive config; +- reconnect policy для controlled session modes. + +## 3. Что не входит в текущий продуктовый scope + +- raw binary frame passthrough в LLM; +- arbitrary bidirectional conversation tunnel; +- full message bus semantics; +- generic browser-like socket inspector; +- guaranteed resumability across arbitrary upstream websocket providers. + +## 4. Ключевое архитектурное ограничение + +WebSocket не публикуется как "живой канал в чат". Он должен быть выражен в одной из execution models: + +- `window` +- `session` +- `async_job` + +Недопустимо: + +- бесконечно проксировать frames напрямую в MCP client; +- скрывать жизненный цикл сокета за одним неопределенным tool call; +- смешивать downstream SSE transport и upstream WebSocket semantics в одну абстракцию. + +## 5. Типовые use cases + +### 5.1. Monitoring and telemetry + +- realtime метрики; +- device telemetry; +- market data; +- anomaly events. + +### 5.2. Event subscriptions + +- alert streams; +- queue events; +- workflow transitions; +- security events. + +### 5.3. Stateful control channels + +- rollout progress; +- remote task status; +- infrastructure control plane updates; +- long-running remote sessions. + +## 6. Внутренняя модель WebSocket operation + +WebSocket operation должна включать: + +- `url` +- `headers` +- `subprotocols` +- `connect_timeout_ms` +- `heartbeat_interval_ms` +- `subscribe_message_template` +- `unsubscribe_message_template` +- `input_mapping` +- `output_mapping` +- `execution_config` +- `tool_description` + +## 7. Как оператор настраивает WebSocket operation + +1. Указывает URL WebSocket upstream. +2. При необходимости выбирает auth profile и headers. +3. Указывает subprotocol или оставляет пустым. +4. Выбирает execution mode: `window`, `session` или `async_job`. +5. Настраивает subscribe payload. +6. Указывает правила извлечения items, status и cursor. +7. Настраивает aggregation limits. +8. Выполняет test run. +9. Публикует operation как MCP tool или tool family. + +## 8. Поведение runtime + +При выполнении WebSocket operation runtime должен: + +1. Валидировать MCP input. +2. Построить subscribe payload. +3. Открыть WebSocket connection. +4. Пройти handshake и auth. +5. Отправить subscribe message. +6. Собрать bounded window или session step. +7. Нормализовать messages в JSON. +8. Применить output mapping. +9. Закрыть соединение или сохранить session state. + +## 9. Критические нюансы + +- upstream WebSocket может быть stateful и требовать explicit unsubscribe; +- heartbeat и reconnect должны быть управляемыми через config, а не захардкоженными; +- session state должен хранить cursor, last_event и subscription metadata; +- disconnect downstream MCP client не означает cancel upstream session; +- runtime обязан уметь cleanly завершать orphaned connections. + +## 10. Почему WebSocket должен быть отдельным adapter + +WebSocket нельзя свести к "почти SSE" или "почти HTTP", потому что: + +- transport двунаправленный; +- lifecycle connection stateful; +- есть handshake, heartbeat и reconnect; +- подписка часто задается сообщением, а не URL; +- semantics событий и прогресса отличаются от request-response вызова. diff --git a/docs/streaming-mcp-plan.md b/docs/streaming-mcp-plan.md index e1fa4d4..70b4a2d 100644 --- a/docs/streaming-mcp-plan.md +++ b/docs/streaming-mcp-plan.md @@ -49,7 +49,8 @@ Crank поддерживает streaming не как бесконечный те - REST SSE в bounded режимах; - GraphQL `query` и `mutation`; - gRPC unary; -- gRPC server-streaming в bounded режимах. +- gRPC server-streaming в bounded режимах; +- WebSocket в bounded режимах. Отложено: @@ -59,6 +60,16 @@ Crank поддерживает streaming не как бесконечный те - arbitrary websocket passthrough; - raw infinite stream forwarding в MCP client. +### 3.3. Protocol capability matrix + +| Protocol | Unary | Window | Session | Async Job | Notes | +| --- | --- | --- | --- | --- | --- | +| REST | Yes | Yes | Limited | Yes | SSE and long-poll sources are supported in controlled form | +| GraphQL | Yes | No | No | Limited | `query` and `mutation` only; `subscription` is future scope | +| gRPC | Yes | Yes | Yes | Yes | server-streaming only; client/bidi deferred | +| WebSocket | No | Yes | Yes | Yes | upstream adapter only; not downstream MCP transport | +| SOAP | Yes | Limited | Limited | Yes | primarily request-response enterprise workflows | + ## 4. Поддерживаемые streaming modes Crank поддерживает четыре режима выполнения operation. @@ -71,7 +82,8 @@ Crank поддерживает четыре режима выполнения op - REST; - GraphQL `query` и `mutation`; -- gRPC unary. +- gRPC unary; +- SOAP. ### 4.2. `window` @@ -91,7 +103,8 @@ Runtime открывает upstream stream или repeatedly polls upstream sour - метрики за период; - event window; - SSE stream snapshot; -- gRPC server-stream window. +- gRPC server-stream window; +- WebSocket event window. ### 4.3. `session` @@ -108,7 +121,8 @@ Runtime создает stream session, после чего данные чита - follow logs; - telemetry follow; - alert/event feed; -- контроль длительных stream-подписок. +- контроль длительных stream-подписок; +- WebSocket subscriptions. ### 4.4. `async_job` @@ -126,7 +140,8 @@ Runtime запускает long-running upstream operation и возвращае - import/export; - deploy/reindex; - batch processing; -- инфраструктурные control-plane действия. +- инфраструктурные control-plane действия; +- SOAP workflows with deferred status polling. ## 5. Бизнес-кейсы @@ -202,6 +217,38 @@ Runtime: - пишет progress в session/job state; - возвращает snapshots по `poll`. +### 5.6. WebSocket Realtime Feeds + +LLM запрашивает: + +- realtime alert snapshot; +- device telemetry window; +- market data slice; +- status feed по subscription channel. + +Runtime: + +- открывает upstream WebSocket; +- подписывается на channel; +- собирает bounded окно или session step; +- возвращает summary и limited items. + +### 5.7. SOAP Enterprise Operations + +LLM запрашивает: + +- создание/поиск сущности в ERP; +- запуск enterprise workflow; +- получение статуса batch operation; +- B2B request через SOAP gateway. + +Runtime: + +- строит SOAP envelope из MCP input; +- вызывает enterprise endpoint; +- нормализует XML response или SOAP Fault; +- возвращает JSON-oriented output. + ## 6. Функциональные требования ### 6.1. Общие @@ -263,7 +310,7 @@ Runtime: - устойчивость к disconnect downstream client; - poll должен быть идемпотентным; - long-running upstream action не должен считаться отмененным из-за SSE disconnect; -- resumability для downstream SSE допускается, но не является обязательной в MVP. +- resumability для downstream SSE допускается как следующая волна, но не является обязательной в первой реализации. ### 7.4. UX @@ -492,13 +539,26 @@ REST: GraphQL: - `query` и `mutation`; -- `subscription` не входит в MVP. +- `subscription` отложен на отдельную protocol wave. gRPC: - unary; - bounded server-stream collection; -- client/bidi не входят в MVP. +- client/bidi отложены на отдельную protocol wave. + +WebSocket: + +- bounded event collection; +- subscribe/poll/stop orchestration; +- heartbeat and reconnect policy. + +SOAP: + +- WSDL-driven request/response adapter; +- XML normalization; +- SOAP Fault normalization; +- future WS-Security expansion. ### 11.5. `apps/mcp-server` @@ -526,9 +586,9 @@ gRPC: - test-run screen для bounded window/session/job behavior; - отдельные предупреждения про truncation и timeouts. -## 12. Ограничения MVP +## 12. Границы текущей продуктовой волны -В MVP входит: +В первой продуктовой волне входит: - `Streamable HTTP` и SSE на MCP transport; - `window` mode; @@ -538,7 +598,14 @@ gRPC: - tool family generation; - bounded session/job state. -В MVP не входит: +Во второй продуктовой волне: + +- WebSocket upstream adapter; +- SOAP adapter foundation; +- richer session tooling; +- expanded protocol smoke suite. + +Отложено: - GraphQL subscriptions; - gRPC client streaming; @@ -592,13 +659,33 @@ gRPC: - `start/poll/stop`; - `start/status/result/cancel`. -### 13.9. `feat/streaming-ui-config` +### 13.9. `feat/websocket-upstream-adapter` + +- bounded WebSocket collection; +- subscribe/unsubscribe templates; +- heartbeat/reconnect policy; +- session integration. + +### 13.10. `feat/soap-architecture-and-core-model` + +- WSDL/XSD-driven domain model; +- SOAP execution config; +- XML normalization strategy. + +### 13.11. `feat/soap-adapter-foundation` + +- runtime SOAP adapter; +- envelope builder; +- fault normalization; +- test-run support. + +### 13.12. `feat/streaming-ui-config` - новый execution mode selector; - limits/aggregation/safety blocks; - test-run UX. -### 13.10. `feat/streaming-e2e` +### 13.13. `feat/streaming-e2e` - публичные smoke targets; - e2e сценарии;