The evaluator, audited against cel-go's own machinery: planner, activation, attributes, decorators, frame, cost and memory — the slate #1489

Written against 40cc365 (2026-09-02, merge of #1424) and against cel-go at the pin (github.com/google/cel-go v0.31.0), the v0.32.0 tag, and upstream master at f8478f1. Third audit beside #1459 (how a value's type travels) and #1421 (how a name resolves): this one reads how an expression is planned and executed — cel-go's interpreter package (the planner, Activation, Attribute/Qualifier, InterpretableDecorator, ExecutionFrame, the cost and memory trackers) against the one evaluator in pkg/flowstate/v1/celenv.go and the activation in eval.go — and what moved upstream in August 2026. Every claim in the sub-issues cites file:line at that revision, a go doc result against the pinned module, or a measurement reproduced in this pass.

What holds

One builder (buildEnv, celenv.go:748), one program cache, one cost estimator installed where both drivers build a program (Limits.programOptions, celenv.go:80), one custom interpreter.Activation both drivers fill through Scope.Activation (nodes.go:93), and a profile pinned per run that every evaluation site resolves from the spec. The ordered-map rewrite (celmap.go) is the one evaluator-side rule and it is applied as an AST rewrite before planning, which keeps both drivers and the stored specification honest. ExecutionFrame (interpreter/frame.go), ConcurrentEval and async functions are already in the pinned version and correctly unused: Flowstate's cancellation contract is ContextEval plus InterruptCheckFrequency, and an async function would be I/O inside workflow code.

What the audit found

• The runtime plans parsed ASTs against a variable-less environment. Every reference is a maybe-attribute probed three times; every call has an empty overload id, which is why byteCostEstimator exists and why plan-time regex compilation and static cost estimation are unreachable. cel: both drivers plan parsed ASTs against a variable-less environment — every steps.x.y is a three-candidate maybe-attribute, every call carries an empty overload id, and cel-go's overload-aware costing, plan-time regex compilation and static cost estimation are unreachable #1481.
• Answering the steps root whole is eager. One field read converts every prior output: 21 ms and 24 MB per evaluation at 1,000 steps, measured. eval: one steps.<id>.<output> read converts every prior step's every output into a CEL value — 21 ms and 24 MB for one field at 1,000 steps, linear in what the run has accumulated, on both drivers #1482.
• Limits is two knobs. Seven cel-go bounds are unset (node count, nesting depth, comprehension and bind nesting, regex program size; parser size and recursion sit at cel-go's defaults), the memory bound does not exist at the pin, and the five policy compilers set their own three. cel: Limits is two knobs (cost, interrupt frequency); the pinned cel-go exposes nine bounds and the five policy compilers set three of their own — decide each bound once, including the memory bound no site has #1483.
• Compaction reimplements partial evaluation by hand. refs.go retains every step when it cannot name one; cel.PartialVars and unknown attribute trails name them, dynamic indexes included. engine: Continue-As-New compaction rediscovers references with a 394-line walker over the proto AST and retains every step whenever it cannot name one; cel-go's partial evaluation names the exact steps.<id>.<output> trails an expression touches, dynamic indexes included #1484.
• EvalDetails is discarded at every site. Cost is measured everywhere and reported nowhere; OptTrackState is the trace flow policy explain, DAP evaluate and check witnesses approximate by re-evaluation. cel: every evaluation site discards EvalDetails — actual cost is measured on every expression and reported nowhere, and OptTrackState would give flow policy explain, DAP evaluate and check witnesses a real per-node trace instead of a re-evaluation #1485.
• The profile is a string slice. Env.ToConfig renders it as data cel-go's own tools load; cel: eight of eleven profile libraries are version-unpinned — the strings pin's own doctrine, unapplied to the rest of 2026.1 #1358's "cel.md unchanged" becomes a structural diff. cel: the profile is a Go string slice and a generated markdown table; cel-go's Env.ToConfig renders the same environment as a YAML env.Config — pin 2026.1 as data, feed it to the REPL and the editor, and make #1358's "cel.md unchanged" a structural diff #1486.
• Upstream moved. cel.dev/cel-go at v0.32.0; per-operation cost observation (the cel: the runtime cost observer makes every large comprehension quadratic in wall time — a 50k-element map costs ~2.5s CPU while the budget reads it as affordable #1357 mechanism), memory tracking, common/cost, type aliasing, and a batch of runtime names landed after the tag. The bump is an interpreter change under invariant 4, gated on cel: eight of eleven profile libraries are version-unpinned — the strings pin's own doctrine, unapplied to the rest of 2026.1 #1358: cel: the pin is google/cel-go v0.31.0; upstream moved to cel.dev/cel-go at v0.32.0 and thirty-one commits past it rewrote cost, memory and observers — decide the bump as a versioned interpreter change, after the pins #1480. The runtime names are screened against the profile rule row by row, including the refusal of HMAC/JWT in the workflow dialect: cel: what cel-go grew past the pin, screened by the profile's own admission rule — json.parse with a target type, hasValue(v), hasOnly/hasAny/hasAll/hasExactly, base64url, HMAC/JWT helpers, timestamp parsing, maps.merge, cross-type numerics #1487.
• Policy composition exists upstream. cel-go's policy compiler implements what Policy: one vocabulary, composable modules, a test verb, and enforcement below the layer that can bypass it #548 sketches; decide adopt, borrow or refuse before a module system is written. policy: cel-go's own policy compiler already implements the composition #548 sketches — variables, nested first-match rules, typed outputs, source-preserving composition, a conformance runner — evaluate it for the five surfaces before writing a module system #1488.

The slate, in the order the pass recommends

Independent, landable now (no upstream change needed):

1. eval: one steps.<id>.<output> read converts every prior step's every output into a CEL value — 21 ms and 24 MB for one field at 1,000 steps, linear in what the run has accumulated, on both drivers #1482 — lazy steps root: a bounded-work defect on both drivers, measured.
2. cel: both drivers plan parsed ASTs against a variable-less environment — every steps.x.y is a three-candidate maybe-attribute, every call carries an empty overload id, and cel-go's overload-aware costing, plan-time regex compilation and static cost estimation are unreachable #1481 — check before plan with dyn declarations only; deletes the debugger's copy of envDeclaring.
3. cel: Limits is two knobs (cost, interrupt frequency); the pinned cel-go exposes nine bounds and the five policy compilers set three of their own — decide each bound once, including the memory bound no site has #1483 — decide the eight bounds that exist at the pin; route the five policy sites through Limits.
4. cel: every evaluation site discards EvalDetails — actual cost is measured on every expression and reported nowhere, and OptTrackState would give flow policy explain, DAP evaluate and check witnesses a real per-node trace instead of a re-evaluation #1485 — keep EvalDetails: cost into spans and metrics, one redacted per-node trace for the explain surfaces.
5. cel: the profile is a Go string slice and a generated markdown table; cel-go's Env.ToConfig renders the same environment as a YAML env.Config — pin 2026.1 as data, feed it to the REPL and the editor, and make #1358's "cel.md unchanged" a structural diff #1486 — the profile as env.Config, pinned and round-tripped.

Upstream-gated:
6. #1358 (existing) — pin the eight open libraries, read from v0.31.0's gates.
7. #1480 — the bump, as a build-id change, byte-identical for 2026.1; brings the memory bound (#1483's last row) and the cost-observer fix (#1357). Note the comment there: three dependencies still import github.com/google/cel-go, so the rename links two copies of cel-go until protovalidate moves.
8. #1484 — partial evaluation for compaction; the comprehension case waits on cel-expr/cel-go#1341.
9. #1487 — the next profile's membership, decided from the screen after 6 and 7.

Decision record:
10. #1488 — cel-policy for the five surfaces, before #548's module system.

Second pass, same revision

Filed after the first slate, from the surfaces the first pass touched but did not open. Each was reproduced or counted before filing.

Bugs, reproduced with go run ./cmd/flow:

• flowfile: an invalid regex, duration or timestamp literal compiles clean — the compiler's env.Check runs none of cel-go's AST validators, so the run fails where flow validate said ok #1500 — flow validate says ok to 'abc'.matches('['), duration('3 days') and timestamp('yesterday'); the run fails on the first. cel-go's literal validators (ValidateRegexLiterals, ValidateDurationLiterals, ValidateTimestampLiterals) are unused anywhere in the tree.
• flowtest: a check: claim written with optional syntax is refused at load with "unsupported syntax '.?'" — claims are parsed against the library-less base environment and evaluated against the run's profile #1512 — flow test refuses a check: claim written with .? at load ("unsupported syntax '.?'") while the workflow it tests uses the same idiom: claims are parsed against the library-less base environment and evaluated against the run's profile.

One mechanism:

• dsl: CEL AST traversal is re-derived in 59 functions over the v1alpha1 proto across 20 files — the child enumeration exists in three full copies and every walker re-lists the expression kinds; cel-go's common/ast is the one traversal, and three files already use it #1501 — 59 hand-written walkers over the v1alpha1 proto AST in 20 files, the child enumeration written out three times; cel-go's common/ast is the traversal and three files already use it.
• dsl: must: is the one expression position stored as source text — re-parsed and re-checked on every compile, refused by a walker no other position uses, and evaluated through the uncached path with an env.Extend per check #1503 — must: is the one expression position stored as source text: re-parsed and re-checked per compile, refused by its own now walker, evaluated through the uncached path.

What the checked AST could say at validate:

• flowfile: the compiler checks every expression and never asks what it will cost — cel-go's static estimator, with max_items/max_len as size hints, can refuse at validate an expression that cannot fit DefaultCostLimit and report the bound in flow audit #1504 — static cost estimation (Env.EstimateCost) with max_items/max_len as size hints; flow audit reports the bound, flow validate refuses the expression whose minimum cost exceeds the budget.

Tooling the existing data already supports:

• lsp: signature help is unadvertised while the catalog already renders one signature per overload — the data celcomplete says "is not available" is what docs/reference/cel.md prints in its Signature column #1506 — LSP signature help from LibraryFunction.Signature, which hover and docs/reference/cel.md already render.
• flowdap: breakpoints are by step id and frames carry no source because v1.Node has no position — the compiler's Positions side table already maps step ids to spans for the launched file, so line breakpoints and navigable frames are a lookup away #1507 — DAP line breakpoints and navigable frames from the compiler's Positions side table, the slice flowdap.go:19-47 names.

Pinning semantics, not only names:

• cel: profile 2026.1's semantics are pinned by a function listing and an examples corpus, not by the language's own conformance suite — cel.dev/expr already ships the textproto cases for every library the profile admits, and it is already in go.mod #1509 — run cel.dev/expr's conformance textprotos (already in go.mod as an indirect dependency) for the profile's libraries through Evaluator, with a reviewed skip list.

Checked and not filed: plugins evaluate no CEL in their own process (cel-go is an indirect dependency of the six plugin modules and no plugin or SDK file references it), so there is no second evaluator across the socket; the macroExamples hand table is correctly hand-written (cel-go's Macro.IsReceiverStyle cannot distinguish a namespace receiver from a value receiver, as catalog_functions.go:261-273 records); the default time zone is UTC unless DefaultUTCTimeZone(false) is set (cel/env.go:904 at v0.31.0), so timestamp accessors are worker-independent.

Third pass: the protobuf side

The second evaluator the second pass said did not exist does, one dependency over.

• validate: protovalidate is a second CEL evaluator in the binary — its own environment, no cost limit, no interrupt, now bound, cross-type numerics on — and plugin-authored cel rules already run through it at flow validate and in the editor #1531 — protovalidate is a second CEL evaluator in the binary: its own environment (cel/library.go:66-90 in buf.build/go/protovalidate@v1.3.0: unpinned ext.Strings, now bound, CrossTypeNumericComparisons(true)), no cost limit, no interrupt, no option to add one — and plugin-authored (buf.validate.field).cel rules already run through it at flow validate, in the LSP on every change, and in the MCP validate tool (flowfile/schema.go:410-432 builds a dynamicpb message from the plugin's descriptor and calls v1.Validate). plugin: the descriptor's own protovalidate rules are checked for literals at flow validate and never at dispatch — every first-party plugin hand-writes its bounds again, and the refusal crosses as free text with no field #1491's open question about dispatch-time cel rules is this decision, and it applies today. Comment on cel: the numeric model is split three ways — the checker refuses int/double mixing the runtime performs behind dyn, JSON numbers arrive as double, and YAML can mint a uint nothing can add to #1432 records the numeric divergence.
• Design: workflow input constraints are 1,559 lines of hand-written Go beside protovalidate, which already validates task inputs from descriptors — the declarations spell buf.validate's names and must: spells its this; decide whether a declaration becomes a descriptor #1534 — workflow input constraints are 1,559 lines of hand-written Go (constraints.go) beside protovalidate, which validates task inputs from descriptors; the declarations spell buf.validate's names (docs/DSL.md:4115-4117) and must: spells its this. Decide whether a declaration compiles to a descriptor, with the dialect and bound tensions stated.
• schema: Node.Outputs.named_values is required, so the wire cannot say "a step produced no outputs" — the server substitutes an empty map for an absent signal payload, and four engine sites build the empty message the rule forbids #1537 — Node.Outputs.named_values is required, so the wire cannot say "no outputs"; the server substitutes an empty map for an absent signal payload (server/lifecycle.go:641, :728) and four engine sites build the message the rule forbids. Relax the rule or refuse the sites.

Checked and not filed: payload encoding is already decided (#911, binary protobuf since #1196); task claims as descriptor options is #1493; the *.test.yaml and policy-file formats as schema messages is #923's question (a comment on #1488 records that the policy documents are Go structs too); secret-typed inputs are #535's family.

Fourth pass: options, prose and the agent surface

Where the schema's own comments and #729's options package should be the one source, and are not yet.

• dsl: the Flowfile grammar's keys and their prose are hand-kept in parse.go, a 65-entry LSP completion table and DSL.md, beside the schema's own comments — derive the key table, hover, a generated grammar reference and a JSON Schema from workflow.proto through one yaml option #1542 — the Flowfile grammar's keys and prose are hand-kept three times: parse.go's key lists, a 65-entry LSP completion table (lsp/completion.go:96-278), and DSL.md — beside workflow.proto's own field comments; no generated grammar reference page and no JSON Schema exist. One yaml option on Design: flowstate/options/v1, a minimal congruent custom-options package modeled on protovalidate and google.api, composable with plugins #729's FieldRules (key and STYLE.md R4 position class), one walker, four projections: the compiler's tables, hover and completion, docs/reference/flowfile.md, flowstate://schema/flowfile.json.
• mcp: the eighteen derived tools carry no annotations — Cancel, Terminate, Signal and Run look identical to Validate to an agent's client; derive readOnlyHint/destructiveHint/idempotentHint from method options and give flow mcp serve a read-only posture #1543 — the eighteen derived MCP tools carry no ToolAnnotations: Terminate and Validate look the same to an agent's client. Derive read-only, destructive and idempotent hints from MethodRules, and give flow mcp serve a --read-only posture backed by scope rather than hints.
• ci: hover, flow tasks, the MCP catalog and docs/reference/tasks.md are rendered from schema comments, and buf lint does not require one — 72 of 606 fields in flowstate/v1 have no comment, including every arm of Value #1544 — hover, flow tasks, the MCP catalog and docs/reference/tasks.md render schema comments, and buf lint does not require one: 72 of 606 fields in flowstate/v1 are uncommented, every arm of Value among them; enable the COMMENTS rules here and in the plugin SDK's recipe.

Comments rather than issues: on #1493, that a plugin's example should be a flowstate.v1.Value literal validated against the field's own rules (as InputDeclaration.example already is) rather than a second literal vocabulary, and that a bounded CEL snippet option compiled at manifest load would make plugin documentation executable the way TestEveryDocumentedCELIdiomCompiles makes the reference docs; on #1452, that the TODO(kent) at value.proto:160-167 is the schema's only in-line statement of the value-kind question and should be retired by that decision.

Checked and not filed: diagnostic codes travel as strings by a recorded decision (diagnosticcodes.go:28-40); plugin comments already travel in the manifest (#723, closed by #874).

Fifth pass: hands-on, from the outside

A two-file workload (a caller with typed inputs, a for_each over call:s, a signal gate, a switch:, typed enum and struct outputs, and a test file) was written against the same build and pushed through every surface — validate, lint, audit, fmt --check, compile, test, run local in text and JSON, twenty-eight deliberate mutations, embed.Compile/RunLocal from a Go program, flow mcp over stdio, flow lsp over stdio, and flow debug replay. What held: twenty-two of the twenty-eight mutations were refused at validate with a position, the right name and usually a suggestion; the test verb's coverage report named the unreached arm by line; the debugger replay refused a bad script before running anything. The findings are at the joints between surfaces, and every one is a reproducer in its issue.

The evaluator's own voice (sub-issues here):

• cel: a runtime expression failure reads "no such overload" and nothing else — cel-go's Err.NodeID() is already in the error chain, the spec holds every node's offset, and Positions holds the step's line #1551 — a runtime expression failure reads no such overload / no such key: urll and nothing else; cel-go's Err.NodeID() is in the error chain, SourceInfo.positions has the offset, Positions has the step's line, and the callee's declared outputs are in the spec. Operator, operand types, caret and candidates are all in hand and discarded at evalProgram.
• flowfile: two checks the compiler already performs are not applied where they are needed — a with: binding of a bare ${inputs.<name>} is not typed against the callee's declaration, and an enum output's values: is not checked against the literal domain switch: already infers #1554 — two checks the compiler already performs are not applied where they are needed: a with: binding of a bare ${inputs.<name>} is not typed against the callee's declaration (checkCallArgumentType lacks the tier checkOutputValueType has), and an enum output's values: is not checked against the literal domain validate_switch.go already infers for the same expression.
• flowfile: a must: that does not type-check is reported three times with cel-go's raw issue text (ERROR: <input>:1:6 … plus an ASCII caret) — and a must: whose regex literal cannot compile validates clean unless a default: or example: happens to evaluate it #1556 — a must: that does not type-check is reported three times with cel-go's raw issue rendering (ERROR: <input>:1:6 … and a caret block), and a must: whose regex literal cannot compile validates clean unless a default: or example: happens to evaluate it (flowfile: an invalid regex, duration or timestamp literal compiles clean — the compiler's env.Check runs none of cel-go's AST validators, so the run fails where flow validate said ok #1500 on the declaration surface).

The surfaces around it (standalone):

• cli/embed/mcp: a refusal at the submit boundary is an untyped fmt.Errorf — --output json prints prose and no document, embed.RunLocal classifies "declared int but was given string" as Internal, and three verbs print a text trailer after their JSON report #1552 — a refusal at the submit boundary is an untyped fmt.Errorf: --output json prints prose and no document, embed.RunLocal classifies "declared int but was given string" as Internal, MCP relays prose; fmt --check, debug replay and audit print text after or instead of their JSON report.
• mcp: flowstate_run_local, run and get answer with protojson Value trees ({"literal":{"int64Value":"2"}}) while --output json projects the same run to plain JSON — the code says the two are "the same bytes", and they are two dialects #1553 — flowstate_run_local, run and get answer with protojson Value trees while --output json projects the same run to plain JSON; the comment at mcp.go:941 says they are the same bytes.
• flowfile: a called workflow's own defect is reported at the caller's call: line in the caller's file — the callee's position lives inside the message text, DiagnosticReport has one file, code is general, and a direct self-call is described as "a chain of files rather than directly" #1555 — a called workflow's defect is reported at the caller's call: line in the caller's file, the callee's position lives inside the message text, DiagnosticReport has one file, and a direct self-call is described as "a chain of files rather than directly".
• embed: a Task.Fn that returns a plain error is retried five times over fifteen seconds and reported as Internal — the facade never says how a task classifies its failure, and a nil-descriptor task lets a misspelled input pass Validate in silence #1557 — an embedded Task.Fn returning a plain error is retried five times over fifteen seconds and reported as Internal; nothing in the facade says how to classify; a nil-descriptor task lets a misspelled input pass Validate.
• flowtest: a failed expectation is a Diagnostic with line: 0, column: 0 — the loader can locate every expect.* key (positionOf/positionOfKey), only coverage arms use it, and --output json hands an editor nothing to underline #1558 — a failed flow test expectation is a Diagnostic with line: 0; the loader can locate every expect.* key and only coverage arms use it.

Comments rather than issues: on #1439, the debugger's break place arms both the caller's and the callee's step of that id and the preflight lists callee ids flattened into the caller's universe; on #1452, the catalog's map[string, string] / info | warn | error prose and the MCP JSON Schema are two more spellings of the type vocabulary.

Checked and not filed: fmt reorders with: keys alphabetically and the declaration keys into a fixed order (R3, one spelling; a callee-declaration order for with: would be a style decision, not a defect); flow validate is quiet on int + "x" over steps.* (that is #1481, not a new finding); hover on ${inputs.plan} inside with: answers nothing and completion after r.place. inside a results.map offers nothing (#1463 and #1434 already carry both); embed.Compile refuses a call: with a diagnostic that names the fix (#1376, working as documented); the LSP advertises no signatureHelpProvider (#1506); the MCP tools carry no annotations (#1543) and take base64 for validate and plain YAML for run_local (#1290).

Recorded, not filed

• Decorators. cel-go's InterpretableDecoratorV2 (interpreter/decorators.go) is the plan-time hook for evaluator-side rules; Flowstate's one such rule (ordered map iteration) is an AST rewrite instead because evalFold is unexported and a decorator cannot reach a comprehension's range. The cleaner end state is upstream — a cel option for deterministic map iteration would delete celmap.go — and is worth proposing to cel-expr/cel-go rather than filing here.
• Sensitive taint through expressions. sensitivevalues.go propagates by content at render time and flowfile/sensitive_log.go by name at lint time; docs/DSL.md records secret: taint as unbuilt. An EvalStateObserver could mark derived values by observing which nodes touched a sensitive input, but the render-time set already catches most of it and the gain is confined to derived substrings. Not filed until a real file shows the gap.
• DeclareContextProto over v1.Scope. run.proto's Scope is one bucket per root, which is the shape cel-go's DeclareContextProto declares from a descriptor; the values are flowstate.v1.Value, not CEL-native, so the declaration would type wrong without a projection. Recorded as a direction dsl: the reference model is re-derived by eighteen hand-kept lists across validator, LSP, debugger, flowtest, rewriter and CLI — derive them from one table #1437's root registry could take, not as a proposal; the narrower mechanism (cel.Types for the closed run/trigger roots) is a comment on dsl: the reference model is re-derived by eighteen hand-kept lists across validator, LSP, debugger, flowtest, rewriter and CLI — derive them from one table #1437.
• Identifier escape syntax for the four lexer-token step ids: a row in cel: what cel-go grew past the pin, screened by the profile's own admission rule — json.parse with a target type, hasValue(v), hasOnly/hasAny/hasAll/hasExactly, base64url, HMAC/JWT helpers, timestamp parsing, maps.merge, cross-type numerics #1487.
• The compiled spec's size. flow compile -o json of the two-file workload is 107 KB: every expression carries a full SourceInfo (location: "<input>", lineOffsets, positions, empty macroCalls), and the callee is inlined per call site. The encoding is decided (design: flowstate stores every payload as ProtoJSON, and nothing has decided that #911/payloadcodec: write payloads as binary protobuf, keep decoding both #1196); the <input> location is the one field worth a look when cel: a runtime expression failure reads "no such overload" and nothing else — cel-go's Err.NodeID() is already in the error chain, the spec holds every node's offset, and Positions holds the step's line #1551 decides where an expression's file name lives.

Already tracked and cited from the finding it touches: #1357, #1358, #1360 (fusion inside one evaluation is the decorator/optimizer seam), #1383, #1432, #1436, #1452, #1454, #1459, #1421, #1437, #1438, #1449, #1468, #1491, #1493, #729, #1225, #1285, #558, #1469, #1288, #545, #548, #326, #332, #911, #923, #1012, #1465, #184, #1439, #1290, #1293, #1426, #1471, #1497, #230.

Not verified

• The eval: one steps.<id>.<output> read converts every prior step's every output into a CEL value — 21 ms and 24 MB for one field at 1,000 steps, linear in what the run has accumulated, on both drivers #1482 benchmark ran the evaluator path directly, not a durable run; the durable driver shares Scope.Activation, so the cost is expected to hold there, and the issue's acceptance criteria require the conformance case to prove it.
• Switch to direct observation of costs on a per-operation basis cel-expr/cel-go#1430's effect on cel: the runtime cost observer makes every large comprehension quadratic in wall time — a 50k-element map costs ~2.5s CPU while the budget reads it as affordable #1357's shape is inferred from the removal of refValStack, not re-measured; cel: the pin is google/cel-go v0.31.0; upstream moved to cel.dev/cel-go at v0.32.0 and thirty-one commits past it rewrote cost, memory and observers — decide the bump as a versioned interpreter change, after the pins #1480's acceptance criteria require the measurement.
• flowtest: a check: claim written with optional syntax is refused at load with "unsupported syntax '.?'" — claims are parsed against the library-less base environment and evaluated against the run's profile #1512's macro-bearing claims (sum, cel.bind) loaded and evaluated correctly in the probe; the mis-shaped tree the walkers see was established by reading the code, not by a witness that came out wrong.
• validate: protovalidate is a second CEL evaluator in the binary — its own environment, no cost limit, no interrupt, now bound, cross-type numerics on — and plugin-authored cel rules already run through it at flow validate and in the editor #1531's cost exposure was established by reading protovalidate's sources (no limit option exists), not by timing a pathological plugin rule; its acceptance criteria require that test.
• ci: hover, flow tasks, the MCP catalog and docs/reference/tasks.md are rendered from schema comments, and buf lint does not require one — 72 of 606 fields in flowstate/v1 have no comment, including every arm of Value #1544's count comes from the embedded source-info descriptor set with map-entry fields excluded; a buf lint run with the COMMENTS rules may count oneofs and enum values differently, and buf is not installed in the audit environment.
• The fifth pass ran the local driver only (no Temporal dev server in the audit environment). cel: a runtime expression failure reads "no such overload" and nothing else — cel-go's Err.NodeID() is already in the error chain, the spec holds every node's offset, and Positions holds the step's line #1551, cli/embed/mcp: a refusal at the submit boundary is an untyped fmt.Errorf — --output json prints prose and no document, embed.RunLocal classifies "declared int but was given string" as Internal, and three verbs print a text trailer after their JSON report #1552 and mcp: flowstate_run_local, run and get answer with protojson Value trees ({"literal":{"int64Value":"2"}}) while --output json projects the same run to plain JSON — the code says the two are "the same bytes", and they are two dialects #1553 name the durable driver in their acceptance criteria because the code paths are shared (ExpressionError, rundoc.go, the submit boundary), not because a durable run was observed.