v1 backlog — MoSCoW prioritization
Prioritized requirements for the Rymflux v1 release. Must = MVP. Won't = explicitly excluded from v1.
v1 backlog — MoSCoW prioritization
Must (MVP)
| # | Item | Rationale | FR / NFR |
|---|---|---|---|
| M1 | Plugin manifest parsing and validation | Without manifests, plugins cannot declare their identity or capabilities | FR-PLUGIN-2 |
| M2 | Plugin filesystem discovery | Without discovery, no plugin can be installed | FR-PLUGIN-1 |
| M3 | Plugin process lifecycle (launch, request, timeout, crash recovery) | Without lifecycle, plugins cannot be used | FR-PLUGIN-3 |
| M4 | Plugin search capability (request/response protocol) | Core value: finding content across sources | FR-PLUGIN-4 |
| M5 | Plugin stream capability (URL mode) | Core value: playing audio from plugins | FR-PLUGIN-5 |
| M6 | Plugin metadata capability (get_track, get_album, get_artist) | Required for browsing and displaying content | FR-PLUGIN-6 |
| M7 | Standardized data models (Track, Album, Artist, SearchResult, StreamInfo) | Without standard models, results from different plugins are incomparable | FR-PLUGIN-4, FR-PLUGIN-5, FR-PLUGIN-6 |
| M8 | Source-agnostic playback engine (URL and file path) | Cannot play audio without it | FR-CORE-1 |
| M9 | Queue management (add, remove, reorder, persistent across rooms) | Core user expectation | FR-CORE-2 |
| M10 | Unified library with source-independent content IDs | Core platform philosophy | FR-CORE-3, FR-ID-1 |
| M11 | Parallel search manager with per-plugin timeout | Core value: cross-source search | FR-CORE-4 |
| M12 | Music Room — browse, search, player expansion | The only room in v1; the entire user-facing experience | FR-MUSIC-1, FR-MUSIC-2 |
| M13 | Home (Lobby) — continue listening, recently played, pinned rooms | Landing page and navigation hub | FR-HOME-1 |
| M14 | Room framework — registration and lifecycle | Required for any room to exist | FR-ROOM-1 |
| M15 | Reference local-files plugin | Without it, the platform has no content at launch | FR-REF-1 |
| M16 | Plugin debugging (stdout/stderr capture, plugin health) | Required for plugin developers to diagnose issues | Scope §1 |
| M17 | Plugin protocol specification (written) | Required for anyone to write a plugin | Scope §6 |
Should
| # | Item | Rationale | FR / NFR |
|---|---|---|---|
| S1 | Room search integration (room-provided filters) | Improves search relevance per room but not required for v1 Music Room | FR-ROOM-2 |
| S2 | Room player expansion customization | Music Room can ship with a hardcoded expansion; framework API can follow | FR-ROOM-3 |
| S4 | Cross-platform support (macOS, Windows) | Linux-first v1 is viable; additional platforms increase test surface | NFR-COMPAT-1 |
| S5 | Queue durability across restarts | Important but v1 can start with in-memory queue and add persistence later | NFR-REL-3 |
| S6 | Library data integrity checks | Important but not required for initial functional release | NFR-REL-4 |
| S7 | Plugin idle timeout and resource limits | Important for long-running sessions but not required for MVP | NFR-RESC-3 |
| S8 | Keyboard navigation for core controls | Important for accessibility but can be added post-MVP | NFR-A11Y-1 |
Could
| # | Item | Rationale |
|---|---|---|
| C1 | Plugin lyrics capability (v2) | Deferred. Protocol method, data model, and Tauri command cut from v1 scope. Revisit when a concrete plugin requests the capability. FR-MUSIC-2 lyrics scenario removed. |
| C2 | Plugin health dashboard — platform UI showing plugin logs, resource usage, and status | CLI-based debugging suffices for v1; a GUI dashboard is polish |
| C3 | Content deduplication in search results | Important for UX but complex; v1 can show duplicates and refine later |
| C4 | Screen reader support | Important but v1 is a desktop app with limited a11y resources |
| C5 | Externalized UI strings for i18n | v1 is English-only; externalization enables community translations |
| C6 | Conformance validator tool for plugin authors | Important for developer experience but not required for first plugin |
| C7 | Versioning and changelog for plugin API | Required before public API release but not for first internal plugin |
Won’t (v1)
| # | Item | Rationale | Revisit |
|---|---|---|---|
| W1 | Additional rooms (Podcast, Audiobook, Radio, Meditation, Educational) | Room framework must be stable first | v2 |
| W2 | Plugin hot-reload (detect new plugins without restart) | Startup scan is sufficient for v1 | v2 |
| W3 | Plugin permissions system beyond capability declarations | Trust model (user-installed) is acceptable for v1 | v2 |
| W4 | Official plugin SDKs (Go, Python, etc.) | Protocol spec is sufficient; SDKs reduce friction but are not required | v2 |
| W5 | Event bus / event system | Direct calls between core components are acceptable for v1 | v2 |
| W6 | User accounts, cloud sync, authentication | v1 is local-first and single-user | v2+ |
| W7 | Mobile or web UIs | v1 is desktop only | v2+ |
| W8 | Advanced playback (gapless, crossfade, audio normalization) | Standard playback is sufficient | v2+ |
| W9 | Core-managed offline downloads | Plugins may handle their own caching | v2+ |
| W10 | Plugin registry / app store | Manual install via directory copy is v1 | v2+ |
| W11 | Extension points beyond plugins (search ranking plugins, recommendation plugins, widget plugins) | Plugin system must be proven first | v2+ |
| W12 | Plugin streaming mode — pipe (raw bytes over IPC) | Binary framing on stdin/stdout is risky for v1. ADR-006 demotes this; revisit when a concrete plugin author requests it. | v2+ |
Revisit cadence
- Must and Won’t are re-evaluated at each phase gate.
- Should and Could are reordered at each sprint planning.
- Items can move between buckets only with Tech Lead + Product Owner agreement (see R6 in risk register).
Related
- Functional requirements — detailed Gherkin acceptance criteria
- Non-functional requirements — measurable NFR targets
- Charter scope — scope boundaries