docs: consolidate product roadmap and source docs
This commit is contained in:
a.tolmachev
+110
-159
@@ -2,217 +2,168 @@
|
||||
|
||||
## 1. Назначение документа
|
||||
|
||||
Этот документ фиксирует порядок перехода от текущего состояния проекта к целевой product-ready integration platform модели.
|
||||
Этот документ фиксирует актуальный порядок подготовки Crank к коммерческой реализации как open-core продукта.
|
||||
|
||||
Документ не повторяет уже выполненные исторические этапы. Он описывает только тот план, по которому проект должен двигаться дальше.
|
||||
|
||||
## 2. Базовый принцип
|
||||
|
||||
Работа делится на два контура:
|
||||
|
||||
1. завершение и hardening открытой редакции `Community`;
|
||||
2. подготовка архитектурных, продуктовых и delivery-границ для `Enterprise` и `Cloud`.
|
||||
|
||||
Принцип:
|
||||
|
||||
- сначала перепроектирование `as is -> to be`;
|
||||
- потом foundation под workspace/agent model;
|
||||
- потом возврат к end-to-end UI сценариям;
|
||||
- потом observability и access layer;
|
||||
- потом polish и demo readiness;
|
||||
- потом расширение до полного protocol platform scope.
|
||||
- сначала нужно сделать честную и законченную `Community`-основу;
|
||||
- затем нужно отделить commercial seams и private delivery;
|
||||
- только после этого имеет смысл реализовывать коммерческие расширения.
|
||||
|
||||
## 2. Этап 1. Перепроектирование `As Is -> To Be`
|
||||
## 3. Этап 1. Open-core product boundary
|
||||
|
||||
Цель:
|
||||
### Цель
|
||||
|
||||
- зафиксировать новую доменную модель и page-driven backend contract.
|
||||
Зафиксировать, что входит в `Community`, а что уходит в `Enterprise` и `Cloud`.
|
||||
|
||||
DoD:
|
||||
### DoD
|
||||
|
||||
- зафиксирован `as is -> to be` план;
|
||||
- page-by-page gap analysis покрывает все целевые экраны;
|
||||
- разобраны все архитектурные конфликты UI vs current backend;
|
||||
- документы `architecture`, `data-model`, `database-schema`, `admin-api`, `mcp-interface` синхронизированы.
|
||||
- документы `product-editions`, `commercial-boundaries`, `architecture`, `module-decomposition` синхронизированы;
|
||||
- в кодовой базе определена capability model по редакциям;
|
||||
- UI и API не обещают Community-функции, которых там не должно быть;
|
||||
- старые review-файлы не требуются как отдельный источник истины.
|
||||
|
||||
## 3. Этап 2. Workspace foundation
|
||||
## 4. Этап 2. Community machine access completion
|
||||
|
||||
Цель:
|
||||
### Цель
|
||||
|
||||
- перевести хранение и API на workspace-scoped модель.
|
||||
Довести базовую модель машинного доступа Community до полностью рабочего состояния.
|
||||
|
||||
DoD:
|
||||
### DoD
|
||||
|
||||
- операции и auth profiles принадлежат workspace;
|
||||
- registry умеет фильтровать данные по workspace;
|
||||
- есть default workspace migration path.
|
||||
- у AI-агента есть собственный ключ;
|
||||
- UI умеет выпускать, показывать, отзывать и удалять agent keys;
|
||||
- `mcp-server` использует agent-scoped machine access;
|
||||
- Community поддерживает только `security_level = standard`;
|
||||
- в системе не остается product-facing assumptions про workspace-wide machine key как основной способ вызова.
|
||||
|
||||
## 4. Этап 3. Agent publishing foundation
|
||||
## 5. Этап 3. Edition capability model
|
||||
|
||||
Цель:
|
||||
### Цель
|
||||
|
||||
- ввести `Agent` и agent-scoped MCP publishing.
|
||||
Подготовить инфраструктуру, которая позволит одной кодовой базе честно различать редакции продукта.
|
||||
|
||||
DoD:
|
||||
### DoD
|
||||
|
||||
- можно создать agent и привязать к нему published operations;
|
||||
- `mcp-server` выдает tools в контексте конкретного agent;
|
||||
- один agent видит только свой curated toolset.
|
||||
- существует server-side capability model:
|
||||
- protocols
|
||||
- auth modes
|
||||
- security levels
|
||||
- workspace/user limits
|
||||
- `admin-api` возвращает capability flags для UI;
|
||||
- UI скрывает или честно блокирует premium functionality;
|
||||
- Community build не содержит ложных "почти доступных" product paths.
|
||||
|
||||
## 5. Этап 4. Operations and wizard integration
|
||||
## 6. Этап 4. Private auth-service seam
|
||||
|
||||
Цель:
|
||||
### Цель
|
||||
|
||||
- посадить operations catalog и wizard на реальные backend contracts.
|
||||
Подготовить публичный код к private реализации короткоживущих и одноразовых токенов.
|
||||
|
||||
DoD:
|
||||
### DoD
|
||||
|
||||
- каталог операций и wizard работают без `localStorage` overrides;
|
||||
- operation edit/delete/publish/test выполняются через backend;
|
||||
- все протоколы работают в рамках одного UI flow.
|
||||
- зафиксированы контракты для:
|
||||
- `POST /mcp-auth/v1/token`
|
||||
- `POST /mcp-auth/v1/token/one-time`
|
||||
- в `mcp-server` существует abstraction для проверки токенов;
|
||||
- `admin-api` и `mcp-interface` знают про эти контракты документированно;
|
||||
- Community при этом остается полностью работоспособной без private token service.
|
||||
|
||||
## 6. Этап 5. Agents UI and backend
|
||||
## 7. Этап 5. Commercial protocol split
|
||||
|
||||
Цель:
|
||||
### Цель
|
||||
|
||||
- реализовать agent-centric слой.
|
||||
Перестать считать весь текущий protocol surface частью открытой редакции.
|
||||
|
||||
DoD:
|
||||
### DoD
|
||||
|
||||
- agent CRUD работает;
|
||||
- binding operations к agent работает;
|
||||
- published agent появляется в MCP runtime.
|
||||
- определен canonical Community protocol set;
|
||||
- premium protocol families и premium execution modes вынесены в коммерческий план;
|
||||
- UI capability-gated по протоколам;
|
||||
- release model для Community не требует shipping premium flow как рабочей open-source функции.
|
||||
|
||||
## 7. Этап 6. Agent-scoped machine access
|
||||
## 8. Этап 6. Frontend launch readiness
|
||||
|
||||
Цель:
|
||||
### Цель
|
||||
|
||||
- реализовать machine access на уровне AI-агента и ввести обязательный уровень защиты операции.
|
||||
Довести UI до коммерчески пригодного состояния для `Community` и подготовить edition-aware product surface.
|
||||
|
||||
DoD:
|
||||
### DoD
|
||||
|
||||
- UI умеет выпускать и отзывать ключи конкретного AI-агента;
|
||||
- длинноживущий машинный доступ больше не описывается ключом рабочей области;
|
||||
- у операции появляется обязательный `security_level`;
|
||||
- machine access не смешивается с upstream auth profiles;
|
||||
- Community поддерживает базовый режим со статическим ключом AI-агента.
|
||||
- agent key UX доведен до продукта;
|
||||
- mobile layouts для data-heavy страниц больше не ломают primary actions;
|
||||
- terminology и localization согласованы;
|
||||
- settings и workspace flows не содержат misleading или half-functional sections;
|
||||
- UI понимает разницу между Community и premium capabilities.
|
||||
|
||||
## 8. Этап 7. Token exchange and short-lived auth
|
||||
## 9. Этап 7. Enterprise access and governance
|
||||
|
||||
Цель:
|
||||
### Цель
|
||||
|
||||
- внедрить расширенные режимы доступа для операций повышенной чувствительности.
|
||||
Реализовать коммерческий access/governance слой в private delivery.
|
||||
|
||||
DoD:
|
||||
### DoD
|
||||
|
||||
- существует конечная точка выдачи токена по ключу агента;
|
||||
- есть модель одноразового токена для чувствительных вызовов;
|
||||
- токены ограничены по сроку жизни, области действия и числу использований;
|
||||
- операции уровня `elevated` нельзя вызвать по статическому ключу;
|
||||
- операции уровня `strict` можно вызвать только по одноразовому токену.
|
||||
- есть `SSO`;
|
||||
- есть `2FA`;
|
||||
- есть расширенная `RBAC`;
|
||||
- есть `audit log`;
|
||||
- существует private delivery path для self-hosted customers.
|
||||
|
||||
## 9. Этап 8. Observability
|
||||
## 10. Этап 8. Cloud control plane
|
||||
|
||||
Цель:
|
||||
### Цель
|
||||
|
||||
- реализовать логи и usage.
|
||||
Подготовить hosted-редакцию как отдельный продуктовый контур.
|
||||
|
||||
DoD:
|
||||
### DoD
|
||||
|
||||
- `Logs` page и `Usage` page работают на реальных данных;
|
||||
- есть продуктовые endpoints, а не только application logs;
|
||||
- rollups и detail views согласованы с UI.
|
||||
- есть metering;
|
||||
- есть billing integration;
|
||||
- есть hosted tenant model;
|
||||
- есть cloud deployment and support tooling;
|
||||
- capability model синхронизирована с hosted plans.
|
||||
|
||||
## 10. Этап 9. Alpine UI integration
|
||||
## 11. Этап 9. Release and distribution hardening
|
||||
|
||||
Цель:
|
||||
### Цель
|
||||
|
||||
- довести `apps/ui` до полной работы на реальном backend.
|
||||
Подготовить безопасную поставку открытой и коммерческой редакций.
|
||||
|
||||
DoD:
|
||||
### DoD
|
||||
|
||||
- `apps/ui` содержит целевой Alpine.js UI;
|
||||
- mock JSON больше не используется на критическом пути;
|
||||
- UI, backend и docs синхронизированы.
|
||||
- Community публикуется из public GitHub repository;
|
||||
- Enterprise поставляется через private container registry и private manifests;
|
||||
- Cloud использует отдельный private operational contour;
|
||||
- build provenance и подпись артефактов документированы;
|
||||
- коммерческий код не требуется публиковать в public repository.
|
||||
|
||||
## 11. Этап 10. Secret store and upstream auth
|
||||
## 12. Этап 10. Live staging and demo readiness
|
||||
|
||||
Цель:
|
||||
### Цель
|
||||
|
||||
- заменить UI placeholder-модель `${secrets.*}` на рабочий backend/runtime слой secrets.
|
||||
Поддерживать реальный стенд и демонстрационный сценарий в состоянии, пригодном для продажи и демонстрации.
|
||||
|
||||
DoD:
|
||||
### 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.
|
||||
- live authenticated staging pass воспроизводим;
|
||||
- deploy smoke и operator docs совпадают с реальной поставкой;
|
||||
- demo user flow подтвержден на реальном окружении;
|
||||
- регрессии в publish/call/auth flow ловятся до релиза.
|
||||
|
||||
## 12. Этап 11. Hardening and demo readiness
|
||||
## 13. Связанные документы
|
||||
|
||||
Цель:
|
||||
|
||||
- довести продукт до стабильного демо-сценария.
|
||||
|
||||
DoD:
|
||||
|
||||
- end-to-end demo воспроизводим;
|
||||
- deployment и healthchecks стабильно зелёные;
|
||||
- документация и продуктовый сценарий совпадают.
|
||||
|
||||
## 13. Этап 12. 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.
|
||||
|
||||
## 14. Этап 13. 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 синхронизированы.
|
||||
|
||||
## 15. Этап 14. 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 работают так же, как для остальных протоколов.
|
||||
|
||||
## 16. Этап 15. 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.
|
||||
|
||||
## 17. Этап 16. Streaming implementation slices
|
||||
|
||||
Цель:
|
||||
|
||||
- перевести streaming design в agent-friendly execution plan по файлам, тестам и DoD.
|
||||
|
||||
DoD:
|
||||
|
||||
- есть отдельный implementation spec по всем streaming slices;
|
||||
- указаны file-level changes;
|
||||
- указаны обязательные тесты и acceptance criteria;
|
||||
- state transitions и sequence outlines зафиксированы явно.
|
||||
- `docs/product-editions.md`
|
||||
- `docs/commercial-boundaries.md`
|
||||
- `docs/frontend-roadmap.md`
|
||||
- `docs/refactoring-roadmap.md`
|
||||
- `docs/agent-auth-model.md`
|
||||
|
||||
Reference in New Issue
Block a user