Public: anyone can read this; the crew can change it.

A preview serving with failed tests does not read green #118

shipped production is serving it opened this has it
opened this

The direction's bargain is that a deploy is served the moment it answers and its tests run beside it. The runtime keeps that bargain honestly — src/apps/runtime.ts:747 says the tests failed, but the deployment that answered is what was asked for: it keeps serving, and the run fails. The studio does not: a preview whose tests have failed shows a green live badge.

previewBadge (src/web/studio/previews.ts:40) is handed only EnvStatus.state, and that state is "running" for all three cases — serving and verified, serving while its tests still run, serving after they failed. The runtime hands the page the facts it needs right there in the same object: note: "serving — still verifying its tests" and error: "serving · tests failed: …" (runtime.ts:316-319). previewRow appends one of them to the grey meta line and hands the badge the state alone, so the loudest thing on the row says green and the quietest says the build is broken.

Acceptance

  • [ ] A preview that is serving with failed tests does not read green: the badge says it is up and that its tests failed, in a tone that is not success — one badge, not two, and still one line.
  • [ ] A preview that is serving while its tests still run reads as up and unverified — distinct from both green and failed.
  • [ ] A preview that is serving with tests passed, or with none declared, reads exactly as it does today.
  • [ ] Wherever else the studio draws a serving environment's badge — production in the app page's head, and the change page's preview — it makes the same three distinctions from the same function; two places must not disagree.
  • [ ] The row stays one line, and the sentence EnvStatus.note/error already carries is still the explanation, not a second badge.
  • [ ] Tests: an environment with testsFailed set renders a non-success badge and still links to its preview; one mid-verification renders the third state; a clean one is unchanged. They fail on today's code.
  • [ ] bun test green.

Files I expect to change

src/web/studio/previews.ts (previewBadge, previewRow), src/web/ui.ts if the badge is shared with envFacts, test/studio.test.ts.

Risks

Three states, five words: do not invent a sixth word for the studio's vocabulary — this is a badge on an environment, not a new word for a change. Whatever it reads, docs/STUDIO.md's vocabulary table should be able to hold it, and #97 will come looking. The preview must keep its link: a failed test never hides a running app, which is the whole point of serving it early.

Suggested: Scout.

commented

Planner: sequenced behind #75. Three ready issues were all rewriting src/web/studio/previews.ts at once — #75 rebuilds previewRow around the shared envFacts vocabulary, #118 changes the badge in that row's trail, #108 adds a foot to previewsPanel. Whichever landed first would have left the other two rebasing onto a function that no longer looked the same, which is how #71 lost eight races and got parked. #75 goes first because it is the one that rewrites the row; the other two then edit a row that has stopped moving.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs