spec: optional per-stem name/description display fields (1.16.0) — FEP #59 - #60
Merged
Conversation
…#59 Additive MINOR: two new OPTIONAL, purely presentational fields on a stems[] entry: - name - short display label for mixers / stem lists; absent => Readers fall back to the id (same rule as arrangements[].name) - description - free-form text saying what the stem is (a click track's count-in, which take an alternate backing carries); a Reader MAY surface it and MAY ignore it The format already allows any number of stems with any ids (only `full` is reserved), so rhythm-guitar / click / alternate-backing stems are legal today — but a Reader had nothing to show for them except the raw id. Stems were the only user-facing manifest list without a display label (arrangements[] and lyric_tracks[] both have `name`). Neither field carries semantics: id stays the stable reference key, and a name on `full` changes none of §5.3's mixdown rules. This PR also cuts release 1.16.0, folding in the pending [Unreleased] FEP #57 change (full-retention SHOULD -> MUST, already version-scoped in spec text to packs declaring >= 1.16.0). manifest.schema.json documents both fields on stemEntry (type-only, matching arrangementEntry.name); the extended example carries a labelled guitar stem and an authored click stem exercising both; version bumped across the guarded locations (spec header + §4.1, README table + citation, CHANGELOG, extended example) and the §4.1 ledger narrates 1.16.0. check_versions passes, both examples validate, 57/57 tests pass, ruff clean, mkdocs --strict builds. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: topkoa <topkoa@gmail.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (5)
📝 WalkthroughWalkthroughFeedpak 1.16.0 adds optional per-stem ChangesFeedpak 1.16.0 specification update
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR lands FEP #59 by adding optional per-stem presentational metadata (name, description) to stems[] entries, and cuts the 1.16.0 spec release while also version-gating the tightened full-retention requirement (FEP #57) to packs declaring feedpak_version >= 1.16.0.
Changes:
- Bump spec/docs/examples to 1.16.0 with release date 2026-07-19.
- Add optional
stems[].nameandstems[].descriptionas display-only fields (no semantics). - Promote
fullretention after separation from SHOULD → MUST for packs declaring 1.16.0+, with corresponding spec and schema text.
Reviewed changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| spec/feedpak-v1.md | Updates version/date, documents new stem display fields, and version-scopes the full retention MUST. |
| schemas/manifest.schema.json | Extends $defs.stemEntry with optional name and description string properties. |
| README.md | Updates the displayed specification version and citation string to 1.16.0. |
| examples/extended.feedpak/manifest.yaml | Updates example pack to feedpak_version: "1.16.0" and exercises new stem display fields. |
| CHANGELOG.md | Cuts the 1.16.0 release section and documents the additive changes and compatibility notes. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lands the FEP #59 proposal and cuts release 1.16.0.
Closes #59
What
Two new OPTIONAL, purely presentational fields on a
stems[]entry (§5.3):name— short display label for mixers / stem lists; absent ⇒ Readers fall back to theid(same rule asarrangements[].name).description— free-form text saying what the stem is (a click track's count-in,which take an alternate backing carries); a Reader MAY surface it and MAY ignore it.
Neither carries semantics:
idstays the stable reference key, and anameonfullchanges none of §5.3's mixdown rules.
Why
The format already allows any number of stems with any ids (only
fullis reserved), sorhythm-guitar / click / alternate-backing stems are legal today — but a Reader had nothing to
show for them except the raw id. Stems were the only user-facing manifest list without a
display label (
arrangements[]andlyric_tracks[]both havename).Release note
Per precedent (1.14.0 / 1.15.0), this PR cuts the release:
[Unreleased]becomes## [1.16.0] - 2026-07-19, folding in the pending FEP #57 change (full-retentionSHOULD → MUST), which the spec text already scoped to packs declaring ≥ 1.16.0. Version
strings bumped across all
check_versions.py-guarded locations; §4.1 ledger narrates 1.16.0.release.ymltags on merge.Files
spec/feedpak-v1.md— header/date, §4.1 version strings + ledger, §5.3 table rows +example + presentational-only note
schemas/manifest.schema.json—stemEntry.name/stemEntry.description(type-only,matching
arrangementEntry.name)examples/extended.feedpak— labelledguitarstem + authoredclickstem (placeholderogg) exercising both fields;
feedpak_version: "1.16.0"README.md,CHANGELOG.md— version bump / release cutVerification
python tools/validate.py examples/minimal.feedpak examples/extended.feedpak— 2/2 validpython tools/check_versions.py— consistent at 1.16.0python -m pytest -q— 57 passedpython -m ruff check tools/ tests/— cleangen_docs.py+mkdocs build --strict— builds🤖 Generated with Claude Code
Summary by CodeRabbit
fullmixdown after separation.