Report the instrument's automatable parameters to the host under a frozen id table, in signal-flow order, with real units

42 of 44 ids issued: pitch key-track and Trigger length stay reserved
pending a live path. Master gain reclassified Live — it never reloaded.

src/shell/instrument/CLAUDE.md

@@ -84,6 +84,37 @@ The editor's `commitLive` is the tier-3 peer of `commitAndReload`; why it still
 parameter set is recorded at its declaration in `reasampler_editor.h`, and why `liveParams_` is
 declared ahead of the instrument slots at that member in `reasampler_processor.h`.
 
+**The VST3 parameter surface is a THIRD surface onto the one model, never a second copy.** The
+pure half — the frozen id table, the exposed set, the plain-value layer, the formatter — is
+`core/instrument/param` and is documented there; this directory only adapts it.
+
+- **The blob stays authoritative.** `getState` serializes the model and nothing new is
+  persisted; the controller's own value list is a cache written FROM the model and never read
+  as truth. A load pushes the model into that cache through `syncParamsFromModel` WITHOUT
+  notifying the host, which the SDK requires.
+- **`setInstrumentParams` is the notification funnel**, for the same reason it is already the
+  limiter mirror's: every writer of the parameter set — the editor's commits, `setState`, the
+  bake's adopt — passes through it, so no internal write can leave the host displaying, and on
+  next touch re-imposing, a superseded value. Master gain has its own funnel
+  (`setMasterGainLinear`) because it is the one exposed control that does not ride the
+  parameter set.
+- **`setState` ordering against the host's first parameter block is irrelevant by
+  construction.** There is one model and one funnel per control, so whichever writes last wins
+  and the host's display follows the model either way — the ordering is not assumed, it is
+  removed as a question.
+- **`process()` reads no parameter queue and is unchanged by the parameter surface.** A host
+  write arrives on the UI/main thread and reaches the audio thread through the SAME live block
+  the editor's knobs publish into, observed once per `render()` — block boundaries, last write
+  wins. `[verify — DAW]` that REAPER delivers automation to a single-component plug-in through
+  `IEditController::setParamNormalized` and not through `ProcessData::inputParameterChanges`
+  alone; if it is the latter only, an RT-safe drain is required and `process()` is where it
+  would have to land.
+- **`IMidiMapping` is deliberately NOT implemented** — no conventional CC names most of what
+  is exposed, an invented map would hijack CCs the user's controller already sends, and
+  REAPER's own per-parameter MIDI learn covers the case without freezing anything.
+  `IParameterFunctionName` and `IAutomationState` are assessed and not implemented; the reasons
+  are in the product spec and are not re-surveyed here.
+
 **Non-goals / guardrails.**
 - The instrument never captures and never inserts into the arrange. Playback is a
   read-only act over the bank. Any instrument path that places a timeline item, or that
@@ -112,6 +143,7 @@ declared ahead of the instrument slots at that member in `reasampler_processor.h
 - `reasampler_embed` — implements `IReaperUIEmbedInterface` so the instrument draws inline in the TCP/MCP without a plugin-owned HWND; delegates layout to `embed_strip`. A read-only readout: the loaded capture across the keyboard span with its root marked, plus the activity level. It takes no mouse input (there is nothing on the strip to select).
 - `editor_stroke` — the editor's LICE side of the analytic stroker: builds a coverage mask with the pure `core/ui/stroke_aa` and blends it into the bitmap ONCE, writing straight to the bitmap's bits (the arithmetic matches LICE's own mode-0 combine, so a stroke composites identically to every other kit draw). Every radial and spline stroke on the editor routes through `strokeArcAA` / `strokePolylineAA` / `strokeLineAA`. Holds the draw-thread-only scratch mask and arc point list — reuse, not a hidden dependency: threading a canvas through the eight paint sites would grow those signatures to carry an allocation detail. Deliberately does NOT touch `shell/panel/draw_kit`: the waveform stroke, the docked bank panel and the browse cards are out of this seam's blast radius.
 - `instrument_bake` — the instrument's half of the resample chain, on the UI thread: render the dialed sound through the pure `core/instrument/bake` modules at the instance's PERSISTED PREVIEW VELOCITY (the velocity the user has been auditioning at — three velocity curves are live, so it is a property of the sound and not a render detail), stage the WAV OUTSIDE the bank folder, publish one `rsbake_<guid>` request, invoke the extension's landing action SYNCHRONOUSLY, read the outcome back over the same key, then adopt + reset in one act. What that key holds afterwards is classified by `core/wire`'s pure `classifyBakeAnswer`, and each of its five non-answers gets its OWN sentence — a silent no-answer stays a failure, but the user is told whether nothing wrote over the key, a stale generation was answered, the answer came in a wire this build cannot read, the request was cleared, or it was refused. All five name the key, because the extension prints one console line per key it scanned and the key is what correlates the two in a multi-instance session. None of them claims the landing never ran — nothing on this side can observe that. Two stack-RAII guards mirror `FxBypassGuard`'s discipline: the staged file and the request key are both cleared on every exit path, so a failed bake leaves no temp, no bank entry and no parameter reset. `bakeAvailable` is the affordance's paint gate. A cloned `instanceGuid` (two instances sharing one `rsbake_` key) is NOT handled here — the residual is contained by pre-existing tracking machinery instead: `planUsagePublish`'s sticky `unioned` poison plus `tiedUsageExists` (`core/tracking/tracking_authority.cpp`) force a clone's bake to `AddDistinct` rather than silently replacing a sibling's entry.
+- `instrument_params` — the VST3 adapter over `core/instrument/param`: one `Parameter` subclass whose `toPlain`/`toNormalized` ARE the taper and whose `toString` calls the one formatter, the single construction of the unit and parameter lists (ascending id, which is also the presentation order), the `setParamNormalized` projection onto the model through each control's existing commit tier, and the `beginEdit`/`performEdit`/`endEdit` notification path every internal writer reaches through `setInstrumentParams`. Decides nothing — the pure module owns the table, the laws and the formatter.
 - `vst_entry` — VST3 entry point: `GetPluginFactory` export, class registration, channel-forked class UIDs.
 - `editor_interaction.h` — the editor's INTERACTION VOCABULARY: `DragKind` (what a gesture in flight is editing) and `HoverKind`/`HoverTarget` (what the pointer can be over). Split out of `reasampler_editor.h`, which had grown past the ~600-line ceiling with no seam — these two catalogues are produced by the input TUs and read by the paint TUs, and neither is behaviour, which is what makes them a responsibility rather than a bisection. Namespace-scope, so the editor's own members still spell them unqualified. Internal to this TU family, like `editor_internal.h`.
 - `editor_internal.h` — INTERNAL shared helpers for the `reasampler_editor` TU family, included only by the editor's own shell TUs (`editor_session` / `editor_controls` / `editor_paint_*` / `editor_input_*` / `editor_platform`), never a public seam: the `Rect`↔kit adapters, small draw primitives (knob face / title band), label helpers, the velocity-curve box derivation, and `dragModifiers()` — THE modifier read for every drag surface and gesture resolver, so the editor cannot grow a second modifier grammar — the helpers more than one band TU needs. The deck's control ids, group ids and group composition are the pure `deck_groups` module's, not this file's. The piano-strip and root-key draws live in `editor_paint_chrome`, their only consumer, not here.