TrueGrowth/openspec/changes/add-visual-business-orchestration/specs/business-orchestration/spec.md

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.