3.2 KiB
@runfusion/fusion
| @runfusion/fusion |
|---|
| minor |
Make task steps workflow-modelable, behind the experimentalFeatures.workflowGraphExecutor flag (off by default).
Step policy — how a task breaks into steps, how each step is reviewed, and what happens on revision/rethink — was previously fixed engine law. Workflows can now model it as graph structure: a foreach node instantiates a per-step template subgraph once per planned step; a step-review node surfaces APPROVE/REVISE/RETHINK/UNAVAILABLE verdicts as outcome edges; rework edges (the only legal graph cycles, bounded per instance) route revisions back to a step-execute seam, with RETHINK triggering a substrate reset-to-baseline (git reset + session rewind). Steps additionally gain parallel execution: with mode: parallel + per-instance worktrees, dependency-satisfied steps (declared via ### Step N (depends: 1,2): annotations) run concurrently off a common base, with an ordered integration stage that lands branches in step order and routes rebase conflicts to a budget-counted rework outcome.
Step parsing itself becomes a graph node: parse-steps(artifact, parser) reads a workflow-declared task artifact and runs a registry parser (built-in step-headings/json-steps, or plugin-contributed parsers under plugin:<id>:<parser>) to write the step list, with routable no-steps/parse-error outcomes. A code node runs sandboxed TypeScript (esbuild + child process, clamped timeout, no store handle) for arbitrary computed routing/field logic. Workflows also declare typed custom task fields (string/text/number/boolean/enum/multi-enum/date/url, with enum options and render hints); values are validated through a single store authority and the task UI renders the field schema dynamically (detail form widgets, card badges, and a workflow-editor Fields panel). fn_task_update accepts a custom_fields patch; fn_workflow_create/update accept the new IR constructs.
The default coding workflow is untouched and byte-identical (the parity oracle); a new built-in stepwise coding workflow demonstrates the full modeling. With the flag off, step execution, review, and the board are exactly as before.
ROLLBACK: This is flag-gated by experimentalFeatures.workflowGraphExecutor and additive on disk. Schema migration v108 only ADDS the workflow_run_step_instances table and the tasks.customFields column (default '{}') — it rewrites no existing rows. The flag is read once and pinned per run, so a mid-flight toggle never switches a task between the legacy and graph step paths; flag-off rollback mid-task converges via the existing fell-back + git-reconcile recovery, because Task.steps[] remains the always-git-reconcilable projection sink. Instance rows are per-run prunable and are never the authority over git history. IR using the new node kinds (foreach/step-review/parse-steps/code) is v2-only, and downgradeIrToV1IfPure already refuses non-v1 node kinds, so the v2 rollback contract from the columns track is preserved automatically. To downgrade to a pre-v108 binary, turn the flag off and let in-flight stepwise tasks settle (or reconcile from git) first; custom-field values on the dropped column are lost on downgrade, so export any needed field values beforehand.