244 lines
15 KiB
Markdown
244 lines
15 KiB
Markdown
# NODE.DC Launcher Design
|
||
|
||
Этот документ фиксирует рабочий дизайн-канон именно для `NODE.DC Launcher`. Источники: `doc/base/nodedc_launcher_tz_frontend_mvp.md`, `doc/base/BASE_THINK.md`, `doc/base/HDESIGN-CODE.md` и визуальный референс `doc/base/VISUALREF.png`.
|
||
|
||
## 1. Продуктовая рамка
|
||
|
||
Launcher - отдельный control plane экосистемы NODE.DC. Он не заменяет NodeDC, Task Manager, Plane, 1C Assistant или будущие сервисы. Его интерфейс показывает доступные приложения, объясняет доступ и даёт администраторам управлять клиентами, участниками, группами, каталогом сервисов, инвайтами и синхронизацией.
|
||
|
||
На текущем фронтовом MVP реальный Authentik не подключается. Но интерфейс и данные должны быть собраны так, чтобы позже заменить mock-профиль на OIDC claims без переписывания экранов.
|
||
|
||
## 2. Визуальная цель
|
||
|
||
Launcher должен ощущаться как витрина приложений, а не как таблица с плитками. Пользовательский экран строится вокруг трёх зон:
|
||
|
||
- `Service Stage`: большая визуальная сцена выбранного сервиса.
|
||
- `Service Detail`: glass-карточка с названием, описанием, статусом и действием.
|
||
- `Service Rail`: нижняя лента доступных сервисов.
|
||
|
||
Референс `VISUALREF.png` даёт направление: тёмная монохромная сцена, слои полупрозрачного glass, мягкий blur, крупная фокусная карточка, плавающая панель управления и нижняя лента элементов. Мы не копируем чужой UI буквально, а переносим композицию, ощущение глубины, верхние толстые pill-кнопки и плавающие окна.
|
||
|
||
## 2.1. Канон Task Manager, перенесённый в Launcher
|
||
|
||
Launcher должен наследовать уже сделанный NODE.DC Task Manager, а не жить отдельной визуальной веткой.
|
||
|
||
Из Task Manager переносим:
|
||
|
||
- логотип `NODE.DC` из `demo-assets/logo.svg` / `apps/admin/app/assets/logos/nodedc-logo.svg`;
|
||
- admin header: лого слева, центральная группа `app-dot + nav-track`, user control справа;
|
||
- top nav items: крупные круглые pill-кнопки без внешней рамки, высота и паддинги как в Task Manager;
|
||
- active top item: светлая filled-плашка с тёмным текстом;
|
||
- user button: прозрачная зона + круглый avatar/control справа;
|
||
- modal/window shell: `nodedc-glass-modal`-логика, matte black glass, radius `1.75rem`, close `X` в правом верхнем углу;
|
||
- settings shell: left navigation + content area, карточки `nodedc-settings-card`, поля `nodedc-settings-input`, кнопки `nodedc-settings-save-button` / `nodedc-settings-secondary-button`;
|
||
- dropdown shell: `nodedc-dropdown-surface`, portal/floating layer, без inline popup внутри карточек.
|
||
|
||
Нельзя делать Launcher-шапку, кнопки или админ-окна локально "на глаз", если в Task Manager уже есть паттерн.
|
||
|
||
В верхней шапке запрещены технические runtime/debug-панели, даты MVP, mock labels и любые отладочные карточки. Dev-переключатели ролей допустимы только как часть пользовательского nav-track и должны выглядеть как production controls.
|
||
|
||
## 3. Роли в дизайне
|
||
|
||
Разный доступ должен быть виден в самом UI, даже без реальной авторизации:
|
||
|
||
- `root_admin`: видит полный каталог, скрытые/отключённые сервисы, всех клиентов и системную диагностику.
|
||
- `client_owner` / `client_admin`: видит только свой клиент, его участников, группы, инвайты и доступы к уже подключённым сервисам.
|
||
- `member`: видит только витрину доступных ему сервисов и профиль.
|
||
|
||
В MVP допустим dev-переключатель профиля, но он должен моделировать будущие роли, а не быть случайным режимом интерфейса.
|
||
|
||
## 4. Цвета и токены
|
||
|
||
Используем CSS variables, совместимые с glass-canon NODE.DC:
|
||
|
||
```css
|
||
:root {
|
||
--nodedc-accent-rgb: 195 255 102;
|
||
--nodedc-card-passive-rgb: 42 43 46;
|
||
--nodedc-card-active-rgb: 195 255 102;
|
||
--nodedc-on-accent-rgb: 11 17 23;
|
||
--launcher-radius-modal: 1.75rem;
|
||
--launcher-radius-card: 1.35rem;
|
||
--launcher-radius-control: 1.25rem;
|
||
--launcher-radius-circle: 999px;
|
||
}
|
||
```
|
||
|
||
Primary CTA на светлом акценте всегда получает тёмный текст. Белый текст на светло-зелёной заливке запрещён.
|
||
|
||
Фон приложения моноцветный: базовый `#050506`. Нельзя добавлять цветные декоративные фоны, орбы, bokeh, радужные подложки или самостоятельные fullscreen-градиенты. Цвет сервиса может жить внутри media-card/stage preview и в акцентных controls, но не должен перекрашивать весь экран приложения.
|
||
|
||
## 5. Surface и glass
|
||
|
||
Базовый surface:
|
||
|
||
```css
|
||
.launcher-glass-surface {
|
||
background:
|
||
linear-gradient(180deg, rgba(255, 255, 255, 0.036) 0%, rgba(255, 255, 255, 0.012) 100%),
|
||
rgba(8, 8, 11, 0.78);
|
||
backdrop-filter: blur(28px);
|
||
-webkit-backdrop-filter: blur(28px);
|
||
border: 0;
|
||
box-shadow:
|
||
0 24px 64px rgba(0, 0, 0, 0.42),
|
||
inset 0 1px 0 rgba(255, 255, 255, 0.025);
|
||
border-radius: var(--launcher-radius-card);
|
||
}
|
||
```
|
||
|
||
Popup, admin overlay, rail-карточки, формы и таблицы используют этот канон. Светлые прямоугольные окна внутри тёмного экрана не используются.
|
||
|
||
## 6. Радиусы
|
||
|
||
- Модалки и большой admin overlay: `1.75rem`.
|
||
- Стандартные карточки и panels: `1.35rem`.
|
||
- Инпуты, селекты, CTA, chips: `1.25rem`.
|
||
- Icon actions и status anchors: круг или `999px`.
|
||
|
||
## 7. Кнопки и controls
|
||
|
||
- Primary: акцентная заливка, тёмный текст, без outline.
|
||
- Secondary: тёмный glass surface, мягкий hover.
|
||
- Danger: мягкая danger-заливка без кислотных рамок.
|
||
- Icon actions: круглые, с tooltip/title, без квадратной active-плашки.
|
||
- Binary settings: круглый checker, а не стандартный квадратный checkbox.
|
||
|
||
Внешние outline запрещены вообще. Не использовать `border` как контур кнопки/карточки/окна. Не использовать синий browser outline. Focus-состояние делается через изменение surface/hover-state, а не через рамку.
|
||
|
||
Верхние кнопки:
|
||
|
||
- только pill/circle geometry;
|
||
- `min-height` около `2.75rem`;
|
||
- нормальный horizontal padding, текст не липнет к радиусу;
|
||
- active item filled, а не outlined;
|
||
- рядом стоящие controls должны иметь одну высоту.
|
||
|
||
## 8. Dropdown / popup
|
||
|
||
Все dropdown, которые открываются внутри карточек, таблиц, scroll-контейнеров, sticky header или detail panel, должны рендериться через portal. Inline popup внутри ограниченного контейнера считается дефектом, потому что создаёт clipping и визуальное налезание.
|
||
|
||
Launcher использует тот же dropdown-канон, что и Task Manager:
|
||
|
||
- shell: `portal-dropdown` / `nodedc-dropdown-surface`;
|
||
- option row: `nodedc-dropdown-option`;
|
||
- placement по умолчанию `bottom-start`;
|
||
- вертикальный offset небольшой, боковой offset без ручной подгонки;
|
||
- surface тёмный matte glass с blur, без светлой подложки и без технического outline;
|
||
- active/selected state нейтральный, без разноцветных status-fill;
|
||
- если trigger уже показывает значение, стрелка внутри trigger не обязательна и не должна ломать ширину control.
|
||
|
||
Статусные selector-ы в таблицах:
|
||
|
||
- не используют нативный browser `select`;
|
||
- не красят каждый статус разным цветом;
|
||
- имеют одну нейтральную pill-плашку;
|
||
- текст внутри pill всегда центрируется;
|
||
- dropdown открывается по клику на всю pill-плашку;
|
||
- popup рендерится через `PortalDropdown`, а не inline внутри таблицы.
|
||
|
||
Для текущего MVP reusable `PortalDropdown` остаётся обязательной точкой расширения. Если появляется новый popup/selector, сначала расширяется shared-компонент и только потом применяется на экране.
|
||
|
||
## 9. Пользовательская витрина
|
||
|
||
Top bar:
|
||
|
||
- логотип NODE.DC Launcher;
|
||
- активный клиент;
|
||
- переключатель mock-профиля;
|
||
- профиль пользователя;
|
||
- кнопка администрирования только при праве `canOpenAdmin`.
|
||
|
||
Service Stage:
|
||
|
||
- всегда держит один большой video/stage-контейнер под будущий фоновой ролик;
|
||
- при выборе сервиса поверх video/stage появляются два блока: image-card выбранного сервиса и glass-description;
|
||
- glass-description обязан использовать `backdrop-filter` / `-webkit-backdrop-filter`, чтобы реально блюрить контент за плашкой;
|
||
- повторный клик по уже выбранной плитке закрывает image-card и glass-description, video/stage остаётся на месте;
|
||
- имеет fallback на абстрактный service preview;
|
||
- меняется при выборе сервиса;
|
||
- не должен выглядеть как marketing hero.
|
||
|
||
Service Rail:
|
||
|
||
- нижняя единая dock-лента сервисов;
|
||
- сервисы отображаются квадратными модульными плитками, а не широкими разрозненными карточками;
|
||
- плитка содержит icon/preview, название и статус;
|
||
- active state использует `--nodedc-card-active-rgb`;
|
||
- maintenance видна, но action disabled;
|
||
- hidden/disabled не видны обычному пользователю.
|
||
|
||
## 10. Admin overlay
|
||
|
||
Admin overlay - floating glass-window поверх Launcher, а не отдельная публичная страница и не full-screen page.
|
||
|
||
Правила:
|
||
|
||
- фон Launcher остаётся видимым под затемнением/blur;
|
||
- выбранный сервис, клиент и профиль в Launcher не сбрасываются при открытии/закрытии;
|
||
- окно закрывается круглой кнопкой `X` в правом верхнем углу;
|
||
- клик по затемнённому фону может закрыть окно, если нет незавершённой формы;
|
||
- внутренний layout повторяет settings/admin паттерн Task Manager: left nav + content;
|
||
- окно имеет max-width/max-height и не занимает весь viewport на desktop.
|
||
|
||
Root admin разделы:
|
||
|
||
- Обзор;
|
||
- Клиенты;
|
||
- Участники;
|
||
- Группы;
|
||
- Каталог сервисов;
|
||
- Доступы;
|
||
- Инвайты;
|
||
- Синхронизация;
|
||
- Аудит.
|
||
|
||
Client admin разделы:
|
||
|
||
- Обзор;
|
||
- Участники;
|
||
- Группы;
|
||
- Доступы к сервисам;
|
||
- Инвайты;
|
||
- Профиль компании.
|
||
|
||
Client admin не видит других клиентов и не может редактировать глобальный каталог сервисов.
|
||
|
||
## 11. Access UI
|
||
|
||
Матрица доступов должна показывать итог, а не только сырые grants:
|
||
|
||
- есть ли доступ;
|
||
- можно ли открыть сервис;
|
||
- источник доступа: клиент, группа, пользователь, исключение;
|
||
- роль в приложении;
|
||
- объяснение причины.
|
||
|
||
Deny exception перекрывает любые client/group/user grants. Это должно быть видно в ячейке и explanation panel.
|
||
|
||
## 12. Тексты
|
||
|
||
Пользовательский UI на русском. В production-видимых элементах не оставлять `Created at`, `Updated at`, `Workspace`, `Project`, `Label`, если экран уже русифицирован.
|
||
|
||
## 13. MVP-границы
|
||
|
||
Сейчас делаем фронтовую механику:
|
||
|
||
- mock API;
|
||
- mock Authentik claims;
|
||
- переключение профилей для проверки ролей;
|
||
- вычисление доступов на фронте;
|
||
- интерфейс витрины;
|
||
- admin overlay;
|
||
- матрицу доступов;
|
||
- mock invite/sync/audit.
|
||
|
||
Не делаем сейчас:
|
||
|
||
- реальный Authentik login;
|
||
- production SSO;
|
||
- email-инвайты;
|
||
- backend CRUD;
|
||
- синхронизацию с Plane/NodeDC;
|
||
- управление проектами, workflow, задачами или runtime-правами внутри подключённых сервисов.
|