Expression type checking for mxcli check (microflows + nanoflows)

[ako]

Tracking issue for the v0.13.0 milestone. Design: docs/11-proposals/PROPOSAL_expression_type_checking.md.

Problem

mxcli check is a syntactic validator today. It catches grammar errors but not type mismatches that produce silent wrong results or CE errors in Studio Pro. Examples that pass mxcli check today:

-- Silent wrong result: + is numeric add, not string concat
declare $Label string = 'Order #' + $Order/OrderNumber;  -- OrderNumber is Integer

-- Silent empty results: enum compared as string literal
if $Order/Status = 'Open' then ...   -- Status is enum; should be Module.OrderStatus.Open

-- Runtime CE0109: parseInteger expects String
declare $N integer = parseInteger($Count);  -- $Count is Integer

Studio Pro catches these at design time; mxcli should too.

Scope

Microflows and nanoflows in this milestone. Pages and security rules use different expression contexts and are out of scope.

Two tiers:

Tier	Requires project?	Examples
Scope-local	No	Variable type tracking, + overload mismatch, function argument count
Catalog-backed	Yes (--references)	Attribute type vs. comparison value, enum-in-expression vs. XPath, microflow return type

Acceptance criteria

• mxcli check reports type errors on all three examples above with actionable messages and line/column positions.
• The three example bugs each become a unit test in the type checker package, locking in detection.
• LSP surfaces scope-local errors as real-time diagnostics in VS Code (same channel as MDL-WIDGET01).
• mxcli check --references extends to catalog-backed checks; passes silently without --references to avoid blocking offline use.
• New mdl-examples/bug-tests/ fixtures cover each catch.
• Documentation: skill file at .claude/skills/type-check.md plus docs-site page with the error code list (e.g. MDL-TYPE001..N).

Non-goals

• Type checking page expressions (different context, deferred to v0.14+).
• Type checking security XPath constraints (catalog-driven; partially covered already by entity-access validation).
• Inferring types Studio Pro itself cannot infer.

Out of milestone but related

• Preserve microflow type and cardinality inference during rebuild #352 — Preserve microflow type/cardinality inference during rebuild (writer-side, not authoring-time)
• Microflow roundtrip: REST call with retry-loop error handler loses main-path variable scope (CE0108) #506 — REST call retry-loop error handler loses variable scope (specific roundtrip bug, not generic type check)

Phases

The proposal proposes implementation in tiers:

1. Scope-local type tracker — walks microflow/nanoflow body, builds a variable→type map per scope, validates expression and activity argument types against it.
2. Function/operator type table — enumerate Mendix built-in functions with signature (arg types) -> return type; check call sites against the table.
3. Catalog-backed attribute/enum checks — when --references is on, resolve $obj/Attr to a declared type from the catalog and validate downstream usage.
4. LSP wiring — surface scope-local diagnostics in real time without project access.
5. Catalog-backed LSP — opt-in when the catalog is loaded.

Each phase is independently shippable.

References

• Proposal: docs/11-proposals/PROPOSAL_expression_type_checking.md

[github-actions]

Issue Triage

Summary:
The issue proposes adding expression type checking to mxcli check for microflows and nanoflows so that type mismatches (e.g., wrong operator overloads, enum‑vs‑string comparisons, incorrect function arguments) are caught and reported with clear diagnostics.

Checklist for feature request completeness

Required information	Present?	Notes
Use case – why the feature is needed, what problem it solves	✅	Described: mxcli check currently only validates syntax, missing type errors that cause silent wrong results or runtime CE errors.
Proposed syntax or behavior (if applicable)	✅	Detailed: mxcli check should report type errors with messages/positions, unit tests, LSP diagnostics, catalog‑backed checks via --references, etc.
Mendix version relevance (if version‑specific)	❓	Not mentioned; please indicate which Mendix version(s) this feature targets or whether it is version‑agnostic.

Next steps
Could you please clarify the Mendix version relevance (e.g., does this apply to all recent Mendix releases, or is it specific to a certain version range)? Once that detail is added, the feature request will be complete. Thank you for contributing!

---

Automated triage via OpenRouter — workflow source