Initial TrueGrowth source import
This commit is contained in:
@@ -0,0 +1,173 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Unified Asset Center
|
||||
The system SHALL expose a first-class "资产中心" that replaces the old navigation-facing "素材库" while preserving the real media-library data source.
|
||||
|
||||
#### Scenario: User opens the asset center
|
||||
- **WHEN** the user opens `/assets`
|
||||
- **THEN** the page title and navigation label show "资产中心"
|
||||
- **AND** the page provides first-level sections for "素材", "作品", and "已发布"
|
||||
- **AND** the page keeps media filters for image, video, and audio assets
|
||||
|
||||
#### Scenario: Published assets are filtered by state
|
||||
- **GIVEN** an asset was included in a successful publish target
|
||||
- **WHEN** the user opens the "已发布" asset section
|
||||
- **THEN** the asset is visible through its published marker
|
||||
- **AND** the system does not create a duplicate copied asset library
|
||||
|
||||
#### Scenario: Asset source tags are available
|
||||
- **WHEN** assets are displayed or selected for publishing
|
||||
- **THEN** the system can distinguish source tags for "主体", "本地", "AI", "数字人", and "剪辑"
|
||||
- **AND** legacy assets without new metadata remain compatible by falling back to local or AI source information
|
||||
|
||||
### Requirement: Auto Publishing Navigation
|
||||
The system SHALL provide a first-class workbench entry named "自动发布" in the left navigation and application center.
|
||||
|
||||
#### Scenario: User opens auto publishing
|
||||
- **WHEN** the user clicks "自动发布" in the left navigation
|
||||
- **THEN** the workbench shows the auto publishing workspace
|
||||
- **AND** the page uses the same visual system, navigation behavior, theme behavior, and responsive layout conventions as the existing workbench pages
|
||||
|
||||
### Requirement: Unified Finished Asset Hub
|
||||
The system SHALL aggregate publishable finished image and video outputs from digital avatar, AI canvas, AI image, AI video, clipping, media library, and task/history sources into the asset center and publish-task selector.
|
||||
|
||||
#### Scenario: Completed generated media appears in the hub
|
||||
- **GIVEN** an image or video generation task has completed with a result URL, thumbnail, or local asset reference
|
||||
- **WHEN** the user opens the asset center "作品" view or the publish-task asset selector
|
||||
- **THEN** the media appears as a publishable asset
|
||||
- **AND** the item shows its media type, source module, title, created time, preview, and existing publish state
|
||||
|
||||
#### Scenario: Duplicate media is normalized
|
||||
- **GIVEN** the same media is visible through task history and the media library
|
||||
- **WHEN** the finished asset hub is loaded
|
||||
- **THEN** the media appears once
|
||||
- **AND** the item keeps references to every known source record
|
||||
|
||||
### Requirement: Multiple Social Account Authorization
|
||||
The system SHALL let users manage multiple authorized accounts per social channel.
|
||||
|
||||
#### Scenario: User authorizes a channel account
|
||||
- **WHEN** the user starts login for a supported channel account alias
|
||||
- **THEN** the system starts the local social upload authorization flow
|
||||
- **AND** the account row records platform, alias, status, last check time, and supported publishing capabilities
|
||||
- **AND** the frontend does not store raw cookies or secrets
|
||||
|
||||
#### Scenario: User checks account status
|
||||
- **WHEN** the user checks an existing account
|
||||
- **THEN** the system verifies authorization through the local social upload bridge
|
||||
- **AND** the UI shows whether the account is available, expired, failed, or needs user action
|
||||
|
||||
#### Scenario: Account list loads before validation completes
|
||||
- **WHEN** the user opens account authorization
|
||||
- **THEN** the system may show cached or quick-loaded account rows immediately
|
||||
- **AND** slower authorization validation updates each row without blocking the page
|
||||
|
||||
#### Scenario: Login requires QR or browser action
|
||||
- **WHEN** the local bridge reports QR data, browser-login progress, or a user-action message
|
||||
- **THEN** the account dialog shows that progress in place
|
||||
- **AND** updates the account row when the bridge reports success or failure
|
||||
|
||||
### Requirement: Multi-Channel Publish Composer
|
||||
The system SHALL allow users to select one or more assets from the asset center or local upload and create a publish draft targeting multiple channels and accounts.
|
||||
|
||||
#### Scenario: User prepares a video campaign
|
||||
- **GIVEN** the user selected a video asset
|
||||
- **WHEN** the user selects multiple authorized channel accounts and enters title, description, tags, and optional schedule time
|
||||
- **THEN** the composer validates channel requirements
|
||||
- **AND** the user can enqueue one campaign containing one publish target per selected account
|
||||
|
||||
#### Scenario: User prepares an image-note campaign
|
||||
- **GIVEN** the user selected one or more image assets
|
||||
- **WHEN** the user selects channels that support image-note publishing and enters title, note body, tags, and optional schedule time
|
||||
- **THEN** the composer validates channel requirements
|
||||
- **AND** unsupported channels are disabled or reported before submission
|
||||
|
||||
#### Scenario: User manages multiple campaign drafts
|
||||
- **WHEN** the user creates several publishing drafts before submission
|
||||
- **THEN** the composer keeps each draft's selected assets, accounts, platform options, title, text, topics, and schedule independently
|
||||
- **AND** the user can submit drafts individually or as a batch
|
||||
|
||||
#### Scenario: User chooses generated or uploaded material
|
||||
- **WHEN** the user adds media to a draft
|
||||
- **THEN** the system offers asset-center content first
|
||||
- **AND** allows local upload fallback for media that was not generated in TrueGrowth
|
||||
|
||||
#### Scenario: User opens publish center
|
||||
- **WHEN** the user opens `/publish`
|
||||
- **THEN** only "发布任务" and "账号授权" tabs are visible
|
||||
- **AND** "发布任务" is the default view
|
||||
- **AND** publish records are shown beside the publish form, not as a separate tab
|
||||
|
||||
#### Scenario: User drafts social copy
|
||||
- **WHEN** the user edits a video description or image-note body
|
||||
- **THEN** the system provides knowledge-base fill and an intelligent copywriting dialog
|
||||
- **AND** generated copy is shaped for external social publishing rather than internal generation prompts
|
||||
|
||||
### Requirement: Social Auto Upload Runtime Bridge
|
||||
The system SHALL integrate bundled `vendor/social-auto-upload` source through a local runtime bridge compatible with the upstream `sau` command flow.
|
||||
|
||||
#### Scenario: Runtime resolves bundled sau
|
||||
- **WHEN** the local runtime starts or checks publishing status
|
||||
- **THEN** it resolves `sau` from `SOCIAL_AUTO_UPLOAD_COMMAND` only when explicitly configured for development
|
||||
- **AND** otherwise runs the bundled `vendor/social-auto-upload/sau_cli.py`
|
||||
- **AND** it does not depend on a system PATH `sau`
|
||||
|
||||
#### Scenario: Bundled sau source is missing
|
||||
- **WHEN** `vendor/social-auto-upload` or its CLI entry is missing
|
||||
- **THEN** the runtime reports an internal bundled publishing module error
|
||||
- **AND** the UI must not instruct the user to install `sau` manually
|
||||
|
||||
#### Scenario: Runtime invokes video upload
|
||||
- **GIVEN** a publish target uses a channel account with video upload support
|
||||
- **WHEN** the job starts
|
||||
- **THEN** the runtime materializes the media to a local file if needed
|
||||
- **AND** invokes the equivalent `sau <platform> upload-video` command with account, file, title, description, tags, and supported channel options
|
||||
- **AND** streams status and logs back to the workbench
|
||||
|
||||
#### Scenario: Runtime invokes image-note upload
|
||||
- **GIVEN** a publish target uses a channel account with image-note support
|
||||
- **WHEN** the job starts
|
||||
- **THEN** the runtime invokes the equivalent `sau <platform> upload-note` command with account, image files, title, note body, tags, and supported channel options
|
||||
- **AND** streams status and logs back to the workbench
|
||||
|
||||
#### Scenario: Runtime maps channel-specific options
|
||||
- **GIVEN** a target includes supported options such as schedule time, cover image, Bilibili partition, Douyin product link, Douyin product title, original declaration, or draft-only intent
|
||||
- **WHEN** the runtime builds the upload command
|
||||
- **THEN** it passes only the options supported by that target channel
|
||||
- **AND** records omitted unsupported options in validation output before the job starts
|
||||
|
||||
### Requirement: Publish Job Tracking
|
||||
The system SHALL track publishing campaigns and per-channel jobs from draft submission through completion.
|
||||
|
||||
#### Scenario: One target fails in a multi-channel campaign
|
||||
- **GIVEN** a campaign has multiple publish targets
|
||||
- **WHEN** one target fails and another succeeds
|
||||
- **THEN** the campaign remains visible with mixed status
|
||||
- **AND** each target shows its own status, error/log summary, retry action, and source asset reference
|
||||
|
||||
#### Scenario: User retries a failed target
|
||||
- **GIVEN** a publish target failed
|
||||
- **WHEN** the user retries it
|
||||
- **THEN** the system reuses the original asset and target metadata
|
||||
- **AND** appends a new attempt to the target history
|
||||
|
||||
#### Scenario: User cancels batch publishing
|
||||
- **GIVEN** multiple campaign drafts are being submitted as a batch
|
||||
- **WHEN** the user cancels the batch
|
||||
- **THEN** the system stops enqueueing remaining drafts where possible
|
||||
- **AND** shows completed, failed, cancelled, and not-started target counts separately
|
||||
|
||||
### Requirement: Channel Capability Guardrails
|
||||
The system SHALL expose platform-specific publishing capabilities and prevent invalid submissions.
|
||||
|
||||
#### Scenario: Unsupported schedule is selected
|
||||
- **GIVEN** a selected channel does not support scheduled publishing through the configured bridge
|
||||
- **WHEN** the user selects a scheduled publish time
|
||||
- **THEN** the composer warns that the target cannot use scheduling
|
||||
- **AND** the target must be changed, excluded, or switched to immediate publish before enqueueing
|
||||
|
||||
#### Scenario: Unsupported media type is selected
|
||||
- **GIVEN** a selected channel account does not support the selected media type
|
||||
- **WHEN** the user validates the draft
|
||||
- **THEN** the target is marked invalid
|
||||
- **AND** no job is created for that target until the issue is resolved
|
||||
Reference in New Issue
Block a user