1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
//! FlowFabric — umbrella crate re-exporting the published crate family.
//!
//! Pin one crate; let Cargo resolve the rest. Closes #279 — prior to
//! v0.8.2 consumers (cairn-fabric, downstream integrations) had to
//! pin all 7–8 `ff-*` crates + `ferriskey` in lockstep and version-
//! skew drift was only caught at `cargo update` time. This crate is
//! the single-line import surface; feature flags gate which backend
//! and which optional internals get pulled in.
//!
//! # Quick start
//!
//! ```toml
//! # Valkey backend (default):
//! flowfabric = "0.8"
//!
//! # Postgres backend (explicit, no valkey):
//! flowfabric = { version = "0.8", default-features = false, features = ["postgres"] }
//!
//! # Advanced — direct engine/scheduler access:
//! flowfabric = { version = "0.8", features = ["engine", "scheduler-internals"] }
//! ```
//!
//! See `docs/CONSUMER_MIGRATION_v0.8.md` § "Umbrella crate
//! (flowfabric)" for mapping from the 7-crate import shape to the
//! umbrella shape.
//!
//! # Re-export map
//!
//! | Umbrella path | Underlying crate | Feature gate |
//! |---|---|---|
//! | `flowfabric::core` | `ff_core` | always |
//! | `flowfabric::sdk` | `ff_sdk` | always |
//! | `flowfabric::valkey` | `ff_backend_valkey` | `valkey` (default) |
//! | `flowfabric::postgres` | `ff_backend_postgres` | `postgres` |
//! | `flowfabric::engine` | `ff_engine` | `engine` |
//! | `flowfabric::scheduler` | `ff_scheduler` | `scheduler-internals` |
//! | `flowfabric::script` | `ff_script` | `script-internals` or `valkey` |
//!
//! The [`prelude`] module glob-re-exports the 80% path
//! (`flowfabric::sdk::*`), which already flattens the most-used
//! `ff_core::contracts` and `ff_core::backend` types via `ff-sdk`'s
//! own `pub use`. Consumers needing scheduler/engine types should
//! enable the respective feature flag and reach through
//! `flowfabric::engine::…` / `flowfabric::scheduler::…` explicitly.
pub use ff_core as core;
pub use ff_sdk as sdk;
pub use ff_backend_valkey as valkey;
pub use ff_backend_postgres as postgres;
pub use ff_engine as engine;
pub use ff_scheduler as scheduler;
// `ff_script` is pulled in by either the `script-internals` opt-in or
// transitively by the default `valkey` feature (valkey-default's
// FCALL path depends on it). Either way, re-expose it at
// `flowfabric::script` so consumers don't have to guess which flag
// to toggle.
pub use ff_script as script;
/// Prelude — convenience glob re-export of the most-used SDK surface.
///
/// `ff_sdk` already re-exports the common `ff_core::contracts` and
/// `ff_core::backend` types (e.g. `ClaimGrant`, `FailOutcome`,
/// `ResumeSignal`, `SummaryDocument`), so a single
/// `use flowfabric::prelude::*;` covers the 80% consumer code path.
///
/// Scheduler/engine/backend types are intentionally NOT flattened
/// here — consumers that need them enable the feature flag and
/// reach through the qualified path (`flowfabric::engine::…`,
/// `flowfabric::scheduler::…`, `flowfabric::valkey::…`). This keeps
/// prelude imports stable across feature-flag configurations.