# Discovery Report: NODE.DC Platform

Дата: 2026-05-04

## Источники

- Базовое ТЗ: `/Users/dcconstructions/Downloads/mnt/NODEDC/DOC/BASE/tz_codex_platform_authentik_launcher_plane.md`
- Краткое ТЗ: `/Users/dcconstructions/Downloads/mnt/NODEDC/DOC/BASE/nodedc_auth.md`
- Launcher repo: `/Users/dcconstructions/Downloads/mnt/data/nodedc_launcher`
- Task Manager repo: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER`

## Workspace

`/Users/dcconstructions/Downloads/mnt/NODEDC` используется как внешний workspace-корень для платформенной работы.

Текущая папка `NODEDC` до нулевого этапа содержала только базовые документы в `DOC/BASE`. Отдельного git-репозитория в этой папке нет.

## Launcher

Путь: `/Users/dcconstructions/Downloads/mnt/data/nodedc_launcher`

Факты discovery:

- отдельный git-репозиторий;
- Vite/React приложение;
- основной entrypoint: `src/main.tsx`;
- команды из `package.json`: `npm run dev`, `npm run build`, `npm run preview`, `npm run test`;
- backend слоя в текущем Launcher не найдено;
- значит OIDC/session handling, Authentik service token, app registry и audit log нельзя хранить только во frontend.

Минимальный вывод: для production-like auth нужен Launcher backend или BFF слой.

## Task Manager / Plane

Путь: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER`

Факты discovery:

- отдельный git-репозиторий;
- self-host runtime лежит в `plane-app`;
- локальный fork исходников лежит в `plane-src`;
- Plane CE self-host запущен через Docker;
- локальный URL стенда: `http://localhost:8090`;
- текущий compose/env: `plane-app/docker-compose.yaml` и `plane-app/plane.env`;
- текущий fork Plane: `plane-src`, версия `1.3.0`;
- основной runtime-контейнер API: `plane-app-api-1`;
- активные контейнеры Plane: web, proxy, api, worker, beat-worker, db, redis, minio, mq, admin, space, live.

Текущий workspace в Plane:

- slug: `nodedc`;
- name: `NODE DC`;
- owner: `dcctouch@gmail.com`;
- codex user: `codex@nodedc.local`.

Существующие проекты в workspace `nodedc` на момент discovery:

- `NODEDCLAUN` / `NODEDC LAUNCHER`
- `CODEX` / `DCTM-WT-CODEX`
- `NODEDCTASK` / `NODEDC TASKMANAGER`
- `MGR` / `Менеджмент`
- `BUH` / `Бухгалтерия`

## NDC details в карточках

Канон карточек описан в `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/AGENTS.md`.

Структурированные блоки карточки хранятся в `Issue.detail_layout` под ключом:

```text
nodedc_structured_blocks
```

Типы блоков:

- `text`: текстовый блок с `title` и `body`;
- `checker`: чекер с `title` и пунктами `items`.

Frontend отображает эти блоки через компоненты:

- `plane-src/apps/web/core/components/issues/issue-detail-widgets/structured-content.helpers.ts`
- `plane-src/apps/web/core/components/issues/issue-detail-widgets/structured-content-blocks.tsx`

## Решение по переносам

Физически переносить Launcher и Task Manager внутрь `NODEDC` на нулевом этапе не нужно.

Причины:

- оба приложения уже являются отдельными git-репозиториями;
- Plane runtime завязан на текущие `plane-app`, `plane.env`, volumes и backup;
- перенос может сломать локальный self-host стенд;
- платформенный слой должен управлять интеграцией, а не становиться монорепозиторием всех исходников.

Допустимый вариант позже: добавить symlink или workspace manifest из `NODEDC` на внешние репозитории, если это потребуется для удобства навигации.

## Риски

- Нельзя пересоздавать существующего Plane admin/user, иначе потеряются связи workspace, задач, комментариев и assignee.
- Нельзя делать Authentik admin token доступным frontend-коду Launcher.
- Нельзя полагаться только на reverse proxy как единственный долгосрочный auth layer для приложений, которые мы контролируем кодом.
- Нельзя публиковать наружу Postgres, Redis, MinIO и внутренние API в staging/production.

## Следующий технический шаг

Создать локальный `platform/infra` слой с Authentik и reverse proxy, но сначала согласовать конкретную схему доменов, ports и secrets.