Add support for Mendix 10.24 - Coding agent should know what is supported on each version

[ako]

The coding agent should what is supported on v10.24 versus 11.6, or 11.8

[github-actions]

Issue Triage

Summary:
The request is for the mxcli coding agent to be aware of which features are supported across different Mendix versions (e.g., 10.24, 11.6, 11.8).

Checklist for feature request

Required info	Present?	Notes
Use case – why the feature is needed, what problem it solves	❌	Not described; please explain the scenario where version‑specific knowledge would help (e.g., avoiding incompatible code generation).
Proposed syntax or behavior (if applicable)	❌	No detail on how the agent should expose or use this information (e.g., new flag, output format, etc.).
Mendix version relevance (if version‑specific)	✅	Mentions Mendix 10.24, 11.6, and 11.8.

Next steps
Could you please add a brief use case describing the problem you’re trying to solve and outline the desired behavior or syntax for the coding agent (e.g., a command‑line option, a query interface, etc.)? Thanks for contributing!

---

Automated triage via OpenRouter — workflow source

[github-actions]

Enhancement Implementation Guide

Completeness Assessment

The enhancement request lacks critical details needed for implementation. To proceed, I need clarification on:

1. Specific scope of version support: Does the user want to know:

   • Which MDL syntax statements are supported in each version? (e.g., CREATE IMAGE COLLECTION only in 11.6+)
   • Which Mendix model elements are available? (e.g., Nanoflows introduced in specific versions)
   • Which API capabilities are available in the modelsdk-go library per version?
   • Which widget types or microflow activities are version-specific?

2. Desired interface for accessing this information:

   • New MDL statement? (e.g., SHOW VERSION SUPPORT FOR 10.24)
   • New CLI command? (e.g., mxcli version-support --version 10.24 --feature microflows)
   • API endpoint in the modelsdk-go library?
   • Enhancement to existing commands like SHOW SETTINGS or SHOW STRUCTURE?

3. Output format expectations:

   • Human-readable table?
   • JSON for programmatic consumption?
   • Simple yes/no for specific feature checks?
   • Detailed documentation with examples?

4. Reference versions: The request mentions 10.24, 11.6, and 11.8, but should this support:

   • Only these specific versions?
   • A range of versions (e.g., all 10.x and 11.x)?
   • Dynamic version specification?

Without these details, any implementation risk building the wrong feature. The current request is too vague to design a proper solution.

Overlap Check

Existing functionality that partially relates to version awareness:

• Code generator: Already accepts -version flag to generate metamodel for specific Mendix versions (go run ./cmd/codegen/main.go -version 10.0.0)
• Reflection data: Version-specific reflection data exists in reference/mendixmodellib/reflection-data/
• Setup commands: mxcli setup mxbuild -p app.mpr auto-downloads mxbuild for the project's Mendix version
• Docker integration: mxcli docker check -p app.mpr uses version-specific mxbuild
• Catalog queries: Can query project metadata but not version-specific feature support

However, there is no existing way to query what MDL syntax/features are supported in a specific Mendix version independent of a project. The reflection data contains the information but isn't exposed through a user-friendly interface for version comparison.

Proposed MDL Syntax

Given the ambiguity, I'll propose a CLI-based solution (more appropriate for meta-information than MDL project modification) and evaluate it against MDL design guidelines:

Proposed CLI Command:

mxcli version-support --version 10.24 --feature microflows
mxcli version-support --version 11.6 --feature pages
mxcli version-support --compare 10.24 11.6 --feature all

Evaluation against MDL CLI patterns (not MDL syntax, but follows similar principles):

• ✅ Reads as English: "version support for 10.24 microflows" is clear
• ✅ Standard patterns: Follows existing mxcli subcommand pattern (mxcli sql, mxcli lint)
• ✅ Qualified concepts: Uses --feature to specify domain (microflows, pages, etc.)
• ✅ LLM-friendly: One example shows the pattern for variants
• ✅ Diff-friendly: Adding a feature flag is a clear, single-line change
• ⚠️ Not MDL syntax: This is a CLI command, not MDL statement (appropriate for tool capabilities)

If an MDL statement were preferred (less suitable for this use case):

SHOW VERSION SUPPORT FOR 10.24 IN MICROFLOWS;
SHOW VERSION SUPPORT FOR 11.6 COMPARED TO 10.24;

This would violate MDL principles as it doesn't operate on Mendix project elements (it's tool meta-information).

Implementation Roadmap

Assuming CLI command implementation (most appropriate):

1. Add CLI command definition (cmd/mxcli/cmd_version_support.go):

   • Define Cobra command with flags: --version, --compare, --feature, --format
   • Register in cmd/mxcli/root.go

