Jammy/TrueGrowth
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial TrueGrowth source import

Browse Source
This commit is contained in:
Jammy
2026-07-07 09:36:36 +08:00
commit 3b6781d695
2283 changed files with 691996 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

74
openspec/changes/update-image-api-compatibility-modes/specs/image-generation/spec.md Normal file
View File

@@ -0,0 +1,74 @@
## ADDED Requirements
### Requirement: Keep Official GPT Image On The Dedicated Official Adapter
The system SHALL keep official GPT Image generation and edit requests on the dedicated official adapter path.
#### Scenario: Official GPT text-to-image uses the official adapter
- **GIVEN** a provider profile resolves image API compatibility to `openai-gpt-image`
- **AND** the selected model is a GPT Image model
- **WHEN** the user submits a text-to-image request
- **THEN** the request SHALL be handled by the dedicated official GPT image adapter
- **AND** SHALL use `/images/generations`
#### Scenario: Official GPT edit uses the official edit transport
- **GIVEN** a provider profile resolves image API compatibility to `openai-gpt-image`
- **AND** the selected model is a GPT Image model
- **AND** the request includes edit inputs
- **WHEN** the image task executes
- **THEN** the dedicated official GPT image adapter SHALL send the request to `/images/edits`
- **AND** SHALL use multipart/form-data
### Requirement: Route Tuzi GPT Generation Through A Dedicated Tuzi Adapter
The system SHALL route Tuzi GPT generation through a dedicated Tuzi GPT image adapter instead of the generic default/basic adapter.
#### Scenario: Tuzi GPT generation uses dedicated adapter ownership
- **GIVEN** a provider profile resolves image API compatibility to `tuzi-gpt-image`
- **AND** the selected model is a GPT Image model
- **WHEN** the user submits a text-to-image request
- **THEN** the request SHALL be handled by the dedicated Tuzi GPT image adapter
- **AND** SHALL NOT rely on GPT-specific translation logic hidden inside the generic default/basic adapter
### Requirement: Keep Generic Basic Compatibility As Fallback
The system SHALL preserve a generic fallback path for broad OpenAI-compatible image gateways.
#### Scenario: Generic compatibility still uses the default adapter
- **GIVEN** a provider profile resolves image API compatibility to `openai-compatible-basic`
- **WHEN** the user submits an image request
- **THEN** the request SHALL remain eligible for the default/basic image adapter
### Requirement: Keep Official Quality Semantics Separate From Legacy Resolution Folding
The system SHALL keep official GPT image quality semantics separate from legacy compatibility resolution semantics.
#### Scenario: Official GPT forwards official quality values
- **GIVEN** a provider profile resolves image API compatibility to `openai-gpt-image`
- **AND** the request includes official GPT image quality such as `auto`, `low`, `medium`, or `high`
- **WHEN** the request is serialized
- **THEN** the outbound official GPT request SHALL preserve the official quality meaning
#### Scenario: Tuzi GPT folds compatibility resolution into legacy quality
- **GIVEN** a provider profile resolves image API compatibility to `tuzi-gpt-image`
- **AND** the request includes a compatibility resolution tier such as `1k`, `2k`, or `4k`
- **WHEN** the request is serialized
- **THEN** the Tuzi GPT adapter SHALL translate that compatibility resolution into the outbound Tuzi/basic quality field
- **AND** SHALL NOT blindly forward official GPT quality values unless the Tuzi contract explicitly supports them
### Requirement: Prepare Tuzi Edit Support Without Rebinding It To Generic Fallback
The system SHALL leave room for a future Tuzi GPT edit contract without requiring it to live permanently inside the generic fallback adapter.
#### Scenario: Tuzi edit remains a dedicated follow-up
- **GIVEN** a provider profile resolves image API compatibility to `tuzi-gpt-image`
- **WHEN** the system later adds image-edit support for that mode
- **THEN** the implementation SHALL route through the Tuzi GPT adapter boundary
- **AND** SHALL NOT require the generic fallback adapter to become the long-term owner of Tuzi GPT edit semantics

48
openspec/changes/update-image-api-compatibility-modes/specs/provider-profiles/spec.md Normal file
View File

@@ -0,0 +1,48 @@
## ADDED Requirements
### Requirement: Default New Provider Profiles To Official GPT Image Compatibility
The system SHALL default newly created image-capable provider profiles to the explicit `openai-gpt-image` compatibility mode instead of `auto`.
#### Scenario: User creates a new provider profile
- **GIVEN** the user creates a new provider profile from the settings UI
- **WHEN** the new profile draft is initialized
- **THEN** the profile SHALL store `imageApiCompatibility = openai-gpt-image`
- **AND** the user MAY still manually switch the profile to `auto`, `tuzi-gpt-image`, or `openai-compatible-basic`
### Requirement: Default Managed Legacy Profiles To Official GPT Image Without Losing Overrides
The system SHALL materialize built-in managed provider profiles with `openai-gpt-image` as their default compatibility mode unless a stored override already exists.
#### Scenario: Managed profile is rebuilt without a stored compatibility value
- **GIVEN** a built-in managed provider profile is reconstructed from legacy/default settings
- **AND** there is no stored `imageApiCompatibility` override for that profile
- **WHEN** the settings manager rebuilds the profile
- **THEN** the resulting profile SHALL default to `openai-gpt-image`
#### Scenario: Managed profile keeps a user-selected compatibility override
- **GIVEN** a built-in managed provider profile already stores an explicit compatibility value
- **WHEN** the settings manager rebuilds or reopens that profile
- **THEN** the system SHALL preserve the stored compatibility value
- **AND** SHALL NOT reset it back to `auto` or the managed default
### Requirement: Preserve Explicit Historical Auto Choices
The system SHALL avoid silently rewriting explicit historical `auto` choices on custom provider profiles while still upgrading missing defaults.
#### Scenario: Historical custom profile explicitly stores auto
- **GIVEN** a custom provider profile already stores `imageApiCompatibility = auto`
- **WHEN** the profile is normalized or loaded
- **THEN** the system SHALL preserve `auto`
- **AND** SHALL continue to resolve it at runtime through the existing auto rules
#### Scenario: Historical profile missing the compatibility field
- **GIVEN** a historical provider profile predates the compatibility field and has no stored `imageApiCompatibility`
- **WHEN** the profile is normalized or upgraded
- **THEN** the system SHALL default the missing field to `openai-gpt-image`
- **AND** SHALL keep the value user-editable afterward

