alex a7d316493e docs: Expand undefined-expression spec to cover in-expression coercion ... Records the product owner's decision to cover both cases in v1: the whole resolved parameter value being undefined, and undefined being coerced into the text "undefined" inside an expression. Declarative nodes are in scope too. Adds the coercion surface mapped by execution (string +, template literals, String(), concat() produce the text; numeric +, Array.join, JSON.stringify and ?? do not), so the criteria can scope case B to the two syntactic sites. Adds a constraints section for case-B detection rather than picking the design: the tournament AST hook seam and the four-touchpoint __sanitize helper pattern to follow, and the hard constraint that transformed code is cached by expression string alone, so the transform must be emitted unconditionally and gated at runtime. Precision and performance become hard guardrails with revert criteria, and splitting the backend issue so case A lands before case B is recommended. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>		2026-08-12 14:10:05 +03:00
..
generated	feat(core): Add poller_state table for durable poll trigger cursors (no-changelog) (#35128)	2026-08-11 16:31:00 +00:00
product	docs: Expand undefined-expression spec to cover in-expression coercion	2026-08-12 14:10:05 +03:00
db.md	feat(core): Add auto-generated database schema documentation (no-changelog) (#32069)	2026-06-12 07:44:01 +00:00