# Архитектурный обзор 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 из коробки — нет.