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

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

Этот документ фиксирует порядок перехода от текущего состояния проекта к целевой модели, заданной `test-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

Цель:

- перенести `test-ui` в `apps/ui` и подключить его к реальному backend.

DoD:

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

## 10. Этап 9. Hardening and demo readiness

Цель:

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

DoD:

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