Initial TrueGrowth source import
This commit is contained in:
@@ -0,0 +1,74 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Manage Default Model Presets
|
||||
|
||||
The system SHALL allow users to define multiple default model presets for switching between default model combinations.
|
||||
|
||||
#### Scenario: Create a new default model preset
|
||||
|
||||
- **GIVEN** the user opens preset management
|
||||
- **WHEN** the user creates a new preset
|
||||
- **THEN** the preset SHALL be stored independently with its own default model configuration
|
||||
|
||||
#### Scenario: Switch the active preset
|
||||
|
||||
- **GIVEN** multiple presets exist
|
||||
- **WHEN** the user selects a different preset as active
|
||||
- **THEN** subsequent generation requests without an explicit model choice SHALL use the default model references from the newly active preset
|
||||
|
||||
### Requirement: Apply Default Models By Task Type
|
||||
|
||||
Each preset SHALL allow separate default model targets for text, image, and video operations.
|
||||
|
||||
#### Scenario: Use different provider-backed models for text and image generation
|
||||
|
||||
- **GIVEN** a preset assigns a text model from one provider and an image model from another
|
||||
- **WHEN** the user sends a text request and then an image request without explicitly overriding the model
|
||||
- **THEN** each request SHALL use the credentials of the provider that owns the selected default model for its own route type
|
||||
|
||||
#### Scenario: Prevent selecting unsupported routes
|
||||
|
||||
- **GIVEN** a provider profile does not support a required capability such as video generation
|
||||
- **WHEN** the user edits a preset
|
||||
- **THEN** models belonging to that provider SHALL not be offered as valid targets for that unsupported route
|
||||
|
||||
### Requirement: Implicitly Bind Providers Through Model Selection
|
||||
|
||||
Selecting a model for a preset or an explicit user action SHALL implicitly determine the provider route for that request.
|
||||
|
||||
#### Scenario: Selecting a preset model binds the provider automatically
|
||||
|
||||
- **GIVEN** the user is editing the image route of a preset
|
||||
- **WHEN** the user selects a model that belongs to a specific provider profile
|
||||
- **THEN** the preset SHALL store that model reference
|
||||
- **AND** future image requests that rely on preset defaults SHALL resolve through the provider that owns the selected model
|
||||
|
||||
#### Scenario: Explicit user model choice overrides preset default
|
||||
|
||||
- **GIVEN** a preset already has a default model configured for a route type
|
||||
- **WHEN** the user explicitly chooses another provider-backed model at invocation time
|
||||
- **THEN** the current request SHALL use the provider that owns the explicitly selected model
|
||||
- **AND** the preset default SHALL remain unchanged unless the user explicitly saves it back into the preset
|
||||
|
||||
#### Scenario: Explicit model choice does not require a separate provider route setting
|
||||
|
||||
- **GIVEN** the user has already selected a provider-backed model in the runtime UI
|
||||
- **WHEN** the request is submitted
|
||||
- **THEN** the system SHALL resolve the provider credentials from that selected model reference
|
||||
- **AND** SHALL not require a separate provider route selection step
|
||||
|
||||
### Requirement: Keep Presets Valid When Models Change
|
||||
|
||||
The system SHALL protect active routing when selected models are removed or become unavailable.
|
||||
|
||||
#### Scenario: Fallback when a preset model is removed
|
||||
|
||||
- **GIVEN** a preset references a model that is later removed from its provider catalog
|
||||
- **WHEN** the preset is loaded
|
||||
- **THEN** the system SHALL mark that route as needing reassignment or apply a safe fallback model from the same profile
|
||||
|
||||
#### Scenario: Preserve preset routes for unaffected task types
|
||||
|
||||
- **GIVEN** only one route type in a preset becomes invalid
|
||||
- **WHEN** the preset is loaded
|
||||
- **THEN** the remaining valid route types SHALL stay unchanged
|
||||
@@ -0,0 +1,62 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Manage Multiple Provider Profiles
|
||||
|
||||
The system SHALL allow users to create and maintain multiple provider connection profiles at the same time.
|
||||
|
||||
#### Scenario: Add a new provider profile
|
||||
- **GIVEN** the user opens provider configuration
|
||||
- **WHEN** the user creates a new profile with a name, Base URL, and API key
|
||||
- **THEN** the system SHALL save that profile independently from existing profiles
|
||||
|
||||
#### Scenario: Disable a provider profile without deleting it
|
||||
- **GIVEN** an existing provider profile is configured
|
||||
- **WHEN** the user disables that profile
|
||||
- **THEN** the profile SHALL remain stored
|
||||
- **AND** it SHALL not appear as an available routing target until re-enabled
|
||||
|
||||
### Requirement: Keep Model Catalogs Scoped To Profiles
|
||||
|
||||
Each provider profile SHALL own its own discovered and selected model catalog.
|
||||
|
||||
#### Scenario: Discover models for one profile without affecting another
|
||||
- **GIVEN** the user has two provider profiles configured
|
||||
- **WHEN** the user fetches models for one profile
|
||||
- **THEN** the discovered models SHALL be stored only under that profile
|
||||
- **AND** the other profile's discovered models SHALL remain unchanged
|
||||
|
||||
#### Scenario: Preserve selected models per profile
|
||||
- **GIVEN** the user adds selected models under a specific provider profile
|
||||
- **WHEN** the user switches to another profile
|
||||
- **THEN** the selected model set from the first profile SHALL remain intact
|
||||
- **AND** not be merged into the second profile automatically
|
||||
|
||||
### Requirement: Present Profile Summaries In Main Settings
|
||||
|
||||
The main settings surface SHALL summarize provider and model state without expanding full model lists inline.
|
||||
|
||||
#### Scenario: Show compact profile and model summary
|
||||
- **GIVEN** the user has many added models under one or more profiles
|
||||
- **WHEN** the user views the main settings surface
|
||||
- **THEN** the system SHALL show compact counts and status summaries
|
||||
- **AND** SHALL provide an entry into a provider-scoped model management flow instead of rendering the full list inline
|
||||
|
||||
### Requirement: Manage Models Within Provider Configuration
|
||||
|
||||
The system SHALL allow users to discover and select models from within the provider configuration flow, without requiring a separate top-level settings section for model management.
|
||||
|
||||
#### Scenario: Fetch and select models from a provider detail view
|
||||
- **GIVEN** the user is editing a configured provider profile
|
||||
- **WHEN** the user opens model management for that provider
|
||||
- **THEN** the system SHALL fetch and present models in the context of that provider
|
||||
- **AND** SHALL allow the user to save selected models back into that provider's catalog
|
||||
|
||||
### Requirement: Migrate Legacy Single-Provider Settings
|
||||
|
||||
The system SHALL migrate legacy single-provider settings into the new profile model without losing the user's existing configuration.
|
||||
|
||||
#### Scenario: Upgrade from legacy gemini settings
|
||||
- **GIVEN** the user has an existing legacy `gemini` configuration but no multi-profile data
|
||||
- **WHEN** the new settings system initializes
|
||||
- **THEN** the system SHALL create a default provider profile from the legacy values
|
||||
- **AND** preserve the existing default model selections through migration
|
||||
@@ -0,0 +1,57 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Discover Models From Base URL And API Key
|
||||
|
||||
The system SHALL allow users to fetch a provider's available model list using the currently entered Base URL and API key, and SHALL scope the result to the specific provider profile being managed.
|
||||
|
||||
#### Scenario: Normalize root base URL before discovery
|
||||
|
||||
- **GIVEN** the user enters a provider root URL such as `https://api.tu-zi.com`
|
||||
- **WHEN** the system performs model discovery for that provider profile
|
||||
- **THEN** the request SHALL be sent to the normalized models endpoint under `/v1/models`
|
||||
|
||||
#### Scenario: Keep discovery results isolated per profile
|
||||
|
||||
- **GIVEN** the user has multiple provider profiles
|
||||
- **WHEN** the system performs model discovery for one profile
|
||||
- **THEN** the fetched model list SHALL update only that profile's catalog
|
||||
- **AND** SHALL not overwrite the discovered or selected models of other profiles
|
||||
|
||||
#### Scenario: Surface discovery failure without breaking other profiles
|
||||
|
||||
- **GIVEN** the current Base URL or API key cannot fetch a valid model list for one profile
|
||||
- **WHEN** the discovery request fails, returns non-JSON, or returns an empty list
|
||||
- **THEN** the user SHALL receive a visible failure message
|
||||
- **AND** catalogs belonging to other profiles SHALL remain available
|
||||
|
||||
#### Scenario: Discover models from the provider management flow
|
||||
|
||||
- **GIVEN** the user is viewing a provider configuration
|
||||
- **WHEN** the user triggers model management for that provider
|
||||
- **THEN** the discovery request SHALL execute in the context of that provider
|
||||
- **AND** the user SHALL be able to review and save selected models without navigating to a separate top-level model management section
|
||||
|
||||
### Requirement: Reuse Runtime Model Lists Across Selectors
|
||||
|
||||
All model selectors that currently depend on static model lists SHALL resolve models from provider-scoped catalogs while preserving provider provenance, with static models remaining available as system defaults.
|
||||
|
||||
#### Scenario: Selectors show enabled provider-backed models grouped by provider
|
||||
|
||||
- **GIVEN** one or more enabled provider profiles have selected models in their catalogs
|
||||
- **WHEN** the user opens an image, video, or text model selector
|
||||
- **THEN** the selector SHALL show the selected provider-backed models grouped by provider
|
||||
- **AND** SHALL continue to expose system models as fallback options
|
||||
|
||||
#### Scenario: Preset switching updates default selection without hiding provider models
|
||||
|
||||
- **GIVEN** the user switches to another active preset
|
||||
- **WHEN** the model selector is next resolved
|
||||
- **THEN** the selector default value MAY change based on the newly active preset
|
||||
- **AND** the available provider-scoped model list SHALL remain derived from enabled provider catalogs rather than only the active preset
|
||||
|
||||
#### Scenario: Selector keeps model ownership information
|
||||
|
||||
- **GIVEN** a selector shows models from multiple provider catalogs
|
||||
- **WHEN** the user chooses a model
|
||||
- **THEN** the selection result SHALL preserve both `modelId` and owning `profileId`
|
||||
- **AND** subsequent request routing SHALL be able to resolve credentials from that preserved model ownership
|
||||
Reference in New Issue
Block a user