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

One tell, one change: the studio's nouns go all the way down #174

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

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

opened this

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).

---

One tell and one change now have the studio's own address, beside the lists #139 gave them: /:owner/:name/tells/:number and /:owner/:name/changes/:number are second doors onto the very pages /issues/:number and /pulls/:number already reach — one handler each (tellPage in src/web/pages/issues.ts, changePage in src/web/pages/pull.ts), rendering the same studioTell/studioPull, behind the same threadContext/pullContext for 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/7 keeps working and ?mode=dev on 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 rule tellsList/changesList follow.

The write surface does not move. Ship, close, comment and decide keep posting under /issues/:number and /pulls/:number; src/web/studio/{tell,change}.ts say so at the one thread constant each, and the asks panel's hidden forms are untouched.

New module src/web/studio/nouns.ts is 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 of lists.ts, which also folds in the two hand-rolled copies runsList and runPage were 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-body anchor), a tell's dependencies and its closing change, a run's own tell, the repo tabs and repo palette rows, the /search page, and the palette's browser-folded remote rows — the palette index now carries studio, so the script builds the same addresses the server just rendered.

Worth a look: test/studio.test.ts gained 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) and test/studio-words.test.ts gained 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

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs