a.tolmachev
137 lines
4.3 KiB
Markdown
137 lines
4.3 KiB
Markdown
# План реализации
|
||
|
||
## 1. Назначение документа
|
||
|
||
Этот документ фиксирует порядок перехода от текущего состояния проекта к целевой Alpine UI модели.
|
||
|
||
Принцип:
|
||
|
||
- сначала перепроектирование `as is -> to be`;
|
||
- потом foundation под workspace/agent model;
|
||
- потом возврат к end-to-end UI сценариям;
|
||
- потом observability и access layer;
|
||
- потом polish и demo readiness.
|
||
|
||
## 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 стабильно зелёные;
|
||
- документация и продуктовый сценарий совпадают.
|