docs(todo-1.0): record second fourth-batch answer round

Item 16 migration settled (adopt first zone); item 15 capture window specced, reset scope ratified; new item 17: provenance/usage consolidation. Nothing awaits Daniel.

TODO-1.0.md

@@ -6,7 +6,10 @@ extension-side bugs. Items 1–3 are the first batch, in Daniel's ordering
 item 14 is a third, single-item batch (2026-07-28, later again); item 15 is
 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).
+answer round (the zone mapping system is retired); item 17 (2026-07-29) is
+likewise not a new ask batch — it records the requirement mandated by
+answer 1 of the second fourth-batch answer round (the provenance/usage
+tracking consolidated and made 100% robust).
 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
@@ -107,9 +110,28 @@ 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:
+beats, velocity, and a preview trigger). **Daniel-blocked state after that
-exactly one question awaits a Daniel decision — item 16's migration of saved
+round: exactly one question awaited a Daniel decision — item 16's migration
-multi-zone instances.** Everything else open across items 1–16 is
+of saved multi-zone instances** (since settled; next paragraph).
+
+A **second fourth-batch answer round** (2026-07-29) — one message — settled
+that migration question and answered the doc's three under-specification
+flags. The unnumbered opening line rules the migration: **adopt the first
+zone's capture and parameters** — a lossy rule Daniel accepts because he has
+**no projects with zones in use**; for a genuinely multi-zone instance the
+doc's standing sounds-identical migration bar is **deliberately relaxed**
+(recorded in item 16). Answer 1 converts the doc's provenance-consolidation
+flag into a requirement — **the provenance/usage tracking is to be
+consolidated and made 100% robust** — recorded in full as **item 17**, on
+which item 15's replace-vs-add rule now explicitly depends. Answer 2
+("that's good") ratifies item 15's derived reset-scope classification —
+promoted from derived to confirmed by Daniel. Answer 3 settles the
+capture-window semantics: the start/end offsets anchor to **note-on and
+note-off** of the programmed note; note length is a **musical division**
+(1/64th through 64/1, with dotted and triplet multipliers), not a free
+duration; beats resolve against **the project tempo under the cursor**.
+**Current Daniel-blocked state: no open question anywhere in items 1–17
+awaits a Daniel decision.** Everything still open is
 verify-or-propose-at-implementation.
 
 Ordering note: item 1's curve/overlay treatment explicitly anticipates item 2's
@@ -144,6 +166,13 @@ 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.
+Item 17 (provenance/usage consolidation) is likewise a **prerequisite of
+meaning** for item 15's bank-side half — the replace-vs-add rule is
+computable only once the consolidated lineage records exist — and is
+independent of the editor chain (items 1–14); it reworks tracking machinery
+today's prune protections ride, so those guarantees must hold undiminished
+through the consolidation. Landing it with or before item 15's bank-side
+half is the natural order.
 
 ---
 
@@ -1154,6 +1183,23 @@ five questions this item carried as awaiting a Daniel decision:
 >    system
 > 5. Undo/Recovery is a plus
 
+**Daniel's second answer round (verbatim, 2026-07-29)** — the fourth
+batch's second answer round. The unnumbered opening line answers item 16's
+migration question (carried there); the numbered answers map, in order,
+onto the doc's three under-specification flags: the
+provenance-consolidation flag (→ item 17), this item's derived reset-scope
+classification, and this item's capture-window semantics:
+
+> adopt the first zone's capture and parameters, I don't have any projects
+> with zones used
+>
+> 1. the provenance/usage tracking will need to be consolidated and made
+>    100% robust
+> 2. that's good
+> 3. yeah relative to note-on and note-off of the programed note length
+>    (1/8., 1/4t, 1/16, 4/1 etc (1/64th to 64/1 with dotted and triplet
+>    multipliers)).  the project tempo under the item cursor.
+
 **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
@@ -1225,14 +1271,29 @@ through.
     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.)*
