fix: use .csproj project references in TypeScript apphost aspire.config.json

.agents/skills/aspire/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: aspire
+description: "Use this skill when the user is working with an Aspire distributed application and needs to operate the AppHost or its resources through the Aspire CLI: start, restart, stop, or wait on the app; inspect resources, logs, traces, docs, or health; add integrations; manage secrets or config; publish, deploy, or rerun a named pipeline step; initialize Aspire in an existing app; recover missing `.modules` files in a TypeScript AppHost; discover the right frontend URL for Playwright from Aspire state; expose custom dashboard/resource commands; or understand unfamiliar Aspire AppHost APIs in C# or TypeScript. Use it even if they describe the task in terms of an AppHost, resources, dashboard, existing app bootstrap, missing generated modules, Playwright URL discovery, C# API understanding, or local distributed app workflow without explicitly naming Aspire. Do not use it for non-Aspire .NET apps, container-only repos with no AppHost, or ordinary build and test tasks."
+---
+
+# Aspire Skill
+
+Use this skill when the task is about operating an Aspire distributed application through the Aspire CLI rather than falling back to ad-hoc `dotnet`, `docker`, or shell workflows.
+
+Resources are typically defined in an AppHost such as, `AppHost.cs`, `apphost.ts`, or `AppHost/AppHost.csproj (Program.cs)`.
+
+## Use this skill for
+
+- Starting, restarting, and stopping AppHosts with `aspire start` and `aspire stop`
+- Initializing Aspire in an existing app with `aspire init` (drops skeleton files; use the `aspireify` skill to complete wiring)
+- Inspecting resources, logs, traces, and docs
+- Adding integrations with `aspire add`
+- Recovering missing TypeScript AppHost support files with `aspire restore`
+- Discovering the correct frontend URL before a Playwright handoff
+- Understanding unfamiliar Aspire AppHost APIs before editing C# or TypeScript AppHosts
+- Managing AppHost secrets and CLI config
+- Publishing and deploying Aspire apps, including single named steps with `aspire do`
+- Adding custom dashboard or resource commands with docs-backed AppHost patterns
+
+## Do not use this skill for
+
+- Non-Aspire .NET applications
+- Container-only workflows that do not involve an Aspire AppHost
+- Replacing normal build and test commands when the task is just compiling code or running unit tests
+
+## Default workflow
+
+1. Confirm that the workspace is an Aspire app and identify the AppHost.
+2. Start the app with `aspire start`. Use `--isolated` in git worktrees or whenever shared local state would be risky.
+3. Use `aspire wait <resource>` before interacting with a resource that needs to be healthy.
+4. Inspect state with `aspire describe`, then use `aspire otel logs`, `aspire logs`, `aspire otel traces`, and `aspire export` before making code changes. Display returned data using the formatting rules in [references/monitoring.md](references/monitoring.md).
+5. Before adding an integration, introducing a custom dashboard/resource command, or using an unfamiliar AppHost API, use `aspire docs search <topic>` and `aspire docs get <slug>` for workflow guidance, then use `aspire docs api search <query> --language csharp|typescript` and `aspire docs api get <id>` when you need the API reference entry itself.
+6. Re-run `aspire start` after AppHost changes. In git worktrees, re-run `aspire start --isolated` instead of switching to `aspire run`.
+
+## C# AppHosts
+
+When the AppHost is implemented in C# such as `AppHost.cs`, `apphost.cs`, or a `Program.cs`-based AppHost, use Aspire docs for workflow guidance and Aspire API docs for the reference entry before editing.
+
+- Use `aspire docs search <topic>` and `aspire docs get <slug>` when you need the documented workflow or pattern.
+- Use `aspire docs api search <query> --language csharp` and `aspire docs api get <id>` when you need the C# API reference entry for a resource builder, extension method, or member.
+- If the `dotnet-inspect` skill is available, use it to inspect local C# APIs, overloads, and builder chains when you need help understanding how the API surface is exposed in code.
+- Keep `dotnet-inspect` scoped to understanding APIs and symbols; use Aspire docs for the documented workflow and recommended pattern.
+
+## TypeScript AppHosts
+
+When the AppHost is `apphost.ts`, the `.modules/` folder at the project root contains generated TypeScript modules that expose the Aspire APIs available to the AppHost. Common files include `.modules/aspire.ts`, `base.ts`, and `transport.ts`.
+
+- Do not edit `.modules/` directly.
+- Use `aspire add <package>` to add integrations and regenerate the available APIs.
+- Inspect `.modules/aspire.ts` after `aspire add` to see the refreshed API surface.
+- The local `tsconfig.json` often includes `.modules/**/*.ts` in its compilation scope.
+
+## Key rules
+
+- Prefer `aspire start` over `dotnet run` for AppHosts. `aspire run` blocks the terminal and is a poor fit for agent workflows.
+- Re-running `aspire start` is the restart path. In git worktrees, `aspire start --isolated` is both the start and restart command. Do not combine `aspire stop` and `aspire run`.
+- Use `--apphost <path>` when the workspace has multiple AppHosts or discovery is ambiguous.
+- Use `--format Json` when another tool or script needs machine-readable output.
+- Do not guess the integration or command shape for unfamiliar AppHost changes. Use `aspire docs search` and `aspire docs get` for the documented pattern, then use `aspire docs api search` and `aspire docs api get` when you need the specific reference entry.
+- For unfamiliar C# AppHost APIs, use Aspire API docs as the primary reference and, if available, use `dotnet-inspect` only to inspect local symbols, overloads, and builder chains.
+- Never install the obsolete Aspire workload.
+- When a TypeScript AppHost uses `.modules/`, do not edit generated files directly. Use `aspire add` to regenerate APIs and inspect `.modules/aspire.ts` afterward.
+- Prefer official docs from `aspire.dev`.
+
+## Common capabilities
+
+- Use `aspire ps` when you need to discover running AppHosts before targeting one.
+- Use `aspire update` when the task is to refresh AppHost package references through the supported CLI workflow.
+- Use `aspire doctor` as an early diagnostics step when the local Aspire environment looks unhealthy.
+- Use `aspire resource`, `aspire secret`, `aspire config`, `aspire publish`, `aspire deploy`, and `aspire do` when the objective is resource operations, secrets/config management, or deployment.
+- Use `aspire restore`, `aspire cache clear`, `aspire certs trust`, and `aspire certs clean` when the task is local environment maintenance or recovery.
+
+## Playwright CLI
+
+If Playwright CLI is already configured in the environment, use Aspire first to discover the running app and its endpoints, especially when multiple frontends exist. Prefer `aspire describe --format Json` when the handoff needs to be scriptable or you need to disambiguate which frontend URL Playwright should use, then hand browser testing off to Playwright CLI.
+
+## References
+
+- For app-level lifecycle, bootstrap, and AppHost-wide commands, see [references/app-commands.md](references/app-commands.md).
+- For waiting on and operating on individual resources, see [references/resource-management.md](references/resource-management.md).
+- For app state, logs, traces, and export workflows, see [references/monitoring.md](references/monitoring.md).
+- For deployment and pipeline-step workflows, see [references/deployment.md](references/deployment.md).
+- For docs, secrets, config, diagnostics, cache, and certificates, see [references/tools-and-configuration.md](references/tools-and-configuration.md).
+- For C# AppHost API-understanding guidance, see [references/csharp-apphosts.md](references/csharp-apphosts.md).
+- For TypeScript AppHost guidance, see [references/typescript-apphosts.md](references/typescript-apphosts.md).
+- For Playwright handoff after Aspire endpoint discovery, see [references/playwright-handoff.md](references/playwright-handoff.md).
+- For investigation order and common agent workflows, see [references/agent-workflows.md](references/agent-workflows.md).

