Module task_launch 

TaskLaunchService — the domain service that runs a Blueprint flow to completion through the engine.

Responsibilities:

1. Compile the Blueprint and link it into a SpawnerAdapter (via service::linker::link, wrapped by EngineDispatcher::with_spawner).
2. Acquire an Operator session (via engine.attach).
3. Run flow.ir’s eval_async_externs through an EngineDispatcher (threading the service-held call_extern registry) and return the final ctx.
4. If any step fails (dispatcher error), the eval errors and the failure propagates as-is.

Callers on the Application layer never touch the engine directly — bind, start_task, and eval_async all stay inside the Service.

A single-task-spawn API (calling start_task directly) is deliberately absent here: a single spawn can be modeled as a one-Step flow, and we do not want two interfaces for the same shape.

Structs

TaskInputSpec

Canonical bag of Task-level fields (project_root / work_dir / task_metadata) — TaskLaunchInput::task_input’s type.

TaskLaunchInput

Input to TaskLaunchService::launch.

TaskLaunchOutput

Result of a successful TaskLaunchService::launch call.

TaskLaunchService

Domain service that compiles, links, and runs a Blueprint’s flow to completion through the Engine. See the module doc for the full responsibility list.

Enums

TaskLaunchError

Failure modes of TaskLaunchService::launch.

Functions

merge_init_ctx_3layer

Issue #19 ST4: 3-layer shallow-merge of the init-ctx cascade — BP default → Task → Run (lowest to highest priority). Built by chaining [merge_init_ctx] twice rather than introducing a distinct 3-way merge algorithm, so the Run layer inherits exactly the same “shallow Object merge, non-Object fully replaces” rule [merge_init_ctx] already established for the BP/Task pair (see its doc for the full semantics).