+  - **Note length is a musical division, not a free duration.** The
+    programmed note length is chosen from musical divisions spanning
+    **1/64th through 64/1, with dotted and triplet multipliers** (Daniel's
+    examples: `1/8.`, `1/4t`, `1/16`, `4/1`). *(Settled by second answer
+    round.)*
+  - **Offsets anchor to note-on and note-off.** The start offset is
+    relative to the programmed note's **note-on**; the end offset is
+    relative to its **note-off**. *(Settled by second answer round.)*
+  - **Beats resolve against the project tempo under the cursor.** A
+    beat-denominated value — the note-length division always, the offsets
+    when expressed in beats — resolves to time against **"the project
+    tempo under the item cursor"** (Daniel's phrase; read plainly: the
+    tempo in effect at the project's cursor position when the preview or
+    bake runs). *(Settled by second 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
+    round; the anchors are settled by the second answer round — with the
-    the offsets' exact anchor points are propose-at-review, below.)*
+    end offset anchored to note-off, the tail reading is direct, no longer
+    a derivation.)*
   - **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.
@@ -1241,8 +1302,10 @@ through.
   "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
+  per-parameter classification follows — it began as this doc's derivation
-  rule is Daniel's; the reading-off is not)*:
+  and is now **confirmed by Daniel** ("that's good," second answer round);
+  the record that it originated as a reading-off is preserved, but the
+  reset/survive lists below are ratified, not derived:
   - **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
@@ -1268,7 +1331,11 @@ through.
   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.
+  lineage question below — answer 4 makes that question load-bearing, and
+  the second answer round's answer 1 converts the dependency into a
+  requirement in its own right: **item 17** (the provenance/usage tracking
+  consolidated and made 100% robust), on which this rule now explicitly
+  depends.
 - **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
