distri_workflow/lib.rs
1//! distri-workflow — workflow types + sidecar stores for Distri.
2//!
3//! After the spec rewrite that unified workflow orchestration with the
4//! task system, this crate is the *data layer*:
5//!
6//! - **Definition** — the workflow as a DAG of steps. Static template;
7//! no runtime state. (`WorkflowDefinition`, `WorkflowStep`).
8//! - **Run-level sidecar** — what a bare `Task` row can't carry:
9//! definition snapshot, entry point, input, shared context.
10//! (`WorkflowExecutionState`).
11//! - **Step-level sidecar** — per-step status, result, error,
12//! timestamps, and the optional `wait_task_id` for wait-style steps
13//! that need to be A2A-addressable. (`WorkflowStepState`).
14//! - **Store trait** — single CRUD surface over both sidecars
15//! (`WorkflowStore`). In-memory and Redis impls.
16//! - **Trigger registry** — routing index from declared workflow
17//! triggers (webhook path / cron / event topic / tool name) back to
18//! `(agent_id, entry_point_id)`. (`WorkflowTriggerRegistry`).
19//! - **In-memory runtime aggregate** — `WorkflowRun` + `WorkflowStepRun`
20//! are the transient in-process view used by the workflow agent's
21//! step driver. The driver lives in `distri-core` (see
22//! `agent/workflow_driver.rs`) — there is no `WorkflowRunner` /
23//! `WorkflowStateStore` / `InMemoryStore` / `EventSink` /
24//! `WorkflowEvent` parallel substrate anymore; everything flows
25//! through the canonical `TaskStore` + `AgentEventBroadcaster` +
26//! `WorkflowStore` triple.
27
28pub mod resolve;
29pub mod trigger_registry;
30pub mod types;
31pub mod workflow_store;
32
33pub use resolve::{
34 build_execution_context, evaluate_skip_condition, resolve_step_input, resolve_template,
35 resolve_value,
36};
37pub use trigger_registry::{
38 InMemoryWorkflowTriggerRegistry, TriggerBinding, WorkflowTriggerRegistry,
39};
40pub use types::*;
41pub use workflow_store::{
42 InMemoryWorkflowStore, WorkflowExecutionState, WorkflowStepState, WorkflowStore,
43};
44
45#[cfg(test)]
46mod tests;