Sync ako/mxcli: fix property-sets, page value round-trips, companion mod, check --v1

.claude/commands/mendix/lint.md

@@ -39,7 +39,7 @@ mxcli lint -p app.mpr --exclude System --exclude Administration
 | MPR004 | quality | ValidationFeedback - Validation feedback with empty message |
 | MPR005 | quality | ImageSource - IMAGE widgets with no source configured |
 | MPR006 | quality | EmptyContainer - Empty layout containers |
-| MPR007 | security | PageNavigationSecurity - Navigation pages need allowed roles (CE0557); every user role must be able to open its home page (else CE2729 per widget) |
+| MPR007 | security | PageNavigationSecurity - Navigation pages need allowed roles (CE0557); every user role must be able to open its home page (at Production security, else CE2729 per widget) |
 | MPR012 | correctness | LegacyImageWidget - staticimage/dynamicimage are unsupported by the React client (CE0582) |
 | SEC001 | security | NoEntityAccessRules - Persistent entities need access rules |
 | SEC002 | security | WeakPasswordPolicy - Password minimum length should be 8+ |

.claude/commands/mxcli-dev/review.md

@@ -52,6 +52,7 @@ proactively. Add a row after every review that surfaces something new.
 | 21 | A registry that reads only one source (an `embed.FS`) has no extension point, so the only way to customise its output is to hand-edit the generated block — which a digest fence then refuses to touch on the next run. The feature ends up hostile to the exact case it was built for | API design | When a guard refuses a user's edit, ask whether the thing being edited should have been authorable. Introduce a source abstraction (`fs.FS` + root) and let a project-local directory shadow the embedded set — the walk functions usually already take a root, so the change is contained |
 | 22 | A test helper that expands a template cross-products every list against every reference (e.g. every `@each $weight` list against every `url()`), inventing artefacts no asset ever shipped and failing on correct input | Test coverage | Scan positionally: a reference must be expanded against the loop it actually sits under. Prove the helper both fires on a real break (delete one shipped file) and stays quiet on correct input — a helper only checked against green code has not been shown to detect anything |
 | 23 | A copy-to-scaffold path renames files but not the identifiers built from the name (`@mixin mxcli-<name>-<alt>`, `@import "mxcli-<name>"`), so two artefacts collide the moment both exist — and the symptom is a rule that silently compiles to nothing | Code correctness | Assert the structural contract on the *generated* artefact, not just the shipped ones: factor the built-in's contract test into a helper and run the scaffold through it. Verify once end to end against the real toolchain and record it |
+| 24 | A stacked PR's base merged at an older head: commits pushed to the base branch after its merge never reach `main`, while both PRs read as fine (ako/mxcli#1108 lost its last two commits this way) | Merge hygiene | Before merging any stacked PR, and after pushing to a branch whose PR may already be merged, check each commit with `git merge-base --is-ancestor <sha> origin/main`; retarget the next PR to `main` so it carries the stranded commits, and say so in its description |
 | 24 | A writer leaves out a property Studio Pro always writes (an empty `Documentation`, the empty half of an attribute/association pair) or writes one Mendix does not declare. `mx check`, the build and the runtime stay green, but Mendix's merge/diff engine compares property NAMES and throws, so the document becomes unmergeable once Studio Pro saves it (mendixlabs/mxcli#1373) | BSON writing | The doctype gate's `checkPropertySets` catches it per script: `mx convert -p` re-serializes what is not canonical. Fix the writer, or record Mendix's value with `MXCLI_PROPERTY_SETS_RECORD` + `internal/propertysets/cmd/propdefaults`; never guess a default |
 | 24 | A skill or command still instructs work into a package the repo has deleted (`sdk/mpr` test locations, a symptom table moved to `findings/*.jsonl` years prior) — the doc reads as authoritative and every instruction in it is a compile error or a no-op | Docs quality | When a package is deleted or a doc is restructured, grep `.claude/` for its name in the same PR. A deletion that leaves the guidance behind is worse than no guidance, because the reader trusts it |
 | 25 | A doc or skill shows a CLI invocation nobody ran — a command name that does not exist (`mxcli dump-bson` for `mxcli bson dump`), or a flag form the parser rejects (`--compare "A" "B"` where `--compare` is a StringSlice needing `"A,B"`). Worst when copied FROM the command's own `--help`, which had the same error, so the doc looks sourced | Docs quality | Run every command a doc shows, against a real project, before committing it. If it came from `--help`, run that form too — the example in the help text is not evidence that it works |

