From 92827c59be43f88116eab366917acc2ebf8ed7a5 Mon Sep 17 00:00:00 2001 From: daniel-c-harvey Date: Thu, 23 Jul 2026 20:10:54 -0400 Subject: [PATCH] Lock M10 provenance spec to Daniel's fork picks (P1=a, P2=a) Settle the reshaped Milestone 10: thin capture-recipe fingerprint and bank-only re-capture; P3/P4 closed as moot. Remove the pending-picks banner in PLAN.md and stamp the provenance product note as settled. --- PLAN.md | 40 +++++++++--------- docs/product/provenance.md | 83 +++++++++++++++++++++----------------- 2 files changed, 66 insertions(+), 57 deletions(-) diff --git a/PLAN.md b/PLAN.md index 4044378..6e2960b 100644 --- a/PLAN.md +++ b/PLAN.md @@ -28,26 +28,26 @@ state persists via the index. fingerprint) on resample-from-sample, and ship a **"re-capture from source"** action that regenerates a sample from its recorded source. Reconciled with the dual-canvas (Phase D2) model. CONTEXT.md §Data model, §capture; product framing + -the reconciliation forks in `docs/product/provenance.md`. +the settled reconciliation in `docs/product/provenance.md`. **Verify (in DAW):** A sample resampled from a bank sample carries its parent id + recipe fingerprint; "re-capture from source" regenerates the file into the bank (never auto-inserting into the timeline — load-bearing principle); re-capture with an unchanged source + request is byte-identical to the original (bit-identical repeats); non-destructive to source items/tracks. -> **PROPOSAL — pending Daniel's fork picks (2026-07-23).** Reshaped from the old -> "provenance + null-test verify" M10. **Cut (fixed by Daniel):** the null-test -> verification *action* and the true-pre-FX-dry *mechanism* the old note required — -> both dropped, see `docs/product/provenance.md` §What was cut. **Kept:** provenance -> + re-capture. The `Sample.provenance` struct and its JSON round-trip **already -> exist** (M1) — M10 populates and consumes the field, it does not add it. The points -> below reflect the **leaned path** (bank-only re-capture, thin fingerprint); the -> re-place variant is deferred behind forks P2–P4. Lock the points once Daniel picks. +> **Reshaped from the old "provenance + null-test verify" M10.** **Cut (fixed by +> Daniel):** the null-test verification *action* and the true-pre-FX-dry *mechanism* +> the old note required — both dropped, see `docs/product/provenance.md` §What was +> cut. **Kept:** provenance + re-capture. The `Sample.provenance` struct and its JSON +> round-trip **already exist** (M1) — M10 populates and consumes the field, it does +> not add it. Fork picks settled by Daniel (2026-07-23): **P1=a thin fingerprint, +> P2=a bank-only re-capture**; P3/P4 moot under P2=a. The points below are locked to +> that path. - [ ] Populate `Sample.provenance` on resample-from-sample: `parentSampleId` (the - bank sample the capture derived from) + `fxChainSnapshot` as a **capture-recipe - fingerprint** (scope + source FX-chain identity at capture time — a drift/repro - fingerprint, NOT a pre-FX-dry chain; see product note fork P1). + bank sample the capture derived from) + `fxChainSnapshot` as a **thin capture-recipe + fingerprint** (scope + source FX-chain identity/hash at capture time — a drift/repro + fingerprint, NOT a serialized pre-FX-dry chain to restore; P1=a settled). - [ ] "Re-capture from source" action: regenerate a provenanced sample by re-running its recorded capture request against the source's **current** state; update the bank file + Sample in place. **Bank-only — never inserts/re-places into the @@ -56,14 +56,14 @@ repeats); non-destructive to source items/tracks. capture (bit-identical repeats); non-destructive (`FxBypassGuard` snapshot/restore as M7); relative-paths-only preserved. -**Dual-canvas reconciliation (forks for Daniel — `docs/product/provenance.md`):** -Under the leaned path (bank-only re-capture) provenance is **pure per-sample bank -metadata**, `bank_model` and `view_mode_model` **stay decoupled**, and M10 touches -no canvas code — compliance is satisfied by staying on the right side of the -capture-never-places line. Forks P3 (canvas/lane memory in provenance) and P4 -(re-capture auto-tag interaction) only wake up if Daniel wants **P2 = -re-capture-and-replace-on-timeline**, which would make re-place a mode-aware -placement. Awaiting picks on P1 (fingerprint shape) and P2 (re-capture scope). +**Dual-canvas reconciliation (settled — `docs/product/provenance.md`):** With +bank-only re-capture (P2=a), provenance is **pure per-sample bank metadata**, +`bank_model` and `view_mode_model` **stay decoupled**, and M10 touches **no** canvas +code. Dual-canvas compliance is satisfied by staying on the right side of the +capture-never-places line — not by any new coupling. Forks P3 (canvas/lane memory in +provenance) and P4 (re-capture auto-tag interaction) were only live under +re-capture-and-replace (P2=b) and are **closed as moot**; if the user manually +re-places a regenerated sample, the existing D2 mode-aware placement rule governs. ## Milestone 11 — polish **Goal:** Batch capture (per selected item / per razor area), diff --git a/docs/product/provenance.md b/docs/product/provenance.md index b649b2b..93eac29 100644 --- a/docs/product/provenance.md +++ b/docs/product/provenance.md @@ -6,11 +6,12 @@ authoritative technical detail is `CONTEXT.md` (§Data model, §capture) plus th note for the reconciliation calls. This doc holds the *why* and the open forks so they don't clutter the build docs. -Status: **PROPOSAL, pending Daniel's sign-off (2026-07-23).** Reshaped from the -old "provenance + null-test verify" M10. Two decisions are fixed by Daniel and are -**not** reopened here (see *What was cut* below). The remaining content is the -provenance-only shape plus the dual-canvas interaction forks Daniel needs to -settle. +Status: **SETTLED (2026-07-23).** Reshaped from the old "provenance + null-test +verify" M10. Two decisions were fixed by Daniel up front (see *What was cut* below). +The four dual-canvas interaction forks are now resolved: **P1=a thin fingerprint, +P2=a bank-only re-capture**, which makes **P3 and P4 moot (closed)**. The fork +analysis below is retained as the rationale record — each fork is stamped with its +resolution inline; nothing here is open. --- @@ -72,7 +73,8 @@ bit — enough of the **source FX-chain identity at capture time** that "re-capt from source" can tell whether the source still matches what was captured. This is a *fingerprint for reproducibility*, not a mechanism for a different render mode. -> **Fork P1 — how much chain state does `fxChainSnapshot` carry?** Two shapes: +> **Fork P1 — how much chain state does `fxChainSnapshot` carry? — CHOSEN: (a) +> thin fingerprint (Daniel, 2026-07-23).** Two shapes: > **(a) thin fingerprint** — a hash/summary of the source scope + FX-chain identity > at capture time, used only to detect drift ("source has changed since capture") > and to re-run the *same* capture request; or **(b) fat snapshot** — a full @@ -85,7 +87,8 @@ from source" can tell whether the source still matches what was captured. This i > most naturally means "run the capture again against the source's *current* state" > — that's the useful workflow (I changed the source, give me the updated sample). > The fingerprint's job is to *tell* the user the source drifted, not to freeze it. -> Confirm this is the intent before scoping. +> **Resolved 2026-07-23: (a). `fxChainSnapshot` is a capture-recipe fingerprint for +> drift detection and re-run — not a serialized chain to restore.** --- @@ -119,7 +122,7 @@ onto the timeline (replacing the old placed item). That is a *placement*, and placement is mode-aware under D2. > **Fork P2 — does "re-capture from source" re-place, or only refresh the bank -> entry?** Two shapes: +> entry? — CHOSEN: (a) bank-only re-capture (Daniel, 2026-07-23).** Two shapes: > **(a) bank-only re-capture** — regenerate the file + update the bank Sample > in place; the user re-places manually if they want the new version on the > timeline. Fully honors the load-bearing principle with zero canvas coupling; @@ -132,6 +135,9 @@ placement is mode-aware under D2. > pillar's clean "capture never places" line and defers all the canvas-placement > complexity. (b) can be a later opt-in ("re-capture and replace in place") once (a) > proves the provenance thread. If Daniel wants (b), P3 and P4 below become live. +> **Resolved 2026-07-23: (a). Re-capture regenerates the file into the bank and +> updates the Sample in place; it never places/replaces on the timeline. P3 and P4 +> are therefore moot — closed (b) can still be revisited as a later opt-in.** ### Does provenance need to record canvas/mode membership? @@ -146,7 +152,8 @@ it needs no canvas memory; the bank stays mode-agnostic and the two pure modules stay decoupled. Under P2 = (b) re-place, the answer becomes **yes, partially**. > **Fork P3 — (only live if P2 = re-place) does provenance store canvas/lane -> membership?** If re-capture re-places, where does it land? +> membership? — CLOSED/moot under P2=a (2026-07-23).** If re-capture re-places, where +> does it land? > **(a) active-mode rule** — re-placement follows the *same* D2 auto-tag/placement > rule as any explicit placement: it lands in whatever mode is active *now*. > Provenance stores **nothing** about canvas; the view model's existing rule @@ -159,6 +166,9 @@ stay decoupled. Under P2 = (b) re-place, the answer becomes **yes, partially**. > avoids. **Lean: (a) active-mode rule**, kept in the view model; provenance stays > pure bank metadata with no view-model ids. Only reach for (b) if "re-capture > restores the exact original lane" is a stated requirement. +> **Closed 2026-07-23: moot under P2=a. Re-capture never places, so it stores no +> canvas memory; provenance stays pure bank metadata and the two modules stay +> decoupled. Revisit only if re-capture-and-replace (P2=b) is later adopted.** ### Re-capture and auto-tagging @@ -171,29 +181,31 @@ must tag the new item explicitly and **suppress** the auto-tag for that GUID (or two fight). > **Fork P4 — (only live if P2 = re-place AND P3 = origin-lane) does re-capture -> preserve or re-run auto-tagging?** If provenance restores the origin lane, the +> preserve or re-run auto-tagging? — CLOSED/moot under P2=a (2026-07-23).** If +> provenance restores the origin lane, the > re-placed item must be tagged to the *origin* mode, not the active mode — so > re-capture has to write the membership itself and exempt that GUID from the > timer's auto-tag (same class as the manual-lane exemption already in > `autoTagNewContent`). **This fork only exists under P2=(b) + P3=(b).** Under the > leaned defaults (P2=a, or P2=b + P3=a) it does not arise: bank-only re-capture > places nothing, and active-mode re-placement rides the existing auto-tag path -> unchanged. +> unchanged. **Closed 2026-07-23: moot under P2=a — bank-only re-capture places +> nothing, so no auto-tag interaction arises.** -### Summary of the leaned path +### Summary of the settled path -If Daniel takes the leans (**P1=a thin fingerprint, P2=a bank-only re-capture**), -the reconciliation collapses to almost nothing: provenance is **pure per-sample -bank metadata**, `bank_model` and `view_mode_model` **stay decoupled**, and M10 -touches **no** canvas code. The dual-canvas compliance is satisfied by *staying on -the right side of the load-bearing line* (capture/re-capture never places), not by -new coupling. P3 and P4 only wake up if Daniel wants re-capture to also re-place -onto the timeline. +Daniel took the leans (**P1=a thin fingerprint, P2=a bank-only re-capture**, +2026-07-23), so the reconciliation collapses to almost nothing: provenance is +**pure per-sample bank metadata**, `bank_model` and `view_mode_model` **stay +decoupled**, and M10 touches **no** canvas code. The dual-canvas compliance is +satisfied by *staying on the right side of the load-bearing line* (capture/re-capture +never places), not by new coupling. P3 and P4 are moot (closed) — they were only +live if re-capture also re-placed onto the timeline. -This is the recommendation: **keep provenance in the bank, keep re-capture a -bank-only regenerate, and let the existing D2 placement rule handle the timeline if -and when the user manually re-places.** It is the smallest thing that delivers the -useful workflow and the cleanest against the architecture. +The settled shape: **keep provenance in the bank, keep re-capture a bank-only +regenerate, and let the existing D2 placement rule handle the timeline if and when +the user manually re-places.** It is the smallest thing that delivers the useful +workflow and the cleanest against the architecture. --- @@ -225,19 +237,16 @@ useful workflow and the cleanest against the architecture. --- -## Open forks for Daniel (the decision list) +## Decision list (settled 2026-07-23) -1. **P1 — `fxChainSnapshot` shape:** thin reproducibility fingerprint *(lean)* vs. - fat serialized FX-chain chunk. -2. **P2 — re-capture scope:** bank-only regenerate *(lean)* vs. - re-capture-and-replace-on-timeline. -3. **P3 — (only if P2=replace) canvas memory:** re-place follows the active-mode - rule, provenance stores no view ids *(lean)* vs. provenance records origin - mode/lane and restores it. -4. **P4 — (only if P2=replace AND P3=origin-lane) auto-tag interaction:** re-capture - writes origin-mode membership and exempts the GUID from the timer auto-tag. Only - live under the two non-leaned choices above. +1. **P1 — `fxChainSnapshot` shape: CHOSEN (a) thin reproducibility fingerprint.** + (Rejected: (b) fat serialized FX-chain chunk.) +2. **P2 — re-capture scope: CHOSEN (a) bank-only regenerate.** (Rejected for now: + (b) re-capture-and-replace-on-timeline; may return as a later opt-in.) +3. **P3 — canvas memory: CLOSED/moot under P2=a.** Was only live under P2=b; lean + was (a) active-mode rule, provenance stores no view ids. +4. **P4 — auto-tag interaction: CLOSED/moot under P2=a.** Was only live under P2=b + + P3=b. -The leaned path (1a, 2a) makes 3 and 4 moot and keeps M10 a small, decoupled, -capture-pillar milestone. Awaiting Daniel's picks before the PLAN M10 points are -locked. +Picks 1a + 2a make P3 and P4 moot and keep M10 a small, decoupled, capture-pillar +milestone. The PLAN M10 points are locked to this path.