Different workflow formats in CLI and Lightning (breaks workflow import!)

The workflow.json or yaml format used by the CLI is different to the workflow structure used by Lightning.

This is partly historical - the CLI and Lightning structures were developed independently. But there's also a difference in motivation - the CLI structure is optimised to be easier to hand-write by humans.

The differences are:

• The CLI format uses a top level { steps } key, vs Lightning's { jobs, triggers, edges }
• The CLI uses arrays, vs lightning's index/object structures (ie, [{ id; 'a' }] vs { a: {} }
• The CLI builds edges as a next key on a step, vs Lightning has an array of edge objects.

Mostly this is absolutely fine, and the CLI historically has abstracted out the difference for users. So no-one knows or cares.

But there is one use-case where this difference is starkly exposed: importing yaml into a new workflow in the app.

As a user, I expect to be able to take a workflow.yaml from a local file and paste it into the Workflow import. But this doesn't work, because the format is different. What is the importer for if not importing workflows written in the CLI or saved to github?

So this is a big problem.

I'm not keen to switch the CLI to use the Lightning { steps, triggers, edges } format. Its a structure which doesn't suit the CLI and I think really hurts users.

Options:

• Create a CLI util to convert the structures. I wonder if anyone will ever use it, and it feels like a fiddly sort of command
• Use AI to convert the structures. This worked well for me recently in dev, but if we wanted to lean into this I'd want a pre-prompted tool that we can share
• Let Lightning support the CLI workflow formats on the importer. Implicitly (it just works) or explicitly (import CLI workflow)

No files or tests are named. Start by tracing the CLI workflow serialization and the Lightning workflow importer, then compare how steps, jobs, triggers, and edges are represented. Done means a workflow.yaml written or saved by the CLI can be imported into a new workflow without manual restructuring.