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