Sync ako/mxcli: 18 reported-issue fixes (check/exec parity, describe round-trips, Mendix 9 JDK)

.claude/skills/fix-issue/findings/cmd-mxcli/2026-10-12-check-several-files-ends-on-check-passed-after-failure.json

@@ -0,0 +1 @@
+{"area": "cmd/mxcli", "date": "2026-10-12", "symptom": "`mxcli check -p app.mpr bad.mdl good.mdl` exits 1 but its last line is \"Check passed!\"; reversing the file order flips the last line, so anything reading the log tail sees success", "cause": "`runCheckFiles` ran `runCheckFileAgainst` per file and kept only the worst exit code; each file prints its own verdict and nothing printed one for the set, so the last file's \"Check passed!\" (plus its no-project note) closed the run", "file": "`cmd/mxcli/cmd_check.go` (`runCheckFiles`)", "insight": "A per-unit verdict line is read as the run's verdict by whoever tails the log (agents especially); when a command loops over inputs, the loop owner must print the aggregate last. The per-file \"Check passed!\" is followed by the two-line no-project note, so assert on the true last line rather than `Contains`, or the test passes against the bug. No project needed for the test: a syntax error makes the failing file", "refs": ["mendixlabs/mxcli#1431"]}

.claude/skills/fix-issue/findings/cmd-mxcli/2026-10-12-describe-module-help-promises-all-contents.json

@@ -0,0 +1 @@
+{"area": "cmd/mxcli", "date": "2026-10-12", "symptom": "`mxcli describe module Banking -p app.mpr` prints only `create or modify module Banking;` and its module roles, although `describe --help` says \"module  Describe a module (all contents)\"; the full output needs `-c \"describe module Banking with all\"`, documented only in the changelog", "cause": "describeMDLCommand maps MODULE to a plain DESCRIBE MODULE (module + roles, by design of the MDL statement); the help line described WITH ALL, which the subcommand had no way to request", "file": "cmd/mxcli/cmd_describe.go, cmd/mxcli/main.go", "fix": "Added `--all` (applyDescribeAll appends WITH ALL; refused on any other type) and made the help say what plain describe module prints", "insight": "Fixed the help, not the default: a plain describe module matches `-c \"describe module X\"` and existing scripts that describe a module to get its header, and WITH ALL has known open gaps (#1421 omits doc types, #1425 truncates at 10k lines silently), so silently switching the default would trade a wrong help line for silently incomplete output. When a subcommand's help and the MDL statement disagree, check which one the -c form agrees with before choosing which to change.", "refs": ["mendixlabs/mxcli#1435"]}

.claude/skills/fix-issue/findings/cmd-mxcli/2026-10-12-describe-subcommand-rejects-rule.json

@@ -0,0 +1 @@
+{"area": "cmd/mxcli", "date": "2026-10-12", "symptom": "`mxcli describe rule M.Rule_X` prints \"Unknown type: rule\" and bare `mxcli describe M.Rule_X` says no describable document is found, while `mxcli -c \"describe rule M.Rule_X\"` works", "cause": "Same drift as #1347: describeMDLCommand had no RULE case, and the auto-detect maps (catalog ObjectType RULE, unit $Type Microflows$Rule) omitted rules — the unit map even said so on purpose, a leftover from before the executor could describe rules", "file": "cmd/mxcli/cmd_describe.go", "fix": "Added RULE -> DESCRIBE RULE, objectTypeToDescribe[RULE] and unitTypeToDescribe[Microflows$Rule] = rule, plus the help and Valid-types lines", "insight": "Second instance of the subcommand's hand-kept type list lagging the DESCRIBE grammar. The executor's own bare-DESCRIBE map (mdl/executor/describe_auto.go objectTypeToDescribeKind) already had RULE — diffing that map's keys against cmd/mxcli's objectTypeToDescribe is the quickest way to find the next missing doctype. The 'not a rule in this project' refusal in the same report is a downstream effect, not a describe bug.", "refs": ["mendixlabs/mxcli#1402"]}

.claude/skills/fix-issue/findings/cmd-mxcli/2026-10-12-marketplace-download-output-directory-rename-file-exists.json

