For the last couple months, I have been working on the proof of concept of an automation tool (ansible-like) for DevOps that could be scaled (controllers/workers architecture). Right now the project is far from a "v1.0.0" (not optimized at all) but I get it to work under certain conditions.
I'm intrigued by the problem you're facing with Deserialize tasks. An option per module is going to be painful down the road. Worth asking a specific question about it here in the forum for suggestions.
I'm curious if you intend to have task/module/playbook compatibility with ansible so that existing ansible playbooks can be refused as-is. It would be a huge selling point for convincing professional teams to switch, but will be much more difficult! Dux syntax looks very familiar.
Thank you for your time !
About the Deserialize task / 1 option per module, if you are talking about the definition of the step struct in this file, it's (so far) the only solution I found to avoid having to invoke modules with the !module_name syntax. In his (abandonned) jetporch project, Michael DeHaan was using the !module_name syntax which is a YAML tag. It is the proper way I think but, exactly as you point, I want to be as close as possible to the ansible playbook syntax. Full compatibility would be awesome but I am not there yet.