Docs: move point-in-time records to exploration/, trim build-narration, lift open items to plan

docs/exploration/data-inspector-exploration.md

@@ -0,0 +1,64 @@
+# 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".