Public: anyone can read this; the crew can change it.
One tell, one change: the studio's nouns go all the way down #174
Check · Review · Land · Live done — Landed and live in production.
Pushed and green (the six failures in the full check are pre-existing on a clean tree in this sandbox — git-push/exec cases in `pulls`, `web`, `apps`, `forks`, unrelated to this diff; `bun x tsc --noEmit`, `studio.test.ts` and `studio-words.test.ts` all pass).
shipped production is serving it deploy 2fa0c24
Sign in to join this conversation.
new above
offline
Pushed and green (the six failures in the full check are pre-existing on a clean tree in this sandbox — git-push/exec cases in
pulls,web,apps,forks, unrelated to this diff;bun x tsc --noEmit,studio.test.tsandstudio-words.test.tsall pass).---
One tell and one change now have the studio's own address, beside the lists #139 gave them:
/:owner/:name/tells/:numberand/:owner/:name/changes/:numberare second doors onto the very pages/issues/:numberand/pulls/:numberalready reach — one handler each (tellPageinsrc/web/pages/issues.ts,changePageinsrc/web/pages/pull.ts), rendering the samestudioTell/studioPull, behind the samethreadContext/pullContextfor who may see them, so a reader who may not gets the forge's not-found at either address.Resolved one way: a dev URL asked for in studio mode answers where it stands — never a redirect — so every link already written to
/issues/7keeps working and?mode=devon it is still one click to dev's own. The studio's noun asked for where the studio does not apply (dev mode,?mode=dev, a repository that is not an app) redirects to dev's address, exactly the ruletellsList/changesListfollow.The write surface does not move. Ship, close, comment and decide keep posting under
/issues/:numberand/pulls/:number;src/web/studio/{tell,change}.tssay so at the onethreadconstant each, and the asks panel's hidden forms are untouched.New module
src/web/studio/nouns.tsis the one place a surface asks where a tell or a change lives (tellHref,changeHref,tellsHref,changesHref) and the one place the "does the studio apply here" rule lives —studioRecord, moved out oflists.ts, which also folds in the two hand-rolled copiesrunsListandrunPagewere carrying. Every studio link site goes through it: the three lists' rows, the app page's now and its footer, the asks cards (including the#comment-bodyanchor), a tell's dependencies and its closing change, a run's own tell, the repo tabs and repo palette rows, the/searchpage, and the palette's browser-folded remote rows — the palette index now carriesstudio, so the script builds the same addresses the server just rendered.Worth a look:
test/studio.test.tsgained three tests (both nouns answer, anchors and form actions unchanged, dev's addresses still answer in place; the redirect cases; 404 for a reader who may not see it) andtest/studio-words.test.tsgained four rows — the two new page nouns and, while I was there, the two list nouns the table had been missing. Three existing assertions changed from the dev noun to the studio noun on studio pages (the run page's tell link, a tell's dependency link, the two search hits): those were asserting the address this issue moves, not a behaviour. I left the board (src/web/pages/board.ts) alone — it is outside this issue's list, has no mode of its own, and its dev addresses keep working — and left the palette's group headings (Issues/Pull requests) in dev's words, which is vocabulary rather than address and belongs with #152.🤖 Generated with Claude Code
Closes #158