Tooling, editor, and diagnostics

Mental model

Story tooling works best when it projects the Story model instead of hiding it. The CLI loads, compiles, bakes, previews, exports, and inspects the same Story contract. The Canvas editor is a projection over one running Story session. The syntax reference is generated from the same descriptor store the compiler uses. Diagnostics are enriched onto the baked model rather than emitted as a separate trace protocol.

Responsibilities and boundaries

• The CLI is the current dynamic plugin host and hot-reload host.
• story canvas owns one preview session for one input Story document, plus the loopback APIs that expose state, media, overlays, selection, and timeline projections.
• The editor timeline projects action order, waits, cue timing, and sprite lifetimes from baked model data.
• story syntax is a generated reference surface, while Specs remain curated narrative contracts assembled from knowledge plus source.

Stable current behavior

• The current tooling stack spans CLI 1.0.0-beta.1, Story schema v1beta1, Canvas protocol 1, and extension manifest 1 as separate version axes.
• Preview/live watch the root Story plus every canonical dependency published by compilation, including source-defined shaders and missing include targets.
• Reload failure preserves the last known good preview scene, while successful reload reuses the existing playback context and replaces the scene in place.
• Canvas selection, overlays, wait rows, and timeline items come from structured model enrichment such as action snapshots, wait diagnostics, and sprite lifetime events.
• The generated syntax reference remains the authoritative current-binary view of descriptor-backed types for documentation lookup.

Current limitations

• The current Canvas boundary is one Story document per session.
• Dynamic plugins: loading is trusted code in the CoreCLR CLI and is unavailable under Native AOT.
• story syntax --reference can document plugin-contributed object descriptors, but its value-type and constructor appendix still stays on the built-in host registry.
• Diagnostics are model enrichment, not a second authoritative runtime event stream.

How the pieces connect

1. The CLI loads YAML, extracts optional plugins:, composes descriptor registries, and compiles the Story.
2. Preview/live optionally hot-reload dependencies and keep a last-known-good scene when the newest load fails.
3. Canvas hosts that same session through loopback APIs for preview, media, selection, and timeline projection.
4. Diagnostic printers and editor projections both read enriched bake results such as source spans, property settle data, and wait provenance.
5. story syntax and Specs then explain the same system at different depths: generated exact surface versus curated contract narrative.

Go deeper

• Learn: Install Rune Story, Preview, live, and export
• Examples: Presentation demo, Examples gallery
• Reference: Story CLI, Story syntax
• Specs: RUNE-1013, RUNE-1001, RUNE-001