.claude/skills/fix-issue/findings/cmd-mxcli/2026-10-11-project-tree-offers-nodes-describe-cannot-answer.json

@@ -0,0 +1 @@
+{"area": "cmd/mxcli", "date": "2026-10-11", "symptom": "Clicking a JavaScript action (or the Navigation root) in a project-tree client fails: `mxcli describe javascriptaction X` is 'Unknown type', and `describe navigation Navigation` looks for a profile named Navigation", "cause": "project-tree and describe each kept their own idea of the node types: the tree emits javascriptaction, pagetemplate, domainmodel and ~20 container types, describe's CLI map had no javascriptaction keyword (the executor and grammar did), and the tree's navigation node carries the qualified name 'Navigation', which is not a profile. Every client (vscode-mdl's openElement fallback list) papered over it with its own guess list", "file": "`cmd/mxcli/project_tree.go` (`treeTypesWithoutSource`, `markDescribable`), `cmd/mxcli/cmd_describe.go` (`describeMDLCommand`)", "insight": "Two hand-kept lists over the same set drift; make one side derive from the other and test the source, not a copy. project-tree now marks each node `describable` from describe's own dispatch, and the guard reads every `Type: \"x\"` literal out of project_tree.go so a new node type fails the test until someone decides whether it has MDL. Revert check: removing the javascriptaction case fails the guard with the exact type named. Measured on Evora: 5748 nodes, 4611 describable, 1137 containers/no-source", "refs": []}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-11-empty-widgets-list-omitted-on-new-owner.json

@@ -0,0 +1 @@
+{"area": "mdl/backend", "date": "2026-10-11", "symptom": "a freshly built Forms$TabPage with no widgets (also DivContainer, GroupBox, LayoutGridColumn, ScrollContainerRegion, NavigationListItem) was written with no Widgets key at all, where Studio Pro stores Widgets: [2]", "cause": "the codec's new-element path emits only dirty properties; an untouched empty PartList is never dirty, so it was omitted. Only Forms$DataView had a per-type TypeDefaults MandatoryListMarkers entry for Widgets", "file": "modelsdk/codec/defaults.go + encoder.go (RegisterMandatoryPropertyList: a property-keyed marker that is also emitted empty on a new element); mdl/backend/modelsdk/widget_list_markers.go registers it for the 15 Widgets owners", "insight": "Sweep presence, not just values: a scan of every $Type with a Widgets key in TestApp + PedApp found it absent 0 times (TabPage 89/89, 20 empty; LayoutGridColumn 732/732; DivContainer 838/838; WidgetValue 20,775/20,775), so the list is mandatory per owner. Key it on owner+property in the codec rather than adding per-type RegisterTypeDefaults entries, which replace (not merge) an existing registration and clobbered defaults once already (#812). The control is a type Studio Pro never stores the key on (TabControl, ScrollContainer) - it must not gain one."}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-11-layoutgrid-column-previewwidth-reset-on-rewrite.json

