feat(intent): cross-model entity references, n:m, and faithful field attributes

[delchev]

Context

Today an .intent model is self-contained: a relation's to: must target an entity in the same model, manyToMany is parsed but never materialized, and each model prefixes its own tables. There was no way to author the real-world pattern the codbex apps use, where each domain (UoM, Country, Currency, Customer, SalesInvoice, CustomerPayment) is its own project and entities reference each other across projects.

The codbex apps solve this with PROJECTION entities: a consumer stores an integer FK to the owner's Id and renders a dropdown sourced from the owner's REST service; the projection generates no table / DAO / controller locally. The owner model owns the single physical table. That mechanism existed only in the visual EDM editor — this PR lifts it into the .intent DSL, adds n:m via an explicit intermediate entity, and adds the field attributes needed for faithful models.

What changed

Tranche A — cross-model references

• New top-level uses: block (UsesIntent) + optional model: on a relation.
• Parser allows a to-one relation to target an entity in a declared uses model; rejects undeclared models and forbids cross-model composition.
• EdmIntentGenerator emits a PROJECTION entity per distinct cross-model target plus an integer FK + dropdown on the consuming side. CrossModelSupport reads the owner's already-generated .model for the exact perspective / PK / table (convention fallback when the owner isn't generated yet). Projections carry a blank perspective so they stay out of the consuming app's navigation.
• workspaceName plumbed through endpoint → service → context for the projectionReferencedModel path.
• No template changes — parameterUtils.js / generateUtils.js and the schema template already handle type=PROJECTION (table skipped; cross-model FK resolves to the owner's table in the shared DB).

Tranche B — n:m via an explicit intermediate entity (composition to one side, cross-model manyToOne to the other, plus bridge fields like Amount for partial allocations). Reuses the composition + cross-model code paths; no extra generator logic. manyToMany stays non-materializing.

Tranche C — faithful field attributes: FieldIntent gains unique, precision, scale, calculatedOnCreate, calculatedOnUpdate; entities gain audit: true (emits the four standard audit columns). EdmIntentGenerator emits dataUnique, precision/scale, isCalculatedProperty + calculatedPropertyExpression*, and auditType — the exact attribute names the DAO/schema templates consume.

Examples + docs + tests

• 6 Billing example .intent files (uoms, countries, currencies, customers, customer-payments, sales-invoices) under engine-intent test resources, including the cross-model SalesInvoiceCustomerPayment n:m intermediate.
• intent-assistant-guide.md documents uses:, cross-model relations, the n:m intermediate pattern, and the new field attributes.
• Parser tests (cross-model accept/reject, cross-model composition reject, unique/calculated parse) + a new EdmIntentGeneratorTest asserting projection shape, FK metadata, no-perspective-leakage, n:m, calculated, and audit. 21/21 pass.

Target runtime

The intent scaffold defaults the code-gen recipe to template-application-ui-harmonia-java (Java DAO/REST + Harmonia UI), which sets javaRuntime=true, so cross-model dropdowns generate as /services/java/{ownerProject}/gen/{ownerModel}/api/{Perspective}/{Entity}Controller. The .model is template-agnostic, so switching a project to the AngularJS/TypeScript recipe emits the /services/ts/... form with no intent changes.

Known limitations (documented, not fixed)

• The cross-model dropdown URL has no workspace segment, so all referenced projects must be published to the same runtime (the codbex deployment model).
• The Java DAO injects a calculated expression as raw Java, so codbex's JS NumberGeneratorService does not apply to the Java path; the example uses a compilable java.util.UUID.randomUUID().toString() and documents the swap.

Verification

• Unit: mvn -pl components/engine/engine-intent test (21 tests pass).
• End-to-end (requires a running Dirigible, not run here): generate the 6 projects leaf-first, then assert CUSTOMERS_CUSTOMER has integer CUSTOMER_COUNTRY/CUSTOMER_CURRENCY, SALES_INVOICES_SALES_INVOICE_CUSTOMER_PAYMENT has the composition FK + integer ..._CUSTOMER_PAYMENT + decimal ..._AMOUNT, no Country/Currency/Customer/CustomerPayment table is created by consuming models, and the cross-model dropdowns + n:m allocation work in the UI.

🤖 Generated with Claude Code