Sync ako/mxcli: filemanager widget, no auto-created module roles, describe round-trip fixes

.claude/skills/fix-issue/findings/mdl-backend/2026-10-13-alter-set-image-static-image-refused-built-in-widget.json

@@ -0,0 +1 @@
+{"area": "mdl/backend", "date": "2026-10-13", "symptom": "`alter page … set (Image: 'M.Images.gear') on staticImage12` was refused with `property \"Image\" is not a property of this built-in widget` although CREATE writes `Image:` and DESCRIBE prints it; same for `DefaultImage:` on a dynamic image (mendixlabs/mxcli#1464).", "cause": "setRawWidgetPropertyMut had no image/defaultimage case, so the key fell through to the pluggable setter, which fails at noPluggableObjectError on any built-in widget.", "file": "`mdl/backend/pagemutator/mutator.go` (setLegacyImageRefMut), `sdk/pages/image_reference.go` (ImageReferenceProperty), `mdl/executor/validate_alter_set.go` (setImageRefErrors), `mdl/executor/helpers.go` (resolveImageRefs)", "insight": "**Every property CREATE gained for a built-in widget (#1057 Image, #1307 Tooltip, #1228 RenderMode) is a SET gap until the mutator switch learns it** — grep the CREATE builder's GetStringProp keys for the widget and diff against setRawWidgetPropertyMut. Guard on the stored $Type, not the key: `image` is also a plausible pluggable template key, and the pluggable Image keeps its own path. Making SET accept a reference also makes it the one place a reference skips `check --references` — the dry run only proves the key is writable, so resolve the written name too (reuse the CREATE resolver, which carries the same-script exemption #1419).", "refs": ["mendixlabs/mxcli#1464", "mendixlabs/mxcli#1307", "mendixlabs/mxcli#1057"], "ce": ["CE1613"]}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-13-create-modify-entity-index-guid-fresh-id-1470.json

@@ -0,0 +1 @@
+{"area": "mdl/backend", "date": "2026-10-13", "symptom": "`CREATE OR MODIFY PERSISTENT ENTITY` on a Studio Pro-authored entity with an index was refused at exec: `1 element(s) kept their $ID but would be written with a different GUID — … (DomainModels$EntityIndex): stored X, would write <$ID>`. Attributes of the same entity were carried fine; `check -p` passed.", "cause": "`carryIndexIdentity` fell back to position only when the semantic index ID was EMPTY. The executor (`buildEntityFromStmt`) mints a FRESH ID for every declared index, so the ID was present and simply missed `storedByID`; the positional branch was never reached, the codec encoded `GUID = $ID`, `TransplantIDs` reattached the stored `$ID`, and `canon.StorageGUIDError` refused. Attributes survived only because their fallback pass is by name and runs for any unpaired attribute, not just ID-less ones.", "file": "`mdl/backend/modelsdk/domainmodel_child_identity.go` (`carryIndexIdentity`)", "insight": "The #1119 carry tests modelled the statement-declared shape as 'members with no ID' and blanked the IDs themselves; the executor never does that, it mints fresh ones. A test of a write path must build its input the way the real caller does (here: fresh attribute, index and segment IDs, segments pointing at the fresh attribute IDs) — 'empty' and 'fresh-but-unknown' take different branches. Fallback passes must run on 'unpaired', not on 'has no key'. Second lesson: the index fallback must be POSITION, not the column list, even though the column list looks like the better identity — `TransplantIDs` aligns a nameless index list by position, so a GUID carried by columns onto a reordered list lands under its neighbour's `$ID` and the guard refuses it (tried, measured, reverted). The carry has to agree with the transplant's pairing or the guard turns the disagreement into a refusal. Proof: old binary refuses the pedapp repro (index GUID byte-patched away from $ID), fixed binary writes it with the GUID intact; reverting the fallback condition fails both new backend tests with the reported message.", "refs": ["mendixlabs/mxcli#1470", "mendixlabs/mxcli#1119"], "ce": []}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-14-alter-set-filemanager-properties.json

@@ -0,0 +1 @@
+{"date": "2026-10-14", "area": "mdl/backend", "symptom": "`alter page … { set (MaxFileSize: 20) on fileManager1; }` was refused with `property \"MaxFileSize\" is not a property of this built-in widget` (likewise Type, AllowedExtensions, ShowFileInBrowser), although `create page` accepted all four on a filemanager (mendixlabs/mxcli#151).", "cause": "setRawWidgetPropertyMut dispatches first-class keys by name and sends everything else to the pluggable setter, which refuses on a native widget. Adding a widget keyword to create (builder + writer + describe) does not reach the ALTER path, which is a separate dispatch over raw BSON.", "file": "mdl/backend/pagemutator/mutator.go (setWidgetFileManagerMut; the case is gated on pages.IsFileManager so `Type` on a pluggable widget keeps its route); sdk/pages/pages_widgets_input.go (CanonicalFileManagerType, shared with buildFileManagerV3)", "insight": "When a widget gains CREATE support, ALTER SET is the second write path to wire: probe it with one `set` per new property before calling the feature done. Gate a generic key like `Type` on the stored $Type rather than claiming it for every widget, and validate with the builder's own rule so set cannot store what create refuses. Keep a stored int's width (int32 vs int64), as DecimalPrecision does.", "refs": ["mdl/backend/pagemutator/filemanager_151_test.go"]}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-14-layout-canvas-not-carried-on-rewrite.json