.agents/skills/aspire/references/agent-workflows.md

@@ -0,0 +1,83 @@
+# Aspire Agent Workflows
+
+Use these patterns when a task needs investigation or orchestration rather than a one-off command lookup.
+
+## Scenario: I Am In A Worktree And Need A Safe Background Run
+
+Start the AppHost with `aspire start` so the CLI manages background execution. In git worktrees, use `--isolated` to avoid port conflicts and shared local state:
+
+```bash
+aspire start --isolated
+```
+
+If the next step depends on one resource, wait for it explicitly:
+
+```bash
+aspire start --isolated
+aspire wait myapi
+```
+
+Keep these points in mind:
+
+- In a git worktree, rerun `aspire start --isolated` whenever AppHost changes need to be picked up.
+- Outside worktrees, rerun `aspire start`.
+- Avoid `aspire run` in normal agent workflows because it blocks the terminal.
+
+## Scenario: Something Is Wrong, But Do Not Edit Code Yet
+
+Inspect the live app before editing code:
+
+1. `aspire describe` to check resource state.
+2. `aspire otel logs <resource>` to inspect structured logs.
+3. `aspire logs <resource>` to inspect console output.
+4. `aspire otel traces <resource>` to follow cross-service activity.
+5. `aspire export` when you need a zipped telemetry snapshot for deeper analysis or handoff.
+
+## Scenario: I Need To Add An Integration, Understand An API, Or Add A Custom Command Safely
+
+Use the docs commands first for the workflow, then use the API reference commands if you need the concrete API entry:
+
+```bash
+aspire docs search postgres
+aspire docs get <slug>
+aspire docs api search postgres --language csharp
+aspire docs api get <id>
+aspire add <package>
+```
+
+For dashboard or custom resource commands, use docs for the pattern and API docs for the specific entry:
+
+```bash
+aspire docs search "custom resource commands"
+aspire docs get custom-resource-commands
+aspire docs api search WithCommand --language csharp
+```
+
+Keep these points in mind:
+
+- Read the docs before editing the AppHost so the implementation follows a documented Aspire pattern instead of guessing the workflow.
+- Use `aspire docs api` when you need the C# or TypeScript reference entry for the exact API you are about to call.
+- If the AppHost is C# and you need to understand local overloads or builder chains, use the `dotnet-inspect` skill if it is available after checking the Aspire API reference.
+- After adding an integration, restart with `aspire start` so the updated AppHost takes effect.
+
+## Scenario: The AppHost Is TypeScript And Generated APIs Matter
+
+If the AppHost is `apphost.ts`, the `.modules/` directory contains generated TypeScript modules that expose Aspire APIs.
+
+- Do not edit `.modules/` directly.
+- Use `aspire add <package>` to regenerate the available APIs when adding integrations.
+- Use `aspire restore` if `.modules/` disappeared after a pull, clean, or branch switch.
+- Inspect `.modules/aspire.ts` after regeneration or restore to see the newly available APIs.
+
+## Scenario: I Need Secrets, Deployment, Or A Playwright Handoff
+
+Use `aspire secret` for AppHost user secrets, especially connection strings and passwords:
+
+```bash
+aspire secret set Parameters:postgres-password MySecretValue
+aspire secret list
+```
+
+Use `aspire publish` and `aspire deploy` for full deployment work, or `aspire do <step>` when the user only wants one named pipeline step such as seeding data or pushing containers.
+
+If Playwright CLI is configured in the environment, use Aspire to discover the endpoint first and let Playwright use that discovered URL afterward. When multiple frontends exist or the URL needs to be passed to another tool, prefer `aspire describe --format Json` before the Playwright handoff.