88
openspec/changes/update-image-api-compatibility-modes/specs/provider-routing/spec.md Normal file
View File

@@ -0,0 +1,88 @@
## ADDED Requirements
### Requirement: Resolve GPT Image Compatibility To A Concrete Internal Mode
The system SHALL resolve GPT Image compatibility from the selected provider profile into a concrete internal mode before adapter selection.
#### Scenario: Automatic resolution chooses official GPT mode
- **GIVEN** a provider profile uses an `api.openai.com` base URL
- **AND** the selected image model is a GPT Image model
- **AND** the stored image API compatibility is `auto`
- **WHEN** provider routing resolves image compatibility
- **THEN** it SHALL resolve to `openai-gpt-image`
#### Scenario: Automatic resolution chooses Tuzi GPT mode
- **GIVEN** a provider profile uses an `api.tu-zi.com` base URL
- **AND** the selected image model is a GPT Image model
- **AND** the stored image API compatibility is `auto`
- **WHEN** provider routing resolves image compatibility
- **THEN** it SHALL resolve to `tuzi-gpt-image`
#### Scenario: Automatic resolution chooses generic fallback
- **GIVEN** a provider profile is neither official OpenAI nor Tuzi
- **AND** the selected image model is a GPT Image model
- **AND** the stored image API compatibility is `auto`
- **WHEN** provider routing resolves image compatibility
- **THEN** it SHALL resolve to `openai-compatible-basic`
#### Scenario: Manual compatibility override wins over auto inference
- **GIVEN** a provider profile stores a non-`auto` image API compatibility value
- **WHEN** provider routing resolves image compatibility
- **THEN** it SHALL use the stored value directly
- **AND** SHALL NOT replace it with an inferred mode
### Requirement: Preserve Legacy Compatibility Values
The system SHALL accept previously stored GPT image compatibility values while converging on the refined internal mode names.
#### Scenario: Legacy Tuzi value is normalized
- **GIVEN** a provider profile stores the legacy compatibility value `tuzi-compatible`
- **WHEN** the profile is normalized or loaded into a routing snapshot
- **THEN** the system SHALL treat it as `tuzi-gpt-image`
- **AND** SHALL keep the profile eligible for the dedicated Tuzi GPT path
### Requirement: Map Internal Modes To Distinct Request Schemas
The system SHALL use request schemas as the formal dispatch boundary between official GPT, Tuzi GPT, and generic fallback routing.
#### Scenario: Official GPT generation emits official schema
- **GIVEN** a GPT Image invocation resolves to `openai-gpt-image`
- **WHEN** the request uses generation semantics
- **THEN** the inferred binding SHALL use request schema `openai.image.gpt-generation-json`
#### Scenario: Official GPT edit emits official edit schema
- **GIVEN** a GPT Image invocation resolves to `openai-gpt-image`
- **WHEN** the request uses edit semantics
- **THEN** the inferred binding SHALL use request schema `openai.image.gpt-edit-form`
- **AND** SHALL submit to `/images/edits`
#### Scenario: Tuzi GPT generation emits dedicated Tuzi schema
- **GIVEN** a GPT Image invocation resolves to `tuzi-gpt-image`
- **WHEN** the request uses generation semantics
- **THEN** the inferred binding SHALL use a dedicated Tuzi GPT generation request schema
- **AND** SHALL NOT collapse into `openai.image.basic-json`
#### Scenario: Generic fallback remains on the basic schema
- **GIVEN** a GPT Image invocation resolves to `openai-compatible-basic`
- **WHEN** the provider binding is inferred
- **THEN** the binding SHALL use request schema `openai.image.basic-json`
### Requirement: Keep Compatibility Metadata And Dispatch In Sync
The system SHALL keep resolved compatibility metadata aligned with the schema used for dispatch.
#### Scenario: Tuzi GPT no longer exists only in metadata
- **GIVEN** a GPT Image invocation resolves to `tuzi-gpt-image`
- **WHEN** routing emits metadata for diagnostics
- **THEN** the emitted `requestSchema` and adapter selection SHALL reflect the Tuzi GPT contract
- **AND** SHALL NOT route through the generic default adapter while only labeling the request as Tuzi-compatible