@@ -0,0 +1 @@
+{"area": "mdl/backend", "date": "2026-10-14", "symptom": "re-executing the unchanged `describe layout` of a Studio Pro-authored layout reported \"Replaced\" and rewrote the unit, moving its canvas to 1280 × 800", "cause": "layoutToGen writes CanvasWidth/CanvasHeight as constants and UpdateLayout carried nothing, while every one of PedApp's 22 Atlas layouts stores another canvas (1198, 1204, 1000, 800, 550, 500 × 600)", "file": "`mdl/backend/modelsdk/layout_write.go` (`UpdateLayout`, `carryStoredLayoutCanvas`)", "insight": "The third document kind with the same defect: pages (#541) and snippets (#705) were fixed one at a time and layouts were missed, because each writer has its own constant-header block. When an editor-only property is carried for one document kind, grep the other writers for the same constant. Proved at the storage layer (unchanged rewrite keeps the unit byte-identical; fails with the carry removed) because Atlas layouts are in a marketplace module exec refuses to write", "refs": ["mendixlabs/mxcli#1411"]}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-12-describe-doc-comment-gutter-only-first-line.json

@@ -0,0 +1 @@
+{"date": "2026-10-12", "area": "mdl/executor", "symptom": "A doc comment line starting with a markdown `*` bullet lost its marker on describe → exec, one marker per cycle: `describe entity` printed `/**\\n * Intro line\\n* bullet one\\n */` and the replay stored `bullet one` (mendixlabs/mxcli#1428, 1 of 155 rows in the banking round trip).", "cause": "The describer side, not the parser: eleven describers (entity, association, enumeration, image collection, queue, regular expression, scheduled event and the four agent-editor doctypes) printed documentation with `\"/**\\n * %s\\n */\\n\"`, which gutters the first line only, and the entity attribute used the inline `/** %s */`. extractDocComment strips exactly one leading `*` per line, so an unguttered `* bullet` line lost its marker. The describers that split on newlines (microflow, page, constant, mappings, module, menu, Java action) were already right.", "file": "mdl/executor/cmd_entities_describe.go (entity + attribute), cmd_associations.go, cmd_enumerations.go, cmd_imagecollections.go, cmd_queues.go, cmd_regularexpressions.go, cmd_scheduledevents.go, cmd_agenteditor_{agents,kbs,mcpservices,models}.go — all now call outputJavadocIndented (cmd_odata.go)", "insight": "Pick the side by asking which one is wrong for a value it can see: the parser's one-`*`-per-line rule is the javadoc convention and correct for a guttered block, so the describer that omits the gutter is the defect. A single-line `/** %s */` is only safe for one line not itself starting with `*` — `/** * x */` loses the marker the same way. The bug survived because describe of a one-line doc looks right; only a multi-line doc whose continuation starts with `*` shows it, and without the `*` the unguttered line was silently tolerated (the parser trims whitespace), so the copy-paste format string spread to eleven files. Grep `/\\*\\*\\\\n \\* %s` for the copy. Verified: three describe → check → exec-on-a-fresh-copy cycles on an 11.6.6 app print byte-identical output, mx check 0 errors.", "refs": ["mdl/executor/doc_comment_bullet_1428_test.go", "mdl-examples/bug-tests/1428-doc-comment-bullet.mdl", "mdl/visitor/visitor_helpers.go", "docs-wiki/bug-patterns/describe-round-trip-gaps.md"]}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-12-describe-index-on-system-changed-date.json

