astrolabe/docs/exploration/data-inspector-exploration.md

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 (§3 1D).
• Renderer/preview home: architecture/05 (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".