.agents/skills/aspire/references/app-commands.md

@@ -0,0 +1,58 @@
+# App Commands
+
+Use this when the task is about app-level lifecycle, bootstrap, or AppHost-wide maintenance.
+
+## Scenario: Start The App Safely In The Background
+
+Use these commands when the user wants the AppHost running, needs a safe worktree session, or wants to pick up AppHost changes.
+
+```bash
+aspire start
+aspire start --isolated
+aspire stop
+```
+
+Keep these points in mind:
+
+- Use `aspire start` for normal background AppHost execution.
+- In git worktrees or when another local instance may already be running, use `aspire start --isolated`.
+- If the CLI shape may have changed or the skill instructions look older than the local CLI, confirm the exact command form with `aspire --help` or the relevant subcommand help before executing.
+- To restart after AppHost changes, rerun the same start command. In a worktree, rerun `aspire start --isolated`.
+- Use `aspire stop` only when the ask is explicitly to stop the app or clean up a running AppHost.
+- Avoid `aspire run` in normal agent workflows because it blocks the terminal.
+
+## Scenario: Create A New Aspire App Or Add Aspire To An Existing App
+
+Use these commands when the task is to bootstrap Aspire support.
+
+```bash
+aspire new
+aspire init
+aspire init --language typescript
+```
+
+Keep these points in mind:
+
+- Use `aspire new` when creating a brand-new Aspire app from scratch.
+- Use `aspire init` when adding Aspire to an existing application.
+- If you are unsure which arguments are supported by the installed CLI, check `aspire init --help` (or the parent help) before running it.
+- If the existing app flow needs a specific AppHost language, choose it explicitly rather than inventing unrelated scaffolding.
+
+## Scenario: Find The Right AppHost Or Refresh AppHost-Wide Support
+
+Use these commands when multiple AppHosts may be running locally, when the AppHost needs an integration, or when local AppHost support files need refresh or restore.
+
+```bash
+aspire ps
+aspire add <package>
+aspire update
+aspire restore
+```
+
+Keep these points in mind:
+
+- Use `aspire ps` first when you need to discover which AppHost is already running.
+- If command arguments may differ across CLI versions, verify the current shape with `aspire <command> --help` before execution.
+- Use `aspire add <package>` when the task is to add a supported integration or regenerate AppHost APIs.
+- Use `aspire update` when the ask is specifically to refresh AppHost package references through the supported CLI workflow.
+- Use `aspire restore` after pulls, cleans, or missing generated files when the AppHost needs its local support restored before running again.

