MetaCore Platform — Architecture & Roadmap

1 Видение продукта

Три аудитории, одна платформа — от чат-бота до enterprise-приложения.

💬

Consumer

Описывает идею в AI-чате → получает работающее приложение. Нулевой порог входа. Как Bubble, но через разговор с AI.

⚙️

Professional

Разработчики и компании. Полный контроль: схемы, хуки, интеграции, процессы. Собственный workspace.

🧩

Plugin Developer

Расширяет платформу. Публикует плагины в marketplace. CLI для разработки, sandbox для тестирования.

2 Ключевой принцип: Everything is an Object

Каждая сущность в системе — типизированный объект с UUID, управляемый через единый ObjectService. Нет специальных таблиц для пользователей, ролей или типов — всё унифицировано.

Object (6ba7b814) ← Корневой тип. Каждая сущность IS an Object. ├── ObjectType (8ba7b815) ← Тип типов. Self-referential. ├── Attribute (6ba7b810) ← Определения атрибутов (code, dataType, isRequired…) ├── AttributeDataType ← String, Number, Boolean, Reference… ├── Plugin ← Метаданные + статус установки плагинов ├── Tenant ← Workspace-изоляция (→ будет Workspace) ├── User, Session, Account ← Auth (core module) ├── Role, Permission ← RBAC (core module) ├── AuditEntry ← Аудит (plugin) ├── MenuItem ← Навигация UI (plugin) └── Employee, Project, Dog… ← Пользовательские типы

🔄

Circular Bootstrap

ObjectType — тип самого себя. Object наследуется от ObjectType, а ObjectType от Object. Kernel bootstrap разрешает циклическую зависимость через raw Cypher MERGE.

🔗

Edge-based References

Все связи — Neo4j рёбра REF_*. Создаются/удаляются через стандартный CRUD. Операторы $add/$remove для коллекций. Нет прямого API для рёбер.

📋

Attribute Inheritance

Каждый тип наследует атрибуты от родителей. MetadataCache обходит parentTypeId цепочку. Object даёт 6 базовых атрибутов всем типам.

🔍

Единый API запросов

IQuery — один интерфейс для всего: find({typeCode: 'Role'}) или find({typeCode: 'ObjectType'}). Типы, атрибуты, данные — единообразно.

3 Архитектура слоёв

Строгое разделение на 5 слоёв. Каждый слой взаимодействует только с соседним. Core — sealed package, его внутренности недоступны.

Consumers Routes · Controllers · Frontend · External API · MCP Gateway

Optional Plugins Audit · UI · FormSpec · Import/Export · Expression Engine · [Community]

Core Modules (не удаляемые) Auth · RBAC · Tenant → Workspace · Events (EventBus)

Hook System (10 hook points) beforeCreate · afterCreate · beforeUpdate · afterUpdate · beforeDelete · afterDelete · beforeQuery · afterQuery · afterBuild · afterBuildMany

@metacore/core — Sealed Package ObjectService (9 методов) · CypherQueryBuilder · MetadataCache · Neo4jDatabase · CascadeService · ConstraintManager

🔒

Sealed Core

package.json exports блокирует доступ к internals. Только 9 публичных методов IObjectService. Хуки работают через IObjectServiceForHooks (findById, find, count, patch).

🪝

Hook Pipeline

Priority-based execution. RBAC (1000) → Tenant (900) → Audit (500) → Custom. Хуки могут блокировать, модифицировать данные или обогащать результаты.

4 Core Modules: Auth, RBAC, Tenant, Events

4 из 8 «плагинов» — не плагины. Система не работает без них, cross-plugin imports нарушают изоляцию. Решение: выделить в Core Modules с фиксированным порядком инициализации.

Проблемы текущей архитектуры

❌

Cross-Plugin Imports

RBAC импортирует AUTH_TYPE_IDS из ../auth/constants. Audit тоже. EventBus импортируется из IUnifiedPlugin интерфейса. Нарушена изоляция.

❌

Ложная опциональность

Auth/RBAC/Tenant помечены как optional в manifest, но система без них не работает. requestContext уже имеет getTenantId()/getUserId() — «плагинные» концепции в ядре.

Целевая структура

Компонент	Тип	Удалить?	Строк	Порядок init
auth	Core Module	Нет	~980	1
rbac	Core Module	Нет	~1,375	2
tenant	Core Module	Нет	~585	3
events	Core Module	Нет	~244	4
audit	Plugin	Да	~697	—
ui	Plugin	Да	~207	—
formspec	Plugin	Да	~119	—
import-export	Plugin	Да	~169	—
expression-engine	Plugin	Да	~200	—

