[docs] Use aspire destroy in deployment cleanup tutorials

src/frontend/src/content/docs/deployment/azure/container-apps.mdx

@@ -325,14 +325,14 @@ After deployment, use the dashboard URL in the CLI output, the Azure portal, or
 
 ## Clean up resources
 
-To remove deployed resources, delete the resource group:
+To tear down deployed resources, use `aspire destroy`. The command discovers the deployment, lists the Azure resources it will remove, and prompts for confirmation before deleting the resource group:
 
-```bash title="Delete resource group"
-az group delete --name <resource-group-name>
+```bash title="Aspire CLI - Destroy the deployed environment"
+aspire destroy
 ```
 
 :::danger
-This command deletes all resources in the resource group, including any resources not created by the Aspire CLI.
+`aspire destroy` deletes the entire resource group, including any resources that weren't created by the Aspire CLI. Pass `--yes` only in automated or CI scenarios where you've already validated what will be removed. This action cannot be undone.
 :::
 
 ## See also

src/frontend/src/content/docs/deployment/docker-compose.mdx

@@ -149,13 +149,19 @@ Aspire provides a progressive deployment workflow for Docker Compose, allowing y
 
 ### Clean up deployment
 
-To stop and remove a running Docker Compose deployment, use the `aspire do docker-compose-down-{resource-name}` command:
+To stop and remove a running Docker Compose deployment, use the `aspire destroy` command:
 
 ```bash title="Terminal"
-aspire do docker-compose-down-env
+aspire destroy
 ```
 
-This command stops and removes all containers, networks, and volumes created by the Docker Compose deployment.
+The command shows the resources that will be removed and prompts for confirmation. Once confirmed, it stops and removes all containers, networks, and volumes created by the Docker Compose deployment.
+
+<Aside type="caution">
+  `aspire destroy` permanently removes the deployed containers, networks, and
+  volumes. This action cannot be undone. Pass `--yes` only in automated or CI
+  scenarios where you've already validated what will be removed.
+</Aside>
 
 ## Multi-environment deployments
 

src/frontend/src/content/docs/deployment/pipelines.mdx

@@ -434,24 +434,13 @@ For complete command reference, see [aspire do command](/reference/cli/commands/
 
 ### Discovering available steps
 
-Before executing pipeline steps, you can discover what steps are available using the `diagnostics` step:
+Before executing pipeline steps, you can discover what steps would run for a given command using the `--list-steps` flag. Every pipeline command (`aspire deploy`, `aspire publish`, `aspire destroy`, and `aspire do`) accepts it:
 
 ```bash title="Aspire CLI — Discover pipeline steps"
