docs(todo-1.0): item 15 answer round; item 16 retires zone mapping

Five blocking questions folded; capture-signal popup specced; items 2, 9,
11, 12 carry supersession notes. Sole remaining Daniel-blocker: multi-zone
migration.

TODO-1.0.md

@@ -4,7 +4,9 @@ Post-1.0 queue for ReaSampler — chiefly the 9000 instrument, plus two
 extension-side bugs. Items 1–3 are the first batch, in Daniel's ordering
 (2026-07-28); items 4–13 are a second batch (2026-07-28, later the same day);
 item 14 is a third, single-item batch (2026-07-28, later again); item 15 is
-a fourth, single-item batch (2026-07-29).
+a fourth, single-item batch (2026-07-29); item 16 (2026-07-29) is not a new
+ask batch — it records the system change mandated by answer 1 of item 15's
+answer round (the zone mapping system is retired).
 Deliberately specified at the level of product
 intent, user-visible behavior, and acceptance criteria — **no implementation
 design, no file/module references**. These were authored while Phase Q was
@@ -89,13 +91,27 @@ processing is captured back into the bank, the source capture is replaced (or
 a distinct capture added when other references exist), the instance re-points
 at the recapture, and the audio parameters reset to default — the
 dial → bake → dial-again iteration loop, run without leaving the sampler.
-**Item 15 reopens the Daniel-blocked state: five of its open questions await
+**Item 15 reopened the Daniel-blocked state: five of its open questions
-a Daniel decision** — the multi-zone scope of "the sound," what the offline
+awaited a Daniel decision** — the multi-zone scope of "the sound," what the
-pass plays (note, velocity, and the Gate-mode hold/tail policy), the
+offline pass plays (note, velocity, and the Gate-mode hold/tail policy), the
 parameter-reset scope, what counts as "other references," and the
 undo/recovery expectation. Its remaining questions are
 propose-at-implementation-review; items 1–14 stay fully unblocked.
 
+A **fourth-batch answer round** (2026-07-29) answered all five. The answers
+are folded into item 15's Behavior (marked *settled by answer round*).
+Answer 1 is a **system change, not a scoping rule**: the zone mapping system
+is retired — ReaSampler 9000 becomes **one capture = one parameter set** —
+recorded in full as **item 16**, which supersedes the doc's per-zone-storage
+and Sample/Zone-panel-parity language throughout (items 2, 9, 11, and 12
+carry marked superseded-by/cross-reference notes; Daniel's verbatim asks
+stand exactly as written). Answer 2 spawns a new sub-feature inside item 15:
+a **capture-signal popup** (note length, start/end offsets in ms and in
+beats, velocity, and a preview trigger). **Current Daniel-blocked state:
+exactly one question awaits a Daniel decision — item 16's migration of saved
+multi-zone instances.** Everything else open across items 1–16 is
+verify-or-propose-at-implementation.
+
 Ordering note: item 1's curve/overlay treatment explicitly anticipates item 2's
 filter envelope ("filter to be added"), and item 3 layers on both. They can land
 in sequence or together, but 1 and 2 are prerequisites for 3's full surface.
@@ -120,7 +136,14 @@ and 14 build — so its spec only becomes fully meaningful once those have
 landed, and its Gate-mode render policy touches item 9's loop-sustain; that
 is a statement of what the feature operates on, not a schedule decision. Its
 bank-side half rides the already-settled capture and prune safety model, not
-any queued item.
+any queued item. Item 16 (zone retirement) is a **prerequisite of meaning**
+for item 15 — it is what makes "the sound" singular and dissolves the
+multi-zone question — and it touches the surfaces other queued items work
+on: items 2, 9, and 11 now store their parameters into the one parameter
+set rather than per-zone, and item 12's full-width piano strip is
+re-grounded by what the strip means with zones retired. That too is
+dependency-of-meaning, not a schedule: the affected items' work is
+unchanged in substance; only its storage/parity framing simplifies.
 
 ---
 
