Module server 

HTTP server wiring — composes the workflow API + dashboard + auth routers into one axum Router. URL surface:

• /auth/* OIDC spec (discovery, authorize, token, …)
• /api/v1/engine/core/* engine-core admin (admin-bearer-gated)
• /api/v1/engine/workflow/* workflow API (admin-bearer-gated)
• /api/v1/engine/auth/* engine-internal auth + admin
• /api/v1/vault/* vault module (admin-bearer-gated)
• /healthz redirect to /api/v1/engine/core/health

Per the decoupled-modules architecture: each module accepts ONLY an admin bearer token at its HTTP boundary. Per-user authentication and policy decisions live upstream of the engine — typically in a dashboard / BFF / API gateway that validates the user session, asks zanzibar if they’re allowed, and then forwards the call to the engine using its own admin bearer. The engine itself does not resolve sessions or check zanzibar at request time.

Share-redeem (GET /api/v1/vault/share/{token}) is the one route that bypasses admin bearer — the biscuit token in the URL is its own auth, verified inside the handler.

Functions

bind_and_serve

Bind a TCP listener on bind_addr and serve a pre-built axum::Router.

build_app

Compose the full axum::Router for the engine.

build_workflow_ctx

Start a WorkflowCtx around the given store. Authentication + authorization are no longer the workflow’s concern — the engine wraps the workflow router with a gate middleware (build_app) that handles all of that.

build_workflow_ctx_with_bus

Like build_workflow_ctx but also wires the engine-wide event bus into the workflow context so SSE + the dispatch-wakeup loop see state transitions.

serve

Bind a TCP listener on bind_addr and serve the composed app.