release: promote v0.20.0 to main

.claude/launch.json

@@ -33,6 +33,28 @@
         "tools/example-svelte"
       ],
       "port": 5202
+    },
+    {
+      "name": "example-vue",
+      "runtimeExecutable": "npm",
+      "runtimeArgs": [
+        "run",
+        "dev",
+        "--prefix",
+        "tools/example-vue"
+      ],
+      "port": 5203
+    },
+    {
+      "name": "example-webcomponent",
+      "runtimeExecutable": "npm",
+      "runtimeArgs": [
+        "run",
+        "dev",
+        "--prefix",
+        "tools/example-webcomponent"
+      ],
+      "port": 5204
     }
   ]
 }

CLAUDE.md

@@ -66,6 +66,37 @@ homepage, feature gallery, manual, demo/examples, screenshots, and the coverage
 inventory, then resolve the review. Surfaces live in `tools/release/doc-surfaces.mjs`; the flow is
 documented in [`docs/reference/release-process.md`](docs/reference/release-process.md).
 
+## Framework parity completion check (mandatory)
+
+**A public capability is not "done" until it has a deliberate parity decision across every framework
+adapter** (DD-031). This applies to **both** viewer surfaces: the toolpath/Preview side
+(`GcodePreview` over `gcode-preview-core`) and the source-model/Prepare side (`ModelViewer` over
+`gcode-model-renderer`'s `createModelPreviewController`, exposed on each adapter's `/model` subpath).
+When a change adds or materially changes a consumer-meaningful capability on a controller or a
+renderer, answer each — "not applicable" is a valid, explicit answer, but it must be a decision, not
+an omission:
+
+1. Does **core** (`GcodePreviewControls` / `GcodePreviewState` / `PreviewEvent`) expose it correctly?
+2. Do **Vue**, **React**, **Svelte**, and the **Web Component** expose it — declaratively where it
+   logically belongs, imperatively via `controls` otherwise?
+3. Are the **lower-level APIs** (`useGcodePreview` / `createGcodePreview` / `element`) covered?
+4. Are **events/callbacks** equivalent (allowing each framework's naming idiom)?
+5. Is it exercised by the **portable behavioral suite** (`gcode-preview-core/src/testing.ts` for
+   toolpath; `gcode-model-renderer/src/model-testing.ts` for the model viewer)? The
+   controls/state-completeness **parity guards** there fail CI if a `GcodePreviewControls` /
+   `ModelPreviewControls` method (or a state field) isn't reachable through an adapter — add new
+   controls/state to the matching required list.
+6. Does the **Feature Lab demo** expose it, and do the **framework showcase examples** demonstrate it
+   where useful?
+7. Is it **documented** consistently across the adapter READMEs + `docs/manual/adapters.md`, and does
+   **visual coverage** (`docs/VISUAL_FEATURE_COVERAGE.md`) need updating?
+
+Deliberate per-framework differences (e.g. the Web Component's property-vs-attribute split and the
+`<gcode-model-viewer>` tag, Svelte's `.svelte` subpath, the `/model` subpath for source-model viewing)
+are fine — but they must be **documented as intentional**, never accidental drift.
+No capability should be reachable only through the `raw.renderer()` escape hatch for lack of a public
+surface. The release review (`RELEASE_REVIEW.md`) carries a parity line so this is checked before a cut.
+
 ## Repo orientation
 
 - `packages/*` — the 14 published packages (foundation → parse → color → render → adapters). Build

README.md

@@ -452,7 +452,7 @@ row inspects the *toolpath*, the bottom row presents the *source model* (see
 
 Design rationale, boundaries, and the accepted architecture live in
 [`docs/design/`](docs/design); the [docs index](docs/README.md) maps the whole set. Fourteen
-packages publish to npm in lockstep (currently **v0.19.0**) with npm provenance.
+packages publish to npm in lockstep (currently **v0.20.0**) with npm provenance.
 
 ## Development
 

RELEASE_REVIEW.md

@@ -12,10 +12,10 @@
   parses them literally. Delete rows only for packages that did not change.
 -->
 
-# Release review — v0.19.0
+# Release review — v0.20.0
 
-**Review version:** v0.19.0
-**Changed-capability inventory diffed against:** `v0.18.0`
+**Review version:** v0.20.0
+**Changed-capability inventory diffed against:** `v0.19.0`
 
 This artifact records the per-release **Public Product + Documentation + Visual** reconciliation:
 before the `dev` -> `main` promotion, compare the changed capabilities below against the README,
@@ -28,9 +28,13 @@ each disposition. Guidance: CLAUDE.md "Public-docs completion check" and
 
 | Package | Changed src files | Changelog summary | Disposition |
 |---|--:|---|---|
-| `@chestnutlabs/gcode-preview-core` | 2 | feat(renderer): `setFeatureRoleVisible(role, visible)` — show/hide a single feature role | Status: reviewed |
-| `@chestnutlabs/gcode-renderer-three` | 2 | feat(renderer): `setFeatureRoleVisible(role, visible)` — show/hide a single feature role | Status: reviewed |
-| `@chestnutlabs/toolpath-core` | 1 | feat(renderer): `setFeatureRoleVisible(role, visible)` — show/hide a single feature role | Status: reviewed |
+| `@chestnutlabs/gcode-model-renderer` | 4 | Make interactive **source-model viewing** (STL / 3MF) a first-class, declarative half of the SDK — | Status: reviewed |
+| `@chestnutlabs/gcode-preview-core` | 4 | Close the dark-capability gaps so no shipped capability is reachable only through the | Status: reviewed |
+| `@chestnutlabs/gcode-preview-element` | 6 | Close the dark-capability gaps so no shipped capability is reachable only through the | Status: reviewed |
+| `@chestnutlabs/gcode-preview-react` | 7 | Close the dark-capability gaps so no shipped capability is reachable only through the | Status: reviewed |
+| `@chestnutlabs/gcode-preview-svelte` | 6 | Close the dark-capability gaps so no shipped capability is reachable only through the | Status: reviewed |
+| `@chestnutlabs/gcode-preview-vue` | 6 | Close the dark-capability gaps so no shipped capability is reachable only through the | Status: reviewed |
+| `@chestnutlabs/gcode-renderer-three` | 3 | `CaptureOptions` gains `includeBuildVolume?: boolean` (default `true`). Set it to `false` to exclude | Status: reviewed |
 
 Set each **Disposition** to one of `Status: reviewed` / `Status: no-change-needed` /
 `Status: not-applicable` (never `Status: pending`).
@@ -42,3 +46,27 @@ Set each **Disposition** to one of `Status: reviewed` / `Status: no-change-neede
 - **Visual review:** resolved — every changed user-facing capability is visually documented, or the coverage matrix records why not.
 
 _Resolve each marker above by replacing `pending` with `resolved` once reconciled._
+
+## Reconciliation notes (v0.20.0)
+
+All seven changed packages are the DD-031 consumer-UX / framework-parity pass, reconciled together:
+
+- **Product:** the whole point of this release is consumer-facing surface. `docs/README.md`
+  "Current state" leads with v0.20.0; the two-viewer (Preview + Prepare) story is accurate. The root
+  README and Pages homepage remain accurate (they describe the toolpath viewer + source-model
+  rendering; the new framework model adapters are additive API documented in the canonical adapter
+  docs). No existing product copy misrepresents the shipped software.
+- **Docs:** `docs/manual/adapters.md` gained "Two viewers: Preview and Prepare" + a per-framework
+  import table; all four adapter READMEs gained a "Model viewing (Prepare side)" section; the
+  `gcode-model-renderer` README documents `createModelPreviewController` + the `/testing` suite;
+  `CLAUDE.md`'s parity check now covers both viewer surfaces. `npm run docs:links` passes.
+- **Visual:** the interactive model viewer is now demonstrated in the Feature Lab + all four
+  showcases (Preview/Prepare toggle) and a minimal model page per framework; the coverage matrix
+  (`docs/VISUAL_FEATURE_COVERAGE.md` §6/§10) records this. Dark **app-UI** screenshots of Prepare
+  mode were captured for review but are **not yet canonical `docs/media`** — the manifest harness
+  emits the mid-grey capability presentation, not app chrome; that gap is explicitly recorded and
+  carried to the next Visual Review. No shipped capability's existing media is now stale.
+- **Framework parity:** every new controller/model capability is exposed across Vue, React, Svelte,
+  and the Web Component (declaratively where it belongs; the `<gcode-model-viewer>` tag and the
+  `/model` subpath are documented intentional differences), exercised by the portable behavioral
+  suites with controls/state completeness parity guards for both the toolpath and model surfaces.