@@ -293,7 +316,12 @@ AHDSR envelope, and make the knob-deck row read in signal-flow order.
 - **Per-zone storage.** The filter's parameters are **stored per-zone**,
   alongside the other playback parameters — Sample/Zone panel parity applies,
   same as the existing per-zone controls (VOICE and MASTER remain the
-  per-instance exceptions). *(Settled by second follow-up.)*
+  per-instance exceptions). *(Settled by second follow-up.)* **Superseded by
+  item 16** (zone retirement): the filter's parameters join the instrument's
+  **one parameter set** — no per-zone storage, no Sample/Zone parity, no
+  per-instance exception structure to be an exception to. The follow-up's
+  substance carries over unchanged: the filter's parameters live with the
+  other playback parameters.
 - **Off by default.** The filter **defaults to off** — pre-existing saved
   instances and freshly loaded captures sound unchanged until the user engages
   it. *(Settled by second follow-up.)*
@@ -332,9 +360,10 @@ AHDSR envelope, and make the knob-deck row read in signal-flow order.
 - Two simultaneously sounding voices at different envelope phases are filtered
   independently (per-voice processing is audible, not a shared instance-wide
   filter).
-- Filter parameters follow Sample/Zone panel parity: they appear and edit on
+- Filter parameters live in the instrument's one parameter set: they edit in
-  both surfaces, and each zone carries its own filter settings (two zones with
+  one place and govern the instrument as a whole. (Original per-zone/parity
-  different filter settings audibly differ).
+  form — two surfaces in parity, per-zone divergence — superseded by item 16;
+  neither is expressible after the zone retirement.)
 - Velocity and key-tracking modulation of the filter ship with this item and
   are audible — velocity following the amp-velocity-transfer-curve pattern,
   key-tracking following the pitch-key-tracking pattern.
@@ -757,9 +786,10 @@ playback cycling the loop until note-off, then release.
 - The regression verification above (removed vs. unexposed).
 - The crossfade parameter's units and range are unspecified — Daniel call, or
   a proposed default surfaced at implementation review.
-- Storage side: presumably per-zone alongside the other playback parameters
+- Storage side: closed by **item 16** (zone retirement) — the loop
-  (Sample/Zone panel parity, with VOICE/MASTER the per-instance exceptions) —
+  parameters belong to the instrument's one parameter set; there is no
-  confirm.
+  per-zone side left to confirm. (Cross-reference: item 15's settled reset
+  scope classifies loop points as baked-in, so they reset on a resample.)
 - Editing surface for loop start/end (waveform markers, knobs, or both) is
   unspecified; the waveform display is the natural home for range markers, but
   Daniel has not said.
@@ -853,7 +883,11 @@ playback cycling the loop until note-off, then release.
   because the proposed MASTER placement implied per-instance storage; with
   the buttons in their own VELOCITY group that doubt is gone, and the
   project's settled convention — playback parameters are per-zone, VOICE and
-  MASTER the per-instance exceptions — decides it.)*
+  MASTER the per-instance exceptions — decides it.)* **Superseded by item
+  16** (zone retirement): the curves live in the instrument's **one
+  parameter set**. The bullet's point survives in simplified form — the
+  curves store with the other playback parameters; the per-zone framing and
+  the parity convention it leaned on are gone.
 - **Bipolar pitch/filter transfer functions.** Pitch and filter velocity
   transfer functions are **bipolar: y range [−1, 1], default y = 0** — flat at
   zero, meaning velocity modulation of pitch and filter is **off until the
@@ -871,7 +905,8 @@ playback cycling the loop until note-off, then release.
   introduced by this item — unverifiable here under the no-code-reads
   constraint; if absent, this item introduces it. (The former second question
   — amp-curve storage under the MASTER placement — dissolved with the
-  placement's supersession; storage is settled per-zone above.)
+  placement's supersession; storage is settled above — per-zone at the time
+  of that round, now the one parameter set per item 16.)
 
 **Acceptance criteria.**
 
@@ -880,8 +915,9 @@ playback cycling the loop until note-off, then release.
 - The three velocity-curve buttons sit together in a deck group labelled
   **VELOCITY**, immediately to the left of the VOICE group; no velocity-curve
   button appears in MASTER, PITCH, or Filter.