@@ -0,0 +1 @@
+{"area": "cmd/mxcli", "date": "2026-10-12", "symptom": "`mxcli marketplace download <id> --output <existing dir>` fails with `write <dir>: rename <parent>/.mxcli-download-*.part <dir>: file exists`; only a file path works", "cause": "The command streams to a temp file in `filepath.Dir(output)` and renames it onto `output`, treating `--output` as a file path unconditionally; rename(2) onto a non-empty directory is EEXIST", "file": "`cmd/mxcli/cmd_marketplace.go` (`runMarketplaceDownload`)", "insight": "The temp-then-rename pattern decides the destination before it knows what `--output` names. Resolve directory-ness first (existing dir, or trailing separator = dir to create), put the temp file inside it so the rename stays on one filesystem, and join the CDN filename (or the content-<id>-<ver>.mpk fallback). Testable offline: `runMarketplace` + `marketplaceClientFactory` with one httptest server serving versions, the 303 hop and the CDN file — the CDN hop uses http.DefaultClient, which reaches a plain-http httptest server fine", "refs": ["mendixlabs/mxcli#1443"]}

.claude/skills/fix-issue/findings/cmd-mxcli/2026-10-12-run-local-mendix9-defaults-to-jdk21.json

@@ -0,0 +1 @@
+{"area": "cmd/mxcli", "date": "2026-10-12", "symptom": "`mxcli run --local --db-type hsqldb` on a Mendix 9.24 app failed in mxbuild's Gradle 7.6 with \"Unsupported class file major version 65\": mxcli resolved JDK 21 and skipped a JAVA_HOME pointing at JDK 17, and the JDK-not-found hint suggested `alter settings runtime ( JavaVersion: '21' )`, which no-ops on 9.x", "cause": "`ProjectJavaMajor` fell back to a flat `DefaultJavaMajor = 21` whenever the model stores no JavaVersion — but a Mendix 9 model never stores one (the setting does not exist before 10.x), and 9.x supports Java 11/17 only. The detect.go hint fired for any major != 21, including 9.x's 17", "file": "`cmd/mxcli/docker/javaversion.go` (`ProjectJavaMajor`, `defaultJavaMajorForMendix`), `cmd/mxcli/docker/detect.go` (`resolveJDKWith` hint gate)", "insight": "\"Setting absent\" meant \"use the platform default\" only while every supported version shared one default; once a version range without the setting has a different JDK, the fallback has to be keyed on the Mendix version, which the reader already has (`ProjectVersion().MajorVersion`). The committed 9.24.30 fixture (modelsdk/mpr/testdata/v1-project) made this testable without mxbuild. Revert proof: ProjectJavaMajor(9.24 fixture) = (21, false), want (17, false)", "refs": ["mendixlabs/mxcli#1437"]}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-12-flow-writes-refused-on-mendix-9.json

@@ -0,0 +1 @@
+{"area": "mdl/backend", "date": "2026-10-12", "refs": ["mendixlabs/mxcli#1410", "mendixlabs/mxcli#1434"], "symptom": "Every create microflow / create nanoflow / alter microflow on a Mendix 9.x project failed after earlier statements had already been written: \"this Mendix 9.24.2 project cannot store Microflows$Microflow.StableId (Mendix 10.2.0+); Microflows$SequenceFlow.CaseValues (Mendix 10.15.0+)\" (10.0-10.14: CaseValues alone), while `mxcli check` passed the script", "cause": "The flow writers emitted the newest shape whatever the version, gated by major at most: StableId as an unconditional FreshGUIDFields codec default (10.2+), the case always as a CaseValues list (10.15+), always a BezierCurve Line (10.16+), ReturnVariableName and parameter IsRequired/DefaultValue on any 10.x (10.12+ / 10.17+). The property floor added on 2026-10-10 started refusing the two that held a value; before it they were written silently, and on 9.24 the case list is not read at all (forced back in: 8 errors, CE0079/CE0773). Line, LineType, ReturnVariableName and the parameter keys were never refused because the floor looks a key up on the element's own $Type only and these are declared on supertypes (Flow, MicroflowBase) or under another $Type (MicroflowParameterObject). And gen bound the single case under its SDK name \"CaseValue\"; Studio Pro stores it as \"NewCaseValue\"", "file": "`mdl/backend/modelsdk/microflow_write.go` (flowVersion, microflowEncoder, sequenceFlowToGen, annotationFlowToGen, microflowParameterToGen), `nanoflow_write.go`, `rule_write.go`, `microflow_mutator_write.go`, `microflow_readback.go`, `microflow.go` (flowsFromGen reads the bezier vectors), `modelsdk/gen/microflows/types.go` (initSequenceFlow storage-name override), `modelsdk/codec/encoder.go` (OmitKeys applies to registered defaults)", "insight": "Get the old shape from a real document, not the gen: dump a Studio Pro-authored 9.x flow (any marketplace module's microflow with a decision) and run `mx convert -p` to a mid-10 version (10.12.19 here) to get a Studio Pro-serialized document for that version for free — its key sets settle LineType (10.8-10.15 only), NewCaseValue, StableId and the absent parameter keys in one dump, and mxcli's output can be diffed key-set for key-set against it. The floor (canon.StripUndeclaredProperties) is a backstop, not a gate: it cannot see supertype-declared keys, so a writer clean under the floor can still write keys the version lacks — check the Model SDK's versionInfo for the type AND its supertypes. A refusal at exec time leaves earlier statements written; #1434 (check is not version-aware) is the same root cause and is cured by the writer emitting a storable shape, not by teaching check the floor."}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-12-system-java-action-by-name.json

