Roadmap

LightFlow is currently a backend foundation. The next work should extend the smallest verifiable path.

Near-Term Priorities

1. Stronger workflow reference validation.
2. JSON schema validation for input and output contracts.
3. DAG dependency model.
4. Request template registry.
5. Thin HTTP adapter over ApiService.

These are near-term because they protect the core contract. A workflow should fail early when it references an unknown model, node, composition, input, output, or request template. The HTTP adapter should be thin enough that the CLI and server produce the same behavior for the same request.

Validation Work

Reference validation should cover:

• workflow to node references
• workflow to composition references
• workflow to model aliases
• step id uniqueness
• input name and output name compatibility
• request template availability
• unresolved runtime placeholders

Schema validation should then make inputs and outputs reviewable before execution. The goal is not to make the DSL rigid; the goal is to make preview useful enough that agents can iterate without creating broken run state.

DAG Work

The current foundation can represent a planned path. A richer workflow model needs explicit dependencies:

• steps with stable ids
• edges between step outputs and step inputs
• fan-out and fan-in
• composition expansion
• skipped or blocked steps
• partial reruns

This should be introduced after preview, manifest, and event semantics are stable, because the DAG will multiply the number of states that need to be represented clearly.

Mid-Term Capabilities

• streaming events
• artifact indexing
• policy-aware preview
• route explanation
• cancellation
• retry and timeout model
• composition expansion
• fake CortexFS integration tests

Streaming and artifact indexing make the system easier to inspect. Policy-aware preview and route explanation make it safer. Cancellation, retry, and timeout handling make it operationally usable. Fake CortexFS integration tests let the backend prove submit and refresh behavior without requiring a live mount in every test.

Documentation Work

The docs should evolve with the runtime:

• keep the asset authoring guide close to real examples
• document every CLI command with expected output shape
• mirror important pages in Chinese and English
• publish deployment instructions for GitHub Pages
• add troubleshooting notes for common CortexFS mount and permission failures

Design Risks

The DSL can become too dynamic too early. If workflow definitions require arbitrary Rust execution, static preview becomes weaker.

LightFlow can duplicate CortexFS concepts. If it owns provider, tool, policy, and audit state directly, the system gets two sources of truth.

Runtime state can leak into Git. Real outputs, caches, locks, sockets, and secrets should remain in XDG paths.

Framework-specific API code can spread. Business logic should stay in ApiService.

Non-Goals For Now

LightFlow should not rush into:

• a full visual canvas
• a provider SDK duplicate
• a cross-platform desktop runtime
• a large scheduler before the manual lifecycle is stable
• hidden state outside XDG and CortexFS

Those may become useful later, but they should be downstream of a reliable backend contract.