АРХ - МЕЖПРОЕКТНАЯ КОММУНИКАЦИЯ: Authentik profile projection

docs/ARCHITECTURE.md

@@ -7,30 +7,35 @@
 Целевой пользовательский сценарий:
 
 1. Пользователь открывает Launcher.
-2. Если сессии нет, его отправляет в Authentik.
-3. После логина Launcher получает identity и app access.
-4. Launcher показывает только доступные приложения.
+2. Если сессии нет, его отправляет в платформенный login flow без публичного брендинга Authentik.
+3. После логина Launcher получает identity, профиль и access projection.
+4. Launcher показывает каталог приложений и состояние доступа.
 5. Переход в Task Manager не требует повторного логина.
 6. Прямой URL Task Manager тоже защищен.
 
 ## Роли компонентов
 
-`Authentik` является единым Identity Provider:
+`Authentik` является внутренним Identity Provider / SSO layer:
 
 - логин;
 - пароль;
-- активность пользователя;
-- группы;
-- app access;
+- активность identity;
+- технические SSO-группы/entitlements;
+- OIDC app access projection;
 - OIDC claims;
-- будущие invite/enrollment/MFA flows.
+- будущие 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;
+- витрина всех приложений и состояния доступа;
+- admin UI управления клиентами, пользователями, группами, инвайтами и доступами;
+- мастер-данные пользователей и профиль платформы;
+- backend-интеграция с Authentik API как внутренняя sync/projection;
 - audit log админских действий.
 
 `Task Manager / Plane` остается отдельным приложением:
@@ -39,7 +44,8 @@
 - собственные workspace/project/task/comment модели;
 - собственные роли workspace/project;
 - OIDC login через Authentik;
-- mapping внешней identity на существующего Plane user.
+- mapping внешней identity на существующего Plane user;
+- возможность работать standalone вне NODE.DC stack при сохранении стандартных Plane auth/API механизмов.
 
 `Reverse proxy` является внешним защитным и маршрутизирующим слоем:
 
@@ -75,14 +81,31 @@ NODEDC/
 Логическая схема:
 
 ```text
-authentik_db     -> identity, groups, app access
-launcher_db      -> app registry, local profiles, audit
+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
 
 Для приложений, которые контролируются кодом:
@@ -91,7 +114,7 @@ future_app_db    -> доменная логика будущих приложе
 - backend/session или BFF layer;
 - JWT/JWKS validation server-side;
 - проверка `issuer`, `audience`, `exp`, `sub`;
-- проверка app access group;
+- проверка app access projection group/entitlement;
 - локальный user profile или external identity link.
 
 Для legacy/временных приложений допускается reverse proxy forward-auth, но это временный внешний слой, а не единственная долгосрочная модель.