@@ -0,0 +1 @@
+{"area": "mdl/backend", "date": "2026-10-11", "symptom": "describe page -> exec on a Studio Pro-built project rewrote Forms$LayoutGridColumn.PreviewWidth from a stored 1 to -1 (ako/mxcli-ledger FINDINGS #170)", "cause": "layoutGridColumnToGen hardcodes SetPreviewWidth(-1) and nothing carried the stored value; PreviewWidth is a Studio Pro editor-canvas value with no MDL spelling", "file": "mdl/backend/modelsdk/widget_layoutgrid_carry.go (carryLayoutGridPreviewWidth, wired in UpdatePage/UpdateSnippet beside carryNoActionExecution)", "insight": "The hardcode matched 731 of 732 stored columns in TestApp+PedApp, so a fixture sweep never showed it; one real project did. A nameless element is carried by position inside its nearest named ancestor (grid name, row i, column j), and only when the stored row has the same column count, so an edited row falls back to the new-column default instead of mispairing. Set only a differing value: an equal set dirties a kept element (#721 L4)."}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-11-open-link-static-address-drops-null-attributeref.json

@@ -0,0 +1 @@
+{"area": "mdl/backend", "date": "2026-10-11", "symptom": "describe page -> exec on a Studio Pro-built project dropped `AttributeRef: null` from the Forms$StaticOrDynamicString Address of every static OPEN_LINK button (Forms$OpenLinkClientAction), so an unchanged page was rewritten (ako/mxcli-ledger FINDINGS #170)", "cause": "staticAddressToGen never set AttributeRef and no type default emitted it; its comment conflated the stored AttributeRef key with gen's extra, never-stored `Attribute` key, so the omission looked deliberate", "file": "mdl/backend/modelsdk/widget_write.go (init registering Forms$StaticOrDynamicString NullFields, staticAddressToGen)", "insight": "Two near-identical key names, one stored and one invented by gen: the earlier 'never invent a key' reasoning was right about `Attribute` and wrongly extended to `AttributeRef`. A key-set sweep of the references (21 of 21 static addresses carry AttributeRef: null) settles it in seconds; a NullFields default is safe for the dynamic branch because it only fills an unset key. Grepped first that no other RegisterTypeDefaults existed for the type, since a second registration replaces the first (#812). The default is per $Type, so it also reaches a navigation menu item's address; the #980 test's hand-built menu fixture lacked the key and failed. `mx convert -p` (11.15.0) on a menu item written without it adds AttributeRef: null, so the fixture, not the writer, was wrong: when no stored reference exists for a context, convert is the measurement."}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-11-rest-inline-value-mapping-writes-isdefaulttype.json

@@ -0,0 +1 @@
+{"area": "mdl/backend", "date": "2026-10-11", "symptom": "Projects written by mxcli carry IsDefaultType on ImportMappings$ValueMappingElement (x49) and ExportMappings$ValueMappingElement (x1), a key Mendix declares only on the object mapping element, so mx diff / merge throws while mx check and the build stay green", "cause": "#882 removed the key from the standalone import/export-mapping writer (mapping_write.go), but the consumed-REST inline mapping writer (restInlineMappingElementToGen, used for both Body: MAPPING and Response: MAPPING) builds its own value elements and still wrote addBool(v, \"IsDefaultType\", false). The legacy modelsdk/mpr serialize_mappings.go / serialize_web_services.go had the same line but had no caller anywhere, tests included", "file": "mdl/backend/modelsdk/consumed_rest_write.go restInlineMappingElementToGen; test mdl/backend/modelsdk/consumed_rest_isdefaulttype_test.go", "insight": "A per-type property fix is only done when every builder of that $Type is fixed: grep the storage name (\"$ValueMappingElement\") and the key across the repo, not the writer named in the report. Mapping elements have three builders here (import mapping, export mapping, REST inline), and the inline one is the high-count source in real projects because every REST operation with a mapped body or response gets one. Assert on the encoded BSON (codec.Encoder), walking nested children and counting visited value elements, so an empty tree cannot pass. Delete dead legacy twins rather than patch them, after grepping their exported entry points for callers", "refs": ["ako/mxcli#1097", "#882"]}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-11-template-grid-contents-widgets-marker-measured.json

