# Подключение приложений

## Текущее состояние

Первый этап не меняет существующие приложения. Репозиторий фиксирует baseline и создаёт пакетный контракт. Это позволяет продолжать текущую разработку без одномоментной переделки Engine, Ops, BIM, CMS, SEO и Launcher.

## Рекомендуемый порядок

### 1. Catalog validation

Сначала компоненты проверяются как самостоятельная система в dark/light и нескольких accent. До этого они не объявляются заменой production-кода.

### 2. Launcher/Hub pilot

Первый consumer — Launcher/Hub как основной visual reference. Подключение выполняется по одному вертикальному набору:

- tokens/theme;
- Button/IconButton;
- Dropdown/Select;
- Window/Confirmation;
- AppHeader.
- ApplicationShell/ApplicationPanel;
- useApplicationWorkspace;
- Icon/IconButton.

Локальные реализации удаляются только после функционального и визуального сравнения.

### 3. CMS и SEO

Используют те же компоненты и механику окон. CMS подключает DOM-layer, SEO — React-layer. Первым общим admin pattern подключается `MediaSourceField`/`createMediaSourceController`; storage API остаётся в приложении. Цветовые различия оформляются theme overrides.

### 4. Engine

Сначала библиотека заменяет компоненты только в уже новом Environment Settings и NDC Agent Inspector. Затем остальные инспекторы переводятся на Inspector/ControlRow постепенно. Legacy UI не переносится в библиотеку и не используется как reference.

### 5. Task Manager / Ops

Подключение начинается с floating-layer и modal primitives, где уже сформулирован канон. Массовая замена Plane UI не выполняется одним изменением.

### 6. BIM Viewer

Подключает tokens/styles и `@nodedc/ui-dom`. React в BIM ради дизайн-системы не добавляется.

## Новые приложения

Новый React-проект начинает с `ApplicationShell`:

- установить опубликованные NODE.DC UI packages;
- выбрать theme и accent;
- передать фиксированный AppHeader, stage, navigation и content;
- управлять shell через `useApplicationWorkspace`, а не набор локально связанных boolean;
- передавать storage/upload в `MediaSourceField` как adapter callback;
- использовать Window/Dropdown и канонический Icon вместо локальных реализаций;
- проверять registry перед созданием локального control;
- хранить доменные компоненты у себя.

Нижняя service rail добавляется только продуктам с витриной сервисов. В обычном оконном приложении она отсутствует.

## Adoption matrix

| Приложение | Текущий источник | Целевой adapter | Первый набор |
| --- | --- | --- | --- |
| Launcher/Hub | React/local shared | React | header, button, dropdown, window |
| SEO | React/local overrides | React | theme, window, field, select |
| CMS | Vanilla DOM | DOM | theme, header, modal, select |
| Engine | React/mixed generations | React | new inspector and environment settings only |
| Ops | React/Plane packages | React | floating behavior and modal primitives |
| BIM Viewer | Vanilla JS | DOM | tokens, glass select, settings surfaces |

## Не делать

- не переписывать все приложения одновременно;
- не копировать `packages/ui-react/src` в consumer;
- не поддерживать отдельную тему путём fork компонента;
- не использовать legacy Engine inspector как промежуточный канон;
- не удалять production local component до проверки package replacement.
