intent: the glue stops carrying Criteria, java.time and BigDecimal - the query, the period and the compared default become data (#7406)

[delchev]

Stacked on #7405, which took the .edm/.model's checks[]. The .glue is the same kind of artefact for the process half — the description every template reads, Java and JavaScript alike — and GlueIntentGenerator was writing Java source into it:

"criteriaExpression": "Criteria.create().lt(\"Due\", java.time.LocalDate.now())",
"lower":  "java.time.LocalDate.now().withDayOfMonth(1)",
"upper":  "java.time.LocalDate.now().withDayOfMonth(1).plusMonths(1).minusDays(1)",
"derivedDefault": "new java.math.BigDecimal(\"1\")"

Across the BusinessIntents fleet that is 69 of the ~135 java-carrying values, and the whole org.eclipse.dirigible.sdk builder surface. The glue now carries the same facts as data, and the language appears one layer out, in JavaLiterals:

"criteria": [ { "op": "lt", "property": "Due",
                "value": { "kind": "moment", "shape": "date",
                           "offset": "P7D", "forward": false } } ],
"kind": "range", "property": "Date", "period": "month",
"derivedDefaultValue": { "kind": "number", "text": "1" }

The change

• ScheduleSupport keeps the operator vocabulary, the moment grammar and every refusal, and returns the CLAUSES instead of the chain (criteria / conditions, replacing criteriaExpression / conditionChain); Moment.javaExpression is gone, its rendering having moved. A create-from's source-row rule (items: where:, intent: generates items: has no source-row rule - every member row is cloned into a line, so an empty or unapproved EmployeeTimesheet is billed (or blocks the whole month) #7091) rides the same reading as itemCriteria.
• A roll-up's and an expansion's criteria were never more than eq(<fk>, <owner>.<key>) over values the descriptor already carries, so they are dropped from the glue outright and built by the binder.
• A run: key term carries the PERIOD the author declared rather than where that period begins and ends — which is also the only place the two bounds stay derived from each other.
• JavaLiterals gains criteriaChain / criteriaExpression, periodLowerExpression / periodUpperExpression / todayExpression and derivedDefaultExpression; GlueGenerator calls them in the four binders that used to copy the rendered key.
• Every one of those binders falls back to the rendered key when the descriptor carries it, so a project generated before this renders byte-identically until it is regenerated — the rule hasGenUnique and the postings: an aggregate: true header column a posting maps is overwritten by save()'s recalculate and read as an amendment on every redelivery; the expressionDefault rename has no .glue fallback #7234 spellings already follow. The ModelGenerationIT fixture orders.glue still carries criteriaExpression and exercises that path.

What is deliberately not here

The expr / guard / guardExpr / dueExpression / guardExpression / languageExpression / fileNameExpression family — the ternaries, the Calc.eval guards and the print SDK calls. Those are expressions, not literals or builder chains; #7406 asks for them last and deliberately, and they are now tracked, inventoried, in #7425.

Verified

• engine-intent unit suite green (1326 tests), ide-template green (176).
• IntentEmissionCoverageIT green — it compiles and runs the generated handlers, so the generated Java is byte-identical where it matters.
• IntentEngineIT green; its glue assertion now pins the neutral clauses and that no Criteria.create() appears anywhere in the generated glue.
• ModelGenerationIT green — it regenerates from a pre-split orders.glue, so the backward-compatible path is covered by a run, not only by a unit test.
• mvn formatter:validate clean with the formatter cache wiped.

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

Fixes #7406

🤖 Generated with Claude Code