# Architecture: NODE.DC Multi-App Platform

## Цель

Собрать единую платформенную основу для Launcher, Task Manager / Plane и будущих приложений NODE.DC.

Целевой пользовательский сценарий:

1. Пользователь открывает Launcher.
2. Если сессии нет, его отправляет в платформенный login flow без публичного брендинга Authentik.
3. После логина Launcher получает identity, профиль и access projection.
4. Launcher показывает каталог приложений и состояние доступа.
5. Переход в Task Manager не требует повторного логина.
6. Прямой URL Task Manager тоже защищен.

## Роли компонентов

`Authentik` является внутренним Identity Provider / SSO layer:

- логин;
- пароль;
- активность identity;
- технические SSO-группы/entitlements;
- OIDC app access projection;
- OIDC claims;
- будущие enrollment/MFA flows, вызываемые из Launcher.

Authentik не является пользовательским control plane и не должен быть видим обычным пользователям/админам в штатном UI.

Hosted Authentik login используется только как временный dev flow. Production-вход должен быть NODE.DC-branded login facade или полностью приведенный к NODE.DC UX Authentik flow без публичного упоминания Authentik.

`Launcher` является control plane:

- входная точка пользователя;
- витрина всех приложений и состояния доступа;
- admin UI управления клиентами, пользователями, группами, инвайтами и доступами;
- мастер-данные пользователей и профиль платформы;
- backend-интеграция с Authentik API как внутренняя sync/projection;
- audit log админских действий.

`Task Manager / Plane` остается отдельным приложением:

- собственная БД;
- собственные workspace/project/task/comment модели;
- собственные роли workspace/project;
- OIDC login через Authentik;
- mapping внешней identity на существующего Plane user;
- возможность работать standalone вне NODE.DC stack при сохранении стандартных Plane auth/API механизмов.

`Reverse proxy` является внешним защитным и маршрутизирующим слоем:

- единая точка входа;
- HTTPS в staging/production;
- routing по app domain;
- forward headers для Authentik;
- deny для пользователей без app access.

## Repository layout

Рабочая схема:

```text
NODEDC/
  DOC/
  platform/
    docs/
    infra/
    packages/
    tasks/

/Users/dcconstructions/Downloads/mnt/data/nodedc_launcher
/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER
```

`platform/` не забирает исходники Launcher и Plane внутрь себя. Он хранит только платформенный слой и договоренности между приложениями.

## Data ownership

Не создается единая общая таблица `users` для всех приложений.

Логическая схема:

```text
launcher_db      -> clients, users, memberships, groups, invites, app registry, access model, profiles, audit
authentik_db     -> identity/session/OIDC projection from Launcher
plane_db         -> workspace, projects, tasks, comments, app roles
future_app_db    -> доменная логика будущих приложений
```

Связь между identity и локальными пользователями выполняется через explicit mapping, а не через прямое чтение чужих таблиц.

Launcher является источником бизнес-пользователя. Authentik хранит техническую identity, необходимую для SSO, но не заменяет Launcher в администрировании клиентов, команд, доступов и профиля.

## App standalone rule

Подключаемые приложения не должны становиться невынимаемыми частями NODE.DC.

Для Plane это означает:

- NODE.DC интеграция добавляется как адаптерный слой: OIDC provider, external identity link, app access projection и будущий service adapter;
- доменные таблицы Plane не становятся частью Launcher DB;
- Launcher не читает и не пишет Plane DB напрямую;
- управление workspace/project/task/comment остается внутри Plane;
- интеграция с Plane выполняется через публичные Plane API, API tokens или явно выделенные adapter endpoints;
- стандартные Plane auth/API механизмы не удаляются без отдельного решения, чтобы можно было поставить Plane клиенту standalone.

Если клиенту нужен только Task Manager, целевая поставка должна позволять развернуть Plane отдельно, отключить NODE.DC Launcher/Auth projection и оставить штатную модель Plane.

## Auth flow

Для приложений, которые контролируются кодом:

- OIDC Authorization Code Flow + PKCE;
- backend/session или BFF layer;
- JWT/JWKS validation server-side;
- проверка `issuer`, `audience`, `exp`, `sub`;
- проверка app access projection group/entitlement;
- локальный user profile или external identity link.

Для legacy/временных приложений допускается reverse proxy forward-auth, но это временный внешний слой, а не единственная долгосрочная модель.

## Plane migration rule

Существующий Plane user нельзя пересоздавать.

Нужен mapping:

```text
authentik_user.sub -> existing plane_user.id
```

Plane должен логинить существующего пользователя по link, сохраняя все старые workspace, assignee, owner, created_by, comments и attachments.