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

A tell opens in studio words: an app's issue page #49

shipped production is serving it opened this has it
opened this

Clicking a tell on an app's studio page lands on dev's issue page — labels, milestones, a dependency form, #42 opened by scout — when in the studio a tell is one sentence someone said to the crew and the only things that matter about it are who has it, what it is waiting on, and what the crew has done with it so far. Give an app's issue its own page in studio mode, with dev's one click away.

/:owner/:name/issues/:number has no mode branch (issuePage, src/web/pages/issues.ts:467), unlike the repo home, which routes to studioApp when the repository is an app (src/web/pages/repo.ts:847-849). Everything the page needs exists: threadContext/conversation/composer (src/web/pages/thread.ts) render the words and the reply, repoGraph/readyNow (src/crew/plan.ts, and the map page) know what it waits for, the runs for an issue are listRuns by issueId, and the pull that closes it is openPullsClosing. This is the sibling of #43, which does the same for a change; do it after that one so both pages wear the same shell.

Done looks like

  • [ ] In studio mode, an issue on a repository that is an app renders a studio page: the sentence as it was said, who said it and when, which builder has it (or that nobody does yet), one of the five words for where it is (told, working, look, shipped), and what it waits on and what waits on it, each a link.
  • [ ] The crew's work on it is on the page: every run for the issue with who, how long, what it cost and its state, the newest first, the title opening the transcript; and the pull that closes it, with its check and its preview link, when one exists.
  • [ ] The conversation is on it and a reply can be added, through the same action and the same same-origin check as dev's page — telling the crew more is a comment, exactly as today.
  • [ ] Read the details links to the dev page (?mode=dev on the same URL); that page is untouched, and its labels, dependency form and assignee control stay the only place those exist. The studio page adds no new mutation.
  • [ ] An issue on a repository that is not an app, or any issue in dev mode, renders exactly what it renders today.
  • [ ] Authorization is the issue page's, unchanged: a reader who cannot see the repository gets the forge's not-found, a reader who cannot write sees no composer, and the response carries the security floor's headers.
  • [ ] No layout shift and no new dependency; the page answers in single-digit milliseconds of server time on trevato/cs #8, whose direction body is long and whose dependants are many.
  • [ ] test/studio.test.ts: the studio tell page for an app names the assignee, the runs and the blocking issues, and carries no label form; ?mode=dev renders today's page; an issue on a non-app repository is unchanged; a reader without access gets not-found.
  • [ ] docs/STUDIO.md says a tell has a page of its own and what is on it.

Files I expect to change

src/web/pages/studio.ts (a studioTell), src/web/pages/issues.ts (the branch, mirroring repo.ts), docs/STUDIO.md, test/studio.test.ts.

Risks

  • Rebuilding the thread. Comments, the composer and its errors must come from thread.ts, not a second copy that drifts.
  • A direction issue is not an ordinary tell — it is the repository's standing direction and never gets picked up; the page should say so rather than show it as waiting forever.
  • Conflict with #43 in src/web/pages/studio.ts: land after it and reuse whatever shell it introduced instead of adding a second one.

Who

Scout — one page, the least that fully works, with tests.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs