Module spec 

Parsing Cuttlefish.spec files.

Scope, and why this is a scanner rather than a parser library

The language this project is heading toward is a typed DSL with let-bound pipelines, block signatures, and inference over them. This is not that. It reads a deliberately flat subset — a spec NAME = { key = value; ... } block with a fixed set of keys — because that is all the first working end-to-end job needs.

Reaching for a parser-combinator library before the grammar has expressions in it would be building the abstraction for a language that does not exist yet, against guesses about its shape. When the pipeline syntax lands, this module gets replaced rather than extended.

The nodes = { ... } / branches = { ... } graph syntax added since is not that pipeline syntax: it is still the same flat key = value grammar, just shaped to describe a graph, with no expressions or inference beyond the node.out reference syntax itself.

Why it refuses so much

A spec grants capabilities. Every accepted-but-misunderstood construct is a job running under permissions nobody wrote down, so anything not fully understood is an error:

• An unknown key is rejected rather than skipped. Silently ignoring one is how a misspelled capabilities becomes a spec with no capabilities that still runs — and looks fine.
• An unsupported model kind or capability kind is rejected by name, rather than being treated as the nearest supported thing.

Being liberal in what it accepts would be exactly the wrong instinct here.

Structs

ModelRef

Where a job’s model comes from.

Spec

A parsed spec.

Enums

DataPolicy

How a job’s data may be handled.

SpecError

Why a spec was rejected.

Functions

parse_spec

Parse a spec.