Что нужно сделать

⚡

Немедленно (low-risk)

• EventBus → platform/events/ (core)
• AUTH_TYPE_IDS → shared constants
• Убрать cross-plugin imports
• Auth/RBAC/Tenant → kernel в manifest

🔧

Среднесрочно

• Интерфейс CoreModule (отличен от IUnifiedPlugin)
• Фиксированный порядок init, нет uninstall
• Core modules по-прежнему используют ObjectService для self-bootstrap

5 Workspace-изоляция

Workspace = развитие текущей Tenant-модели. Все объекты workspace (включая типы!) связаны через REF_objects рёбра. Типы уже scoped per tenant — workspace-изоляция для типов работает.

🏢 Platform Workspace

User: Маша (создатель)
User: Петя (создатель)
Billing, Subscriptions
Kernel types (shared)

💅 Masha's Workspace

ObjectType: Клиент
ObjectType: Запись
ObjectType: Услуга
Object: Клиент "Аня"
Object: Запись "15:00 маникюр"
User: Аня (клиент Маши)

Ключевой инсайт

💡

Types ARE Objects — уже scoped per tenant!

ObjectType имеет typeId = OBJECT_TYPE_TYPE и хранится как обычный Object. TenantHook.beforeQuery уже фильтрует запросы ObjectType по tenant. Workspace-изоляция для типов — уже работает. Не нужна отдельная система!

Как запросы фильтруются

API Request → Middleware: X-Tenant-Id / subdomain → TenantHook.beforeQuery → edgeFilter: REF_objects → Cypher: EXISTS {MATCH}

План реализации

📡

Routing

Subdomain: masha.metacore.app или path: /workspace/:slug/api/v1/...

🔐

Auth per Workspace

Клиенты Маши — отдельные пользователи в её workspace. Не видят другие workspaces.

📦

Per-Workspace Plugins

Каждый workspace устанавливает свой набор плагинов. Plugin types создаются внутри workspace scope.

6 Plugin Registry

Эволюция от захардкоженного manifest к динамическому обнаружению и marketplace.

Формат плагина

@metacore/plugin-crm/ ├── package.json ← metacore.plugin section ├── metacore.json ← id, version, dependencies, capabilities, typesCreated └── dist/ ├── index.js ← compiled IUnifiedPlugin (backend) └── plugin.js ← frontend bundle (IIFE, optional)

Этапы перехода

📁

Этап 1: File-based

Плагины в runtime/plugins/ как папки. File scanner заменяет manifest. Built-in плагины обёрнуты в тот же формат.

🌐

Этап 2: HTTP Registry

Отдельный сервис. UI для browse/install/uninstall. CLI: metacore plugin init/build/publish.

🏪

Этап 3: Marketplace

Рейтинги, отзывы, платные плагины. Developer portal, sandbox для тестирования.

Уровни доверия

Уровень	Доступ	Изоляция
Core plugins	Полный доступ к platform	Нет ограничений
Verified plugins	IObjectService + CapabilityRegistry	Прошли ревью, подписаны
Community plugins	Только IPluginLifecycleContext	Нет прямого доступа к DB, файлам, сети. Frontend в iframe с CSP.

Runtime Install Flow

UI: Install CRM → Download tarball → Unpack to runtime/plugins/ → require(dist/index.js) → register → install → Types + hooks active

7 Expression Engine

Sandboxed JavaScript-выражения через isolated-vm (V8 isolates). Базовая инфраструктура для Process Engine, FormSpec, Computed Fields, Validation.

🔒

Полная изоляция

isolated-vm — production-grade V8 isolates (как Cloudflare Workers). 8MB памяти, 100ms timeout. Нет доступа к Node.js API, файлам, сети.

📐

JavaScript-синтаксис

Знакомый язык, не нужен DSL. Поддерживает: условия, reduce, map, стрелочные функции. Контекст — read-only переменные.

Примеры использования

// Условие в бизнес-процессе order.amount > 1000 && customer.rating >= 4 → true // Computed field items.reduce((sum, item) => sum + item.price * item.qty, 0) → 350 // FormSpec conditional visibility status === "needs_approval" && amount > 5000 → true // Валидация endDate > startDate → true/false

Кто потребляет

Expression Engine ← Process Engine (условные переходы)

Expression Engine ← FormSpec v2 (conditional visibility)

Expression Engine ← Computed Fields · Validation Rules · Access Rules

8 Roadmap: порядок реализации

Зависимости определяют порядок. Параллельные фазы отмечены. Каждая фаза — инкрементальный шаг к полноценной low-code платформе.

Граф зависимостей

