diff --git a/PLAN.md b/PLAN.md index bab3f9b..56cf1ea 100644 --- a/PLAN.md +++ b/PLAN.md @@ -223,9 +223,9 @@ A new `api/release` controller — the medium unit is the *release*, not the tra - **Acceptance criteria:** Mix browser lists only Mix releases and shows per-row waveform status; uploading a Mix generates + stores a high-res waveform; the per-row Generate action recovers a missing waveform. - **Prerequisite:** 9.2. - **Open questions:** - - **Genre browse fate.** Renaming the Genre tab to Release Archive takes its slot. Recommend keeping `CmsGenreBrowser` route-reachable but tab-less (it's built and works), not retiring genre browse wholesale. Confirm with Daniel. + - **Genre browse fate.** Resolved: the Genre tab slot is taken by Release Archive (Wave 3A as specced); the existing genre browse functionality is deprioritized and stays route-reachable as-is — no active development, no retirement. The team should not remove it. - **Waveform preprocessor reuse.** Is the existing preprocessor factored to accept a resolution parameter, or does 9.3.C include a refactor to share one pipeline across player-bar and Mix? Recommend one parameterized pipeline. - - **Single-track invariant.** Is "single track per Session/Mix" a hard upload constraint (drop the multi-track master list for those media) or a convention? Recommend enforce — it simplifies both form and detail view. + - **Single-track invariant.** Resolved: hard constraint. One track per Session/Mix release is enforced at upload — the CMS form for those media drops the multi-track master list entirely. --- @@ -241,7 +241,7 @@ A new `api/release` controller — the medium unit is the *release*, not the tra - **Why:** Honour the existing studio-release browse under the new medium taxonomy. Lowest-effort of the three media. - **Shape:** Parameterize `AlbumsView`'s data load with a medium filter rather than forking a component. `/cuts` = `AlbumsView` with `Medium == Cut`. - **Acceptance criteria:** `/cuts` shows only `Cut` releases with the current AlbumsView ergonomics. - - **Open question:** Does the current Releases/`AlbumsView` route redirect to `/cuts` or stay an all-media view? Small routing call. + - **Resolved:** When `/cuts` lands, the existing `/albums` route issues a redirect to `/cuts`. Old URLs keep working; no hard 404. - **9.4.C — SESSIONS (`/sessions` + `/sessions/{id}`).** - **What:** Gallery of session cards (cover, session name, artist) at `/sessions`; detail at `/sessions/{id}` mirroring `TrackDetail` but with the **hero image dominant above the fold**, cover secondary. - **Why:** Sessions are an authored content kind the home page advertises; the hero image is their distinctive visual. diff --git a/product-notes/phase-9-release-medium-types.md b/product-notes/phase-9-release-medium-types.md index 5b99ba8..ada7ad3 100644 --- a/product-notes/phase-9-release-medium-types.md +++ b/product-notes/phase-9-release-medium-types.md @@ -426,26 +426,20 @@ above-the-fold without polluting the others. 1. **Waveform storage shape (§2.3).** Vault blob + `WaveformEntryKey` (recommended) vs. JSON column on `MixMetadata`. Determines whether Wave 1 touches the vault abstraction. *Recommend vault blob.* -2. **Genre browse fate (§3.1).** "Rename the Genre tab to Release Archive" takes the third tab's - slot. Does genre browsing survive (route-reachable but tab-less — recommended), move under the - Cut browser as a secondary filter, or retire in the CMS? *Recommend keep route-reachable.* +2. **Resolved: Genre browse fate (§3.1).** Daniel's decision: the Genre tab slot is taken by Release Archive (Wave 3A as specced); the existing genre browse functionality is deprioritized and stays route-reachable as-is — no active development, no retirement. The team should not remove it. 3. **Waveform preprocessor reuse (§3.4).** Is the existing player-bar waveform preprocessor factored to accept a resolution parameter, or does Wave 3 track C include a refactor to share one pipeline across player-bar (low-res) and Mix (high-res)? *Recommend one parameterized pipeline.* 4. **Detail-page strategy (§5.3).** Three separate detail pages vs. one branching `TrackDetail` vs. shared `ReleaseDetailScaffold` + per-medium hero slot (recommended). Sets the public-site Wave 4 shape. *Recommend the scaffold.* -5. **Old releases route (§5.2).** Does the current Releases/`AlbumsView` route redirect to `/cuts`, - or stay as an all-media view? *Small routing call.* +5. **Resolved: Old `/albums` route fate (§5.2).** Daniel's decision: when `/cuts` lands, the existing `/albums` route issues a redirect to `/cuts`. Old URLs keep working; no hard 404. 6. **Nav model children (§5.1).** Extend `MenuPages` with an optional `Children` collection (recommended, generalizes) vs. hardcode ARCHIVE as a bespoke popover component. *Recommend the model extension.* 7. **`MixWaveformVisualizer` seek-on-click (§5.4).** Design the position-binding seam now even if click-to-seek ships later? *Recommend design the seam, defer the feature.* -8. **Single-track invariant for Session/Mix (§3.3).** Sessions and Mixes are "single-track." Is that - a hard constraint enforced at upload (one track per Session/Mix release), or a convention? If - hard, the CMS upload form for those media should drop the multi-track master list entirely. - *Recommend enforce — it simplifies both the form and the detail view.* +8. **Resolved: Single-track invariant for Session/Mix (§3.3).** Daniel's decision: hard constraint. One track per Session/Mix release is enforced at upload — the CMS form for those media drops the multi-track master list entirely. ---