RFC: drop `microflow` keyword from MDL property values once catalog-backed type checking exists

[ako]

Follow-up to #573. Depends on #580 (catalog-backed expression type checking, v0.13.0).

Problem

Several MDL property values today require a leading microflow keyword that exists purely to tell the visitor which lookup table to use:

ConfigurationMicroflow: microflow Module.ConfigureRequest
HeadersMicroflow:       microflow Module.SetHeaders
ErrorHandlingMicroflow: microflow Module.HandleError

The keyword is redundant: the property name already tells the reader and the executor that a microflow reference is expected. We require it because today's offline parser can't distinguish a microflow qualified name from a constant qualified name without help.

The @ keyword for constants is NOT in scope — @Module.Constant mirrors actual Mendix expression syntax (if @Module.Debug then … inside microflow expressions), so dropping it would diverge from Studio Pro's idioms. It stays.

Proposal

Once #580 phase 3 (catalog-backed resolution: "resolve Module.X → is it a microflow / constant / entity / … with the right signature?") lands, the microflow keyword becomes a parse-time crutch we don't need on property-value positions. Make it optional:

-- both forms equivalent after this change
ConfigurationMicroflow: microflow Module.ConfigureRequest    -- still accepted
ConfigurationMicroflow: Module.ConfigureRequest              -- new, preferred

The existing form stays accepted (back-compat). The new form is preferred in documentation, describe output, and skill examples. Studio Pro reports the wrong-kind case as a real error via the same machinery #580 uses for parseInteger($IntVar) etc.

In scope (microflow-ref property values)

Document type	Property	Today	After
ODATA CLIENT	ConfigurationMicroflow	microflow X.Y	X.Y
ODATA CLIENT	HeadersMicroflow	microflow X.Y	X.Y
ODATA CLIENT	ErrorHandlingMicroflow	microflow X.Y	X.Y
ENTITY event handler	EventHandler	microflow X.Y	X.Y
ATTRIBUTE	CalculatedBy microflow	microflow X.Y	X.Y
(sweep mdl/visitor/ for other "MICROFLOW " + emitters during implementation)

Out of scope

@Constant references — kept as-is because it mirrors Mendix expression syntax. Properties that accept an expression (e.g. ServiceUrl: @Mod.UrlConst) continue to use @; properties that take a by-name constant reference (e.g. ProxyHost: Mod.HostConst) continue without it.

Structural / action-call sites — keep the keyword because it's grammar-structural, not just a disambiguator:

• call microflow X.Y(...) vs call java action X.Y(...) vs call rest … — the keyword routes to a different action shape.
• expose entity X as microflow Y (published OData CallMicroflowToRead/Change) — distinguishes a CallMicroflow* source from a database source.
• Anywhere the keyword sits at the head of a statement or selects between distinct grammar productions.

Tradeoffs

1. Offline check loses microflow-kind validation on these properties. Today, mxcli check (no --references) catches ConfigurationMicroflow: @Mod.X as a parse-time wrong-kind use. After this change it'd parse silently; mxcli check --references catches it via the resolver. Acceptable — today's check is nominal anyway (just keyword presence, not actual resolution).
2. Round-trip churn. DESCRIBE would switch to emitting the bare form, so existing user MDL scripts that used the keyword would diff against new output. Mitigation: emit the bare form by default; keep a --legacy-keywords flag on describe for older toolchains.
3. LSP completion. Today the keyword anchors completion ("after microflow , complete microflow names"). After the change, completion must be type-aware (driven by the property name on the LHS). This is mostly free once Expression type checking for mxcli check (microflows + nanoflows) #580 phase 4/5 lands (LSP-side resolver).

Acceptance criteria

• Visitor accepts both forms on every in-scope property; grammar tests for both shapes.
• mxcli check --references reports an actionable error when the resolved kind doesn't match the property's expected kind (e.g. MDL-TYPEXX: ConfigurationMicroflow expects a microflow, got constant 'Module.X').
• DESCRIBE emits the bare form by default.
• One bug-test per in-scope property in mdl-examples/bug-tests/ (wrong-kind case → caught by mxcli check --references).
• .claude/skills/ updates point at the new preferred syntax.

Non-goals

• Removing the @ keyword for constants — kept to match Mendix expression syntax.
• Removing the keyword from structural / action-call sites.
• Dropping back-compat for the microflow X.Y form.
• Inferring property kinds from the value (always drive from the property name — explicit and stable).

Milestone

v0.14+, after #580 phase 3 lands.

[github-actions]

Issue Triage

Summary:
The issue proposes making the microflow keyword optional in MDL property values once catalog‑backed type checking is available, allowing both microflow X.Y and the bare X.Y forms while keeping backward compatibility.

Checklist for feature request

Required info	Present?	Notes
Use case – why the feature is needed, what problem it solves	✅	Clearly described in the “Problem” section.
Proposed syntax or behavior (if applicable)	✅	Detailed in the “Proposal” section with examples and acceptance criteria.
Mendix version relevance (if version‑specific)	⚠️	Not explicitly mentioned; the change is tied to mxcli milestones (v0.14+) rather than a specific Mendix version, so version relevance is not required here.

Conclusion:
All essential information for a feature request is provided. Thank you for the thorough RFC!

---

Automated triage via OpenRouter — workflow source