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

Working opens a transcript that reads as the studio: what the crew is doing, live #51

shipped production is serving it opened this has it
opened this

Working is one of the studio's five words and clicking it lands on dev's run page — a run id, agent · assigned, a wall of tool calls — when what a person wants while a change is being built is: who is on it, which tell it came from, what it has done so far in sentences, what it has cost, and the one box that tells them to try something else. Give a run on an app its own page in studio mode, with dev's transcript one click away.

/:owner/:name/runs/:id has no mode branch (runPage, src/web/pages/runs.ts:334), unlike the repo home (src/web/pages/repo.ts:847-849). The parts are all there: the log tails over SSE (GET …/runs/:id/log?follow=1, src/runs/log.ts, src/web/live.ts), logLine/lineKind/durationText already classify a line, steering is POST …/runs/:id/steer and stopping is …/cancel (both with the same-origin check the page has today), and the issue and the pull the run belongs to are on the run row.

Done looks like

  • [ ] In studio mode, a run on a repository that is an app renders a studio transcript: who is running, what they were told (the tell's title, linking to it), how long it has been going, what it has cost so far, and its state in the studio's own word.
  • [ ] The log is the page's body and it tails live without a reload, with a fixed-height scrolling area so nothing shifts as lines arrive, and a cap on what is held in the DOM; with JavaScript off the page still tells the truth and refreshes itself while the run is in flight.
  • [ ] Steer and Stop are on the page for anyone who can write here, going through the same actions with the same same-origin check and the same errors — no new way to touch a run.
  • [ ] When the run has pushed, the pull and its preview link are on the page as soon as they exist — this is the page someone sits on while waiting for a change to become visible.
  • [ ] Read the transcript links to dev's page (?mode=dev on the same URL), which is untouched; a run on a non-app repository, or any run in dev mode, renders exactly what it renders today.
  • [ ] Authorization is the run page's, unchanged: a reader who cannot see the repository gets the forge's not-found, and the live stream honours the same check — a private app's log leaks nowhere.
  • [ ] The page stays inside MAX_LIVE_STREAMS (3) with whatever else it mounts, and adds no dependency; the client stays data attributes read by src/web/live.ts, never interpolated script text.
  • [ ] test/studio.test.ts and test/live-pages.test.ts: the studio transcript for an app names the tell, the cost and the steer box, refuses a reader without access, and renders a finished run without offering Stop.
  • [ ] docs/STUDIO.md says working has a page and what is on it.

Files I expect to change

src/web/pages/studio.ts (a studioRun), src/web/pages/runs.ts (the branch, mirroring repo.ts), src/web/live.ts if the stream needs a run-scoped config, docs/STUDIO.md, test/studio.test.ts, test/live-pages.test.ts.

Risks

  • A chatty agent. A run left open for an hour must not grow the DOM without bound; cap the lines held and say so.
  • Two copies of the log renderer. Reuse logLine/lineKind from runs.ts; the studio changes the frame, not how a line is read.
  • Overlap with #13 — that issue lands the New app page with a run streaming on it; whatever it builds for a run-scoped stream, reuse rather than write twice.

Who

Scout — one page, live, with tests, and nothing more than it needs.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs