Nexus Engine Plugin System & Schema-Driven UI

The Problem with Traditional Editors

In a traditional editor application, the UI code (React components, sidebars, property inputs) for every object in the game is hardcoded into the editor itself. If you add a "Drone" object, a developer has to write React code in the editor's Sidebar to handle the "Speed" slider.

This approach is fundamentally incompatible with a marketplace SDK model. If third-party developers sell plugins (Systems), they cannot modify the source code of the Editor to add their sliders.

The Solution: Schema-Driven UI

The Nexus Engine Editor is entirely agnostic to the systems it loads. It knows absolutely nothing about Drones, Bots, Phones, or NLP.

Instead, every System exports an EditorPlugin object alongside its runtime logic. This object contains a strict, language-agnostic JSON Schema describing the variables the system exposes. The Editor dynamically parses this schema and auto-generates the UI (sliders, text inputs, toggles) at runtime.

The Plugin Schema Standard (@neural-workspace/nexus-engine-core)

export interface SystemPropertySchema {
  id: string;               // The property key (e.g., 'speed', 'modelUrl')
  label: string;            // The human-readable name in the editor UI
  type: 'string' | 'number' | 'boolean' | 'select' | 'behavior_script';
  options?: any[];          // Used if type is 'select'
  min?: number;             // Used if type is 'number'
  max?: number;
  step?: number;
  default: any;             // The default value when first spawned
}

export interface EditorPlugin {
  id: string;               // Unique system identifier
  name: string;             // Display name in the editor
  category: string;         // E.g., 'Systems', 'UI / OS', 'Logic'
  iconSvg: string;          // Serialized SVG string for the add menu icon
  is3D: boolean;            // Does this plugin exist in 3D space?
  properties: SystemPropertySchema[];
  
  // Optional: A URL to a lightweight proxy GLB to visualize the system in the Editor viewport
  // If not provided, the Editor draws a generic bounding box.
  viewportHelperModel?: string; 
}

Example: The Drone System

The @neural-workspace/nexus-engine-agents package will export both the runtime <Drone /> component and its schema:

export const DroneEditorPlugin = {
  id: "drone",
  name: "Drone Agent",
  category: "Systems",
  is3D: true,
  iconSvg: "<svg>...</svg>",
  viewportHelperModel: "/models/optimized/drone_animated.glb",
  properties: [
    { id: 'modelUrl', label: 'Model URL', type: 'string', default: '/models/optimized/drone_animated.glb' },
    { id: 'speed', label: 'Movement Speed', type: 'number', min: 1, max: 20, step: 0.5, default: 5 },
    { id: 'calculatePath', label: 'Preview Exact Path', type: 'boolean', default: false },
    { id: 'previewProgress', label: 'Path Preview Progress', type: 'number', min: 0, max: 100, default: 0 },
    { id: 'behaviorScript', label: 'Behavior Script', type: 'behavior_script', default: [] }
  ]
};

How the Editor Uses It

When the editor mounts, it fetches all installed plugins via the SDK Core.

1. Left Sidebar: Groups all plugins by category and uses iconSvg and name to render the drag-and-drop buttons.
2. Right Sidebar: When a Drone is selected, it loops over properties. When it sees { id: 'speed', type: 'number' }, it automatically renders a <input type="range" /> component and wires up the state.
3. Viewport: It renders the GLB specified in viewportHelperModel so the user knows where the drone is placed.

Extensibility benefits

By decoupling the UI generation from the UI framework, plugin developers never have to write Tailwind CSS or React components for the editor. If we later port the Nexus Editor to Vue.js, Svelte, or a native desktop app, the plugins remain 100% compatible.