## 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