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

The studio home keeps itself current: asks and apps arrive without a reload #55

shipped production is serving it opened this has it
opened this

The app's page now shows a deployment arriving by itself (#35), but the front door — the page a person leaves open — still offers ↻ New activity — refresh for everything: a pull that turns green, a run that starts, an app that comes back up. Give the studio home the same treatment the app head just got: the regions that change refresh themselves in place.

#35 landed the pattern — one fragment endpoint that serves the same markup as the first paint, a coalesced fetch in src/web/live.ts driven by data attributes, no interpolated script (the CSP forbids it). The home (studioHome, src/web/pages/studio.ts) draws Asks you, On you and Your apps from the same reads on every render, so this is that pattern applied twice, not new machinery.

Done looks like

  • [ ] On an event that touches an app you can land — a deploy serving, a pull opening, closing or merging, a check finishing, a run starting or ending — Asks you and Your apps refresh in place: a card that is answered goes, a new one arrives, an app's live dot and its last-activity line change.
  • [ ] One fragment endpoint per region serves exactly the markup the page rendered, from the same function; there is never a second copy of that HTML.
  • [ ] Refreshing coalesces: at most one fetch in flight per region, a burst of ten events costs one fetch, and the pill still covers everything the regions do not (it must not sit there saying refresh about something that already refreshed).
  • [ ] Nothing shifts: a region keeps its height while it swaps, and a card being decided keeps looking busy exactly as it does today.
  • [ ] Authorization is the home's, per viewer: the fragment answers with what that person may land and nothing else, carries the security floor's headers, and a signed-out request to it gets what a signed-out home gets.
  • [ ] The page stays inside MAX_LIVE_STREAMS and adds no dependency; with JavaScript off the home is what it is today.
  • [ ] test/studio.test.ts and test/live-pages.test.ts: the fragment renders the asks region for a viewer who may see it, refuses one who may not, and shows a card leaving the region between two calls after a pull merges.
  • [ ] docs/STUDIO.md, The home, says it keeps itself current.

Files I expect to change

src/web/pages/studio.ts, src/web/live.ts, src/http/server.ts (the routes), test/studio.test.ts, test/live-pages.test.ts, docs/STUDIO.md.

Risks

  • A fetch storm across a busy forge. The home listens to every app a person can see; coalesce hard and back off, and prefer one fragment for both regions if the reads are shared.
  • A decision in flight being swapped out from under a click — a region that is mid-decision must not be replaced beneath the person deciding.
  • Cost of the home's reads. It is the heaviest studio page; if a refresh is expensive, say so in the pull with numbers (and #48's bench is where that number belongs).

Who

Scout — small, live, tested, and nothing more than it needs.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs