fix: skip System.* references in mxcli check --references

[hjotha]

Summary

mxcli check --references reports java action not found: System.VerifyPassword (and similar) on any microflow that calls a Mendix runtime built-in. The validator listed only Java actions found in the project's MPR; System-module actions are runtime-provided and never appear in the MPR.

Studio Pro's mx check resolves them against the runtime, so they pass there — but mxcli check --references cannot reach the runtime and produced false positives on built-in calls (System.VerifyPassword, System.GenerateRandomString, System.SubMicroflow*, etc.).

Skip Java/JavaScript action references whose qualified name starts with the System module — the same pattern (isBuiltinModuleEntity) already guards entity references in cmd_microflows_create.go and cmd_nanoflows_create.go.

Reproduction

Any MPR with a microflow that calls a System Java action — Administration.ChangeMyPassword is one example, but it affects every project that uses System.VerifyPassword, password handling, or other runtime built-ins.

$ mxcli describe -p app.mpr microflow Administration.ChangeMyPassword > /tmp/x.mdl
$ mxcli check /tmp/x.mdl --references -p app.mpr
Reference errors:
  statement 1: microflow 'Administration.ChangeMyPassword' has reference errors:
  - java action not found: System.VerifyPassword (referenced by call java action)

✗ 1 reference error(s) found

After this PR the same check returns ✓ All references valid.

Test plan

• TestValidateMicroflowReferencesSkipsSystemJavaAction — System.VerifyPassword reference must not error.
• TestValidateMicroflowReferencesReportsMissingUserJavaAction — pins that genuine missing user-module Java actions still error (so this skip doesn't mask real typos).
• go test ./... passes.
• Manual reproduction on Control Centre's Administration.ChangeMyPassword: pre-fix → CE0117 reported by mxcli check; post-fix → ✓ All references valid. Studio Pro's mx check was already happy in both cases (mpr_check_errors=0).

🤖 Generated with Claude Code

[github-actions]

AI Code Review

Critical Issues

None found.

Moderate Issues

None found.

Minor Issues

None found.

What Looks Good

• The fix correctly addresses the reported issue: skipping System.* Java/JavaScript action references during validation to avoid false positives.
• The implementation reuses the existing isBuiltinModuleEntity helper function, maintaining consistency with how built-in module entities are handled elsewhere (in entity validation).
• The test coverage is excellent:
  • TestValidateMicroflowReferencesSkipsSystemJavaAction verifies System actions are skipped
  • TestValidateMicroflowReferencesReportsMissingUserJavaAction ensures genuine missing user actions still produce errors
  • Both tests use the mock backend appropriately
• The change is minimal and focused, touching only the validation logic where the false positives occurred.
• The new helper function qualifiedNameModule is simple, safe, and well-scoped.
• The PR follows the established pattern from entity validation (cmd_microflows_create.go and cmd_nanoflows_create.go).
• Manual reproduction confirms the fix works as intended.
• All tests pass including the new ones.

Recommendation

Approve the PR. The fix is correct, well-tested, minimal, and follows existing patterns in the codebase. It resolves the false positives without masking real errors.

---

Automated review via OpenRouter (Nemotron Super 120B) — workflow source

[ako]

Review

Clean, minimal, approve-worthy. Two minor notes.

---

No blockers

The fix is the right call. isBuiltinModuleEntity is already the established guard for entity references in cmd_microflows_create.go and cmd_nanoflows_create.go; applying the same predicate to Java/JavaScript action references is consistent and correct. System-module actions are runtime-provided, never present in the MPR, and cannot be resolved without a live runtime — skipping them is the only sensible option short of a full static catalog of built-ins (which would be Mendix-version-dependent and hard to maintain).

---

Minor

m1 — ReadJavaActionByNameFunc in TestValidateMicroflowReferencesReportsMissingUserJavaAction is never called

The test sets ReadJavaActionByNameFunc on the mock, but validateFlowBodyReferences goes through buildJavaActionQualifiedNames → ctx.Backend.ListJavaActions(), not ReadJavaActionByName. The field does nothing in this test. Not a correctness problem, but it misleads a reader into thinking the validation path uses single-action lookups. Drop it.

m2 — qualifiedNameModule could return an empty string for an unprefixed name

func qualifiedNameModule(qn string) string {
    if i := strings.Index(qn, "."); i >= 0 {
        return qn[:i]
    }
    return ""
}

If a reference somehow arrives without a module prefix (e.g. "VerifyPassword"), qualifiedNameModule returns "", and isBuiltinModuleEntity("") returns false — the reference falls through to the known-map lookup and errors normally. That's fine in practice (all action references are qualified), but a comment on the function noting this contract would make the intent explicit.

---

LGTM

[ako]

Follow-up: stronger long-term alternatives

Merging this as-is is fine. For context on two longer-term approaches:

Near-term: catalog parity via a virtual Java actions list

System entities are already in the catalog because sdk/mpr/system_module.go builds a virtual System domain model (BuildSystemDomainModel) that is appended by ListDomainModels before the catalog builder runs. buildJavaActions in the catalog builder calls ListJavaActionsFull — which only reads from the MPR. There's no BuildSystemJavaActions equivalent.

Adding one would be straightforward — same pattern as systemEntities in system_module.go — and would let reference validation actually catch typos in System action names (System.VerifyPasswrd) rather than silently skipping all System.* calls. The downside is maintaining another hardcoded version-frozen list.

Longer-term: MCP-driven metamodel extraction

PROPOSAL_schema_extract.md (docs/11-proposals/) describes using Studio Pro's MCP PED API (ped_get_schema) to extract the complete metamodel — property structure, valid enum values, BSON $Type storage names — for every element type directly from Studio Pro. The same mechanism could enumerate the System module's Java actions and their parameter types empirically, producing a generated system_module.go rather than a hand-maintained one. PROPOSAL_mcp_bson_benchmark.md covers using MCP as a BSON correctness oracle more broadly.

That path would make system_module.go self-updating across Mendix versions, which is the root fix for the whole class of "runtime-provided but not in MPR" gaps.

[ako]

Also relevant: PR #335 (feat: add modelsdk — auto-generated type-safe model SDK) includes modelsdk/meta/ for System module metadata and a supplements.json-driven codegen approach that auto-generates 1,500+ types across 53 domains. That's the most direct predecessor to the MCP-extraction path — if the auto-generated SDK lands, system_module.go's hand-maintained entity and (future) Java action lists would migrate into generated metadata automatically.