Workflow · Primary read path

Browse & view traces

Anyone — signed in or not — can open the public catalog, a team profile, or a trace link, and see a rendered conversation seconds later. This workflow is about how a URL becomes a page, and how the platform answers "may this person see this trace?" on every single read.

Goal, trigger, and result

Goal: read traces — the public catalog, a namespace profile, or one conversation. Trigger: opening a URL in a browser. What enters: the URL and, optionally, the reader's sign-in cookie. What leaves: a fully rendered page — highlights of the conversation by default, the complete message list on demand — or a polite refusal when visibility rules say no.

From URL to page

Pages are rendered on the server. The web app checks for a sign-in cookie first — an anonymous visitor costs zero account lookups — then asks the platform's API for exactly the data the page needs, forwarding the cookie so the API can decide what this reader may see. Popular public answers are remembered briefly so a traffic spike on a shared link doesn't hammer the backend; anything private is always fetched fresh.

sequenceDiagram
  autonumber
  actor Reader as Reader (browser)
  participant Web as Web app (server-rendered)
  participant API as Platform API
  participant Meta as Metadata store
  participant Ana as Analytics store

  Reader->>Web: open a URL (catalog · profile · trace link)
  Web->>Web: sign-in cookie present?
  Note over Web: no cookie → anonymous, no account lookup
  Web->>API: request page data (cookie forwarded)
  API->>Meta: resolve who is asking and what they may see
  alt public listing or profile
    API->>Ana: query the catalog/profile rows
    Ana-->>API: trace cards (with analysis merged in)
  else single trace page
    API->>Meta: load the trace record · check visibility & membership
    API->>Ana: fetch the first page of conversation bodies
    Ana-->>API: messages with typed parts
    API-->>Web: trace detail (fresh fields win over mirrored copies)
  end
  API-->>Web: page data, or a refusal
  Web-->>Reader: rendered page
  opt reader pages deeper or filters
    Reader->>Web: load more / change filters
    Web->>API: same-origin relay for further pages
    API-->>Reader: next slice of the conversation
  end

Why two stores show up in one page view

A trace page merges two sources with different promises. The metadata store answers "does this trace exist, who owns it, and may this reader see it" — and it holds the fields people edit, so its answer is always current. The analytics store holds the bulky conversation bodies and the AI analysis, and it lags by a few seconds. The read path resolves anything freshness-sensitive from the metadata store and lets the analytics store fill in the rest, so a rename or visibility change is visible the instant it happens, even though the heavy content reads stay cheap.

What the reader experiences

A trace link opens on the highlights view — the substantive conversation without the noise — with the full message list one tab away, plus the generated summary when analysis has run. Private traces render only for namespace members; link-only (direct) traces render for anyone holding the URL but never appear in listings; public traces appear everywhere. When a team turns on live updates, an open trace page can also refresh itself as new messages arrive — the ordinary paged reads remain the fallback when that is off.