@@ -0,0 +1 @@
+{"area": "mdl/backend", "date": "2026-10-12", "refs": ["mendixlabs/mxcli#1445"], "symptom": "`list java actions in System` showed System.VerifyPassword, but `describe java action System.VerifyPassword` failed with \"java action not found: System.VerifyPassword\", and exec of a microflow calling it logged \"warning: could not look up Java action System.VerifyPassword: java action not found ... (entity type params will be empty)\"", "cause": "ReadJavaActionByName only scanned stored JavaAction units, after first resolving the module by name, which fails for System since it has no stored module unit; the System built-ins are virtual (meta.SystemJavaActions) and were synthesized on the list paths only", "file": "`mdl/backend/modelsdk/java_read.go` (ReadJavaActionByName, systemJavaActionByName)", "insight": "Virtual System-module members have to be synthesized on EVERY read path of a doctype, not just the list path: when one is fixed, grep the backend for the matching by-name reader. The fallback must also sit before the module lookup, because GetModuleByName(\"System\") returns nothing. Stored units still win, and an unknown System.X stays 'not found' (the test's control)."}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-12-alter-settings-javaversion-noop-on-9x.json

@@ -0,0 +1 @@
+{"area": "mdl/executor", "date": "2026-10-12", "symptom": "`alter settings runtime ( JavaVersion: '17' )` on a Mendix 9.24 model printed \"Unchanged model settings\" — a silent no-op instead of an error that the property does not exist on that version", "cause": "`refuseIfNotStored` exempted JavaVersion unconditionally because it is stored under one of two keys (JavaVersion / JavaMajorVersion), but a 9.x document carries neither, and `settingsoverlay.SetJavaVersion` writes nothing when `JavaVersionKey(raw)==\"\"`", "file": "`mdl/executor/cmd_settings.go` (`refuseIfNotStored`)", "insight": "An exemption from a presence gate written for 'stored under an alias' must still check that some alias is present: the alias resolver returning \"\" is the not-stored case. DESCRIBE already gated on `JavaVersionKey != \"\"`; the ALTER path had not been made symmetric. Revert proof: MockBackend with a 9.24-shaped part (no Java key) returns nil from alterSettings", "refs": ["mendixlabs/mxcli#1438"]}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-12-child-slot-content-described-not-template.json

@@ -0,0 +1 @@
+{"date": "2026-10-12", "area": "mdl/executor", "symptom": "mendixlabs/mxcli#1400: describe emits `content { }` for native pluggable-widget child slots (Repeater, SafeAreaView); check fails \"`content` is not a container of `repeater` — it declares: template [MDL-WIDGET26]\" and exec fails \"content needs a name\". 35 occurrences in the round-trip runs.", "cause": "Two derivations of one keyword. The widget definition names a widgets-typed slot with mdlContainerForWidgetSlot (content -> TEMPLATE, plus per-widget overrides); describe's extractChildSlots borrowed deriveObjectListKeyword, the OBJECT-LIST convention (singularise, its own override table), which leaves `content` as is.", "file": "mdl/executor/cmd_pages_describe_childslots.go", "fix": "extractChildSlots derives the keyword with mdlContainerForWidgetSlot(widgetID, key), the function the definition side uses.", "test": "TestExtractChildSlots_KeywordMatchesDefinition (tagContentContainer slot is the control)", "insight": "**When describe and the definition each compute a keyword, they must call the same function** — describe borrowed the nearest-looking helper (object lists) and agreed with the definition on every key except the overridden ones, so only a widget with a `content` slot showed it. The MDL-WIDGET26 message lists what the definition declares; compare that against the describe output before reading either side's code. Not covered: a placeholder inside a SafeAreaView is invisible to layoutPlaceholderNames (mdl/backend/modelsdk/layout_write.go), which walks only typed containers, not a CustomWidget's raw child slots."}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-12-describe-java-action-param-separator-after-doc-comment.json

