Fantasia 🪄
Fantasia is a concurrent workflow orchestrator for Elixir. Inspired by the Python stokowski library, Fantasia brings robust task orchestration to the BEAM, allowing you to define, manage, and execute complex dependency graphs with fault tolerance and speed.
While Python is great, orchestrating I/O-bound tasks, concurrent workflows, and complex dependency trees is where the BEAM truly shines. Fantasia leaves the GIL behind to give you:
- True Concurrency
-
Thousands of lightweight processes running side-by-side without breaking a sweat.
- Frictionless Pipelines
-
Define your orchestration flow using standard Elixir pipe operators (|>) for clean, readable execution graphs.
- Robust State Handling
-
Granular control over task success and failure states using deep pattern matching, ensuring that a single node failure doesn’t bring down your entire orchestration pipeline unless you want it to.
- Supervision Trees
-
Built-in fault tolerance. If a worker process crashes, Fantasia knows exactly how to restart it.
Fantasia will use Continuum as the execution boundary around each deterministic workflow stage. One issue maps to one Continuum workflow run. Investigation, implementation, review, merge, Linear updates, Git operations, and LLM calls execute as activities, while the workflow graph alone decides which stage runs next. Model output remains data rather than control flow.
Continuum journals workflow decisions and activity results so the same history can be replayed through the same orchestration code. With its PostgreSQL journal, a process or node may stop in the middle of a long-running issue and another process can reconstruct the run, recover the last durable boundary, and continue without guessing from terminal output. Human approvals, rework requests, and other external events arrive as durable signals, allowing a workflow to wait safely for hours or days.
This gives Fantasia deterministic recovery, auditable stage histories, controlled activity retries, and replay tests that catch incompatible workflow changes. External effects still require stable idempotency keys and reconciliation because an API call cannot always be made exactly once.
The initial compatibility release will use Continuum’s in-memory journal while Linear tracking comments remain the cross-restart recovery authority. PostgreSQL-backed durability will be an opt-in mode after the no-database workflow reaches parity.
Initialize the submodules and install the toolchain pinned in the root mise.toml, then prepare the umbrella from the repository root:
git submodule update --init --recursive
mise install
mise exec -- mix setupADR 0008 records the current toolchain refresh and its relationship to the historical compatibility evidence.
Validate the Phase 0 contracts and build the unpublished checkout-independent artifact:
mise exec -- mix phase0.verifyThe verification builds a BEAM escript, copies it to a temporary directory outside the checkout,
and requires it to report the canonical version from .version.txt. The artifact requires a
compatible Erlang runtime; native standalone packaging is intentionally deferred by ADR 0005.
Compatibility behavior and its provenance are indexed by
apps/stokowski/test/fixtures/compatibility_ledger.yaml; normative decisions live under
documents/decisions/.
The ledger and runner fixtures retain the versions that produced their historical evidence.
The root mise.toml selects the current installed tools, and the launcher verifies each
configured runner against those pins. For runner updates, refresh provenance and capability
evidence together with the pin or record an explicit superseding compatibility decision;
ADR 0008 covers Codex 0.155.1
and Claude Code 2.1.276 without relabeling the Phase 0 fixtures.