Design decisions

Nuxt Board limits its extension points to keep state ownership and failure behavior understandable.

One engine owns board state

Decision: nodes, camera, grid, selection, hierarchy, and plugin slices belong to one engine.

Benefit: commands, snapshots, events, and persistence cannot silently use different board instances.

Cost: applications must adapt existing product data at a deliberate boundary instead of mirroring every field into Vue state.

Commands are the mutation boundary

Persistent changes stage a candidate, validate it, and publish only after the outer transaction succeeds. The cost is that direct record mutation is unsupported. The benefit is atomic failure and one observable lifecycle.

Document and session state are separate

Pointer gestures update transient geometry. Completion commits once; cancellation discards the override. Runtime and exported state can differ during a gesture. That difference keeps persistence and history stable.

JSON Canvas node types are canonical

Custom renderers use existing text, file, link, and group records. This rules out arbitrary type strings, but prevents a second persistence schema.

Plugins are first-party infrastructure

Connections and history install during engine construction. The unsupported @lupinum/board-core/internal ABI exists for separately published first-party packages, not application extensions.

Nuxt owns no board behavior

@lupinum/nuxt-board registers imports and styles. Domain invariants stay below the framework boundary.