Editor: view-scoped data context — per-view dataset columns in hints and transforms

docs/architecture/08-vega-editor-techniques.md

@@ -286,16 +286,22 @@ thin app-layer services.
 
 - `spec-transforms` — wrap a view in `layer`/`hconcat`/`vconcat`/`facet`/`repeat`; collapse
   a single-child composition (`unwrapSingleton`). Object-in/object-out.
-- `spec-cursor` — `findViewRange` (cursor offset → the enclosing view's byte range) and
-  `valueKeyAtOffset`/`stringValueAtOffset` (the JSON context at the cursor), over `jsonc-parser`.
-- `spec-fields` — field names a spec's own transforms introduce (their `as`).
-- `spec-inline-data` — the inline rows a spec carries (`data.values`, a `datasets` entry).
+- `spec-data` — the Vega-Lite data model: classify a `data` block (`classifyData`, mirroring
+  `isNamedData`), the library reference name (`libraryRefName`), and the data binding in scope
+  at a cursor path (`dataBindingAtPath`, honoring a view's data inheritance from its parent).
+- `spec-cursor` — `findViewRange` (cursor offset → the enclosing view's byte range),
+  `pathAtOffset` (cursor → JSON path), and `valueKeyAtOffset`/`stringValueAtOffset` (the JSON
+  context at the cursor), over `jsonc-parser`.
+- `spec-fields` — field names a spec's transforms introduce (their `as`), scoped to a
+  cursor's ancestor chain (`derivedFieldNamesAtPath`).
+- `spec-inline-data` — the rows a specific `data` binding carries for profiling
+  (`rowsForDataBinding`: inline `values`, or a self-defined `datasets` entry).
 - `spec-insert` — composition arrays + appending a view to one.
 
 **Services (app, store-aware via `getState`):** `spec-transform-actions` (the
 wrap/simplify/add-view operations and their surfaces), `spec-dataset-hints` (completion,
-hover, inlay providers), `active-dataset` (`dataInfo()` — the columns/types/stats + derived
-fields the draft sees). `SpecEditor` does the wiring.
+hover, inlay providers), `active-dataset` (`dataInfoAt(text, offset)` — the columns/types/stats
+plus derived fields the draft sees at the cursor). `SpecEditor` does the wiring.
 
 Decision rules:
 
@@ -312,12 +318,17 @@ Decision rules:
 - **One edit path.** The lightbulb returns a `WorkspaceEdit` (no editor handle); the toolbar
   and palette use `executeEdits`. Both build the replacement through the same
   serialize-and-reindent step, bracketed by `pushUndoStop`, so ⌘Z restores the prior text.
-- **Field source for hints.** `dataInfo()` reads columns from the named library dataset the
-  draft references, else profiles the spec's **inline data on the fly** (`spec-inline-data` +
-  `core/profile`) — a "ghost dataset" with nothing stored — and adds the spec's derived
-  fields. Memoized by draft text, since providers fire per keystroke and per scroll. Out of
-  scope: data-dependent derived columns (`pivot`/`lookup` output) and `url`/CSV-string inline
-  data, which need the pipeline run or format-aware parsing.
+- **Field source for hints (view-scoped).** `dataInfoAt(text, offset)` resolves the data
+  binding of the cursor's **nearest enclosing view** (`dataBindingAtPath` — a child inherits a
+  parent's data unless it declares its own), then its columns: a named **library dataset**
+  (matched case-insensitively, like the renderer), else the binding's **inline rows** profiled
+  on the fly (`rowsForDataBinding` + `core/profile`) — a "ghost dataset" with nothing stored.
+  Derived fields come from that view's and its ancestors' transforms only
+  (`derivedFieldNamesAtPath`), so a sibling view's `calculate` does not leak in. Profiling is
+  memoized per (draft text, enclosing view), so the inlay provider's many per-line queries
+  profile once. A composed spec whose views bind different datasets therefore gets the right
+  columns per view. Out of scope: data-dependent derived columns (`pivot`/`lookup` output) and
+  `url`/CSV-string inline data, which need the pipeline run or format-aware parsing.
 - **No unknown-field diagnostic.** Hints are additive and forgiving, so over- or
   under-listing costs nothing; a "field not in data" squiggle would false-positive on every
   derived or data-dependent field, so there is deliberately none.