2. Implement version support logic (cmd/mxcli/version_support.go):

   • Load reflection data for specified versions from reference/mendixmodellib/reflection-data/
   • Map reflection data to MDL feature support (requires understanding what reflection elements correspond to MDL capabilities)
   • Implement comparison logic for --compare flag
   • Format output as table (default) or JSON (--format json)

3. Define feature domains (based on existing MDL areas):

   • domainmodel (entities, associations, enumerations)
   • microflows (activities, nanoflows)
   • pages (widgets, snippets, layouts)
   • security (roles, access rules)
   • navigation
   • business-events
   • project-settings
   • odata
   • java-actions
   • constants
   • folders/move

4. Update help system:

   • Add help text in cmd/mxcli/help.go
   • Create help topic file cmd/mxcli/help_topics/version-support.txt

5. Update documentation:

   • Add to CLI reference in CLAUDE.md
   • Document in docs/03-development/ if appropriate

BSON Investigation

Not directly applicable since this feature queries tool capabilities rather than Mendix project BSON structures. However, to implement version support checking, I would need to:

1. Investigate reflection data structure:

   • Examine reference/mendixmodellib/reflection-data/<version>/ directories
   • Understand how reflection data maps to Mendix model elements
   • Identify which reflection types correspond to MDL-supported features
   • Check if reflection data includes version introduction/deprecation info

2. Specific investigation steps:

   # Compare reflection data between versions
   ls reference/mendixmodellib/reflection-data/10.24.0/
   ls reference/mendixmodellib/reflection-data/11.6.0/
   
   # Check for version-specific elements
   # Look for annotations like "since" or "deprecated" in reflection JSON
   grep -r "since" reference/mendixmodellib/reflection-data/11.6.0/

3. Key files to review:

   • internal/codegen/schema/ - How reflection data is loaded
   • generated/metamodel/ - See what types are generated for different versions
   • Existing version-specific tests if any

Testing Strategy

1. Unit tests for version support logic:

   • Test loading reflection data for different versions
   • Test feature detection accuracy (e.g., confirm nanoflows appear in 11.6+ but not 10.24)
   • Test comparison functionality
   • Test output formatting (table vs JSON)

2. Integration tests via CLI:

   # Basic functionality
   ./bin/mxcli version-support --version 10.24 --feature microflows
   
   # Comparison
   ./bin/mxcli version-support --compare 10.24 11.6 --feature pages
   
   # JSON output
   ./bin/mxcli version-support --version 11.8 --feature security --format json
   
   # Error cases
   ./bin/mxcli version-support --version 99.0  # Invalid version
   ./bin/mxcli version-support --feature nonexistent  # Invalid feature

3. Validation against known version differences:

   • Verify nanoflows are reported as unsupported in 10.24
   • Verify image collections are supported in 11.6+ (based on existing MDL implementation)
   • Check specific widget introductions if known

4. Add to test suite:

   • Add test file in cmd/mxcli/version_support_test.go
   • Ensure make test passes

Gotchas & Risks

1. Reflection data completeness:

   • Risk: Reflection data may not clearly indicate version introduction/deprecation
   • Mitigation: Cross-reference with Mendix release notes or Studio Pro behavior for key features

2. Mapping reflection to MDL features:

   • Risk: Not all reflection elements correspond to MDL-supported features
   • Mitigation: Focus on high-level domains first (entities, microflows, pages) rather than granular API differences

3. Version data availability:

   • Risk: Missing reflection data for specific versions (10.24, 11.6, 11.8)
   • Mitigation: Verify data exists in reference directory; document supported versions

4. Performance:

   • Risk: Loading large reflection datasets on every command invocation
   • Mitigation: Cache reflection data in memory after first load

5. Output clarity:

   • Risk: Technical output confusing to end users
   • Mitigation: Use clear feature names, group related features, provide summary counts

6. Maintenance overhead:

   • Risk: Need to update feature mappings when adding new MDL capabilities
   • Mitigation: Design loose coupling; consider generating feature map from MDL grammar/reflection during build

Critical recommendation: Before implementing, create a working example in Studio Pro for each version to verify what's actually supported (per BSON investigation guideline in CLAUDE.md). For instance, create a project with nanoflows in 11.6 and verify it fails to open in 10.24 Studio Pro.

---

Automated guide via OpenRouter — workflow source

[github-actions]

Enhancement Implementation Guide

Completeness Assessment

The enhancement request lacks critical details needed for implementation. The phrasing "The coding agent should what is supported" contains a grammatical error and doesn't specify what action the coding agent should take with version information.

Specific questions to ask the reporter:

