Docs: landing scope memo, deployment record, VS Code extension exploration

docs/exploration/vscode-extension.md

@@ -0,0 +1,71 @@
+# VS Code / Positron Extension — Exploration
+
+_Point-in-time memo, 2026-07-04. Option recorded for post-1.0; nothing is being built.
+Assesses shipping Astrolabe's authoring intelligence as an editor extension._
+
+## The idea
+
+Port the editor-intelligence layer — scaffolding CodeLenses, spec-aware completions, the
+data inspector, live preview — to a VS Code extension (and Positron via OpenVSX), working
+on `.vl.json` files in the user's own workspace.
+
+## Why it's cheap: the core/adapter boundary
+
+Everything interesting is already editor-agnostic. `src/core/` (spec analysis, scaffold
+construction, site detection over JSON offsets, rendering preparation) has no Monaco
+imports; the Monaco layer (`spec-param-scaffold`, `spec-transform-scaffold`,
+`editor-cursor-lens`) is thin adapters. VS Code's extension API has one-to-one
+counterparts:
+
+| Astrolabe piece                 | VS Code counterpart                                  |
+| ------------------------------- | ---------------------------------------------------- |
+| CodeLens scaffolds              | `languages.registerCodeLensProvider` + core verbatim |
+| Param/transform completions     | `registerCompletionItemProvider` / code actions      |
+| Live preview (`chart-renderer`) | Webview panel running vega-embed (same browser ctx)  |
+| Data inspector (`inspectData`)  | Same webview, message bridge to the render handle    |
+| Bundled schema (offline)        | `jsonValidation` contribution                        |
+| Dataset-by-name (`data.name`)   | Resolve against a workspace `datasets/` folder       |
+
+Both editors expose offset↔position conversion, so the core's offset-based site
+detection transfers without change.
+
+## The marketplace gap
+
+Preview exists; authoring help does not.
+
+- [Vega Viewer](https://marketplace.visualstudio.com/items?itemName=RandomFractalsInc.vscode-vega-viewer)
+  and [Vega Preview](https://marketplace.visualstudio.com/items?itemName=mdk.vega-preview)
+  render specs — preview-only.
+- The [official vega plugin](https://github.com/vega/vega-vscode) is deprecated; its note
+  points out VS Code's built-in JSON service already gives `$schema`-driven completion and
+  validation. **Schema completion/validation are therefore table stakes in VS Code, not
+  differentiators** — unlike on the web, where Astrolabe had to build them.
+- Nothing in the marketplace offers scaffolds, an input-vs-resolved data inspector,
+  dataset references, or theme configs.
+
+Positron (Posit's VS Code fork, OpenVSX-distributed) concentrates the Altair audience —
+people whose wrapper output is already Vega-Lite and who live in an editor. For them an
+extension is more native than any website.
+
+## v1 scope, if built
+
+In: bundled-schema validation (offline), scaffold CodeLenses (params/transforms), live
+preview panel, data inspector, `data.name` resolution against a workspace folder, theme
+as an apply-able config file. Out, deliberately: the library, drafts/publish (git covers
+it), the chart builder UI, the theme builder, fonts UI. The extension is "Astrolabe's
+authoring intelligence, detached" — the _home_ identity does not port, because in an
+editor the workspace already is the home.
+
+## Strategic read
+
+For: real organic discovery (people search "vega" in the marketplace; nobody web-searches
+for a snippet manager they don't know exists); every extension user is a lead for the
+app; the port validates the core-first architecture.
+
+Against: a second product surface for a single maintainer; it showcases the commodity
+part of Astrolabe (editing) rather than the unique part (the home); Positron/OpenVSX
+publishing is an extra channel to maintain.
+
+**Decision: defer until after the web app's 1.0.** The only standing cost of keeping the
+option open is one we already pay by conviction: keep `src/core/` free of editor and
+browser imports.