Asta Flows: workflows.yaml spec and compiled task schemas

[charliemcgrady]

This puts the Asta Flows schema spec up for review ahead of the tooling that uses it.

assets/workflows.yaml is the source of truth. Each workflow is a tree of typed tasks, and each task declares its mission, the CLI it may call, its inputs (including fan-in), and the structured fields it must emit in output.json. assets/compiled/ holds what the schema compiler generates from it: one JSON Schema per task type — what each executing agent's output is validated against — and graph.json, the same workflows expanded into a machine-readable graph that the runtime scripts and report renderer read (committed so the runtime only needs jq and jsonschema, never PyYAML).

Review workflows.yaml first — it is the readable form of everything here. The compiled files are generated output, checked in so you can see exactly what agents are held to.

This change is additive: the existing schemas.yaml and the scripts that read it are untouched and keep working. The compiler, report tooling, and skill rework that consume these files come in follow-up PRs, which will retire schemas.yaml.

[rodneykinney]

Feel free to merge if you're happy with the results it gives.

Some basically aesthetic comments on workflows.yaml as a DSL:

Compound types defined in outputs sometimes refer to other elements in outputs and sometimes to enums in vocabulary which complicates parsing. A parser doesn't know where to look up the name, which could appear in both places

workflow.yaml defines both a set of types and a set of workflows. Since those types get translated into json-schema by the compiler anyway, maybe they should just be declared as json-schema in the first place. Then workflows.yaml would be purely about workflows. I recognize that json-schema isn't really human-editor-friendly, but having a mature type-definition language avoids awkwardnesses like the previous point.

The config part of workflows.yaml feels really tacked-on. It seems like it could be declared as a type just like the outputs and then given as the input of a theorizer or autodiscovery workflow step. Probably this wasn't done because that would mean adding config to outputs and the config is not an output. But this is just another argument for having a standalone type-definition file like the previous point.