1. What exact action should the coding agent perform with version information? (e.g., show comparisons, block unsupported syntax generation, provide version-specific examples, add LSP diagnostics?)
2. Which Mendix concepts should be version-checked? (All features? Specific domains like microflows, pages, security? Or just MDL syntax elements?)
3. Should this be implemented as:
   • New MDL syntax (e.g., SHOW VERSION SUPPORT)?
   • Enhanced CLI commands (e.g., mxcli check --target-version 11.6)?
   • LSP diagnostics that warn about version-incompatible syntax?
   • Updated documentation/skill files?
4. What output format is desired? (Tabular comparison? Error messages? Inline suggestions?)
5. Should the tool automatically detect the project's Mendix version from the .mpr file, or require explicit version specification?

Without these details, implementation cannot proceed accurately. The request appears to want the AI assistant (coding agent) to have version-aware knowledge when assisting users, but it's unclear how this should manifest in the mxcli tool itself.

Overlap Check

Existing features that partially address version awareness:

• Codegen tool: Already accepts -version parameter to generate version-specific metamodels (go run ./cmd/codegen/main.go -version 10.0.0)
• Reflection data: Version-specific reflection data exists in reference/mendixmodellib/reflection-data/
• Project detection: The mxcli setup mxbuild command auto-downloads version-specific mxbuild tools
• BSON handling: The parser/writer already handles some version differences through storage name mappings (documented in CLAUDE.md)
• Catalog queries: Existing SHOW CATALOG TABLES and SQL querying could potentially expose version metadata
• LSP infrastructure: The language server already provides syntax diagnostics that could be extended for version checks

No existing feature provides explicit version comparison or validation of MDL syntax against specific Mendix versions.

Proposed MDL Syntax

Since the request focuses on the coding agent's knowledge rather than a user-facing MDL feature, I recommend not adding new MDL syntax for this request. Instead, implement version awareness through:

1. Enhanced LSP diagnostics (no new syntax needed)
2. CLI command extensions (extending existing mxcli check)
3. Documentation/skill updates (no syntax changes)

If MDL syntax were absolutely required, it would violate design guidelines:

• ❌ SHOW VERSION SUPPORT - Not standard CRUD verb pattern
• ❌ CHECK VERSION COMPATIBILITY - Custom verb instead of standard patterns
• ✅ Better approach: Extend existing mx cli check with --target-version flag

Recommended approach: Extend existing validation rather than invent new syntax.

Implementation Roadmap

Focus on enhancing existing validation mechanisms rather than adding new MDL syntax:

Phase 1: Infrastructure (No user-facing changes)

1. Investigate version metadata storage

   • File: reference/mendixmodellib/reflection-data/
   • Examine how version differences are currently tracked
   • Check if reflection data includes introducedIn/deprecatedIn fields

2. Create version comparison utility

   • File: internal/version/version.go (new)
   • Functions: IsSupported(version, feature), GetUnsupportedFeatures(fromVersion, toVersion)
   • Pattern: Follow existing internal/codegen/ version handling

3. Modify reflection data loader

   • File: internal/codegen/schema/loader.go
   • Enhance to load version metadata alongside type definitions

Phase 2: LSP Diagnostics (User-facing)

1. Add version-aware diagnostics

   • File: cmd/mxcli/lsp.go
   • Enhance publishDiagnostics to check syntax against project's target version
   • Read target version from mpr file or mxcli.yaml config
   • Show warnings (not errors) for syntax requiring higher version

2. Add version configuration

   • File: cmd/mxcli/init.go
   • Add mxcli init --set-target-version 11.6 capability
   • Store in .mxcli/version or mxcli.yaml

Phase 3: CLI Validation Enhancement

1. Extend mxcli check command

   • File: cmd/mxcli/cmd_check.go
   • Add --target-version flag
   • When specified, validate all syntax against that version
   • Exit with error code if unsupported syntax found

2. Add version reporting command

   • File: cmd/mxcli/cmd_version.go (new)
   • mxcli version show - Shows detected project version
   • mxcli version features - Lists features available in current version
   • mxcli version compare 10.24 11.6 - Shows differences

Phase 4: Documentation & Skills

1. Update skill files

   • File: .claude/skills/check-syntax.md
   • Add section on version-specific validation
   • Example: mxcli check --target-version 11.6 script.mdl

2. Update CLI help

   • File: cmd/mxcli/help.go
   • Document new --target-version flag
   • Add version subcommand help

Phase 5: Testing

1. Add doctype test

   • File: mdl-examples/doctype-tests/99-version-test.mdl
   • Contains syntax valid in 11.6 but not 10.24
   • Verify correct behavior with --target-version flags

2. Add unit tests

   • File: internal/version/version_test.go
   • Test version comparison logic
   • Test feature support lookup