@@ -0,0 +1 @@
+{"date": "2026-10-12", "area": "mdl/executor", "symptom": "`describe entity` of an entity with an index on its changedDate system member (Siemens FSM template 9.24.2, ten entities) printed `index ( desc);`, which `check` refuses (\"index on unknown attribute 'desc'\"), so every statement referencing the entity failed with it (mendixlabs/mxcli#1401).", "cause": "Not a dangling pointer: a system-member index segment is stored as DomainModels$IndexedAttribute.Type = ChangedDate/CreatedDate, with no attribute behind AttributePointer. The sdk IndexAttribute had no Type, indexFromGen dropped it, the describer resolved the column by attribute ID only (empty name, then ` desc`), the create/alter paths silently dropped or refused a `ChangedDate` column, and indexToGen hard-coded Type Normal — so any rewrite of such an entity (even `alter entity … set comment`) turned the index into an attribute segment pointing at nothing.", "file": "sdk/domainmodel/domainmodel.go (IndexAttribute.Type); mdl/backend/modelsdk/domainmodel.go (indexFromGen) and domainmodel_write.go (indexToGen); mdl/executor/cmd_entities.go (systemIndexMemberType, newSystemIndexSegment, indexSegmentName, reconcileDroppedIndexes); mdl/executor/cmd_entities_describe.go", "insight": "Before choosing between 'skip it' and 'resolve it' for a pointer that resolves to nothing, look in the gen type for a discriminator: IndexedAttributeType's CreatedDate/ChangedDate values (modelsdk/gen/domainmodels/enums.go) answered what the stored index holds without a Studio Pro fixture, and the repro (`ChangedDate: AutoChangedDate` next to the empty column) pointed at it. The semantic struct had narrowed the enum to a constant, so the read side lost it and the write side reinvented 'Normal' — the rewrite-drops-unauthored-state class, live on every entity rewrite, not only on describe. MDL spells the column as describe declares the member (`index (ChangedDate desc)`); the names are MDL020-reserved for attributes so they cannot collide. Verified on a blank 11.6.6 app: exec → mx check 0 errors, describe → check → re-exec Unchanged, unrelated alter keeps the index, describe → exec on a fresh copy → identical describe. A segment that resolves to neither now describes as a `-- index skipped` comment on its own line, so the statement still parses. Studio Pro's exact AttributePointer bytes for such a segment were not observed (no fixture holds one); mxcli writes the all-zero GUID it already uses for the sibling AssociationPointer, which mx check accepts.", "refs": ["mdl/executor/index_system_date_column_test.go", "mdl/backend/modelsdk/issue1401_index_system_member_test.go", "mdl-examples/bug-tests/1401-index-on-changed-date.mdl", "docs-wiki/bug-patterns/describe-round-trip-gaps.md", "docs-wiki/bug-patterns/rewrite-drops-unauthored-state.md"]}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-12-describe-selection-of-unemitted-widget.json

@@ -0,0 +1 @@
+{"area":"mdl/executor","date":"2026-10-12","symptom":"describe page wrote `DataSource: selection grid1` for a data view listening to a legacy Forms$DataGrid it only emitted as a \"NOT re-executable\" comment; check -p and exec refused the page: \"widget 'dataView1': selection DataSource references 'grid1' but no widget with that name exists on this page\" (mendixlabs/mxcli#1415).","cause":"outputWidgetMDLV3 renders each widget independently, so the default branch's decision to drop a widget never reached a sibling that referenced it by name. Now describeWidgetBody (page and snippet bodies) records the dropped names, and a widget whose selection source is dropped is commented out with it — transitively, and re-rendered when the dependent precedes its source in document order.","file":"`mdl/executor/cmd_pages_describe_dangling.go`, `cmd_pages_describe_output.go` (hook + default branch), `cmd_pages_describe.go` (page/snippet bodies)","insight":"A per-widget describer cannot keep a cross-widget reference honest: any widget it drops can strand a `selection X` elsewhere, before or after it. Check without -p passes such output (the reference needs the page tree), so only check -p / exec shows it. To reproduce without the FSM template, retype a list view in the fixture BSON: \"Forms$ListView\\x00\" and \"Forms$DataGrid\\x00\" are the same length, so a byte replace gives a real unauthorable widget with nothing else moved. A commented data view still loses data on re-exec, by necessity — the fix makes that visible, not lossless.","refs":["mendixlabs/mxcli#1415"]}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-12-enum-split-sixteen-branch-limit.json

@@ -0,0 +1 @@
+{"date": "2026-10-12", "area": "mdl/executor", "symptom": "`check -p` and `exec` refused an enum split DESCRIBE printed (the FSM template's 28-value NativeModelCheck_Process): \"enum split has 29 branches; at most 16 branches are supported\". `check` without -p passed, and `(empty)` counted toward the 16.", "cause": "addEnumSplit and the -p body validator capped branches at len(splitCaseOrderAnchors) = 16, the 4x4 origin/destination pair table that once stored each case's order. Since the grouped-lines change a split of four or more cases stores the order as origin side + canvas depth (enumSplitOriginAnchors / orderedEnumSplitFlows) and never consults the table, so the cap guarded nothing.", "file": "mdl/executor/cmd_microflows_builder_actions.go (addEnumSplit, maxEnumSplitBranches and enumSplitBranchCount removed); mdl/executor/cmd_microflows_builder_validate.go", "insight": "A limit derived from len(someTable) outlives the table's job: when the encoding it served is replaced, grep for every reader of the table before keeping the cap. The verdict on which side was wrong came from mxbuild, not reasoning: a 29-branch split written by exec into a blank 11.6.6 app checks at 0 errors, and describe -> check -p -> exec reports Unchanged with an identical re-describe.", "refs": ["mendixlabs/mxcli#1416", "mdl/executor/cmd_microflows_builder_enum_split_test.go", "mdl/executor/validate_microflow_enum_split_test.go", "mdl-examples/bug-tests/1416-enum-split-more-than-16-branches.mdl"]}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-12-forward-flow-calls-mutual-recursion.json