-- The velocity curves follow Sample/Zone panel parity and persist per-zone
+- The velocity curves persist in the instrument's one parameter set and
-  (two zones with different curves audibly differ).
+  round-trip save/reload. (Original per-zone/parity form superseded by
+  item 16; per-zone divergence is no longer expressible.)
 - Opening the pitch or filter curve shows a bipolar editor ([−1, 1]) defaulted
   flat at y = 0; played velocities produce no pitch/filter modulation until a
   curve is drawn, then audibly follow it.
@@ -917,7 +953,13 @@ playback cycling the loop until note-off, then release.
 - **Cross-references.** Item 11 also changes the preview button (glyph); the
   two compose — the glyph button in its new toolbar position. Item 13's
   anti-aliasing audit covers the key-pattern rendering if aliasing turns out
-  to be the cause.
+  to be the cause. **Item 16** (zone retirement) removes the zone count
+  label's referent entirely — this item's removal of the label is doubly
+  settled — and re-grounds what the full-width strip displays: with no zone
+  bars, its surviving jobs are the root affordance (item 15's answer round
+  makes root explicitly resample-stable) and these note-name tooltips;
+  whether any key-range display remains follows item 16's key-range
+  question.
 
 **Acceptance criteria.**
 
@@ -1095,6 +1137,23 @@ follow-up round extends the same rule to item 2's filter envelope.
 > parameters to default, effectively allow reiteration over sounds from
 > within the sampler.
 
+**Daniel's answer round (verbatim, 2026-07-29)** — answering, in order, the
+five questions this item carried as awaiting a Daniel decision:
+
+> 1.  I don't actually care, or even really understand, our zones.  Retire
+>     the zone mapping system, simplify.  I don't expect to use it,
+>     reasampler 9000 becomes 1 capture = one parameter set
+> 2.  capture root (so that parameter is not reset by resampling), for the
+>     gate and velocity questions, we need a popup menu to program note
+>     length, start/end offsets in ms AND in beats, and velocity for the
+>     capture signal.  The popup shoulud have a preview trigger button to
+>     allow previewing the note capture as currently programed.
+> 3. only what is baked into the sample recapture (contours, filter, master
+>    gain, etc)
+> 4. any usage of that capture that is tied by the provenance/recaptureing
+>    system
+> 5. Undo/Recovery is a plus
+
 **Intent.** Close the sound-design loop from inside the instrument: once the
 filtering, pitching, and amp are set up nice, one click bakes that processing
 into the audio itself — a new bank capture — and hands the instrument back at
@@ -1121,8 +1180,9 @@ through.
 - **Replace, or add distinct.** When nothing else references the source
   capture, the recapture **replaces** it as the bank entry; when other
   references exist, the original entry stays and the recapture is **added as