@@ -1282,41 +1349,48 @@ through.
   (multi-zone scope; what the offline pass plays; reset scope; "other
   references"; undo/recovery) are **all settled by the answer round** and
   folded into Behavior above. What remains:
-- **Capture-window semantics — propose at implementation review.** The
+- **Capture-window residuals — propose at implementation review.** The
-  popup's dual ms/beats denomination is settled; its reference points are
+  second answer round settles the anchors (note-on / note-off), the tempo
-  not: the natural reading (start offset anchored to note-on, end offset to
+  source (the project tempo under the cursor), and note length as a
-  note-end, beats resolved against the host tempo) should be proposed
+  musical division (1/64th–64/1, dotted/triplet). Two residuals remain:
-  concretely at review, along with whether negative offsets are meaningful.
+  whether negative offsets are meaningful (unchanged from before); and a
+  denomination seam — the first answer round expressed the offsets "in ms
+  AND in beats" while note length is now musical-division-only. The plain
+  reading is that the ms/beats duality applies to the offsets only; if an
+  ms display or entry for note length seems wanted at implementation,
+  propose it at review rather than assuming either way.
 - **Reset-scope edge cases — verify at implementation review.** The rule is
-  settled (baked-in resets, mapping survives); the per-parameter
+  settled and the per-parameter classification above is now ratified by
-  classification above is derived. Any parameter whose side of the line is
+  the second answer round ("that's good"). Only a genuinely new parameter —
-  unclear at implementation time is classified against the rule and
+  one arriving with a queued item and absent from the ratified lists — is
-  surfaced at review — not a new Daniel call.
+  classified against the rule and surfaced at review; not a new Daniel
+  call.
 - **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; now
+- **Provenance of the recapture — homed in item 17.** Captures carry a
-  load-bearing.** Captures carry a reproducibility fingerprint of their
+  reproducibility fingerprint of their capture recipe; a resample's recipe
-  capture recipe; a resample's recipe is the instrument's own settings, not
+  is the instrument's own settings, not a track's chain. The answer round
-  a track's chain. The answer round raises the stakes: replace-vs-add is
+  made this load-bearing (replace-vs-add is decided by usage ties, so the
-  decided by usage ties in the provenance/recapture system (answer 4), so
+  settled record-nothing conservative default is no longer available for
-  the settled record-nothing conservative default is no longer available
+  the lineage half — the recapture must carry whatever record makes
-  for the lineage half of this question — the recapture must carry whatever
+  answer 4's decision computable), and the second answer round's answer 1
-  record makes answer 4's decision computable. Whether the
+  converts it into **item 17**, where the consolidation requirement and
-  recipe-fingerprint half records a resample-shaped fingerprint stays a
+  its open questions now live. This item's dependency stands: its
-  propose-at-review call.
+  replace-vs-add half is meaningful only once item 17's consolidated
-- **Naming and lineage — propose at implementation review.** When
+  lineage exists.
-  add-distinct fires, the new capture needs a display name (derived from
+- **Naming and lineage — propose at implementation review, jointly with
-  the original?), and the bank some way to read iteration lineage across
+  item 17.** When add-distinct fires, the new capture needs a display name
-  repeated bakes; propose at review, as one proposal with the provenance
+  (derived from the original?), and the bank some way to read iteration
-  question above, on which answer 4 now leans.
+  lineage across repeated bakes; propose at review as one proposal with
-- **Multi-zone migration — owned by item 16, awaits Daniel there.** Not
+  item 17's lineage-record question, on which answer 4 leans.
-  this item's question, but it gates resample on pre-existing multi-zone
+- (The multi-zone migration question this list previously carried is
-  instances: what such an instance becomes under item 16's migration rule
+  settled in item 16 by the second answer round — adopt the first zone's
-  decides what its resample would bake.
+  capture and parameters; a pre-existing multi-zone instance's resample
+  therefore bakes its first zone's sound.)
 
 **Acceptance criteria.**
 
@@ -1330,11 +1404,16 @@ through.
   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
+- The capture-signal popup exposes: note length as a musical-division
-  offset — each readable and editable in both ms and beats — plus velocity;
+  picker spanning 1/64th to 64/1 with dotted and triplet multipliers;
-  its preview trigger auditions the capture note exactly as programmed, and
+  start and end offsets, each readable and editable in both ms and beats,
-  the bake renders that same programmed performance (preview and bake
+  anchored to note-on and note-off respectively; and velocity. Its preview
-  cannot diverge).
+  trigger auditions the capture note exactly as programmed, and the bake
+  renders that same programmed performance (preview and bake cannot
+  diverge).
+- Beat-denominated values resolve against the project tempo under the
+  cursor: the same programmed division yields a correspondingly different
+  rendered duration when the tempo at the cursor differs.
 - 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).
@@ -1342,9 +1421,10 @@ through.
   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 (provenance-tied usage of the original exists): the
+  Other-references case (provenance-tied usage of the original exists —
-  original entry is untouched, a distinct new entry appears, and every
+  the tie computed by item 17's consolidated tracking): the original entry
-  other holder of the original sounds exactly as before.
+  is untouched, a distinct new entry appears, and every 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.
@@ -1364,6 +1444,12 @@ through.
 > zone mapping system, simplify.  I don't expect to use it, reasampler 9000
 > becomes 1 capture = one parameter set
 
+**Daniel's follow-up (verbatim, 2026-07-29 — the second answer round's
+unnumbered opening line, answering this item's migration question).**
+
+> adopt the first zone's capture and parameters, I don't have any projects
+> with zones used
+
 **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
@@ -1393,6 +1479,24 @@ scope), which it dissolves rather than resolves; hence its own item.
   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.
+- **Migration: adopt the first zone's capture and parameters.** *(Settled
+  by the second answer round.)* A saved multi-zone instance lifts to the
+  one-capture model by adopting its **first zone's** capture and that
+  zone's parameters; the remaining zones' captures and parameters drop
+  from the instance. Dropping a zone touches no file and no bank entry —
+  the instance simply no longer holds those captures; bank and prune
+  behavior are unchanged, per the bullet below. Daniel's stated rationale
+  is what makes a lossy rule acceptable here: **he has no projects with
+  zones in use**, so the migration path carries essentially no real-world
+  risk — no actual project sounds different under it. Consequently, for a
+  genuinely multi-zone instance the doc's standing sounds-identical
+  migration bar is **deliberately relaxed**: such an instance reopens
+  playing its first zone's sound only, and that is the accepted outcome —
+  accepted for that reason. Single-zone instances — the actual universe —
+  lift losslessly and reopen sounding identical, so the bar holds
+  everywhere it has real referents. (Which zone is "first" — the
+  instance's existing zone ordering — is a verify-at-implementation
+  detail with no real-world stakes, given the rationale.)
 - **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
@@ -1406,18 +1510,12 @@ scope), which it dissolves rather than resolves; hence its own item.
 
 **Open questions.**
 
