Configure an ORION MES application

The panel reads an application JSON document from the backend. That document chooses one root panel, composes child panels, defines data requests, and wires events and actions.

Start with the smallest application

{
  "version": "1.0.0",
  "description": "Production orders",
  "layout": { "padding": true },
  "panel": {
    "id": "orders",
    "type": "table",
    "request": { "metaTypeName": "ProductionOrder" },
    "columns": [
      { "attribute": "itemId", "label": "Order" },
      { "attribute": "name", "label": "Name" }
    ]
  }
}

version: "1.0.0" is the current supported TypeScript contract. Fetched JSON is assigned without runtime schema validation, so the load boundary does not currently reject a missing or different version. Do not rely on that gap as forward-compatibility.

Choose your next task

1. Define the application envelope.
2. Compose panels and choose a registered variant.
3. Load object, linked, method, or custom-request data.
4. Add user actions and cross-panel events.
5. Configure object and link editors, then control values and localization.
6. Follow complete cross-panel journeys or open the matching runnable fixture.
7. After understanding the feature, use the secondary parameter reference for exact paths, defaults, relationships, and known runtime/type drift.

Configuration boundaries

The JSON configurator covers application content, panel composition, requests, actions, events, editors, and panel-specific options. It does not configure Nuxt environment variables, internal Pinia state, component props, or API response fields.

Type declarations are useful navigation, but they are not runtime validation. Where a type-only field has no consumer, the reference marks that drift instead of presenting the field as working behavior.