9.7 KiB
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
saufromSOCIAL_AUTO_UPLOAD_COMMANDonly 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-uploador 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
saumanually
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-videocommand 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-notecommand 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