# MVP scope

> This document defines the first complete release: the journey that must work end to end, what each capability delivers at each stage, and the acceptance criteria that decide whethe

Source: https://docs.tune.toys/contributors/mvp/

This document defines the first complete release: the journey that must work end to end, what each capability delivers at each stage, and the acceptance criteria that decide whether it is done. The public MVP is gates P1–P3 in the [roadmap](https://github.com/joshstovall/TuneToys/blob/main/docs/delivery/roadmap.md). No gate is claimed complete; see [implementation status](https://github.com/joshstovall/TuneToys/blob/main/docs/delivery/implementation-status.md).

The user has additionally authorized the [full collaborative community platform](https://docs.tune.toys/contributors/community/). That active objective extends the initial release scope below; social APIs alone do not complete the requested editor, cursor, collaboration and community journeys.

## First complete release

A creator opens a template in the web editor, edits typed nodes, nests a reusable group, exposes stable controls, designs a Frame, saves, publishes and shares a playable link. A second user plays and forks it, bookmarks, tags and rates it, signs into TuneToys Player, loads the cached release in a DAW, automates controls and recalls the session offline.

An agent can propose a graph, group or Frame change through the same revision-checked authoring API, explain the diff, validate it and prepare an audition. Acceptance and publication are separate actions. The app works without the agent service.

The initial reference is a useful stereo effect with live input and packaged test audio. Gain is the foundation's schema example; the product reference adds a musically useful filter/delay once primitive fixtures pass. A small instrument is the next reference so the API never assumes every Toy has audio input.

## Scope by delivery stage

| Capability                          | Foundation delivered here             | First product MVP                                                   | Following release                           |
| ----------------------------------- | ------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------- |
| Portable source                     | Draft schema/types/validator/examples | Versioned authored model and migrations                             | Broader domain models                       |
| Node/group editing and Frame design | Ownership/specification               | Functional web editor, nested groups, explicit membership           | Richer widgets and domains                  |
| Agent authoring                     | Operations/API design                 | In-app prompt for bounded proposals and review                      | Broader tools and providers                 |
| Browser playback                    | Adapter/engine plan                   | Shared DSP with live input and packaged audio                       | More admitted primitives and browsers       |
| Account and sharing                 | Entity/visibility design              | Public/private/unlisted, fork, bookmarks, personal tags, ratings    | Teams, collections, advanced discovery      |
| TuneToys Player VST3                | Shared native plan                    | Account library sync, local cache, automation, offline recall       | Additional DAWs/platforms and AU            |
| Independent Toy plugin export       | Identity and release design           | Feasibility proof required; public automated export follows gate P4 | Managed builds, signing, publisher delivery |
| Hosting                             | Static publication plan               | Share links, immutable revision URLs, small managed hosting         | Custom domains, commercial hosting tiers    |
| Commerce                            | Terms and optional billing foundation | Free releases initially; optional billing foundation                | Paid Toys and publisher tooling             |
| Remote control                      | Protocol/grant design                 | No public remote-control service                                    | Authenticated relay and native host pairing |
| Desktop/mobile/extension/firmware   | Reserved target boundaries            | Excluded                                                            | Desktop first; others by evidence           |

Standalone plugin export remains a core product outcome with an early feasibility spike and a separate public release gate; it is not removed from the platform plan.

## Acceptance criteria

- Another person creates, shares, forks and plays a Toy without editing JSON by hand or needing the original developer's machine.
- A nested definition instantiated twice has independent control values and processing state. Its reusable Frame binds to the selected instance.
- Public parameter IDs survive rename, reorder and UI changes. Agent proposals reject a stale revision and can be undone after acceptance.
- A recipient can access a public or unlisted web release without signing in. Private content and its derived assets remain authorized end to end. Forking follows source and remix permissions.
- Bookmarks, tags and ratings appear in the Player library after authenticated sync; a bookmark does not force a download. Explicit install or load acquires the pinned release.
- Player audio continues if the UI closes or the network fails. A saved DAW project restores its pinned package and parameter mapping offline without credentials in project state.
- Preparation failure leaves the last valid program running. Update notices never hot-replace an active DAW sound.
- A declared browser and one DAW/OS configuration pass the [validation gate](https://github.com/joshstovall/TuneToys/blob/main/docs/delivery/validation.md). All other configurations remain unqualified.

## Explicitly later

Simultaneous collaborative editing, arbitrary user code execution, broad marketplace payments, third-party VST/AU hosting, remote audio streaming, native GPU/video pipelines, lighting outputs and firmware are expansion work. A browser-only video engine and sensing, plus MIDI cables, control nodes and buses on every engine host, shipped in [v0.0.5](https://github.com/joshstovall/TuneToys/blob/main/docs/delivery/sprints/v0.0.5/README.md) as expansion beyond this loop, not as MVP requirements ([signal types and domains](https://github.com/joshstovall/TuneToys/blob/main/docs/architecture/signal-types-and-domains.md)). Their integration boundaries are planned without making them prerequisites to shipping the audio loop.

## Related

- [Vision and vocabulary](https://docs.tune.toys/contributors/vision/), [roadmap](https://github.com/joshstovall/TuneToys/blob/main/docs/delivery/roadmap.md), [validation](https://github.com/joshstovall/TuneToys/blob/main/docs/delivery/validation.md).
- Contracts the criteria depend on: [Toy source format](https://docs.tune.toys/contributors/toy-format/), [operations](https://github.com/joshstovall/TuneToys/blob/main/docs/specs/operations.md), [releases](https://github.com/joshstovall/TuneToys/blob/main/docs/specs/releases.md), [Player authorization](https://github.com/joshstovall/TuneToys/blob/main/docs/specs/player-authorization.md).