-  a new distinct capture**. (What counts as an "other reference" is an open
+  a new distinct capture**. (What counts as an "other reference" is settled
-  question below.)
+  by the answer round — usage tied by the provenance/recapture system; see
+  the settled bullet below.)
 - **Replacement never destroys audio bytes.** "Replace" means the bank entry
   now denotes the recapture; the superseded file itself is not deleted by
   this action. *(Derived, not a Daniel quote: the settled rule that the
@@ -1138,83 +1198,153 @@ through.
   audio parameters return to default — destructive to the dialed settings
   **by design**: the processing now lives in the recaptured audio, and the
   neutral controls are the starting point for the next iteration. Which
-  parameters "audio parameters" covers is an open question below.
+  parameters "audio parameters" covers is settled by the answer round — see
+  the reset-scope bullet below.
 - **No timeline item, ever.** Resampling is a capture act: it writes a file
   to the bank and updates the index; nothing is placed in the arrange view.
   *(Derived, not a Daniel quote: the tool's load-bearing capture/placement
   separation forces this — any framing of the feature that auto-inserts the
   recapture into the timeline is invalid.)*
+- **Single capture, single parameter set — "the sound" is unambiguous.**
+  Answer 1 dissolves the multi-zone question by **system change, not scoping
+  rule**: the zone mapping system is retired outright — recorded in full as
+  **item 16**. With one capture = one parameter set, one click resamples the
+  instrument's one capture through its one parameter set; no multi-zone rule
+  is needed because no multi-zone state exists. *(Settled by answer round —
+  by reference to item 16.)*
+- **The capture-signal popup.** A **popup menu programs the capture
+  signal**: **note length**, **start and end offsets — in ms AND in
+  beats**, and **velocity**. The popup carries a **preview trigger button**
+  that auditions the capture note exactly as currently programmed — the
+  user hears the bake before committing it — and the offline pass renders
+  that same programmed performance. *(Settled by answer round — a new
+  sub-feature, specced here with its own acceptance criteria below.)*
+  - **The note is the capture's root.** The rendered note is the capture's
+    root note — and, as Daniel states as a consequence, **the root-note
+    parameter is therefore not reset by resampling** (capturing at root is
+    what makes the root parameter survivable: it composes with the
+    reset-scope rule below, and resetting it would detune every subsequent
+    iteration). *(Settled by answer round.)*
+  - **Gate's hold and tail are answered by the programmed window.** The
+    programmed **note length is the Gate hold bound** — the gate holds for
+    the note length, then releases; item 9's loop-sustain cycles within the
+    held span and the render still terminates. The **end offset** is the
+    natural home of the tail policy: captured time past the note's end is
+    where the release rings. *(The hold reading is settled by the answer
+    round; the end-offset-as-tail reading is derived — the natural one, but
+    the offsets' exact anchor points are propose-at-review, below.)*
+  - **Velocity is explicit.** The programmed velocity is the render
+    velocity — material because the velocity transfer curves modulate amp
+    (and, with items 2 and 11, pitch and filter) at that velocity.
+    *(Settled by answer round.)*
+- **Reset scope: only what the bake baked in.** *(Settled by answer round.)*
+  "Reinitialize the audio parameters to default" covers **only the
+  parameters whose effect is baked into the recaptured audio** — Daniel
+  names contours, filter, and master gain, with an explicit "etc". The
+  per-parameter classification follows *(derived, marked as derivation: the
+  rule is Daniel's; the reading-off is not)*:
+  - **Reset** (their effect is in the audio): the envelope contours — staged
+    and spline alike — the filter parameters, master gain, the pitch
+    envelope/engine settings, the velocity transfer curves (their effect at
+    the programmed velocity is in the audio), and the loop points (they
+    shaped the render, and old loop positions are meaningless against new
+    audio).
+  - **Survive** (mapping facts, not present in the audio): the **root
+    note** (explicit in answer 2), and — post-item-16 — whatever remains of
+    key mapping (key-tracking; any key-range concept item 16's open
+    question settles), plus the VOICE group (polyphony behavior leaves no
+    trace in a single rendered note).
+  - Edge classifications are verified at implementation review **against
+    the rule** — not new Daniel calls (open question below).
+- **"Other references" = usage tied by the provenance/recapture system.**
+  *(Settled by answer round.)* Replace-vs-add is decided by whether **any
+  usage of the source capture is tied to it by the provenance/recapture
+  system**: tied usage exists → the original entry stays and the recapture
+  is added distinct; none → replace. Read plainly: the reference universe
+  is the resample system's own lineage records — **not** the
+  prune-protection universe. The answer does not appear to cover bank
+  multi-membership, items placed in the arrange, or a plain hold by another
+  instance outside any recapture lineage — those do not force add-distinct,
+  and need not for safety: the superseded file survives until prune, and
+  prune's protection universe is unchanged and broader than this one. How
+  the provenance/recapture system represents a "usage tie" is part of the
+  lineage question below — answer 4 makes that question load-bearing.
+- **Undo/recovery: a plus, not a requirement.** *(Settled by answer round —
+  at exactly that strength.)* Undo of the bake chain is **desirable but not
+  required**: welcome if it falls out cheaply, and the feature ships
+  without it. The guaranteed recovery path remains the floor already stated
+  above — the superseded file survives on disk until a prune reclaims it.
+  This is a nice-to-have note, not a spec.
 
 **Open questions.**
 
-- **Multi-zone scope — awaits a Daniel decision.** The ask speaks of "the
+- The five awaiting-a-Daniel-decision questions the fourth batch opened
-  sound" and "that sampler capture" in the singular. On an instrument with
+  (multi-zone scope; what the offline pass plays; reset scope; "other
-  multiple zones — or zones referencing different captures — what does one
+  references"; undo/recovery) are **all settled by the answer round** and
-  click resample: is the feature restricted to single-capture setups, does
+  folded into Behavior above. What remains:
-  it bake one zone (which?), or is there a whole-keymap story? The
+- **Capture-window semantics — propose at implementation review.** The
-  single-capture reading is the natural one, but the multi-zone rule — even
+  popup's dual ms/beats denomination is settled; its reference points are
-  if the rule is an explicit restriction — must be chosen, not assumed.
+  not: the natural reading (start offset anchored to note-on, end offset to
-- **What the offline pass plays — awaits a Daniel decision.** "A trigger or
+  note-end, beats resolved against the host tempo) should be proposed
-  gate" presumably follows the active playback mode, but the render
+  concretely at review, along with whether negative offsets are meaningful.
-  performance is otherwise unstated: which note (natural lean: the capture's
+- **Reset-scope edge cases — verify at implementation review.** The rule is
-  root), what velocity (material, because the velocity curves modulate amp —
+  settled (baked-in resets, mapping survives); the per-parameter
-  and, with items 2 and 11, pitch and filter), and for Gate mode a hold
+  classification above is derived. Any parameter whose side of the line is
-  length and tail policy — how long the gate holds (item 9's loop-sustain
+  unclear at implementation time is classified against the rule and
-  makes a held gate indefinite, so *some* bound is required) and how long
+  surfaced at review — not a new Daniel call.
-  the release rings before the capture ends. Trigger mode has a natural
-  answer (play to completion); Gate does not.
-- **Reset scope — awaits a Daniel decision.** Does "reinitialize the audio
-  parameters to default" mean every parameter, or only those whose effect
-  the recapture baked in? Concretely undecided either way: zone key ranges,
-  loop points, the VOICE group, MASTER gain, and the velocity transfer
-  curves — which reset, which survive.
-- **What counts as "other references" — awaits a Daniel decision.** Other
-  sampler instances holding the capture? Items placed in the arrange from
-  it? Its membership in more than one bank? The answer decides when
-  iteration updates the bank entry in place versus forks a distinct
-  capture — i.e., whether a sound something else still depends on can
-  disappear from the bank (its file survives regardless; see Behavior). The
-  prune model already has a settled notion of what protects a file from
-  deletion; whether that same universe governs replace-vs-add here is the
-  decision.
-- **Undo / recovery — awaits a Daniel decision.** The chain is destructive
-  to the dialed settings by design. Is any of it undoable — one undo
-  restoring the bank entry and the instrument's prior parameters — or is
-  the loop deliberately forward-only, with the superseded file's
-  survival-until-pruned the only recovery path? The bank side has a settled
-  one-operation-one-undo convention; the instrument-parameter side has no
-  precedent to lean on.
 - **Extension presence — propose at implementation review.** The instrument
   plays self-contained with the extension absent, but the bank is the
   extension's surface, and resampling mutates the bank. The natural answer
   is that resample requires the extension present and is cleanly
   unavailable — not silently lossy — without it; propose the exact behavior
   at review.
-- **Provenance of the recapture — propose at implementation review.**
+- **Provenance of the recapture — propose at implementation review; now
-  Captures carry a reproducibility fingerprint of their capture recipe; a
+  load-bearing.** Captures carry a reproducibility fingerprint of their
-  resample's recipe is the instrument's own settings, not a track's chain.
+  capture recipe; a resample's recipe is the instrument's own settings, not
-  Whether the recapture records a resample-shaped fingerprint or — the
+  a track's chain. The answer round raises the stakes: replace-vs-add is
-  settled conservative default for ambiguous cases — records nothing is a
+  decided by usage ties in the provenance/recapture system (answer 4), so
+  the settled record-nothing conservative default is no longer available
+  for the lineage half of this question — the recapture must carry whatever
+  record makes answer 4's decision computable. Whether the
+  recipe-fingerprint half records a resample-shaped fingerprint stays a
   propose-at-review call.
 - **Naming and lineage — propose at implementation review.** When
   add-distinct fires, the new capture needs a display name (derived from
   the original?), and the bank some way to read iteration lineage across
-  repeated bakes; propose at review.
+  repeated bakes; propose at review, as one proposal with the provenance
+  question above, on which answer 4 now leans.
+- **Multi-zone migration — owned by item 16, awaits Daniel there.** Not
+  this item's question, but it gates resample on pre-existing multi-zone
+  instances: what such an instance becomes under item 16's migration rule
+  decides what its resample would bake.
 
 **Acceptance criteria.**
 
-- On a dialed-in single-capture instrument, one click yields all of: a
+- On a dialed-in instrument (one capture, one parameter set — item 16), one
-  recapture in the bank, the instance holding that recapture, and the audio
+  click yields all of: a recapture in the bank, the instance holding that
-  parameters at their defaults (per whatever reset scope Daniel settles).
+  recapture, and the baked-in audio parameters at their defaults — with the
+  root note and the other surviving mapping parameters untouched (the
+  settled reset scope).
 - The bake is audible and faithful: after the click, playing what the
-  offline pass played (same note, same velocity, same mode) through the
+  offline pass played (the programmed capture note: root, at the programmed
+  length, offsets, and velocity, in the active mode) through the
   now-neutral controls sounds as the dialed instrument sounded just before
   the click — the processing has moved from the controls into the audio.
+- The capture-signal popup exposes note length, start offset, and end
+  offset — each readable and editable in both ms and beats — plus velocity;
+  its preview trigger auditions the capture note exactly as programmed, and
+  the bake renders that same programmed performance (preview and bake
+  cannot diverge).
+- A Gate-mode bake terminates on its own: the gate holds for the programmed
+  note length, then releases — even with item 9's loop-sustain active, the
+  render ends (no indefinite capture).
+- After the bake the root note is unchanged — iteration never detunes: the
+  next bake plays the same root.
 - Sole-reference case: the bank afterwards shows the recapture where the
   source capture's entry was; no other bank entry is disturbed.
-  Other-references case: the original entry is untouched, a distinct new
+  Other-references case (provenance-tied usage of the original exists): the
-  entry appears, and every other holder of the original sounds exactly as
+  original entry is untouched, a distinct new entry appears, and every
-  before.
+  other holder of the original sounds exactly as before.
 - The click deletes no file: the superseded audio file still exists on disk
   afterwards, and only a later prune — under the settled orphan rules, only
   when nothing references it — can reclaim it.
@@ -1223,3 +1353,97 @@ through.
   the first's result, repeatable indefinitely.
 - Save/reload: an instance holding a recapture reloads and plays it exactly
   like any other loaded capture.
+
+---
+
+## 16 — Enhancement (simplification): retire the zone mapping system — one capture = one parameter set
+
+**Daniel's ask (verbatim, 2026-07-29 — answer 1 of item 15's answer round).**
+
+> I don't actually care, or even really understand, our zones.  Retire the
+> zone mapping system, simplify.  I don't expect to use it, reasampler 9000
+> becomes 1 capture = one parameter set
+
+**Intent.** Simplification by deletion, not a feature: the multi-zone
+keymap — zones with note ranges, per-zone parameters, and the dedicated
+zone-editing surface — comes out of ReaSampler 9000 entirely. Daniel's
+motive is stated plainly: he does not use it, does not care to understand
+it, and wants the instrument simpler. The instrument becomes what its
+common case already is: **one loaded capture played through one set of
+parameters.** This arrived as answer 1 of item 15's answer round — it is a
+far larger change than the question it answers (item 15's multi-zone
+scope), which it dissolves rather than resolves; hence its own item.
+
+**Behavior.**
+
+- **One capture = one parameter set.** (Daniel's words.) The instrument
+  holds one loaded capture and one set of playback parameters governing it.
+  No zones, no per-zone divergence, no keymap of captures.
+- **The zone-mapping surface goes away.** Forced by the decision, not
+  separately decided: the dedicated zone-editing surface and its authoring
+  affordances — add/delete zone, the per-zone parameter panel, and the
+  Low/High/Root zone legend — exist only to author zones and retire with
+  them. (The root note itself survives as a first-class parameter of the
+  one set — item 15's answer round makes it explicitly resample-stable;
+  only its zone-legend housing goes.)
+- **The per-zone/per-instance storage distinction collapses.** Forced:
+  today playback parameters store per-zone, with VOICE and MASTER the
+  per-instance exceptions, and panel parity keeps the two editing surfaces
+  in step. With one parameter set there is nothing to be an exception to
+  and no second surface to keep in parity — every parameter simply belongs
+  to the instrument. Items 2, 9, and 11 carry superseded-by notes where
+  they asserted the per-zone convention.
+- **The single-capture experience is unchanged.** *(Derived, not a Daniel
+  quote: the retirement removes the multi-zone superstructure, not the way
+  a single capture plays — today's single-capture instrument already
+  behaves as one capture with one parameter set.)* A loaded capture still
+  plays across the keyboard repitched from its root, key-tracking still
+  applies, and every queued enhancement (items 1–15) lands on the one
+  parameter set unchanged in substance.
+- **No effect on the bank or the extension.** The zone system is an
+  instrument-side mapping concept; captures, banks, the capture/placement
+  separation, and the prune safety model are untouched.
+
+**Open questions.**
+
+- **Migration of saved multi-zone instances — awaits a Daniel decision.** A
+  project saved with an instance carrying multiple zones — possibly with
+  different parameters per zone, possibly referencing different captures —
+  must become *something* under the one-capture model, and no natural
+  answer exists: adopt one zone's capture and parameters (which one?),
+  refuse to lift and stay silent until re-pointed, or something else. Every
+  option changes what such a saved project sounds like, so the doc's
+  standing sounds-identical migration bar cannot hold for genuinely
+  multi-zone instances — the bar itself needs Daniel's ruling here.
+  (Instances that were single-zone all along — the expected overwhelming
+  majority, per his "I don't expect to use it" — lift losslessly under any
+  answer.)
+- **Does any key-range concept survive? — propose at implementation
+  review.** With zones gone, does the capture respond across the entire
+  keyboard (repitched from root), or does a user-settable low/high playable
+  range survive as a plain parameter of the one set? Lean, consistent with
+  the simplification motive: no range concept — full-keyboard response —
+  with a low/high pair re-addable later as ordinary parameters if missed.
+  Not Daniel-blocking because the lean is cheap to reverse.
+- **What the piano strip means with no zones — propose at implementation
+  review, jointly with item 12.** Item 12 keeps the full-width note-range
+  piano strip and adds note-name tooltips; item 15 needs the root
+  affordance. With no zone bars to draw, the strip's surviving jobs are the
+  root display/affordance and the tooltips — plus a range display only if
+  the key-range question keeps one. Propose the strip's exact contents at
+  review alongside item 12's work.
+
+**Acceptance criteria.**
+
+- The editor exposes no zone-mapping surface anywhere: no zone view or
+  button, no add/delete-zone affordance, no per-zone parameter panel, no
+  Low/High zone legend. The root-note control survives as a first-class
+  parameter.
+- Every playback parameter edits in exactly one place and governs the
+  instrument as a whole; no gesture can express per-zone divergence.
+- A single-capture instance saved before this change reopens sounding
+  identical — same keyboard response, same parameters, same root.
+- A multi-zone instance saved before this change lifts per whatever
+  migration rule Daniel settles (gated on the open question above).
+- The one parameter set round-trips save/reload intact.
+- Bank, capture, placement, and prune behavior are unchanged.