The studio's one number for the direction is wrong by however long a deploy waited to start. servedPhrase (src/web/ui.ts:57) computes servingAt - deployStartedAt and words it 3.4s after the push, but deployStartedAt is the deploy run's own start (runtime.ts:658, claimed.startedAt) — the deploy's log is honest about the same number and calls it N after the deploy started (src/apps/runtime.ts:674). Between the push and that start sits Gate(concurrency ?? 2) (src/apps/runtime.ts:192, src/git/env.ts:92): on a forge with several apps and previews, a third push waits for a permit, and the studio silently drops that wait out of the number it prints on the front door.
Acceptance
[ ] The phrase is measured from the instant the push created the deploy run (Run.createdAt), not from when it was claimed, and every page that shows it uses the one function.
[ ] When the deploy waited more than a second to start, the phrase says so — live 6.1s after the push · 2.4s queued — and when it did not, it reads exactly as it does today.
[ ] EnvStatus carries the run's createdAt alongside servingAt and deployStartedAt; nothing else in EnvStatus changes shape.
[ ] A deploy with no servingAt still says nothing about elapsed time, and a clock skew that would make the number negative clamps to zero rather than printing -0.3s.
[ ] The deploy log's own sentence stays as it is — it is measured from the deploy's start and says so.
[ ] A test fails on today's code: a run created 5s before it started and serving 1s after that reads 6.0s after the push with the queued wait named.
Files I expect to change
src/web/ui.ts (servedPhrase, envFacts), src/apps/runtime.ts (EnvStatus, status()), test/apps.test.ts or test/studio.test.ts.
Risks
Run.createdAt is the push's instant only for deploys the push created; a redeploy a person pressed, or a boot reconcile, has a different reason (run.reason) and should not claim a push — word those from the deploy's start, or say after the redeploy. Do not widen the API's run shape in this issue.
The studio's one number for the direction is wrong by however long a deploy waited to start.
servedPhrase(src/web/ui.ts:57) computesservingAt - deployStartedAtand words it3.4s after the push, butdeployStartedAtis the deploy run's own start (runtime.ts:658,claimed.startedAt) — the deploy's log is honest about the same number and calls itN after the deploy started(src/apps/runtime.ts:674). Between the push and that start sitsGate(concurrency ?? 2)(src/apps/runtime.ts:192,src/git/env.ts:92): on a forge with several apps and previews, a third push waits for a permit, and the studio silently drops that wait out of the number it prints on the front door.Acceptance
Run.createdAt), not from when it was claimed, and every page that shows it uses the one function.live 6.1s after the push · 2.4s queued— and when it did not, it reads exactly as it does today.EnvStatuscarries the run'screatedAtalongsideservingAtanddeployStartedAt; nothing else inEnvStatuschanges shape.servingAtstill says nothing about elapsed time, and a clock skew that would make the number negative clamps to zero rather than printing-0.3s.6.0s after the pushwith the queued wait named.Files I expect to change
src/web/ui.ts(servedPhrase,envFacts),src/apps/runtime.ts(EnvStatus,status()),test/apps.test.tsortest/studio.test.ts.Risks
Run.createdAtis the push's instant only for deploys the push created; a redeploy a person pressed, or a boot reconcile, has a different reason (run.reason) and should not claim a push — word those from the deploy's start, or sayafter the redeploy. Do not widen the API's run shape in this issue.Suggested: Mason.