@@ -0,0 +1 @@
+{"date": "2026-10-12", "area": "mdl/executor", "symptom": "`describe microflow ModA.MF_A; describe microflow ModA.MF_B` of two mutually recursive microflows, re-checked against a project without them, failed: \"microflow ModA.MF_A references microflow ModA.MF_B before it is created (statement 3), and the project does not have it\"; plain creates got MDL-ORDER01. No order of the two statements passes, so mutual recursion could not round-trip without a hand-written stub (mendixlabs/mxcli#1405).", "cause": "The flow builder resolved a CALL MICROFLOW/NANOFLOW target in statement order (microflowExists against the project; ctx.scriptFlows was filled only by check's verdict pass, with earlier statements), and MDL-ORDER01 / validateForwardDefRefs mirrored that refusal (#955). But a call is stored by name (MicroflowCall.Microflow, QN parameter mappings), so the BSON is the same whether the callee exists yet; the only hazard was a later statement failing and leaving the call dangling, which #1408's all-or-nothing journal removes.", "file": "mdl/executor/executor.go (SetForwardFlowCalls, enterScriptFlows fills scriptFlows from the whole program); mdl/executor/validate_definition_order.go (defRef.flowCall: skipped by MDL-ORDER01, refused by validateForwardDefRefs only when the run cannot roll back); mdl/executor/validate.go (annotateForwardRef hint); cmd/mxcli/cmd_exec.go, cmd_check.go, cmd_diff.go (mode)", "insight": "The rule was right for the mode it was measured in, not for the language: a forward reference is unsafe only where a later failure cannot be undone. So the exemption is per run mode (plain exec and check accept; --continue-on-error, REPL, -c refuse with the stub recipe) and per reference kind — only flow-call targets, because a page button's flow and an IN QUEUE target are still resolved eagerly when written (TestForwardFlowCall_PageReferenceStillOrdered pins one). Measured on Mendix 11.6.6: A<->B microflows and nanoflows in either order, exec then mx check 0 errors, describe -> exec -> describe identical.", "refs": ["mdl/executor/forward_flow_calls_1405_test.go", "mdl/executor/validate_definition_order_test.go", "mdl-examples/bug-tests/1405-forward-flow-calls.mdl", "mdl-examples/bug-tests/955-forward-definition-order.fail.mdl"]}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-12-java-action-undeclared-type-parameter.json

@@ -0,0 +1 @@
+{"date": "2026-10-12", "area": "mdl/executor", "symptom": "`describe java action GenAICommons.ChunkCollection_AddKnowledgeBaseChunk` printed `MxObject: \"Entity\"` with nothing declaring the type parameter Entity; `check` passed, and exec wrote the parameter as the entity `.Entity` — mx check CE1613 \"The selected entity '.Entity' no longer exists\" (mendixlabs/mxcli#1404).", "cause": "MDL declared a Java action type parameter only through an `entity <T>` parameter (the visitor collected TypeParameters from those alone), so a type parameter bound by its argument with no entity selector had no spelling. exec then sent the unqualified name down the entity path as Module \"\" + \".\" + Name, and no check looked at unqualified type names in a java action signature.", "file": "mdl/grammar/domains/MDLMicroflow.g4 (javaActionTypeParameters header); mdl/visitor/visitor_javaaction.go (header names first, then entity selectors); mdl/executor/cmd_javaactions.go (javaActionTypeParameterHeader in describe, undeclaredJavaActionTypeNames refusal in exec); mdl/executor/validate_javaaction_types.go (MDL-JA01 at check)", "insight": "The header is printed only when the entity selectors would not reproduce the stored list in its order, so every action that already round-tripped describes byte-identically. The refusal is the other half: an unqualified type in a java action signature can only be a type parameter or `Microflow`/`Nanoflow` (mapped by exec), so anything else was always a CE1613 that check could have caught. An unbound entity selector (`entity <>`) still has no MDL form; as for JavaScript actions it is commented out under `-- NOT re-executable:`. JavaScript actions keep the commented-out form for the undeclared shape — the header is not in their grammar yet.", "refs": ["mdl/executor/describe_java_action_type_params_test.go", "mdl-examples/bug-tests/1404-java-action-undeclared-type-parameter.mdl", "mdl/executor/describe_javascript_action_type_params_test.go"]}