intent: the glue's expression keys carry readings, not Java - the mapped values, the Calc guards, the print SDK calls and the ternaries (#7425)

[delchev]

Continues #7406, whose literal and builder-chain tiers shipped in #7426. What was left was the tier that issue named last: the expressions. Across the BusinessIntents fleet the .glue still carried Java source in every expression key:

"expr":  "Calc.eval(\"-(Net - Discount)\", source, 2)",
"guard": "Calc.eval(\"Vat\", source, 6).compareTo(new java.math.BigDecimal(\"0\")) != 0",
"attachLanguageExpression": "attachLanguageSource == null || ... ? org.eclipse.dirigible.sdk.print.Print.defaultLanguage() : attachLanguageSource.Code.trim()",
"fileNameExpression": "org.eclipse.dirigible.sdk.print.FileNames.part(document.Number) + \"_\" + ...",
"dueExpression": "entity.ValidUntil == null ? java.util.Date.from(java.time.Instant.parse(\"9999-12-31T00:00:00Z\")) : ...",
"conditionalRuleGuards": ["(Calc.eval(\"Method\", source, 6).compareTo(new java.math.BigDecimal(\"1\")) == 0 ? ruleRow.CashAccount : ruleRow.BankAccount)"]

The change

The glue now carries each of those as a reading - a kind-tagged map of the authored facts - and the Java appears one layer out:

"reading":      { "kind": "calc", "text": "-(Net - Discount)", "owner": "source", "scale": "2" },
"guardReading": { "kind": "calcCompare", "owner": "source", "property": "Vat", "equal": false, "text": "0" },
"attachLanguage": { "kind": "languageFrom", "owner": "attachLanguageSource", "property": "Code" },
"fileName": { "kind": "concat", "parts": [ { "kind": "concat", "parts": [ { "kind": "part", "of": { "kind": "read", "owner": "document", "property": "Number" } }, ... ], "forceString": true }, { "kind": "string", "text": ".pdf" } ] },
"due": { "kind": "due", "property": "ValidUntil", "shape": "date" },
"guardTerms": [ { "owner": "entity", "property": "Internal", "equal": false, "type": "boolean", "value": "true", "numericKey": false } ]

• Readings (engine-intent, package-private) is the one factory every emitting site spells a reading through; JavaExpressions (ide-template, beside JavaLiterals) is the one renderer - a closed vocabulary of 21 kinds, each rendering exactly what the generator used to write, so the generated handlers are byte-identical (qualifiedExpression spells Calc fully qualified for the transition controller, which imports none).
• The keys: reading on every assignment (create-from fields / items / computed lines, schedule generate fields / children / natural-key property terms, posting header and item cells, posts: cells, prompt: conversions), guardReading on a derived row and a transition, guardTerms on every event binding (triggers, notifications, integrations, outbound, resolves, waits - the very typed terms CheckSupport.conditionTerms produces for the model's checks, or the untyped spelling-inferred terms for the three sites that never had an entity to type against), due on a timer loader, attachLanguage / attachFileName on every notify site, language / fileName on a snapshot. conditionalRuleGuards is no longer carried at all: the binder derives it from the cells whose reading is a ruleCase.
• Every binder falls back to the rendered key an older .glue carries (expr, guard, guardExpr, guardExpression, dueExpression, the attach / language / file-name expressions), so an unregenerated project renders byte-identically - ModelGenerationIT's pre-split orders.glue still exercises that path.
• Three rules the shape obeys because the glue is serialized: keys in one fixed order per kind (intent: .glue terms built with Map.of serialize in a JVM-salted key order - a regen on a fresh container flips property/expr inside genUnique with no semantic change #7130), every number as text ("scale": "2" - the glue is read back through a parser that types every number as a Double), and an optional key omitted rather than written as null (Gson drops a null map entry).
• The Java renderers this leaves without a caller are removed: NotificationSupport.guard(...) / literalToJava, CheckSupport.condition / javaCondition / comparison / numericComparison / access, PostSetSupport.expression, GlueIntentGenerator's promptConversion / postSetExpr / conditionalRuleExpression / literalExpression / calcExpression / stringCellExpression / computedCellExpression. The templates are unchanged - they read the rendered keys the binder now writes.

Deliberately not changed

The untyped guards of a trigger, a wait and a register lookup stay untyped (a number term type renders the bare spelling), so Objects.equals(entity.Status, 3) is unchanged; typing them against the entity would change a to-one guard's comparison and is a separate decision. Keys outside the issue's inventory that carry no Java package (toExpression / subjectExpression / bodyExpression, urlExpression, matchSourceExpression, statusMatchExpression, an arrival's mapFields) are untouched.

Verified

• engine-intent unit suite green (1334 tests, of which the ~100 glue assertions that used to read expr / guard / guardExpression now render the reading through the test helper GlueRendering and still assert the same Java); ide-template green (192, incl. the new JavaExpressionsTest over every kind and the GlueGeneratorTest fallbacks).
• IntentEngineIT green (81) - its glue assertion now pins that none of the ten rendered keys and no Calc.eval appear anywhere in a generated glue, and that the guards and the snapshot language travel as readings.
• IntentEmissionCoverageIT green - it compiles and runs the generated handlers.
• ModelGenerationIT green - the backward-compatible path, run rather than only unit-tested.
• mvn -T 1C formatter:validate clean with the formatter cache wiped; the release-profile javadoc build of both modules clean.

Not verified: no run against a deployed instance, and no fleet regen - the fleet's .glue files change shape on their next regen (the keys above), which is the intent.

Fixes #7425

🤖 Generated with Claude Code