Choose composition before scheduling
WorkflowComposer supplies tenant-aware composition, validation, a runner, state and persistence adapters. Its runner requires supplied operation execution and state persistence. A provider-specific scheduler belongs at a different boundary. The workflow-orchestration module adds reusable product-facing views and lifecycle/approval behavior. Start by deciding whether your task is to describe a graph, execute selected steps, schedule work durably, or present an operator view; that decision identifies which package to open first.
Keep graph changes deterministic
The maintained composer applies extensions in stable priority order, rejects duplicate injected step IDs and invalid anchors, and checks hidden-step overlays so they do not orphan the remaining graph. Metadata and annotations are merged into the composed result. These details matter when adding a tenant or product extension: inspect the resulting graph and its references, not just the added step. Keep step identity stable enough for state, traces and operator actions to refer to the same work.
Make execution and persistence visible
The canonical leaves include workflow context, SLA monitoring and SDK error conversion as well as validation and shared task validators. Choose the state store and operation executor the host actually supplies. A saved plan, a running instance, a retried step and a completed external effect are different states. Capture outcomes and failure paths at the point where callbacks or adapters return. For automation that can improve or regenerate itself, use the separate governed proposal and promotion lifecycle rather than replacing an active workflow silently.
Follow a practical path.
Follow an existing graph
Record the entry, operation references, branch conditions and terminal outcomes. Inspect one extension and compare the composed graph to its base. Check which registry and source version resolve each step.
Select state and execution adapters
Begin with the maintained memory/file or supplied adapter appropriate to the example. Identify the durable store and scheduler needed for the intended host before claiming restart or retry guarantees.
Review interruption and recovery
Use existing tests or fixtures to inspect a failed step, repeated delivery and cancelled instance. Confirm that persisted state and returned results explain what happened and that retry behavior belongs to an explicit host/runtime contract.