@@ -0,0 +1 @@
+{"area": "mdl/backend", "date": "2026-10-11", "symptom": "Forms$TemplateGridContents.Widgets was written with marker 3 when its first child had no child-type registration (e.g. a TabControl), when emptied, and on selective rebuild, and was omitted when new and empty; Studio Pro writes [2]", "cause": "TemplateGridContents was left off the Widgets property-marker owner list because neither reference app has a template grid", "file": "mdl/backend/modelsdk/widget_list_markers.go (Forms$TemplateGridContents added to widgetsListOwners)", "insight": "No reference document is not no evidence: mx convert (11.15.0) re-serializes every unit, so injecting a deliberately wrong marker ([3]) and reading the converted BSON measures Studio Pro's serializer directly - with a control (a DivContainer written [3] comes back [2]) proving the unit was rewritten. A bare injected element is also filled out by convert, which shows mandatory keys. The same probe settles which gen types are dead: convert refuses Forms$TableCell, Forms$VerticalFlow and NativePages$NativeLayoutCallArgument/NativePage ('type cache does not contain a type'), and an 11.x table cell is Forms$DbTableCell, which gen does not model (decoded opaque), so registering any of them would be inert."}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-11-widgets-list-marker-follows-first-child-type.json

@@ -0,0 +1 @@
+{"area": "mdl/backend", "date": "2026-10-11", "symptom": "describe page -> exec on a Studio Pro-built project rewrote the typed-array marker of a LayoutGridColumn.Widgets list whose first child is a Forms$TabControl from 2 to 3 (ako/mxcli-ledger FINDINGS #170)", "cause": "codec partListMarker derives a list's marker from its first child's $Type via RegisterListMarker, defaulting to 3; Forms$TabControl had no registration. The same 3 default also hit an emptied Widgets list and the selective-rebuild path (a stored list with one dirty child), which never consult child-type markers", "file": "mdl/backend/modelsdk/widget_list_markers.go (RegisterPropertyListMarker(owner, \"Widgets\", 2) for the 15 evidenced owners)", "insight": "The marker belongs to the property, not to the child: 22,000+ Widgets lists across TestApp and PedApp, every owner, empty or not, are 2, while TabControl.TabPages is 3 (32/32). Per-child registration is whack-a-mole that leaves every unregistered widget type and both the empty and the selective paths on 3; a one-file sweep of markers grouped by owner.key and first child settles it. Register by STORAGE owner name (Forms$FormCallArgument, not gen's LayoutCallArgument)."}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-11-create-modify-edit-inside-loop-body-refused.json

