Skip to content

feat: viewer should connect to cb serve API instead of reading files from disk #71

Description

@rajnavakoti

Description

The viewer currently reads entity files from disk at build time (via entity-loader.ts). It does NOT connect to the cb serve API. This means users who run cb serve --block my-block still see the wrong data in the viewer — it falls back to whatever entities it finds locally (usually the healthcare demo in synthetic-domains/).

The workaround is setting CB_OUTPUT_DIR=/path/to/block before starting the viewer, but this is undiscoverable and breaks the mental model that cb serve + viewer work together.

Current Behavior

  1. cb serve --block cortex starts API on port 8321 — serves cortex entities correctly
  2. npm run dev in viewer/ — reads files from disk, ignores the API
  3. User sees healthcare demo instead of their block data

The viewer has two disconnected data paths:

  • Digest/Graph/Gaps pages: read from disk via entity-loader.ts (build-time)
  • Ask page: fetches from cb serve API at runtime (correct)

Acceptance Criteria

  • Viewer pages (digest, graph, gaps, evals) fetch data from cb serve API at runtime, not from disk at build time
  • Running cb serve --block my-block + opening the viewer shows that block's data automatically
  • No CB_OUTPUT_DIR env var needed for the standard workflow
  • Fallback: if no API is running, viewer shows a clear "connect to cb serve" message instead of silently loading demo data

Out of Scope

  • Changing how cb serve works (API is fine)
  • Viewer redesign or new pages
  • SSR/deployment concerns — dev mode is the priority

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1-nextNext after OSS releaseviewerViewer/UI

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions