docs: add Web UI section to EvoBGP architecture plan, detailing Svelte and shadcn-svelte integration, user experience coverage, and security considerations for the new containerized interface.

.cursor/plans/evobgp_архитектура_0e73ef02.plan.md

@@ -35,6 +35,9 @@ todos:
   - id: ci-gitea
     content: .gitea/workflows/ci.yaml, документация для act runner
     status: completed
+  - id: web-ui
+    content: "Web UI (Svelte + shadcn-svelte) в отдельном контейнере: списки, расписание, мониторинг"
+    status: pending
 isProject: false
 ---
 
@@ -78,6 +81,7 @@ Control-plane на **Go**, анонс префиксов через **BIRD**, п
 14. [Тестирование BIRD2 и матрица сценариев](#14-тестирование-bird2-и-матрица-сценариев)
 15. [CI/CD (Gitea Actions)](#15-cicd-gitea-actions)
 16. [Риски и этапы внедрения](#16-риски-и-этапы-внедрения)
+17. [Web UI (Svelte, shadcn-svelte)](#17-web-ui-svelte-shadcn-svelte)
 
 ---
 
@@ -951,6 +955,30 @@ Raft, HTTP/`gorqlite`; для HA control-plane; не замена дефолтн
 4. Ревизии, rollback, bundle API.
 5. **evobgp-node** на отдельной ВМ; observability.
 6. Hardening, документация операторская.
+7. **Web UI** в отдельном контейнере ([§17](#17-web-ui-svelte-shadcn-svelte)): полный UX по спискам, расписанию и мониторингу.
+
+---
+
+## 17. Web UI (Svelte, shadcn-svelte)
+
+Цель — **единая операторская поверхность** поверх уже описанного REST ([§7](#7-rest-api)) и observability ([§4](#4-сервисы-сравнение-профилей), этапы в [§16](#16-риски-и-этапы-внедрения)), без дублирования бизнес-логики на фронтенде: UI только вызывает API и визуализирует состояние.
+
+### Стек и упаковка
+
+- **Svelte** (актуальная ветка проекта, SvelteKit при необходимости SSR/роутинга) и **shadcn-svelte** — доступные компоненты (формы, таблицы, диалоги, навигация), единый визуальный язык.
+- **Отдельный сервис в Docker Compose** (профиль **reference**): образ со статической сборкой или Node-сервером за reverse-proxy; **не** вшивать UI в `evobgp-api`. Контейнер получает только `VITE_*` / публичный **base URL API** и при необходимости URL метрик/health-прокси (см. ниже).
+- Сборка и публикация артефакта UI — отдельный job в CI ([§15](#15-cicd-gitea-actions)) по мере появления кода в репозитории (например `web/` или `ui/`).
+
+### Покрытие user experience
+
+1. **Списки и сущности** — модули префиксов, ревизии, пиры, community, DoH-профили, спикеры: просмотр, фильтрация, создание/редактирование там, где это отражено в OpenAPI; связь с jobs и аудитом ([§7.10](#710-задачи-job_audit)).
+2. **Расписание** — триггеры и окна обновления модулей/ETL, ручной refresh, очередь задач и статусы без «чёрного ящика» ([§7](#7-rest-api), scheduler в [§1](#1-структура-репозитория-файлы-и-пакеты)).
+3. **Мониторинг системы** — дашборд health API, агентов и нод; интеграция с метриками/алертами (Prometheus/Grafana или встроенные виджеты по публичным эндпоинтам); наглядное состояние BGP-сессий и последних deploy/revision там, где данные доступны через API или безопасный read-only прокси.
+
+### Безопасность и эксплуатация
+
+- Аутентификация и роли — по [§7.13](#713-матрица-прав-роли); UI не хранит секреты вне согласованного потока (cookie/session или OIDC — на этапе проектирования конкретной инсталляции).
+- Для **microVPS** полноценный отдельный контейнер UI **опционален** (можно тот же образ с `profiles` или отключённый сервис), чтобы не раздувать single-node; приоритет — **reference** как эталон операторской панели.
 
 ---
 

.cursor/settings.json

@@ -0,0 +1,7 @@
+{
+  "plugins": {
+    "svelte": {
+      "enabled": true
+    }
+  }
+}