feat(dashboard): full AWS UI coverage + hosted state-viewer deployment

[DavidJFelix]

Completes two gaps in the dashboard and makes it deployable: every AWS resource now renders in the dashboard, and the dashboard runs as a hosted state viewer — the same SPA the CLI serves for deploy --ui, deployed against a state store with no CLI process involved.

• AWS UI coverage goes from 135 to 691 resources across all 193 service directories (parity with Cloudflare). Per-service providers live in AWS/{Service}/ui.ts; AWS/UI.ts is regenerated with nested Layer.mergeAll groups.
• New alchemy/Dashboard/Viewer: the read-only half of the dashboard API as a platform-free handler (no FileSystem/Path/process) over any StateService — document snapshots, SSE, deployment history + journal folds, projections. sse: "stream" | "poll" adapts the transport to hosts that buffer responses.
• Registry test suites in packages/dashboard/test/registry.test.ts: a conformance sweep executing all 940+ UI providers against undeployed/empty state (callbacks total, icons are real lucide names, no URL interpolates a missing value), and a coverage gate asserting every Resource<>("Cloud.Type") in a registered cloud has a UIProvider — the 691/691 census as a permanent check (it already caught GitHub.Environment, Docker.Context, Docker.Swarm).
• Merge maintenance: main is merged into the branch (Plan.destroy, aggregated DestroyError, provider modes reconciled with the deployment journal; on a successful destroy, state.deleteStack runs after the journal closes since the journal lives inside the stage directory).

Hosted viewer: host x state-backend matrix

viewer({ state }) takes any StateService, so the host and the backend are independent axes. The backend choice is one expression in each example; the Effect R-channel enforces which combinations a host can satisfy.

viewer host \ state backend	Cloudflare HTTP store	AWS S3 store	local FS
Cloudflare Worker	examples/dashboard-viewer	possible, not shipped (see below)	not possible
AWS Lambda + CloudFront	config swap of the AWS example (see below)	examples/dashboard-viewer-aws	not possible
CLI (alchemy dashboard / deploy --ui)	yes	yes	yes — this is the local cell

Cloudflare Worker + HTTP store (viewer.ts): SPA as Worker assets (runWorkerFirst: ["/api/*"], SPA fallback), state over makeHttpStateStore. Same-zone worker-to-worker fetch is blocked (error 1042), so the state API rides a service binding to alchemy-state-store (FetchHttpClient.Fetch override); plain fetch remains the cross-zone fallback. A bare bun run deploy self-configures from the credentials Cloudflare.state() caches at ~/.alchemy/credentials/{profile}/cloudflare-state-store.json.

Lambda + S3 store (viewer-function.ts, alchemy.run.ts): the S3 store has no server, so the viewer Lambda is the reader — its execution role gets s3:GetObject/s3:ListBucket on the state bucket plus kms:Decrypt; no long-lived credentials exist. One AWS.Website.Router distribution serves the SPA from S3 and routes /api/* to the function URL. Lambda URLs buffer responses, so this host uses sse: "poll" (one snapshot frame + retry: hint, then close; EventSource auto-reconnect makes it polling).

Lambda + Cloudflare store (no example needed): swap AWS.makeS3State(...) for makeHttpStateStore({ url, authToken }) in the Lambda and drop the IAM statements — plain HTTPS to the store worker, no same-zone constraint.

Worker + S3 store (possible, deliberately not shipped): makeS3State runs on workerd (distilled AWS is fetch-based), but the Worker would need long-lived IAM user keys stored as worker secrets plus kms:Decrypt — the one cell where credential posture degrades instead of improving (every other cell uses a scoped bearer token or an ephemeral execution role). Anyone who wants it can compose it; the examples don't encourage it.

Local FS: hosted viewers cannot reach a developer's .alchemy/state by construction (makeLocalState requires FileSystem, which no remote host provides — it fails to compile, not at runtime). The CLI dashboard is that cell; alchemy state sync bridges local state into a hosted store.

In every cell the viewer exposes whatever its credential can read (props/attrs with secrets redacted by the state encoding, journals, outputs) — hosted deployments should sit behind an access layer (Cloudflare Access, CloudFront auth) before sharing.

[sam-goodwin]

Can you include some screenshots or video?

[DavidJFelix]

I think i'm at a pause point looking for either a merge or direction.

Hosted view

ui starts at ~0:45. This showcases a couple of my stacks unrelated to this pr and navigating around them as expamples

Screen.Recording.2026-08-03.at.5.58.09.PM.mov

CLI view with approve/deny

this existed already but just showing it in action

Screen.Recording.2026-08-03.at.6.07.21.PM.mov

Next steps

• Small UX improvements to hierarchy of the page and naviagation
• UI nits i have that I tried not to focus on
• Ensuring the example provides a suggestion for auth

Long goals

• Some idea of what hosted approval looks like if at all?

[sam-goodwin]

Nice, took a look at the videos. I like how i can be deployed and how i can just see the stages with all the pr-* stages :)

[DavidJFelix]

Ok @sam-goodwin I removed the store versioning and the demo folder. I think instead demoing from the examples using --ui is the correct way. I think this is ready to merge and I'll follow up with any UI nits and maybe docs around securing this (with access?).