Skip to content

CDX Integration

CDX consumes published workflow packages. It does not own the runtime. cdx_feature_workflows is the Flutter inbox. cdx_workflow_templates supplies the canonical approval definition.

Ownership

OwnerContract
Workflow packagesDefinitions, activity/user-task contracts, replay, templates
ProductSchema, immutable version rows, master-data policies, handlers, IAM assignment, outcome effects
Workflow serviceExecution, commands, signals, inbox projection, events, workers, administration

Server Runtime

dart
import 'package:cdx_workflow_templates/cdx_workflow_runtime_templates.dart';
import 'package:vyuh_workflow_engine/vyuh_workflow_runtime.dart';
import 'package:vyuh_workflow_service/vyuh_workflow_service.dart';
import 'package:vyuh_workflow_storage_supabase/vyuh_workflow_storage_supabase.dart';

final approval = ApprovalWorkflowDefinition.standard(
  workflow: const WorkflowRef(
    code: 'directory.entity_master_approval',
    version: 1,
  ),
  digest: 'directory.entity_master_approval:v1',
).buildDefinition();

final application = WorkflowServerApplication(
  adapter: WorkflowServerAdapter(
    storage: SupabaseWorkflowStorage(
      client: serviceRoleClient,
      schema: WorkflowRuntimeInstaller.defaultSchema,
    ),
    operations: workflowOperations,
    access: productAccess,
  ),
  workerId: replicaId,
  modules: [
    WorkflowModule(
      name: 'directory',
      workflows: [approval],
      activities: directoryApprovalBindings,
      userTasks: directoryApprovalUserTasks,
    ),
  ],
);

Install the durable schema once. Seed immutable workflow_versions rows in a reviewed migration. create_run rejects unknown or digest-mismatched versions.

Canonical Approval

cdx_workflow_templates ships a durable Dart definition and a legacy graph definition. Parity tests cover approval, rejection, revision, resubmission, and cancellation. Existing ELOG and DocsIQ runs stay on LegacyWorkflowEngine until the adoption gate passes.

Start new durable approvals with the typed ApprovalStart envelope and the workflow service, not engine.startWorkflow.

Feature Inbox

cdx_feature_workflows still exports:

  • WorkflowActionBar, driven by server-provided List<UserTaskAction>;
  • WorkflowStatusCard;
  • inbox row/detail helpers;
  • WorkflowActivityTimelineView;
  • CdxFeatureWorkflowsPlugin.

The action bar switches on the sealed action subtype. It does not call the runtime and it does not hold a service-role key.

Blueprint

A product declares one WorkflowBlueprintDefinition. Blueprint owns the master-data workflow policy entity. The six runtime tables are DbObjectOwnership.external; the Supabase adapter owns their schema.

Inspector

vyuh_workflow_inspector reads runs, events, and commands. Embed it against the same storage contract the server uses. Operator retry, redrive, and cancel write audited history.

Visual Editor

The editor authors constrained workflow documents. Simulation still drives external completions manually. It is not a second production engine.

Keep The Layers Separate

LayerOwns
WorkflowRuntimeReplay, commands, history
Supabase storageSchema, RPCs, fencing
Workflow serviceTrusted product and operations API
CDX typesShared inbox and approval contracts
CDX templatesCanonical durable approval definition
CDX feature workflowsFlutter inbox UI
InspectorObservation and audited recovery

See Also