aspire

# Aspire ## Trigger On - `Aspire.AppHost.Sdk`, `Aspire.Hosting.*`, `DistributedApplication.CreateBuilder`, `apphost.mts`, `createBuilder`, `WithReference`, `WaitFor`, `AddProject`, `addNodeApp`, `addViteApp`, `AddRedis`, `AddPostgres`, `aspire run`, `aspire init`, `aspire add`, or `aspire update` - `Aspire.Hosting.Testing`, `DistributedApplicationTestingBuilder`, or a test harness that mixes an Aspire AppHost with `WebApplicationFactory` - orchestrating multiple services and resources with an AppHost for local development or cloud deployment - setting up `ServiceDefaults`, service discovery, OpenTelemetry, health checks, or the Aspire Dashboard - choosing between official first-party Aspire integrations and `CommunityToolkit/Aspire` - upgrading older 8.x or 9.x Aspire solutions to the current CLI and AppHost SDK model - wiring polyglot services into an Aspire topology, especially when Go, Bun, Java, Python, or extra dev-time tools enter the picture ## Workflow 1. Classify the task first: new AppHost creation, existing-solution enlistment, integration wiring, testing and observability, deployment, or version upgrade. 2. Prefer the current Aspire toolchain. Choose a C# AppHost for .NET-first repositories or a TypeScript `apphost.mts` for JavaScript/TypeScript-first repositories; both are first-class in 13.4. Use the Aspire CLI and current SDK-generated app model instead of writing new guidance around the deprecated legacy workload. 3. Treat 13.4.x releases as servicing and ...