feat: render a workflow from JSON passed in from outside (claude)

[VsevolodX]

Add WorkflowViewer: hand it workflow JSON and it shows the workflow's units as cards plus the selected subworkflow's units as a flowchart, with no store, router or dependency injection to wire up first.

The types are the ecosystem's own, with nothing in between: JSON going in is @mat3ra/esse's WorkflowSchema or JobSchema (as the object, or a JSON string of one), and what comes out of createWorkflowFromConfig() is a @mat3ra/wode Workflow — the entity that gives the cards their subworkflows, model instances, properties and statuses. A host app that already holds a Workflow can pass it straight through. The constructor's required entity lists (units, subworkflows, workflows) are defaulted when a config omits the empty ones, as Subworkflow.toJSON()-derived payloads do.

The entity validates against the ESSE schemas on the way in, so a config that is not valid ESSE is reported in place, naming the schema and what it requires, rather than half-rendering JSON nobody can vouch for:

wove: not a valid workflow config: REQUIRED_PROPERTY_MISSING — Subworkflow Schema requires: application, model, name, properties, units

The standalone bundle exposes window.renderWorkflow(workflowConfig, container, options), the same contract as wave.js' window.renderThreeDEditor(materialConfig, container), so a notebook or any other page can embed a workflow view through the api-examples viewer helpers with render_function="renderWorkflow". Stylesheets are emitted as main.css to keep that URL stable next to main.js, and the demo page mounts into its own container so importing the bundle only registers schemas and defines the global rather than rendering anything.

Checked in a browser on both entry points — the demo page and window.renderWorkflow() from the built bundle — plus tsc, both builds, and 43 tests, one of which constructs every one of the 57 standata workflows.

[timurbazhirov]

Review pass over the whole PR. The ESSE-schemas point is addressed in the thread above; the rest of what I found, with the fixes pushed:

1. Parallel type hierarchy (fixed, 7ed3cbb). Covered in the thread — the two *Like interfaces and the JSON stand-ins are gone, any no longer launders stand-ins past components that declare subworkflow: WodeSubworkflow, and the fallback they existed for was only reachable with configs that aren't valid ESSE.

2. editable enabled a Delete button that did nothing (fixed, a05d08f). WorkflowUnitsFlowchart gated the card's Delete on editable alone while defaulting onRemove to a no-op. WorkflowViewer sets editable but wires no onUnitRemove, so editable: true rendered an enabled Delete whose click went nowhere. It is now gated on a handler actually being present; callers that pass one are unaffected. On the read-only viewer editable means the Copy action, which does work on its own — the prop doc and the README say that now instead of promising "editing affordances".

3. Header chips were hand-rolled (folded into 7ed3cbb). The viewer walked subworkflowInstances and deduped labels itself. Workflow.usedApplications already does exactly this, dedupes, and covers nested workflows, which the hand-rolled version missed.

Verified rather than assumed: both entry points driven in a real browser (demo page and window.renderWorkflow() from the built bundle), tsc, both builds, and 43 tests — one of which constructs every one of the 57 standata workflows, so the entity path is exercised against real configs rather than a hand-written fixture.

Two things I left alone, flagging rather than changing:

• assetFileNames: "main.[ext]" in vite.config.ts is right for the stable main.css URL, but it is a collision risk the moment the bundle emits a second asset of any one type (a font, an image) — they would all want the same filename. Fine today: the build emits only main.css.
• npm run lint cannot run here — @exabyte-io/eslint-config is not in devDependencies, so eslint exits before doing anything. Pre-existing and CI skips eslint (skip-eslint: 'true'), so nothing in this PR is affected, but the lint script is currently decorative. Prettier I checked file by file: my changes add no formatting drift. (The repo-wide prettier --check failures come from a prettier 2 → 3 JSX >-placement change and hit untouched files too.)

---

Generated by Claude Code

[VsevolodX]

Picked up the first of the two flagged items — the asset-name collision risk was mine, and it's fixed in 3383e92.

assetFileNames is now a function: the stylesheet keeps the stable main.css name a host page loads by URL, everything else goes back to [name]-[hash].[ext]. So the wave.js-style contract holds without every asset of a given type wanting the same filename the day the bundle emits a font or an image.

Verified against a fresh build: main.js and main.css both serve 200 at their documented URLs, a page that loads the stylesheet by URL gets React Flow's styles, and with editable set the card offers an enabled Copy and a disabled Delete — i.e. a05d08f's gating behaves as intended through the built bundle.

The second item I'm leaving alone deliberately: npm run lint needs @exabyte-io/eslint-config added to devDependencies, which is a repo-wide fix rather than this PR's, and CI already skips eslint. Worth its own change.

---

Generated by Claude Code