NODEDC_LAUNCHER/design.md

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:

: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:

.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 и визуальное налезание.

Для текущего MVP, где dropdown можно заменить компактным selector/segmented control без clipping-риска, portal можно не вводить насильно. Но reusable PortalDropdown остаётся обязательной точкой расширения.

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-правами внутри подключённых сервисов.