99 lines
5.0 KiB
Markdown
99 lines
5.0 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Support Audio As A First-Class Generation Modality
|
|
|
|
The system SHALL treat audio as a first-class generation modality across routing, task execution, and UI entry points.
|
|
|
|
#### Scenario: Audio default route is configured in presets
|
|
|
|
- **GIVEN** the user manages invocation presets
|
|
- **WHEN** the user selects a default provider-backed model for audio generation
|
|
- **THEN** the preset SHALL store an `audio` route independently from `text`, `image`, and `video`
|
|
|
|
#### Scenario: Audio mode is available in the AI input bar
|
|
|
|
- **GIVEN** the current workspace supports AI generation entry from the input bar
|
|
- **WHEN** the user switches generation type
|
|
- **THEN** the user SHALL be able to choose an `audio` mode
|
|
- **AND** the request SHALL be parsed as an audio generation request rather than being routed through text or video fallbacks
|
|
|
|
### Requirement: Resolve Suno Capability Identifiers Separately From Execution Versions
|
|
|
|
The system SHALL distinguish discovered Suno capability identifiers from the executable version fields required by submit requests.
|
|
|
|
#### Scenario: Discovered Suno capability is not used as submit version directly
|
|
|
|
- **GIVEN** a provider profile exposes discovered capabilities such as `suno_music` or `suno-continue`
|
|
- **WHEN** the user submits a music generation request
|
|
- **THEN** the system SHALL map the chosen capability to an executable binding
|
|
- **AND** SHALL send the actual Suno version through the request field `mv`
|
|
- **AND** SHALL not assume the discovered capability identifier itself is the executable version string
|
|
|
|
#### Scenario: Uploaded continuation appends upload suffix to mv
|
|
|
|
- **GIVEN** the selected audio action represents continuation from an uploaded clip
|
|
- **WHEN** the user submits the request with a base Suno version such as `chirp-v3-5`
|
|
- **THEN** the system SHALL transform the submitted version to the upload variant required by the provider
|
|
- **AND** SHALL keep the rest of the request flow on the same submit endpoint
|
|
|
|
### Requirement: Submit Suno Music Requests Through Provider-Specific Audio Bindings
|
|
|
|
The system SHALL submit Suno music generation requests through provider-specific audio bindings that describe the provider endpoint, request fields, and supported parameters.
|
|
|
|
#### Scenario: Submit a basic music generation request
|
|
|
|
- **GIVEN** the active audio binding targets Suno music generation
|
|
- **WHEN** the user provides lyrics or prompt text and submits an audio request
|
|
- **THEN** the system SHALL send the request to `/suno/submit/music`
|
|
- **AND** SHALL include the selected `mv`
|
|
- **AND** SHALL include `prompt`
|
|
|
|
#### Scenario: Submit music request with optional tags and title
|
|
|
|
- **GIVEN** the active audio binding supports Suno custom music generation fields
|
|
- **WHEN** the user provides `tags` and `title`
|
|
- **THEN** the system SHALL forward those fields in the submit request
|
|
- **AND** SHALL keep them associated with the created audio task
|
|
|
|
#### Scenario: Submit continuation fields when continuing a clip
|
|
|
|
- **GIVEN** the user is continuing an existing clip
|
|
- **WHEN** the user provides `continue_clip_id` and `continue_at`
|
|
- **THEN** the system SHALL include those fields in the submit request
|
|
- **AND** SHALL execute the request through the same provider-specific audio binding
|
|
|
|
### Requirement: Poll Suno Audio Tasks Through Fetch Endpoint
|
|
|
|
The system SHALL poll Suno audio tasks through the provider fetch endpoint and normalize provider statuses into internal task states.
|
|
|
|
#### Scenario: Audio task is queried after submit
|
|
|
|
- **GIVEN** a Suno audio submit request returns a task identifier
|
|
- **WHEN** the system tracks that task asynchronously
|
|
- **THEN** it SHALL query `/suno/fetch/{task_id}`
|
|
- **AND** SHALL update the internal audio task status based on the provider response
|
|
|
|
#### Scenario: Completed Suno task returns audio output
|
|
|
|
- **GIVEN** a Suno fetch response indicates success or completion
|
|
- **WHEN** the result payload includes audio clip data
|
|
- **THEN** the system SHALL extract at least one playable audio URL
|
|
- **AND** SHALL store it in the internal task result for audio history and follow-up actions
|
|
|
|
### Requirement: Expose Audio Parameters In User-Facing Controls
|
|
|
|
The system SHALL expose the audio parameters needed for Suno music generation in user-facing configuration and submission flows.
|
|
|
|
#### Scenario: Audio parameters are editable before submit
|
|
|
|
- **GIVEN** the user is preparing an audio generation request
|
|
- **WHEN** the current binding supports Suno music generation
|
|
- **THEN** the UI SHALL allow the user to review and edit `mv`, `title`, `tags`, and continuation parameters when relevant
|
|
|
|
#### Scenario: Unsupported advanced Suno actions stay hidden from primary flow
|
|
|
|
- **GIVEN** the provider profile exposes additional Suno capabilities beyond initial music generation
|
|
- **WHEN** those capabilities are not implemented in the current product slice
|
|
- **THEN** the primary audio generation flow SHALL not expose them as if they were fully supported submit actions
|
|
- **AND** the runtime MAY preserve their metadata for future expansion
|