CoreEx: Subscribe to a Command (End-to-End)

Guides you through making a domain receive and act on a command: the contract it owns, the handler, the dedicated command-queue receiver in the Subscribe host, the broker topology, the tests and the Aspire E2E — all context gathered once.

Events vs Commands — decide first

	Event subscriber (coreex-subscriber-e2e)	Command subscriber (this skill)
Source	Shared topic, this domain's subscription	This domain's queue {Destination}-{this-domain} (e.g. contoso-products)
Contract owner	The publisher	This domain — it defines subject + payload; publishers conform
Host wiring	Receiver receiver-events → subscriber-events → hosted-subscriber-events	Second receiver receiver-commands → subscriber-commands → hosted-subscriber-commands
Failure semantics	Usually tolerant (other domains' events you don't care about are ignored)	Explicit ErrorHandler for expected business outcomes; never silently drop a command

A domain never subscribes to another domain's command queue. If the message is addressed to someone else, stop.

When to Use

• "Products must handle a reservation confirm command sent by Shopping"
• Adding a command handler to a Subscribe host that already handles events (or has no command queue yet)
• The developer wants contract + handler + wiring + topology + tests + Aspire in one pass

When Not to Use

• Reacting to an event — coreex-subscriber-e2e
• Sending a command — coreex-command-publish-e2e
• Creating the Subscribe host itself — coreex-scaffold

Workflow Overview

1. Read Feature Configuration — messaging-provider, data-provider (SqlServer / Postgres / Cosmos / None), rop-enabled, outbox-enabled.
2. Inspect the host — is the existing event receiver already keyed? Is there already a command receiver? (Retrofit rules in the workflow.)
3. Interview — command shape, action, persistence, publisher location; one batched turn.
4. Execute L1 sequence (table below).
5. Host wiring + topology + tests + Aspire.
6. Validate — build, Subscribe tests, report.

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

L1 Sequence

Step	Skill	Condition
1	`coreex-contract`	Only if the command carries a payload (a key-only command needs no contract)
2	`coreex-db-migration` + `coreex-repository`	Only if the command persists new state (data-provider ≠ None)
3	`coreex-validator` / `coreex-policy`	Only if the payload/state needs validating
4	`coreex-app-service`	Always — the action the command triggers
5	`coreex-subscriber`	Always — [Subscribe("{parent}.{this-domain}.{entity}.{action}[.v1]")]
6	(inline — host wiring + topology)	Always — command receiver in Program.cs; queue in Test.Common ServiceBus
7	`coreex-test-subscribe`	Always — keyed subscriber-commands tests
8	`coreex-aspire`	When an aspire/ folder exists

Key References

• `/.github/instructions/coreex-event-subscribers.instructions.md` — subscriber conventions, keyed receivers, subject naming
• `/.github/instructions/coreex-host-setup.instructions.md` — Subscribe host Program.cs
• `/.github/instructions/coreex-tests.instructions.md` — Subscribe test conventions
• `/.github/instructions/coreex-aspire.instructions.md` — Aspire wiring
• Illustrative examples (CoreEx sample — not present in your project): `ReservationConfirmSubscriber`, Products.Subscribe `Program.cs` (two keyed receivers)