BSON Investigation

For version-specific features, focus on:

1. Reflection data structure

   • Location: reference/mendixmodellib/reflection-data/{version}/
   • Investigate: Do XML/JSON files contain version annotations?
   • Key files to check: domainmodels.xml, microflows.xml, pages.xml

2. BSON storage name variations

   • Already documented in CLAUDE.md (e.g., ShowPageAction → ShowFormAction)
   • Check if storage names changed between versions
   • Action: Create test MPR files in versions 10.24, 11.6, 11.8
   • Use go run ./cmd/debug/main.go to compare BSON structures

3. Required defaults by version

   • Some properties became required in newer versions
   • Check: sdk/mpr/writer_*.go for hardcoded defaults
   • Action: Create minimal entities in each version, examine BSON

Investigation steps:

# Create test projects in each version
mxcli setup mxbuild -p test1024.mpr --version 10.24
mxcli setup mxbuild -p test116.mpr --version 11.6
mxcli setup mxbuild -p test118.mpr --version 11.8

# Add identical microflow with REST call to each
# Dump BSON for comparison
go run ./cmd/debug/main.go test1024.mpr <microflow-id>
go run ./cmd/debug/main.go test116.mpr <microflow-id>
go run ./cmd/debug/main.go test118.mpr <microflow-id>

Testing Strategy

Doctype Test Script

Create mdl-examples/doctype-tests/99-version-test.mdl:

// Syntax valid in 11.6+ but not 10.24
CREATE MICROFLOW VersionTest.NewFeature()
RETURNS Boolean AS $Result
BEGIN
  // Example: Use a feature introduced in 11.6
  $Result = CALL MICROFLOW SomeModule.NewActivity_11_6();
  RETURN $Result;
END;

Validation Tests

1. LSP diagnostics

   • Open 99-version-test.mdl in VS Code
   • With project set to 10.24: Should show warning on NewActivity_11_6
   • With project set to 11.6: No warning
   • Verify diagnostic message includes version info

2. CLI validation

   # Should fail with 10.24 target
   mxcli check 99-version-test.mdl -p app.mpr --target-version 10.24
   # Expected: Error about unsupported syntax
   
   # Should pass with 11.6 target
   mxcli check 99-version-test.mdl -p app.mpr --target-version 11.6
   # Expected: Syntax OK

3. Integration tests

   • File: mdl/executor/version_test.go
   • Test mxcli version compare output accuracy
   • Test version-aware code generation

Expected mx check validations

• With --target-version: Returns non-zero exit code if unsupported syntax detected
• Error message format: VS0123: 'NewActivity_11_6' requires Mendix 11.6 or higher (current target: 10.24)
• Without flag: Uses project's detected version from .mpr file

Gotchas & Risks

Common Pitfalls

1. Storage name vs qualified name mismatches

   • Risk: Assuming feature availability based on qualified name when storage name changed
   • Mitigation: Always verify against actual BSON/storage names from reflection data
   • Example: CreateObjectAction qualified name existed in 10.0 but stored as CreateChangeAction

2. Missing BSON defaults in older versions

   • Risk: Generated BSON missing required properties for target version
   • Mitigation: Version-aware writer that adds version-specific required defaults
   • Check: sdk/mpr/writer_*.go for version-conditioned serialization

3. Reflection data gaps

   • Risk: Incomplete version metadata in reference/mendixmodellib/reflection-data/
   • Mitigation: Fallback to safe assumption (feature unsupported) when data missing
   • Action: Verify reflection data completeness for versions 10.24, 11.6, 11.8

4. Performance impact

   • Risk: Version checks slowing down LSP/parsing
   • Mitigation: Cache version comparisons; lazy-load metadata
   • Benchmark: Ensure <5ms overhead per diagnostic

5. False positives/negatives

   • Risk: Overly restrictive version checking blocking valid syntax
   • Mitigation: Start with warnings (not errors) for LSP; make CLI flags explicit
   • Guideline: When in doubt, assume feature is supported (avoid blocking valid work)

Version-Specific Risks

• 10.24 → 11.6: Major namespace changes (many System → Mendix moves)
• 11.6 → 11.8: Minor feature additions, mostly API/stability focused
• Critical: Always validate with actual Studio from

---

Automated guide via OpenRouter — workflow source

[ako]

Relevant docs:

• https://github.com/mendixlabs/mxcli/blob/main/docs/11-proposals/BSON_SCHEMA_REGISTRY_PROPOSAL.md
• https://github.com/mendixlabs/mxcli/blob/main/docs/11-proposals/PROPOSAL_version_aware_agent_support.md

[ako]

@retran, @engalar Any thoughts on these?