# Data Inspector — exploration (future direction)

> **Status:** parked idea (2026-06-11). A deliberate divergence from the Phase-1
> chart-builder scope, recorded here so it isn't lost. **Not built.** The shipped
> seed is the builder's 1D data preview (raw source rows); this is its transform-aware
> evolution, generalized to the main editor.

## What

A vega-editor-style **data inspector**: show the data tables the chart actually uses at
runtime — _after_ the spec's transforms run — not just the raw source rows. Two homes:

1. **Chart Builder** — make the existing data preview (1D) transform-aware: show the
   filtered rows and any calculated columns, so the preview reflects the `transform`
   block the builder emits. (Today 1D shows the **raw dataset rows**, pre-transform — an
   "inspect the source" view. This adds the "inspect the result" view alongside it.)
2. **Main window** — a **togglable data panel below the Live Preview** in the editor,
   for any snippet (not only builder-made ones): inspect each named dataset / the
   post-transform rows while authoring a spec by hand.

## Why

vega-editor surfaces every internal data table below the chart (its "Data Viewer"), and
it is the primary way to debug "why is my chart empty / wrong" — you look at what the
transforms produced. Astrolabe has no equivalent today: the only data views are of the
**raw source** (the Datasets manager, and builder 1D). Seeing the **resolved** data
closes that debugging gap and is useful well beyond the builder.

## Technique

Vega exposes runtime datasets via `view.data(name)` — the rows of any named dataset in
the compiled dataflow, including the root data _after_ transforms. The renderer already
owns the only `view` reference behind `RenderHandle` (`src/app/services/chart-renderer.ts`);
add a `RenderHandle.listData()` / `data(name)` accessor that wraps `view.data(...)`,
mirroring how `toImageURL` wraps `view.toImageURL` — so no component touches the raw
view and the embedding boundary holds (architecture/05 §1–§2).

Vega-Lite compiles user transforms into named datasets (e.g. `source_0`, `data_0`);
mapping those to friendly labels and choosing which to expose is the main design work.

## Scope notes / open questions

- **Read-only**, like 1D — it inspects, never mutates (the "moderately capable" ceiling:
  a debugging aid, not a data editor).
- **Big datasets** — cap the rows shown (reuse the 50-row preview cap). The view holds
  every row; the table must not.
- **Which tables to list** — just the post-transform root/result, or every internal
  dataset (the vega-editor dropdown)? Start with the result; expose the rest behind a
  selector if it earns its place.
- **Main-window placement** — a third stacked region inside the preview pane (toggle +
  persisted visibility, like the existing pane toggles) vs. a tab over the chart. Wants a
  small interaction pass (architecture/10) before building.
- **Refresh timing** — the data is only available once a view has rendered; the panel
  reads from the live `RenderHandle` and updates when a new render resolves (it must not
  read a finalized view — same generation discipline as the preview).

## Relationship to shipped work

- Seed: builder **1D** data preview — see
  [`chart-builder-enhancement-scope.md`](./chart-builder-enhancement-scope.md) (§3 1D).
- Renderer/preview home: [`architecture/05`](../architecture/05-rendering-theming-preview.md)
  (the `RenderHandle` boundary the `view.data` accessor extends).
- Behaviour, once built, is specified in `docs/spec/04` (Live Preview) and `docs/spec/06`
  (the builder preview), per "spec follows code".