Expression Engine ← не зависит ни от чего Plugin Registry ← не зависит ни от чего Core Modules ← не зависит ни от чего Workspaces ← Core Modules + Plugin Registry Process Engine ← Expression Engine FormSpec v2 ← Expression Engine AI Chat ← Expression Engine + Workspaces

Timeline

Phase 0: Architecture Cleanup Complete

@metacore/core sealed package. TypeLifecycleHook, AttributeLifecycleHook. 4 read hook points. TenantHook, RBAC consolidation. API consolidation.

25 задач → 15 выполнено, 9 deferred, 1 partial
~2,200 строк across ~65 файлов
Тесты: 1,131 (773 backend + 250 frontend + 108 E2E)

Phase 1.5: Tenant & Migration Overhaul Complete

Замена V3–V21 миграций на base + plugin migration. System Tenant. Plugin management UI. Schema Visualizer.

17 шагов, ~40 коммитов
System Tenant — все объекты имеют явного tenant-владельца
Тесты: 1,417 (1,109 backend + 308 frontend)

Phase 2: Plugin Architecture Unification Complete

IUnifiedPlugin — единый интерфейс. PluginManager + BootOrchestrator. Route decomposition. ObjectService API reduction.

37 шагов, 52 итерации
IUnifiedPlugin — 8 методов, один интерфейс вместо трёх
IObjectServiceForHooks — сужен до 4 методов (findById, find, count, patch)
Тесты: 1,275 (84 suites, backend)

Phase RR: Reverse References & edgeFilter Complete

reverseReference data type. Generic edgeFilter. Tenant owns objects via REF_objects. $add/$remove operators.

Phase 2.5: Core Modules Refactoring In Progress

Auth/RBAC/Tenant/Events → Core Modules. Фиксированный порядок инициализации. Убрать cross-plugin imports.

EventBus → platform/events/ (core)
AUTH_TYPE_IDS → shared constants
CoreModule interface (не IUnifiedPlugin)
Нет uninstall — ядро нельзя удалить

Phase 3a: Expression Engine Future

isolated-vm integration. API через CapabilityRegistry. Helper-функции. Можно параллелить с 3b.

Phase 3b: Plugin Registry Future

Plugin package format (metacore.json). File-based discovery → HTTP Registry. CLI: metacore plugin init/build/publish.

Phase 4: Workspace Isolation Future

Workspace scope для типов. Per-workspace plugin installation. Subdomain/path routing. Self-service workspace creation.

Phase 5: AI & Chat Interface Future

Chat panel, NL→Schema, NL→Query, MCP Gateway, Agents SDK, Bot Framework (Telegram/Discord).

Phase 6: Process Engine Future

ProcessDefinition/ProcessInstance as objects. Graph-based execution. Expression conditions. Visual Process Designer.

Phase 7: Product Plugins Future

Link-in-Bio, News-Podcast — каждый продукт = плагин. Демонстрация расширяемости платформы.

9 AI & Process Engine

Две ключевые фазы, которые превращают MetaCore из объектной платформы в AI-powered конструктор приложений.

🤖

AI Chat Interface (Phase 5)

NL → Schema: «Создай тип Клиент с именем, телефоном и email» → ObjectType + Attributes.

NL → Query: «Покажи всех клиентов за последний месяц» → IQuery.

MCP Gateway: Внешние AI-агенты получают доступ к платформе через MCP протокол.

Agents SDK: Agent lifecycle, tool registry, Bot Framework с Telegram/Discord адаптерами.

⚙️

Process Engine (Phase 6)

Graph-based: ProcessDefinition и ProcessInstance — объекты. Node-graph execution model.

Node types: Action, Condition, Human-Task, Wait, Subprocess.

Expressions: Условные переходы через Expression Engine: score >= 700.

Visual Designer: Drag-and-drop редактор процессов в UI.

Как всё связано

User Interface AI Chat · Process Designer · Form Builder · Dashboard

Intelligence Layer LLM Provider · MCP Gateway · Agent Runtime · Expression Engine

Business Logic Process Engine · Workflow Nodes · Computed Fields · Validation Rules

Platform Core Core Modules (Auth + RBAC + Tenant + Events) · Hook System · Plugin Manager

Data Layer ObjectService · Neo4j · Workspace Isolation

∞ Итого

MetaCore — граф-нативная платформа где всё является объектом. Sealed core гарантирует стабильность. Hook system даёт расширяемость. Core Modules обеспечивают безопасность. А Workspaces, AI и Process Engine делают её полноценным конструктором приложений.

4

Фазы завершены

1,275+

Backend тестов

6

Фаз впереди

MetaCore Platform Архитектура нового поколения