## ADDED Requirements

### Requirement: Visual Orchestration Workbench
The system SHALL provide a first-class workbench module for visual business workflow orchestration on the existing `/workflow` entry.

#### Scenario: User opens orchestration from navigation
- **GIVEN** the user is in the TrueGrowth workbench
- **WHEN** the user opens the "流程编排" navigation item
- **THEN** the workbench navigates to `/workflow`
- **AND** shows the visual orchestration editor
- **AND** the page follows the TrueGrowth desktop visual system.

#### Scenario: User opens orchestration from App Center
- **GIVEN** the user is viewing the App Center
- **WHEN** the user opens the "流程编排" app card
- **THEN** the workbench navigates to the same orchestration module.

#### Scenario: Legacy workflow page is replaced
- **GIVEN** the current `/workflow` route uses a simple stage-list workflow page
- **WHEN** this change is implemented
- **THEN** the route is rebuilt as a visual DAG editor
- **AND** any useful old presets are available as graph templates rather than static linear cards.

### Requirement: Drag-and-Drop DAG Editor
The system SHALL let users build directed acyclic workflows by dragging nodes onto a canvas and connecting them with edges.

#### Scenario: User creates a workflow graph
- **GIVEN** the orchestration editor is open
- **WHEN** the user drags supported nodes onto the canvas and connects compatible ports
- **THEN** the editor creates a workflow graph with persisted node positions, node configuration, and edges
- **AND** the graph can be saved and reopened without losing layout or configuration.

#### Scenario: User connects incompatible nodes
- **GIVEN** a source node output is incompatible with a target node input
- **WHEN** the user connects the nodes or validates the workflow
- **THEN** the editor reports the incompatibility
- **AND** the workflow cannot be executed until the issue is resolved or explicitly skipped by a supported rule.

#### Scenario: User creates a cycle
- **GIVEN** a workflow graph already contains a dependency path
- **WHEN** the user adds an edge that creates a cycle
- **THEN** the editor rejects the edge or marks the workflow invalid
- **AND** explains which nodes are involved in the cycle.

### Requirement: Business Node Catalog
The system SHALL provide configurable nodes for TrueGrowth creation, editing, intelligence, and publishing capabilities.

#### Scenario: User configures creation and publishing nodes
- **GIVEN** the user adds image generation, video generation, digital-human, intelligent editing, and publish-center nodes
- **WHEN** the user selects each node
- **THEN** the inspector shows detailed settings for provider, model, prompt, media inputs, output mapping, timeout, retry, and capability-specific options.

#### Scenario: User configures an intelligence/news node
- **GIVEN** the user adds an intelligence or news summary node
- **WHEN** the user configures topic, source range, language, output format, and model
- **THEN** the node can produce structured summaries, scripts, prompts, or downstream variables for later nodes.

#### Scenario: User configures intelligent editing
- **GIVEN** the user adds an intelligent editing node
- **WHEN** the user selects ASR, FunClip, FFmpeg, subtitle, clip, merge, or format options
- **THEN** the node records a normalized edit configuration
- **AND** the runtime executes it through the appropriate local sidecar or provider adapter.

### Requirement: Workflow Validation
The system SHALL validate workflows before execution.

#### Scenario: Workflow has missing required configuration
- **GIVEN** a workflow contains a node with required fields missing
- **WHEN** the user validates or runs the workflow
- **THEN** the system reports the missing fields on the node and in the validation summary
- **AND** the run is not started.

#### Scenario: Publish target is unsupported
- **GIVEN** a publish node targets a platform account that does not support the selected media type or schedule option
- **WHEN** the workflow is validated
- **THEN** the system marks the publish node invalid
- **AND** shows the unsupported capability before execution.

### Requirement: DAG Runtime Execution
The system SHALL execute valid workflow graphs according to node dependencies and configured concurrency limits.

#### Scenario: Runtime executes dependent nodes
- **GIVEN** a valid workflow has upstream and downstream dependencies
- **WHEN** the user starts a run
- **THEN** the runtime executes nodes only after their dependencies have succeeded or produced required outputs
- **AND** records each node status, progress, logs, outputs, and artifacts.