@@ -0,0 +1 @@
+{"date": "2026-10-12", "area": "mdl/executor", "symptom": "`describe java action` on an action with a documented parameter printed `Name: String not null -- This sets the Name of the tool...,` so the comma sat inside the comment and `mxcli check` of the output failed `line 255:4 mismatched input 'Name' expecting ')'`.", "cause": "The parameter loop wrote the `, ` separator at the start of the next iteration, i.e. after the previous parameter's trailing `-- doc` comment. The JavaScript action describer is a copy of the same loop and had the same bug.", "fix": "Write the separator at the end of each non-final parameter, before its `--` comment (cmd_javaactions.go and cmd_javascript_actions.go).", "insight": "Any describer that emits a trailing `--` comment must emit list separators before it; a separator written 'before the next item' is only safe when nothing line-terminating can come between. grep `\"  -- \"` in mdl/executor for other list emitters. A describe->visitor.Build round trip catches it; a substring assertion on the describe text does not. Avoid naming a test parameter `Count`: it is an MDL keyword and the parser's keyword hint then masks the real error.", "issue": "mendixlabs/mxcli#1412", "file": "mdl/executor/cmd_javaactions.go, mdl/executor/cmd_javascript_actions.go (parameter loop)", "test": "mdl/executor/describe_code_action_param_separator_test.go TestDescribeJavaAction_ParamDocCommentKeepsSeparator, TestDescribeJavaScriptAction_ParamDocCommentKeepsSeparator; control: both fail `mismatched input 'Amount' expecting ')'` with the fix reverted"}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-12-describe-user-role-drops-check-security-false.json

@@ -0,0 +1 @@
+{"date": "2026-10-12", "area": "mdl/executor", "symptom": "`describe user role` omits `CheckSecurity` when it is false; create role with CheckSecurity: false, describe, drop, replay -> `show user roles` says Check Security: Yes. Silent security change on replay.", "cause": "formatUserRoleMDL followed 'leave out a property at Mendix's default (R12)' but printed CheckSecurity only when true, the inverse of the default: Security$UserRole.CheckSecurity defaults to true (modelsdk/canon/studiopro_property_defaults.json), and genSec.NewUserRole writes it so. `create or modify` keeps an unstated stored value too, so even replay onto an existing role kept true.", "fix": "Always print `CheckSecurity: <bool>` in formatUserRoleMDL.", "insight": "An 'omit at default' describer is only correct if the omitted value equals what the writer gives a new element; check the default in studiopro_property_defaults.json, not Go's zero value. The executor mock hid it: userRoleCtx's AddUserRole built roles with Go's zero CheckSecurity (false), matching the describer's wrong assumption, so the #707 round-trip test was green. A mock write method must mirror the real writer's defaults or the round trip proves nothing. For a security flag prefer always-explicit: create-or-modify keeps unstated values, so omission is never safe on replay onto an existing role.", "issue": "mendixlabs/mxcli#1427", "file": "mdl/executor/cmd_security.go (formatUserRoleMDL)", "test": "mdl/executor/issue707_remaining_test.go TestIssue1427_UserRoleCheckSecurityFalseSurvivesReplay; mdl-examples/bug-tests/1427-user-role-check-security-false.mdl; control: before the fix 'recreated role has CheckSecurity true, want false' and 'modified role kept CheckSecurity true, want false'"}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-12-image-collection-same-script-ref.json

@@ -0,0 +1 @@
+{"area":"mdl/executor","date":"2026-10-12","symptom":"a page whose `image` widget names `ModA.Icons.pix` was refused by check (\"image collection not found: ModA.Icons (referenced as ModA.Icons.pix)\") and by exec (\"Refusing to execute: 1 unresolved reference(s) above. Nothing was written.\") when the same script created the collection; split into two scripts it passed (mendixlabs/mxcli#1419)","cause":"validateWidgetReferences resolved image refs against the project only, under a comment saying MDL cannot create an image collection — stale since CreateImageCollectionStmt existed; scriptContext had no image-collection or image sets","file":"`mdl/executor/helpers.go` (validateWidgetReferences image branch), `mdl/executor/validate.go` (scriptContext.imageCollections/images, collectSingle)","insight":"**A comment justifying a missing same-script exemption ages into the bug.** Every other widget reference kind merges `sc.<kind>` into the project set; grep `validateWidgetReferences` for a kind that does not, and check whether the statement that creates it now exists. Merge only into non-nil project sets: nil means the project could not be read and must keep reporting nothing. The pre-check context is whole-script (collectDefinitions), like the other kinds — statement-order is not enforced here","refs":["mendixlabs/mxcli#1419"],"ce":[]}