Show the time of each stage in the table view

[anurag]

Summary

The stage table of the table view at /table shows how long each stage took, and a timer counts the seconds of the stage that runs now. The classic view at / does not change.

• Time column: a new column next to the name of each stage. A stage that stopped shows its time. The row of the stage that runs now shows a timer that counts each second. A stage that the run goes into again, as Building after a failed verification, shows the sum of its times. A stage that did not start has no time.
• Phone layout: the time is on the line of the name of the stage, at the right.

API and schema

• New column stage_history (jsonb, default []): one item for each time that the run goes into a stage, with the stage and the time. setRunStage() adds the item in the same update that changes the stage.
• GET /v1/apps/:runId and GET /ui/apps now also give stageHistory, with stage, startedAt, and finishedAt for each item. A stage stops when the next stage starts, and the last stage stops when the run stops. finishedAt is null for the stage that runs now. Postgres writes each time in the JSON with the offset of its session, and the API gives it in UTC, as the other times of a run.
• scripts/doctor.ts checks the new column.

Code

• public/table.js adds up the times of each stage at each poll. Between polls, a timer adds the time since the stage that runs now started. The timer runs four times each second, because a timer that runs once each second can skip a second when it runs late. It writes a cell only when the text of the cell changes.
• The stage table keeps aria-live="off", so a screen reader does not read the timer each second.
• formatDuration() now always shows the seconds, also for one hour or more (1h 2m 13s). This also changes the "Time to generate" column of the sites table for such runs.
• AGENTS.md, docs/README.md, and docs/FAQ.md tell about the new column and the new field.

Deploy note

Only the pre-deploy command of the gateway applies app/schema.sql, and the workflows service builds faster. So for a short time after the merge, a run can start on the new setRunStage() before the column exists. Such a run fails at once at its first stage, with column "stage_history" does not exist. Submit the prompt again after the deploy. #40 had the same gap for finished_at. Runs from before this change have no stage times.

Test plan

• npm run check: Biome, tsc, and 390 Vitest tests pass. New tests cover the start and stop times in the run response, the stage that runs now, and the Time cell of each row of the stage table.
• The migration, on a throwaway Postgres with the schema of main and an old row: it runs two times with no error, and the old row gets an empty history.
• setRunStage(), finishRun(), getRun(), and listRunsByUser() against that Postgres, with the session time zone set to America/Los_Angeles. Postgres writes -07:00, and the API gives UTC.
• The table view with seeded runs (running, failed, and deployed with a second build round) at 1280, 900, and 375 pixels wide. The timer counts each second. When the run went from Building to Verifying, the next poll stopped Building at the right time. When the run failed, the timer stopped.
• After the deploy: a real run shows the times of its stages.

🤖 Generated with Claude Code