CoreEx: Aspire Wiring & E2E

Makes a code change visible and testable in the Aspire environment: AppHost resources and references, MockHost stubs for anything outside the AppHost, the code-based Service Bus topology, and a cross-host E2E test. Aspire is where inter-domain dependencies are real — everything intra-domain tests deliberately mock is exercised here.

When to Use

• A new Api / Relay / Subscribe host must join the AppHost
• A change introduces a Service Bus queue (e.g. a command queue) that the E2E topology must create
• A new queue/topic needs session requirements or a destination-specific producer session profile
• A host now calls another domain's HTTP API (needs service discovery) or a third-party API (needs a MockHost stub)
• A cross-host flow needs an automated E2E test (*.Test.Aspire)
• Invoked by `coreex-command-publish-e2e` and `coreex-command-subscribe-e2e` for their final step

When Not to Use

• Running / stopping / inspecting a live AppHost (logs, traces, resource status) — use the aspire skill
• Intra-domain tests — coreex-test-api, coreex-test-subscribe, coreex-test-relay
• Generating the AppHost for the first time — coreex-scaffold (dotnet new coreex-aspire)
• Writing the typed HTTP client / adapter — coreex-adapter (this skill only wires it into Aspire)

Resolve project-wide choices from state before asking. Read the solution-root AGENTS.md Feature Configuration
(data-provider, messaging-provider, outbox-enabled) and inspect the existing *.Aspire/AppHost.cs, *.Aspire.MockHost
and *.Test.Aspire before interviewing. Re-state resolved values for confirmation.

The Deciding Question — where does the callee live?

Callee	Mechanism	Stub in Test.Aspire?
Another domain in the same AppHost	.WithReference(calleeApi) on each caller + BaseAddress = https+http://{resource-name}	No — real call
A third-party API	MockHost + .WithMockHostEnvironment("Section__BaseAddress", mockhost, "http")	Yes — app.HttpMock(...) in OnAfterStartAsync
Another domain outside this AppHost	Same as third-party	Yes

Get this wrong and the E2E either hides a real integration (stubbing an in-AppHost domain) or hits the internet (not stubbing a third party).

Workflow Overview

1. Inspect — read AppHost, MockHost, Test.Aspire, Test.Common ServiceBus, the calling host's Program.cs + appsettings.Development.json.
2. Interview — what changed; where each callee lives; which async effect the E2E should prove.
3. AppHost — add/adjust visible external resources via CoreEx.UnitTesting's AddExternalConnectionString, AddProject + WithReference (+ ProjectReference); service-discovery BaseAddress; MockHost wiring.
4. Topology — add queues/topics/subscriptions to the ServiceBus class used by Test.Aspire (union class if multi-domain); mark session-enabled entities with RequiresSession = true and check the producer's exact destination-specific session profile.
5. Test.Aspire — OnBeforeStartAsync (migrate, cache, broker reset) / OnAfterStartAsync (wait, stubs); E2E test with bounded polling.
6. Validate — dotnet build the AppHost + Test.Aspire; dotnet test when infrastructure is up.

For step-by-step guidance see `references/workflow.md`.

Key References

• `/.github/instructions/coreex-aspire.instructions.md` — AppHost / MockHost / Test.Aspire invariants
• `/.github/instructions/coreex-tests.instructions.md` — intra-domain test conventions (what Aspire deliberately does not re-cover)
• `/.github/instructions/coreex-host-setup.instructions.md` — AddTypedHttpClient, receivers, Program.cs
• Related skills: `coreex-adapter` (typed HTTP client), `coreex-scaffold` (AppHost scaffold)
• Aspire & End-to-End — optional (after /coreex-docs-sync)
• Illustrative examples (CoreEx sample — not present in your project): `AppHost.cs`, `E2ETest.cs`, `ServiceBus.cs`