Expand description
CEL (Common Expression Language) evaluation — the ONE gated exception to the
zero-dependency moat (--features cel, default OFF).
CEL is used wherever agentd evaluates a deterministic expression over run
data: workflow {"op":"cel"} predicates, computed assign.expr values,
infer.check value constraints, and reactive {"op":"cel"} wake conditions.
Its design properties are exactly the requirements here: non-Turing-complete,
no I/O, guaranteed termination — the one form of “code” a model can safely
author and agentd can immediately execute.
This module is ALWAYS compiled; only its internals are feature-gated. A non-cel build answers every call with a clear “requires the ‘cel’ build feature” error, so authoring surfaces reject CEL at define/parse time (fail-closed) instead of silently mis-evaluating at run time.
Constants§
- FEATURE_
MSG - The message every entry point returns on a build without the feature.
- MAX_
CEL_ EXPR - Expression length cap — a routing/shaping expression is a line, not a program; an oversized one is refused at compile-check time.
Functions§
- compile_
check - Compile-check an expression (define/parse-time validation): length cap +
full CEL parse.
Errcarries the parser’s message for the author. - eval_
bool - Evaluate an expression to a BOOLEAN with the given variables in scope
(each
(name, value)becomes a top-level identifier). A non-bool result is an error — a predicate must decide, not coerce. - eval_
value - Evaluate an expression to a JSON VALUE with the given variables in scope —
the computed-
assignpath. - vars_of
- Convenience: a blackboard-shaped variable list (
BTreeMap<String, Value>→ the(name, value)slice shape the eval fns take).