-aspire do diagnostics
+aspire deploy --list-steps
 ```
 
-This command displays:
-- All available steps and their dependencies.
-- Execution order with parallelization indicators.
-- Step dependencies and target resources.
-- Configuration issues like orphaned steps or circular dependencies.
-
-The output includes several sections:
-
-- **Execution order**: A numbered list showing the order in which steps would execute
-- **Detailed step analysis**: Each step's dependencies, associated resources, tags, and descriptions (✓ = dependency exists, ? = dependency missing)
-- **Potential issues**: Identifies problems like orphaned steps or circular dependencies
-- **Execution simulation**: "What if" analysis showing what steps would run for each possible target step, with concurrency indicators for steps that can run in parallel
+This lists the pipeline steps that would be executed by the chosen command, in execution order, without running them. Pair `--list-steps` with the command you intend to run (for example, `aspire publish --list-steps` or `aspire do build --list-steps`) to see exactly which steps a given invocation would trigger.
 
 ## Custom pipeline steps
 
@@ -669,7 +658,7 @@ Follow these steps to replace your Aspire 9.x publishing code with Aspire 13.x p
 1. **Identify publishing callbacks** in your code that use `WithPublishingCallback`.
 2. **Convert callbacks to pipeline steps** using `WithPipelineStepFactory` or `builder.Pipeline.AddStep`.
 3. **Update dependencies** with parameters or properties. When using `builder.Pipeline.AddStep`, configure dependencies with the `dependsOn` / `requiredBy` parameters. When creating `PipelineStep` instances directly, use the `DependsOn` and `RequiredBySteps` properties.
-4. **Test the migration** using `aspire do diagnostics` and `aspire do deploy`.
+4. **Test the migration** using `aspire deploy --list-steps` and `aspire deploy`.
 
 </Steps>
 
@@ -793,13 +782,13 @@ builder.Pipeline.AddStep("smoke-tests", async (context) =>
 
 The pipeline system provides several advantages over publishing callbacks:
 
-- **Better visibility**: Use `aspire do diagnostics` to see all steps and their dependencies.
+- **Better visibility**: Use `aspire deploy --list-steps` to see all steps that would run for a deploy and the order they'd run in.
 - **Selective execution**: Run specific steps with `aspire do <step-name>`.
 - **Parallel execution**: Independent steps run concurrently automatically.
 - **Clearer dependencies**: Explicit dependency declaration with `DependsOn` and `RequiredBySteps`.
 - **Better error handling**: Failed steps don't block unrelated operations.
 - **Reusability**: Steps can be reused across different deployment scenarios.
 
 <Aside type="tip">
-After migrating, use `aspire do diagnostics` to verify that your pipeline steps are correctly configured and that dependencies are properly declared.
+After migrating, use `aspire deploy --list-steps` to verify that your pipeline steps are correctly configured and that dependencies are properly declared.
 </Aside>

src/frontend/src/content/docs/get-started/deploy-first-app.mdx

@@ -297,7 +297,7 @@ In the AppHost, chain a call to the appropriate environment API method to config
 </Tabs>
 
 <Aside type="tip" title="CLI protip" icon="forward-slash">
-After installing a new deployment package, you can run `aspire do diagnostics` in your terminal to see the available deploy steps. For more information, see the [aspire do diagnostics](/reference/cli/commands/aspire-do/) reference docs.
+After installing a new deployment package, you can run `aspire deploy --list-steps` in your terminal to see the pipeline steps that would be executed for the deploy. For more information, see the [aspire deploy](/reference/cli/commands/aspire-deploy/) reference docs.
 </Aside>
 
 </Pivot>
@@ -368,7 +368,7 @@ In the AppHost, chain a call to the appropriate environment API method to config
 </Tabs>
 
 <Aside type="tip" title="CLI protip" icon="forward-slash">
-  After installing a new deployment package, you can run `aspire do diagnostics` in your terminal to see the available deploy steps. For more information, see the [aspire do diagnostics](/reference/cli/commands/aspire-do/) reference docs.
+  After installing a new deployment package, you can run `aspire deploy --list-steps` in your terminal to see the pipeline steps that would be executed for the deploy. For more information, see the [aspire deploy](/reference/cli/commands/aspire-deploy/) reference docs.
 </Aside>
 
 </Pivot>
@@ -1135,22 +1135,18 @@ To verify that your application is running as expected after deployment, follow
 
 After deploying your application, it's important to clean up resources to avoid incurring unnecessary costs or consuming local system resources.
 
-<Tabs syncKey="deploy-target">
-    <TabItem id="docker-compose" label="Docker Compose">
-        To clean up resources after deploying with Docker Compose, you can stop and remove the running containers using the following command:
+Use `aspire destroy` to tear down the deployed environment. The command discovers the deployment, shows what will be removed, and prompts for confirmation before continuing.
 
-        ```bash title="Aspire CLI - Stop and remove containers"
-        aspire do docker-compose-down-env
-        ```
-    </TabItem>
-    <TabItem id="azure" label="Azure">
-        To clean up resources after deploying to Azure, you can use the Azure CLI to delete the resource group that contains your application. This will remove all resources within the resource group.
+```bash title="Aspire CLI - Destroy the deployed environment"
+aspire destroy
+```
 
-        ```bash title="Azure CLI - Delete resource group"
-        az group delete --name <RESOURCE_GROUP_NAME> --yes --no-wait
-        ```
-    </TabItem>
-</Tabs>
+<Aside type="caution">
+  `aspire destroy` permanently removes deployed resources. For Azure
+  deployments it deletes the entire resource group and everything in it; for
+  Docker Compose it stops and removes the running containers, networks, and
+  volumes. This action cannot be undone.
+</Aside>
 
 <LearnMore>
 For a deep-dive into the related foundational concepts, see [Pipelines and app topology](/deployment/pipelines/).
@@ -1163,23 +1159,18 @@ You've just built your first Aspire app and deployed it to production. Now you m
 
 After deploying your application, it's important to clean up resources to avoid incurring unnecessary costs or consuming local system resources.
 
-<Tabs syncKey="deploy-target">
-    <TabItem id="docker-compose" label="Docker Compose">
-        To clean up resources after deploying with Docker Compose, you can stop and remove the running containers using the following command:
-
-        ```bash title="Aspire CLI - Stop and remove containers"
-        aspire do docker-compose-down-env
-        ```
-    </TabItem>
-    <TabItem id="azure" label="Azure">
-        To clean up resources after deploying to Azure, you can use the Azure CLI to delete the resource group that contains your application. This will remove all resources within the resource group.
+Use `aspire destroy` to tear down the deployed environment. The command discovers the deployment, shows what will be removed, and prompts for confirmation before continuing.
 
-        ```bash title="Azure CLI - Delete resource group"
-        az group delete --name <RESOURCE_GROUP_NAME> --yes --no-wait
-        ```
-    </TabItem>
+```bash title="Aspire CLI - Destroy the deployed environment"
+aspire destroy
+```
 
-</Tabs>
+<Aside type="caution">
+  `aspire destroy` permanently removes deployed resources. For Azure
+  deployments it deletes the entire resource group and everything in it; for
+  Docker Compose it stops and removes the running containers, networks, and
+  volumes. This action cannot be undone.
+</Aside>
 
 <LearnMore>
   For a deep-dive into the related foundational concepts, see [Pipelines and app topology](/deployment/pipelines/).

src/frontend/src/content/docs/reference/cli/commands/aspire-do.mdx

@@ -89,16 +89,17 @@ The following options are available:
 
 ## Discovering available steps
 
-Before executing a pipeline step, you can discover what steps are available in your application's pipeline and understand their dependencies using the `diagnostics` step.
+Before executing a pipeline step, you can discover which steps would run for a given command and understand their dependencies using the `--list-steps` flag.
 
 ### Understanding pipeline structure
 
-The `aspire do diagnostics` command provides comprehensive information about your pipeline, including:
+Running any pipeline command with `--list-steps` lists the steps that would execute, in order, without actually running them:
 
-- All available steps and their dependencies
-- Execution order with parallelization indicators
-- Step dependencies and target resources
-- Configuration issues like orphaned steps or circular dependencies
+```bash title="Aspire CLI"
+aspire do --list-steps
+```
+
+`--list-steps` is supported by every pipeline command (`aspire deploy`, `aspire publish`, `aspire destroy`, and `aspire do`), so you can scope the listing to a specific operation — for example, `aspire deploy --list-steps` shows only the steps required to deploy.
 
 This is particularly useful after installing a deployment package or when you want to understand which steps will execute for a given command.
 
@@ -120,10 +121,10 @@ The following examples demonstrate common pipeline operations:
 - Examine the pipeline structure and available steps:
 
   ```bash title="Aspire CLI"
-  aspire do diagnostics
+  aspire do --list-steps
   ```
 
-  This displays all steps in your pipeline, their dependencies, and execution order. Use this to understand what steps are available and how they relate to each other.
+  This lists the pipeline steps that would run, in execution order, without running them. Pair `--list-steps` with the command you intend to run (for example, `aspire deploy --list-steps`) to see exactly which steps a given invocation would trigger.
 
 - Build container images for your application:
 

src/frontend/src/content/docs/whats-new/aspire-13.mdx

@@ -1304,7 +1304,7 @@ This enables incremental deployments, debugging specific steps, and CI/CD pipeli
 
 **Pipeline diagnostics:**
 
-Use `aspire do diagnostics` to understand your pipeline graph, view execution order with parallelization indicators, see step dependencies and resources, simulate "what if" scenarios, and detect configuration issues like orphaned steps or circular dependencies.
+Use the `--list-steps` flag (available on `aspire deploy`, `aspire publish`, `aspire destroy`, and `aspire do`) to inspect the pipeline that would run for a given command — including step order, dependencies, and the resources each step targets — without actually executing it.
 
 **Benefits:**