On a scaffolded project running under Aspire, the resource graph misrepresents its own backing services: SQLite is absent entirely, and deno-kv appears as an unresolved parameter rather than a working resource.
Reported by the maintainer on a fresh clone, following the docs.
What the dashboard shows
The graph renders board, issues, prisma-studio and deno-kv. Two problems:
1. deno-kv is an unresolved parameter, not a resource.
- Dashboard banner: "Unresolved parameters — There are unresolved parameters that need to be set. Please provide values for them."
- The node carries a warning triangle, and its detail pane reads
Parameter: deno-kv with Value: undefined
- 0 URLs · 0 references · 0 back-references · 0 health checks — "No data to show!" · 0 environment variables
So the KV backing service the project depends on is modelled as a parameter awaiting a value, and nothing checks it. It looks provisioned in the graph while being, in fact, unconfigured.
2. SQLite is missing from the graph.
The project uses SQLite, and it does not appear as a resource at all. The developer's mental model of "what is actually running" is built from this graph, and it is incomplete.
Why this matters
aspire describe and the dashboard graph are what a developer — and, per #1204/#1206, an agent — consults to answer what is running and is it healthy. A resource that is silently absent, and another that renders as an undefined parameter with zero health checks, make the graph unreliable for exactly that question.
This is the same failure class as the empty healthReports trap already in our briefs: something can look present and checked while nothing was ever verified.
The rest of the observability story works well by contrast — distributed traces are excellent (a POST /api/rpc/* trace resolves cleanly through orpc.v1/issues/comment → call_procedure → handler → prisma:client:transaction with per-span timings). The gap is specifically the resource graph's model of backing services.
Acceptance
On a scaffolded project running under Aspire, the resource graph misrepresents its own backing services: SQLite is absent entirely, and
deno-kvappears as an unresolved parameter rather than a working resource.Reported by the maintainer on a fresh clone, following the docs.
What the dashboard shows
The graph renders
board,issues,prisma-studioanddeno-kv. Two problems:1.
deno-kvis an unresolved parameter, not a resource.Parameter: deno-kvwith Value: undefinedSo the KV backing service the project depends on is modelled as a parameter awaiting a value, and nothing checks it. It looks provisioned in the graph while being, in fact, unconfigured.
2. SQLite is missing from the graph.
The project uses SQLite, and it does not appear as a resource at all. The developer's mental model of "what is actually running" is built from this graph, and it is incomplete.
Why this matters
aspire describeand the dashboard graph are what a developer — and, per #1204/#1206, an agent — consults to answer what is running and is it healthy. A resource that is silently absent, and another that renders as an undefined parameter with zero health checks, make the graph unreliable for exactly that question.This is the same failure class as the empty
healthReportstrap already in our briefs: something can look present and checked while nothing was ever verified.The rest of the observability story works well by contrast — distributed traces are excellent (a
POST /api/rpc/*trace resolves cleanly throughorpc.v1/issues/comment→call_procedure→handler→prisma:client:transactionwith per-span timings). The gap is specifically the resource graph's model of backing services.Acceptance
deno-kvis modelled as a resource with a resolved value and URL — not as an unresolved parameter (its health check moved to aspire: backing services report no real health check — blocked on TypeScript AppHost custom health-check support #1280)withHttpHealthCheckwould generate a false probe. Not satisfiable in 0.0.5 without lying.