3.1 KiB
3.1 KiB
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
modelIdand owningprofileId - AND subsequent request routing SHALL be able to resolve credentials from that preserved model ownership