.agents/skills/aspire/references/csharp-apphosts.md

@@ -0,0 +1,30 @@
+# C# AppHosts
+
+Use this when the AppHost is implemented in C# and the task involves understanding APIs, extension methods, overloads, or builder chains before editing code.
+
+## Scenario: I Need Official Docs For An Unfamiliar C# AppHost API
+
+Use these commands when you need the documented Aspire pattern and the C# API reference before changing AppHost code.
+
+```bash
+aspire docs search <query>
+aspire docs get <slug>
+aspire docs api search <query> --language csharp
+aspire docs api get <id>
+```
+
+Keep these points in mind:
+
+- Use Aspire docs first when the task is about understanding an unfamiliar integration workflow or dashboard command pattern.
+- Use `aspire docs api` when the task is about finding the C# reference entry for a resource builder API, extension method, or member.
+- Search for the resource or pattern name before guessing the C# API shape.
+
+## Scenario: I Need To Read The Local C# API Surface More Closely
+
+Use this when the docs tell you what concept to use, but you still need to inspect local symbols, signatures, or overloads in C# code.
+
+Keep these points in mind:
+
+- If the `dotnet-inspect` skill is available, use it to inspect local C# APIs, extension methods, overloads, and chained builder return types.
+- Keep `dotnet-inspect` scoped to understanding APIs and symbols; do not treat it as a replacement for Aspire docs.
+- When `dotnet-inspect` is not available, fall back to reading local AppHost code together with the relevant Aspire docs pages.

.agents/skills/aspire/references/deployment.md

@@ -0,0 +1,35 @@
+# Deployment
+
+Use this when the task is about deployment artifacts, deployment execution, or named pipeline steps.
+
+## Scenario: Regenerate Deployment Artifacts And Redeploy
+
+Use these commands when the task is to build fresh deployment artifacts and run the full deployment flow.
+
+```bash
+aspire publish
+aspire deploy
+aspire deploy --clear-cache
+```
+
+Keep these points in mind:
+
+- Use `aspire publish` when artifact generation is part of the request.
+- Use `aspire deploy` when the goal is the full deployment flow, not just one step inside it.
+- Use `aspire deploy --clear-cache` when cached deployment state is stale or stuck.
+
+## Scenario: Run One Named Deployment Step Instead Of The Whole Deployment
+
+Use these commands when the deployment pipeline already exists and the user wants only one step, such as seeding data, running diagnostics, or pushing containers/images.
+
+```bash
+aspire do seed-data
+aspire do push-containers   # if the app defines this step
+aspire do diagnostics       # if the app defines this step
+```
+
+Keep these points in mind:
+
+- Use `aspire do <step>` when the request is specifically about one named pipeline step.
+- Common scenarios include seeding data, running a diagnostics step, or pushing containers/images, but the step names are app-defined.
+- Do not substitute `aspire deploy` when the request is to rerun only one step from the deployment pipeline.