# Архитектурный обзор Plane CE под NodeDC

## Короткий вывод

Как база под локальный PoC и дальнейший форк Plane подходит.

Причины:
- monorepo прозрачный, фронт и бэк лежат рядом
- backend на Django с довольно прямой моделью данных
- frontend разбит на приложения и пакеты без сильной магии
- роли, проекты, workspace и work items вынесены в явные модели и API
- self-host runtime отделен от исходников, поэтому можно независимо разворачивать стенд и вести форк

Слабые места:
- есть шероховатости в self-host setup и в некоторых runtime-флоу релиза `v1.3.0`
- часть UI-строк все еще размазана по компонентам, не везде i18n идеально дисциплинирован
- attachment flow в текущем релизе выглядит хрупко

Что проверено уже на живом локальном инстансе:
- login/onboarding экран
- домашний экран workspace
- project issues/work items
- project views
- project settings
- profile settings

Фактический остаток после русификации на этих экранах небольшой:
- timezone label `Moscow Time`
- отдельные технические loader/accessibility строки вне основного happy-path
- часть secondary/admin экранов не аудировалась так же глубоко, как основной `apps/web`

## Как устроен frontend

Основное web-приложение:
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/web`

Соседние приложения:
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/admin`
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/space`

Технологически:
- React
- React Router
- TypeScript
- MobX stores
- Vite/react-router build
- общие UI/утилиты вынесены в workspace packages

Полезные пакеты:
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/packages/i18n`
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/packages/services`
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/packages/ui`
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/packages/types`
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/packages/shared-state`

Практически это удобно для форка:
- можно менять только `apps/web`, не трогая backend
- можно переопределять поведение через store/services слой
- локализация и общие UI-слои вынесены отдельно, это удобно для русификации и брендирования под NodeDC

## Как устроен backend

Основной backend:
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api`

Технологически:
- Django
- Django REST style API
- Postgres
- Redis
- RabbitMQ
- MinIO/S3-совместимое хранилище

Модельный слой читаемый, без сложной скрытой генерации.

Ключевые модели:
- users: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/user.py`
- workspace: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/workspace.py`
- projects: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/project.py`
- issues/work items: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/issue.py`
- views: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/view.py`
- instance admin: `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/license/models/instance.py`

## Где живет auth / users / roles / projects / work items

### Auth

Auth-слой:
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/authentication`

Что видно на практике:
- есть email/password вход
- есть magic-code и OAuth-провайдеры
- session auth используется в license/admin API
- для локального PoC email/password сценарий нормальный и достаточно простой

Для NodeDC это плюс:
- можно оставить Plane как внутренний task-сервис
- внешнюю SSO/SSO-агрегацию лучше строить аккуратно через отдельный auth gateway или через ограниченный backend patch, а не переписывать весь auth слой сразу

### Users

Основная пользовательская модель:
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/user.py`

Пользовательские настройки и профили привязаны к workspace/user preference модели, а не размазаны хаотично.

### Roles

Роли workspace/project заданы явно числовыми choice-полями.

Файлы:
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/workspace.py`
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/project.py`

Базовая ролевая модель:
- `Admin`
- `Member`
- `Guest`

Это достаточно для PoC, но для NodeDC, если нужны тонкие корпоративные ACL, вероятнее всего придется строить внешний mapping или дополнительный policy layer.

### Projects

Файл:
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/project.py`

Проект содержит нужный минимум:
- имя
- identifier
- network/доступность
- участники
- инвайты
- архивирование

### Work items / issues

Файл:
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/apps/api/plane/db/models/issue.py`

Что важно practically:
- issue-модель богатая
- есть assignees
- comments
- attachments
- labels
- relations
- subscribers
- activity/history
- versions

Под встроенный task-management контур это хорошая база: предметная модель уже богаче, чем нужен минимальный NodeDC PoC.

## Что выглядит хорошими точками кастомизации

### 1. Frontend fork

Самая безопасная и быстрая зона кастомизации.

Что удобно менять:
- локализацию
- названия сущностей в UI
- onboarding
- проектные экраны
- навигацию
- виджеты карточек и work item detail
- интеграционные кнопки и ссылки в NodeDC

Причина:
- это в основном `apps/web`
- изменения изолируются без тяжелого вмешательства в доменную модель
- уже подтверждено практикой на этом стенде: русификация, переименование UI-лейблов и правка hardcoded строк делаются без вмешательства в backend

### 2. Слой сервисов и stores

Хорошее место для мягкой интеграции с NodeDC.

Файлы/пакеты:
- `/Users/dcconstructions/Downloads/mnt/data/dc_taskmanager/NODEDC_TASKMANAGER/plane-src/packages/services`
- store-слой внутри `apps/web/core/store` и `hooks/store`

Подходит для:
- прокидывания дополнительных данных из NodeDC
- feature-flags
- брендированных сценариев
- дополнительных UI-проверок
- синхронизации preferred language / workspace defaults / видимости пунктов меню

### 3. Bootstrap / seed / миграции рядом с runtime

Для PoC и внутренних стендов это удобно держать отдельно от core-кода Plane.