@@ -0,0 +1 @@
+{"area": "mdl/executor", "date": "2026-10-11", "symptom": "ako/mxcli#1106: under `mdl 1;` a re-run `create or modify microflow` whose only change is one expression in a `set` inside a `loop` body is refused: \"the Loop at (x, y) changes inside its body; the splice does not edit inside a loop, and replacing the whole loop would rebuild every node it holds. Nothing was written. [MDL-V1-REBUILD]\" — so one script cannot both provision and update a flow that loops; the advised `alter … replace loop` means stating the body twice or giving up provisioning", "cause": "patchDiff.gap refused as soon as sameLoopShell held and the bodies differed (loopBodyChanged), without asking how they differed; alter's applyTo refused any in-loop target (enclosingLoop); the mutator's graph.node refused any node with n.loop set. The stated reason (body coordinates are relative to the loop box) only applies to changes that add, remove or move a node", "file": "mdl/executor/cmd_flow_modify.go (loopBody, inLoopBody, editableLoopBody, storedLocator.within, lcsStatements), mdl/executor/cmd_alter_flow.go (applyTo in-loop guard, upstreamOf/iteratorsAround/loopsAround), mdl/backend/mfmutator/splice.go (replaceInLoop)", "fix": "A loop body of the same shape — same length, each statement as stored, a nested loop of the same shape, or the same kind of plain activity (no if/return/break/continue, no custom error handler) whose annotations state nothing the stored one lacks — is diffed into in-place replaces, located among the loop's own objects (body @positions are loop-relative, so the top-level locator cannot be used). The mutator swaps the activity's document in the loop collection's slot, at the stored RelativeMiddlePoint and Size, and repoints the flows in/out (the last body activity has no flow out — removable() rejected it). alter accepts the same one-for-one replace; scope inside a body adds the enclosing loops' iterators and what runs before each loop. Such loops are also paired by lcsStatements so a change beside the loop does not merge with it into a replace", "test": "mdl/executor/cmd_flow_loop_body_edit_pedapp_test.go TestCreateOrModify_EditInsideLoopBody (only the edited activity's $ID changes, replacement at the same position, re-run Unchanged, iterator-reading edit, change beside the loop + inside it, controls insert/drop/swap/kind-change still refused with nothing written), TestCreateOrModify_EditInsideNestedLoopBody; mfmutator splice_test.go TestSplice_ReplaceInsideALoopIsInPlace (byte-exact expected unit, first and last body activity, resized stored Size kept, two-for-one refused). Fix reverted: both executor tests fail with 'changes inside its body; the splice does not edit inside a loop', the mutator test with 'alter does not splice inside a loop yet'. Real 11.14.0 app (mxcli new): old binary refuses with MDL-V1-REBUILD under mdl 1 and 'Replaced' (rebuild) under mdl 0; fixed binary 'Modified … (spliced: 1 replaced)', re-run in sync; mx check 0 errors on both copies", "insight": "A refusal justified by geometry (loop-relative coordinates) should be asked of the changes that actually have geometry: an in-place replace of one activity by one of the same kind moves nothing, so recurse into the body when it has the same shape and keep refusing only shape changes. Two traps on the way: describe's body @positions are relative to the loop box, so locating a body statement must use a locator over that loop's objects only; and the last activity of a loop body has no outgoing flow, so the top-level 'exactly one flow out' removability check does not apply there. When validating with the CLI binary, rebuild it after the fix — a bin/mxcli built before the change reproduced the refusal and looked like the fix failing on a real app", "refs": ["ako/mxcli#1106", "ako/mxcli#942"]}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-11-source-attribute-change-leaves-view-entities-out-of-sync.json

@@ -0,0 +1 @@
+{"area": "mdl/executor", "date": "2026-10-11", "symptom": "Changing a source attribute's Localize (`DateTime` -> `DateTime not localized`) with `alter entity … modify attribute` or `create or modify entity` leaves every view entity selecting it with the old LocalizeDate; `mxcli check`/`exec` are silent and `mx check` reports CE6770 \"View Entity is out of sync with the OQL Query\" once per view. A String length / kind / enumeration change on the source breaks a pass-through view column the same way", "cause": "A view column's LocalizeDate was derived from its source (viewDateTimeLocalize, #1297) only when the view statement itself ran; nothing on the source-entity write paths looked at the views reading it", "file": "mdl/executor/oql_view_resync.go (resyncViewsOverSource), called from execAlterEntity modify attribute and the create-or-modify branch of execCreateEntity in mdl/executor/cmd_entities.go", "insight": "A property derived from another document at write time goes stale when that other document changes: every derivation needs a re-derivation hook on the source's write paths, not only on the deriving statement's. Diff type signatures (kind, length, enum ref, localize) before/after the source write, resolve `alias.Attr` refs per view column through extractAliasMap, rewrite only a column whose derived value differs (repeat run writes nothing; a view not reading the changed attribute is the control), chain to views over the resynced view. What the view text declares (length, kind, enum) cannot be re-derived without rewriting the user's statement, so it is an exec-time warning naming view and column — check cannot see it because check never applies the source change. Ledger FINDINGS #169", "refs": ["ako/mxcli-ledger FINDINGS #169", "#1297"]}