A preview serves seconds after a push (#19) but its picture waits for the whole test run and is never taken at all when the tests fail — publish the moment a deployment starts serving and take the look from that.
src/looks/service.ts:132 queues a look on run.finished with kind: "deploy" and state: "ok". Since serve-before-tests landed, that instant is the end of bun test, not the moment the app answered: production deploys of trevato/cs measured 3.0 s to 36.1 s between the two, all of it tests. Worse, a preview whose tests fail is serving and pictureless, so the one change you most want to look at is the one the studio cannot show you. The instant already exists in the runtime — servingAt is stamped at the swap-in (src/apps/runtime.ts:653-659, from #26) — it is simply not on the bus; there is no app.* event for it (app.created, app.updated, app.deleted, app.stopped are the whole set).
Done looks like
[ ] The runtime publishes one event at the swap-in, the same statement the log already makes: repo, app, env, commit, servingAt, deployStartedAt, and whether the tests are still running. Nothing else changes about the deploy.
[ ] src/looks/service.ts queues on that event instead of run.finished, so a preview is pictured while its tests run, and a preview whose tests then fail keeps its picture rather than never getting one.
[ ] A later deploy of the same environment still replaces a look still waiting (the one-per-env rule in enqueue is unchanged), and a look still never blocks or fails a deploy.
[ ] A deploy that never serves — image build failed, health check never passed — publishes nothing and is pictureless, as today.
[ ] The event carries no secret: no grant token, no environment variables, no URL a signed-out subscriber could not already derive; whoever may subscribe to the repo's events may see it.
[ ] test/looks.test.ts: serving publishes and a look is queued from it with the tests still running; a red check after a green serve does not remove the picture; two deploys in a row leave one queued look at the newer commit. test/apps.test.ts: the event's payload at the swap-in.
Files
src/apps/runtime.ts (publish at the swap-in), src/looks/service.ts (subscribe to it), src/design/activity.ts (a word for the new kind, so the activity feed does not print a bare kind), test/looks.test.ts, test/apps.test.ts.
Risks
The bus is in-process and the looks service is best-effort — the failure mode to avoid is a deploy path that now throws through a subscriber; publish inside the same try the log write uses. Two events for one deployment (serving, then run.finished) must not mean two pictures of the same commit: dedupe on app+env+commit, which enqueue nearly does already. Keep run.finished handling for the case where an environment came up before this change shipped.
A preview serves seconds after a push (#19) but its picture waits for the whole test run and is never taken at all when the tests fail — publish the moment a deployment starts serving and take the look from that.
src/looks/service.ts:132queues a look onrun.finishedwithkind: "deploy"andstate: "ok". Since serve-before-tests landed, that instant is the end ofbun test, not the moment the app answered: production deploys oftrevato/csmeasured 3.0 s to 36.1 s between the two, all of it tests. Worse, a preview whose tests fail is serving and pictureless, so the one change you most want to look at is the one the studio cannot show you. The instant already exists in the runtime —servingAtis stamped at the swap-in (src/apps/runtime.ts:653-659, from #26) — it is simply not on the bus; there is noapp.*event for it (app.created,app.updated,app.deleted,app.stoppedare the whole set).Done looks like
servingAt,deployStartedAt, and whether the tests are still running. Nothing else changes about the deploy.src/looks/service.tsqueues on that event instead ofrun.finished, so a preview is pictured while its tests run, and a preview whose tests then fail keeps its picture rather than never getting one.enqueueis unchanged), and a look still never blocks or fails a deploy.test/looks.test.ts: serving publishes and a look is queued from it with the tests still running; a red check after a green serve does not remove the picture; two deploys in a row leave one queued look at the newer commit.test/apps.test.ts: the event's payload at the swap-in.Files
src/apps/runtime.ts(publish at the swap-in),src/looks/service.ts(subscribe to it),src/design/activity.ts(a word for the new kind, so the activity feed does not print a bare kind),test/looks.test.ts,test/apps.test.ts.Risks
The bus is in-process and the looks service is best-effort — the failure mode to avoid is a deploy path that now throws through a subscriber; publish inside the same try the log write uses. Two events for one deployment (serving, then
run.finished) must not mean two pictures of the same commit: dedupe on app+env+commit, whichenqueuenearly does already. Keeprun.finishedhandling for the case where an environment came up before this change shipped.Suggested: Scout.