Что уже сработало:
- отдельный bootstrap-скрипт на Django shell
- demo-данные живут рядом с self-host runtime, а не смешаны с upstream

## Что лучше не трогать без необходимости

### 1. Базовый self-host stack целиком

Не стоит на старте переписывать:
- compose topology
- proxy слой
- очередь/redis/minio wiring

Причина:
- локальный runtime уже и так неидеален
- при ранней кастомизации инфраструктурного слоя слишком легко получить нестабильный стенд

### 2. Ядро auth-провайдеров

Не стоит сразу глубоко влезать в:
- `/apps/api/plane/authentication/provider`
- `/apps/api/plane/authentication/adapter`

Лучше сначала решить, нужен ли NodeDC-side SSO gateway, либо достаточно controlled login flow.

### 3. Низкоуровневый attachment/storage flow

По факту релиза `v1.3.0` это место уже выглядит хрупко.

Если кастомизировать загрузки и документы, лучше:
- сначала стабилизировать текущий runtime-флоу
- потом отдельно проектировать document-service интеграцию

Практический вывод по этому пункту:
- для NodeDC-сценария "запрос документов" Plane лучше использовать как UI и контур задач
- документный бинарный контент и его жизненный цикл разумнее держать в отдельном sidecar/document-service

## Что конфигурируется из коробки

Из практических вещей без тяжелого форка:
- self-host параметры через `plane.env`
- локальный URL/ports
- storage через MinIO/S3
- email/auth провайдеры
- язык пользователя
- workspace/project structure
- demo users/projects/issues
- i18n-переводы frontend UI
- локальные image tags для собственного форка frontend/admin/space

## Что, вероятно, стоит делать отдельным sidecar/service рядом с Plane

### 1. Корпоративная интеграция с NodeDC-админкой

Если NodeDC уже источник истины по оргструктуре, сотрудникам и ролям, лучше не вшивать это насмерть в core Plane.

Практичнее вынести рядом:
- sync-service пользователей
- sync-service оргструктуры / отделов / контуров
- mapping ролей NodeDC -> Plane workspace/project roles

### 2. Документный контур

Под сценарий “запросы документов” логично иметь sidecar:
- файловое/документное хранилище
- правила доступа к документам
- интеграцию с существующей NodeDC-документной подсистемой

Plane можно оставить как task/workflow UI, а не как единственный документный источник истины.

### 3. Внешние бизнес-правила

Если понадобятся:
- SLA
- маршруты согласования
- специфические статусы для бухгалтерии/менеджеров
- автоматическое создание задач из событий NodeDC

Это лучше сначала делать внешним orchestration/service слоем, а не перепахивать core issue lifecycle в Plane.

## Что можно синхронизировать с NodeDC-админкой

Наиболее реалистичные направления синхронизации:
- пользователи
- команды / отделы / контуры
- принадлежность к workspace/project
- справочник ролей и роль-mapping
- автосоздание проектов под контуры NodeDC
- начальные шаблоны проектов и saved views
- статусы и labels для типовых процессов вроде бухгалтерии и запросов документов

## Итог по пригодности под NodeDC

Для сценария "встроенный task-management контур внутри NodeDC" оценка положительная, если держать реалистичную границу кастомизации:
- Plane как готовое ядро задач, проектов, activity, comments, views и базовых ролей
- NodeDC как источник оргструктуры, корпоративных правил, документов и внешних интеграций

Нехороший путь:
- пытаться быстро превратить Plane в единственный источник истины по оргструктуре, документам и enterprise-ACL

Хороший путь:
- форк `apps/web` + ограниченные backend-патчи
- sidecar для sync и document workflows
- постепенное brand/UI-domain подстраивание под NodeDC
- автосоздание work items из событий NodeDC
- ссылки из NodeDC admin в конкретные work items Plane

## Практическая оценка пригодности под NodeDC

### Что уже хорошо

- есть рабочий self-hosted open-source контур
- модель projects/work items уже зрелая
- UI достаточно богат для быстрого PoC
- фронт реально поддается форку и русификации
- предметные сущности хорошо ложатся на сценарии “бухгалтерия / менеджеры / запросы документов”

### Что сыровато

- официальный self-host flow не полностью воспроизводим без ручных правок
- attachment/storage часть выглядит ненадежно
- не весь UI идеально дисциплинирован по i18n
- часть внутренних UX-решений все еще ориентирована на общий SaaS-сценарий Plane, а не на embedded B2B-контур

### Что опасно брать в глубокий форк

- глубокую переделку auth ядра на первом этапе
- радикальную переделку storage/attachments без отдельного тестового контура
- попытку сделать из Plane master-system для всего NodeDC вместо роли task/workflow сервиса

## Итог

Для сценария “встроенный task-management контур внутри NodeDC” Plane CE можно брать как базу под ручную докрутку.

Но разумная стратегия такая:
- Plane использовать как ядро task/work item UI и workflow-базы
- NodeDC оставить источником истины по оргструктуре и, возможно, идентификации
- сложные корпоративные правила и интеграции выносить в sidecar/sync services рядом

То есть: как стартовая база для PoC и дальнейшего прикладного форка подходит, как готовый безболезненный enterprise-foundation из коробки — нет.
