One file a target generator produces. relative_path is relative to the
--out-dir the CLI was given — a single-file target (Rust) returns one
entry named from stem (e.g. "order-fulfillment.rs"); a target whose
ecosystem expects a package/directory layout (Java, Go, …) returns
several, with relative_path encoding that structure (e.g.
"com/example/OrderFulfillment.java"). The registry-facing side (the
CLI) never special-cases how many files a target produces — it just
writes whatever list comes back, creating parent directories as needed.
A pluggable code-generation backend (spec-neutral term: “target”). Every
target consumes the same validated EtlDocument + resolved fault-tree
probabilities + AsyncAPI registry — parsing, semantic validation, and
fault-tree evaluation happen exactly once, upstream of this trait, in
crate::Compiler; a target implementation only turns that already-
resolved representation into target-language source text. Nothing here
re-parses .etdl, re-validates ECEL conditions, or re-evaluates fault
trees — see docs/architecture/targets.md.