Expand description
TaskInputMiddleware — a SpawnerLayer that propagates task-level
execution context (project_root / work_dir / task_metadata) into
Ctx.meta.runtime.
Issue #19 ST2: these three fields are canonical Task-level data, kept
independent of init_ctx (the flow.ir initial ctx value, a pure eval
seed). crate::service::task_launch::TaskLaunchService::launch reads
them off crate::service::task_launch::TaskLaunchInput::task_input
(a crate::service::task_launch::TaskInputSpec) and builds this layer
via [Self::new_from_fields], layering it onto the spawner stack only
when at least one field is present — mirroring the
crate::middleware::project_name_alias::ProjectNameAliasMiddleware /
crate::middleware::worker_binding::WorkerBindingMiddleware
conditional-layering convention. Resolving task_input itself — sibling
body field first, falling back to the legacy shape where these three
keys were nested directly inside init_ctx — happens once at the wire
boundary (mlua-swarm-server’s run_flow_form), not here; see
[Self::from_init_ctx] for the now-deprecated constructor that used to
do that extraction inline.
Downstream Operator / Spawner code (for example mlua-swarm-server’s
Operator::execute) reads the injected keys back via
ctx.meta.runtime.get(...) the same way it reads worker_binding /
project_name_alias — splicing them into the SubAgent’s Spawn
directive prompt is a downstream concern, out of scope here.
§Pattern
Same shape as ProjectNameAliasMiddleware: a task-wide (not per-agent)
value set once at launch time and inserted into every spawn’s ctx,
unconditionally (no ctx.agent lookup — unlike WorkerBindingMiddleware,
which is keyed by agent name).
Re-exports§
pub use crate::core::agent_context::TASK_PROJECT_ROOT_KEY;pub use crate::core::agent_context::TASK_WORK_DIR_KEY;pub use crate::core::agent_context::TASK_METADATA_KEY;
Structs§
- Task
Input Middleware SpawnerLayerthat drops task-level execution context (project_root/work_dir/task_metadata) intoctxjust before spawn.