This directory provides a reusable fixture and end-to-end coverage for composed systems. The fixture deploys a two-node queue, a two-node result store, and a worker process that consumes queued jobs and records their completion:

workload -> queue -> worker -> result store -> expectation

The local happy-path test drives the fixture through a scenario:

let mut scenario = AppHost::scenario()
    .with_app(JobStackApp::new())
    .with_workload(EnqueueJobs::new(10))
    .with_expectation(AllJobsCompleted::new(10))
    .build()?;

multi-app-fixture owns the stack definition. It deploys child apps, exposes their typed handles, and returns a composed stack handle:

let queue = ctx.deploy_and_expose(self.queue).await?;
let results = ctx.deploy_and_expose(self.results).await?;
let worker = ctx
    .deploy_and_expose(JobWorkerApp::new(queue_url, results_url))
    .await?;

let stack = JobStackHandle { queue, results, worker };
ctx.expose(stack.clone())?;

Workloads, expectations, and later lifecycle tests request the composed handle:

let stack = ctx.require_app::<JobStackHandle>()?;

The worker is part of the deployed system, rather than test code moving data between otherwise unrelated applications. It lives in the multi-app-job-worker crate, receives the queue and result-store endpoints from the parent deployment, and is started through LocalProcessApp. Reverse cleanup stops the worker before either dependency.

Resource lifecycle comes from the TF adapter used by a child deployment:

LocalProcessApp manages one local binary process.
LocalAppCluster manages a uniform local cluster.

Attached and external sources are not registered again at the app layer. The outer scenario resolves them through its existing source providers, and the app deployment receives the resulting node clients and control profile through DeployContext. When the active deployer provides node control or cluster readiness, the same handles are available through DeployContext::node_control and DeployContext::cluster_wait; the app layer does not create replacements.

Managed adapters register cleanup during deployment. Cleanup runs in reverse acquisition order and does not depend on the last handle clone being dropped. An app-specific deployment only describes composition; it does not implement a second lifecycle interface.

For a single uniform cluster, the core ScenarioBuilder<AppEnv> flow remains valid. For composed systems, prefer this app-layer shape instead of building a fake outer cluster or adding app-specific code to TF.

Run the local end-to-end test from the workspace root:

cargo test -p multi-app-e2e --test local_happy_path