-- **Migration of saved multi-zone instances — awaits a Daniel decision.** A
+- The migration question this item carried as awaiting a Daniel decision
-  project saved with an instance carrying multiple zones — possibly with
+  is **settled by the second answer round** — adopt the first zone's
-  different parameters per zone, possibly referencing different captures —
+  capture and parameters — and folded into Behavior above, with his
-  must become *something* under the one-capture model, and no natural
+  rationale (no projects with zones in use) recorded there. **Nothing in
-  answer exists: adopt one zone's capture and parameters (which one?),
+  this item awaits a Daniel decision.** What remains is
-  refuse to lift and stay silent until re-pointed, or something else. Every
+  propose-at-implementation-review:
-  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
@@ -1443,7 +1541,133 @@ scope), which it dissolves rather than resolves; hence its own item.
   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
+- A multi-zone instance saved before this change reopens holding its first
-  migration rule Daniel settles (gated on the open question above).
+  zone's capture with that zone's parameters — no error, no file touched,
+  no bank entry disturbed. (The sounds-identical bar deliberately does not
+  apply to this case: the instance reopens playing the first zone's sound
+  only — the settled, accepted outcome.)
 - The one parameter set round-trips save/reload intact.
 - Bank, capture, placement, and prune behavior are unchanged.
+
+---
+
+## 17 — Enhancement (requirement): consolidate provenance/usage tracking — one system, 100% robust
+
+**Daniel's ask (verbatim, 2026-07-29 — answer 1 of the second fourth-batch
+answer round).**
+
+> the provenance/usage tracking will need to be consolidated and made 100%
+> robust
+
+**Intent.** A requirement, not a feature: the tracking machinery in the
+provenance/usage territory becomes one coherent, fully robust system. This
+began as a doc flag — item 15's answer 4 made recapture lineage
+load-bearing while the territory's mechanisms were separate and ad-hoc —
+and Daniel's answer converts the flag into a standing requirement. Today
+the territory holds two separately-grown mechanisms plus one new demand:
+(1) the **capture-recipe fingerprint** — a thin reproducibility record of
+how a capture was made, deliberately not a restorable chain, conservatively
+recording nothing when the situation is ambiguous; (2) the **instance-usage
+tracking** — each live instrument instance declares the captures it holds,
+so the prune can never delete a capture a live instance is using, with a
+fail-safe stance that unreadable usage state halts the prune entirely; and
+(3) item 15's demand for **recapture lineage** — records tying usages of a
+capture to it "by the provenance/recaptureing system," deciding
+replace-vs-add at bake time. "Consolidated" plainly means these stop being
+separate ad-hoc mechanisms: one tracking system in which recipe provenance,
+live usage, and recapture lineage are facets of the same record-keeping.
+"100% robust" is a strength statement Daniel chose deliberately: this
+territory gates the system's only file-deletion authority (prune) and its
+only capture-replacement act (item 15's resample) — the two places where a
+tracking error loses a user's audio or sound.
+
+**Behavior.**
+
+- **One system, not three mechanisms.** Recipe provenance, live-instance
+  usage, and recapture lineage are kept by one consolidated tracking
+  system, and every consumer — the prune's protection decision, the
+  resample's replace-vs-add decision, and any future lineage reader — is
+  answered from it.
+- **What "100% robust" observably means.** Daniel stated the strength, not
+  the mechanics; the territory's stakes force three observable
+  implications, recorded without inventing further specifics:
+  - **No silent gaps.** Every capture the system itself creates is tracked
+    from the moment of its creation; a recapture carries its lineage from
+    birth, never backfilled. There is no window in which a
+    system-created file exists untracked.
+  - **Fail-safe on unreadable or ambiguous state.** Tracking state that
+    cannot be read never yields the destructive answer: the prune deletes
+    nothing (today's settled stance — preserved and generalized, not
+    relaxed), and the resample never takes the replace branch on
+    unreadable lineage (whether the safe branch is add-distinct or a halt
+    with a clear message is propose-at-review).
+  - **Consumers cannot disagree.** The prune's protection answer and the
+    resample's tied-usage answer are different questions with different
+    universes — item 15 settles that the replace-vs-add universe is
+    narrower than the prune-protection universe — but both are computed
+    from the same consolidated records, so they cannot drift apart or
+    contradict.
+- **Existing guarantees are the floor.** Consolidation must not weaken
+  anything now settled: the prune still deletes only the system's own
+  orphans and never a referenced or live-held capture; the fail-safe abort
+  on unreadable usage state survives; the recipe fingerprint's
+  record-nothing-when-ambiguous conservatism survives for the recipe half.
+  The lineage half is the one place that conservatism is foreclosed —
+  item 15's answer 4 makes the lineage record mandatory for a recapture,
+  since replace-vs-add must be computable.
+- **Dependency of meaning for item 15.** Item 15's replace-vs-add rule is
+  computable only once this item's consolidated lineage exists; item 15's
+  provenance-of-the-recapture question is homed here, and its
+  naming-and-lineage question is proposed jointly with this item's
+  lineage-record question. This is dependency of meaning, not merely
+  sequencing: without this item, "usage tied by the provenance/recapture
+  system" denotes nothing.
+
+**Open questions.**
+
+- None awaiting a Daniel decision — the requirement and its strength are
+  his; the shape is review work:
+- **The consolidated shape — propose at implementation review.** What "one
+  system" concretely is (one record family, one authority, how the three
+  facets relate) is design work proposed at review, not a Daniel call.
+- **The lineage record — propose at implementation review, jointly with
+  item 15's naming-and-lineage question.** What constitutes a "usage tie,"
+  when it is written, whether it is ever severed, and whether iteration
+  lineage is user-readable from the bank.
+- **The recipe-fingerprint half of a recapture — propose at implementation
+  review.** A resample's recipe is the instrument's own settings, not a
+  track chain; whether the fingerprint records a resample-shaped recipe —
+  and what its conservatism means there — is proposed at review. (The
+  lineage half has no record-nothing option; the recipe half may keep
+  one.)
+- **Never-recorded vs. unreadable — propose at implementation review.**
+  Pre-existing captures predate lineage records, and the two absences
+  demand opposite treatment: never-recorded means no tied usage exists
+  (replace is legitimate, per item 15's settled rule); unreadable means
+  fail-safe. How the consolidated system distinguishes them — and how
+  pre-existing banks lift in without weakening any protection they enjoy
+  today — is proposed at review.
+
+**Acceptance criteria.**
+
+- One consolidated tracking system answers both safety-critical consumers:
+  the prune's protected set and the resample's replace-vs-add decision are
+  each computed from it, per their own settled rules; no separate ad-hoc
+  tracking mechanism remains in the territory.
+- No silent gaps: a recapture created by item 15's bake is tracked from
+  the instant it exists — a bake followed immediately by a prune, or by a
+  second bake, behaves correctly with no window in which the recapture is
+  untracked or its lineage absent.
+- Fail-safe throughout: with tracking state made unreadable, the prune
+  deletes nothing (and reports what blocked it, per today's behavior) and
+  the resample never takes the replace branch; no destructive act follows
+  from ambiguity, anywhere in the territory.
+- Every protection settled today holds undiminished after consolidation: a
+  capture held by a live instance cannot be pruned; files the system did
+  not create are untouchable; unreadable usage state still halts the
+  prune.
+- A pre-existing bank lifts into the consolidated system with no loss of
+  protection and no spurious lineage, and never-recorded remains
+  distinguishable from unreadable.
+- Item 15's other-references case is decidable: for any capture, "does
+  provenance-tied usage exist" has a definite yes/no answer.