Workflow kit

A reusable toolkit for authoring workflows and working with their running instances, built on Vyuh Diagram. Authoring and execution experiences are equally important.

Planned, separate package

This page describes the intended scope. The workflow kit will live in a separate repository and is not implemented or shipped with Vyuh Diagram today.

Authoring

The kit should provide a configurable palette of operations, decisions, waits and reusable groups. Applications register their own node definitions, configuration fields and input/output schemas.

• Nodes and connections: typed ports, named outcomes, conditions and rules for valid connections.
• Configuration: panels for inputs, outputs, assignments and operation settings, with field validation and useful defaults.
• Graph validation: identify incomplete configuration, broken references, unreachable steps and invalid branches; link each issue to its node or connection.
• Reusable definitions: templates, reusable subflows, duplication and clear version boundaries between drafts and published definitions.
• Editing: reuse the diagram's selection, connection editing, rich text, navigation and undo/redo, with workflow-aware commands entering the same transaction pipeline.

Execution experiences

The same visual definition should support inspecting a run and taking the actions permitted by the host application.

• Run state: distinguish pending, running, waiting, completed, failed and cancelled work with readable node and connection states.
• Inspection: show inputs, outputs, errors, timing and a chronological execution history for the selected step or run.
• Actions: expose available work, provide input or resolve a wait, and offer retry or cancellation when supported by the runtime.
• Navigation: move between active work, failures and completed steps while retaining the user's viewport and selection.
• Live updates: reconcile backend events with stable node IDs and the exact definition version used by the run.

Integration contract

The kit should offer adapters for loading and saving definitions, receiving run updates and submitting actions. The host owns authentication, permissions, persistence and execution. Available actions and their results come from that authority; a visual status change alone does not execute work.

A published workflow definition and its running instances have separate lifecycles. Each run references a specific definition version, so editing a draft cannot silently change an existing run.

Built on the diagram foundation

Workflow semantics attach to registered shapes and connectors. Geometry, text layout, ports, selection and history continue to use the diagram's canonical model. Execution state is projected onto those stable identities rather than maintained as a second mutable diagram.

Application-specific terminology and business rules belong in the host application. The kit should remain useful across approval flows, automation, onboarding, data processing and other workflows.