Compatibility And Caveats

Last validated: 2026-05-14

This page summarizes DSL authoring caveats between parser support, runtime behavior, and CLI/API parity.

For full service-level matrix, see 07-feature-status.md.

Parser vs Runtime Notes

Construct	Parser	Runtime today
`do` with `on error`	Implemented	Recovery forms parse; behavior depends on runtime/tool path
`each ... parallel`	Implemented	Parallel fast path limited; complex bodies may run sequentially
`pipe ... parallel`	Implemented	True parallel path limited to simple execute body patterns
`together`	Implemented	Full parallelism limited; multi-step lanes may degrade to sequential
`decide`	Implemented	Rules and LLM parse; some branch metadata/binding details are limited
`check ... on fail: retry`	Implemented	Retry path has partial behavior in runtime matrix
`send ... via`	Implemented	Channel support currently limited (`slack`, `email`)
`ask` + resume	Implemented	API supports resume; CLI still lacks direct resume command

Tool import syntax is import tools ... (or legacy tools ...).
Direct script file import syntax (import "file.scriptum" as x) is not part of current parser.
Section markers are tokenized via ### ... ###; avoid relying on a standalone section keyword.
each optional quoted label is accepted but not preserved as a named field in AST.
env declarations default to text when no explicit type is provided.
Object declarations are permissive; keep downstream tool contracts explicit.

Prefer deterministic decide ... with rules for critical routing.
Keep parallel blocks simple (single execute-heavy lanes) when throughput matters.
Always provide explicit bindings (-> name) for inspectability and debuggability.
Add check gates after high-variance LLM/tool steps.
For large outputs, design with yield + stream retrieval in mind.
Keep ask prompts typed (type, options, timeout, max_retries) to reduce resume failures.