#### Scenario: Runtime executes parallel branches
- **GIVEN** a valid workflow has independent branches
- **WHEN** the workflow run starts
- **THEN** the runtime may execute branches in parallel according to configured global, provider, and platform concurrency limits.

#### Scenario: Runtime handles node failure
- **GIVEN** a node fails during execution
- **WHEN** retry policy allows another attempt
- **THEN** the runtime retries the node according to policy
- **AND** records every attempt in the run history.

#### Scenario: Runtime cancels a run
- **GIVEN** a workflow run is queued, running, or waiting
- **WHEN** the user cancels the run
- **THEN** the runtime stops scheduling new nodes where possible
- **AND** marks pending or active nodes as cancelled with a clear final run state.

### Requirement: Progress Feedback
The system SHALL provide live progress feedback for workflow runs and node executions.

#### Scenario: User watches a running workflow
- **GIVEN** a workflow run is active
- **WHEN** a node changes state, emits progress, writes a log, or produces an artifact
- **THEN** the canvas, run panel, and run details update with the latest status.

#### Scenario: User opens a historical run
- **GIVEN** a previous run exists
- **WHEN** the user opens its details
- **THEN** the system shows trigger source, start/end time, duration, final status, node timeline, logs, errors, and generated artifacts.

### Requirement: Scheduled Task Center
The system SHALL provide a scheduled task center for recurring and one-off workflow automation.

#### Scenario: User schedules a daily automation
- **GIVEN** the user has a saved workflow that summarizes news, generates a digital-human video, edits it, and publishes it
- **WHEN** the user creates a schedule for every day at 09:00 in a selected timezone
- **THEN** the system stores the schedule
- **AND** shows the next run time and enabled status.

#### Scenario: Scheduler fires a workflow
- **GIVEN** an enabled schedule reaches its next run time
- **WHEN** the local scheduler fires
- **THEN** the system creates an immutable workflow run with trigger metadata
- **AND** execution appears in the scheduled task center history.

#### Scenario: User disables a schedule
- **GIVEN** a schedule is enabled
- **WHEN** the user disables it
- **THEN** no future runs are created for that schedule until it is enabled again
- **AND** existing historical runs remain visible.

#### Scenario: Scheduled run overlaps existing run
- **GIVEN** a schedule fires while a previous run for the same schedule is still active
- **WHEN** the schedule has an overlap policy
- **THEN** the runtime follows the policy to skip, queue, or allow the new run
- **AND** records the decision in schedule history.

### Requirement: Durable Persistence and Recovery
The system SHALL persist workflow definitions, schedules, runs, node events, logs, and artifacts so work can recover after refresh or runtime restart.

#### Scenario: User refreshes during an active run
- **GIVEN** a workflow run is active
- **WHEN** the workbench refreshes
- **THEN** the UI reloads the latest run state from the local runtime
- **AND** resumes progress updates where supported.

#### Scenario: Local runtime restarts
- **GIVEN** the local runtime restarts after previous runs or schedules existed
- **WHEN** orchestration storage is loaded
- **THEN** saved workflow definitions, schedules, completed runs, and recoverable active runs are restored
- **AND** unrecoverable active nodes are marked with a clear recovery status.

### Requirement: Adapter Isolation
The system SHALL execute provider, sidecar, and publishing work through normalized adapters.

#### Scenario: Adapter emits normalized events
- **GIVEN** a node calls image generation, video generation, digital-human, intelligent editing, intelligence, or publishing
- **WHEN** the underlying provider emits progress, logs, artifacts, success, or failure
- **THEN** the adapter converts the result into orchestration events
- **AND** no provider-specific secret values are exposed to the frontend.

#### Scenario: Heavy sidecar crashes
- **GIVEN** a heavy sidecar runs in an isolated desktop process
- **WHEN** the sidecar crashes or exits unexpectedly
- **THEN** the runtime records the node failure
- **AND** the workbench shows a recoverable error without crashing the renderer.