Add a table view of the UI, with links to the Render Dashboard

[anurag]

Summary

A second view of the UI at /table. It shows the same runs as the classic view at /, and each view has a button in the top bar that opens the other view. The classic view does not change, except for this button.

• Sites table: the site, its status, its URL, the time that its run took, the time that the run started, and a delete button. The delete button opens the same dialog as the classic view, and asks for the app name. A click on a row selects the site.
• Stage table: each stage, what it does, where it runs, and its links to the Render Dashboard. The row of the stage that runs now has a tint, so that a presenter can talk along with it. The status, the link to the live site, and the error summary are above the table.

Dashboard links

The gateway builds the links from IDs in Postgres, and gives null for a link that it cannot make.

Link	Format	Where the IDs come from
Workflow run	/wf/<workflowId>/runs/<taskRunId>	workflow_run_id, which exists. The gateway reads the workflow ID once, from the task run and its task, in the background.
Sandbox	/sandbox-group/<groupId>/sandboxes/<sandboxId>	prompt-to-app records its sandbox and the sandbox group of the workspace.

Limits:

• Each stage links to the run of prompt-to-app, which lists its subtasks. The Render SDK does not give the ID of a subtask run.
• The sandbox of publish-app has no link: it is not recorded.
• In the alpha, a workspace has at most one sandbox group. With more than one, there is no sandbox link, because a sandbox does not name its group.
• Local development gets no workflow links: local task runs are not in the Dashboard.
• A Blueprint cannot give the gateway the workflow ID: fromService has no id property.
• Runs from before this change have no sandbox link.

API and schema

• New columns: sandbox_id, sandbox_group_id, and finished_at. A delete changes updated_at, so finished_at records when a run stopped. The migration copies updated_at into finished_at for the runs that stopped before this change.
• GET /v1/apps/:runId and GET /ui/apps now also give finishedAt and links.
• scripts/doctor.ts checks the new columns.

Code

public/runs.js has the parts that both views share: the prompt form, the poll, the run panel, the stage states, and the delete dialog. app.js (classic) and table.js (table view) render only what differs. AGENTS.md, docs/README.md, and docs/FAQ.md tell about the table view.

Test plan

• npm run check: Biome, tsc, and 388 Vitest tests pass. New tests cover the links, the finish time, the workflow ID read, the record of the sandbox, the Basic Auth of the new routes, and the stage table.
• The migration, on a throwaway Postgres with the schema of main and old rows: it runs two times with no error, and it copies the time only for runs that stopped.
• The new store functions against that Postgres.
• In a browser, against a mock of /ui/apps: both views, with a running, a deployed, and a failed run; the delete from a row; the selection by a click on a row; the phone width, with no horizontal scroll of the page.
• After the deploy: open the workflow and sandbox links of a new run in the Dashboard.

🤖 Generated with Claude Code