Sync ako/mxcli: check catches CE1406/CE0114/CE6585 and version gates, revoke and OData fixes, run --listen-addr

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

@@ -64,6 +64,7 @@ proactively. Add a row after every review that surfaces something new.
 | 31 | A test helper that needs a heavyweight object only to satisfy a signature (`NewLintContext(nil, nil)`, which panics) invites a nil-guard added purely to make the test compile — behaviour nothing in production needs, defended forever | Test coverage | Narrow the signature instead: if the helper does not use the parameter, drop it and let the caller apply the part it owns. A test that cannot construct an argument is usually telling you the argument does not belong |
 | 32 | A fix adds a diagnostic for a capability the model lacks while leaving in place the code that asserts the capability EXISTS — MDL042 telling the author a loop's `@caption` is dropped, while `cmd_microflows_builder_annotations.go` still ran `case *microflows.LoopedActivity: activity.Caption = ann.Caption` under the comment "LOOP / WHILE activities can carry a caption just like splits", and the describer still emitted one. Nothing read either back. The next reader trusts the code over the warning, deletes the check, and reopens the bug from the other side. The reason it survives is that it usually has TESTS — three here asserted the caption was carried, all of them against the semantic object and none against storage, so they passed throughout and failed only on the correct fix | Code correctness | `generated/metamodel` is the arbiter: a field on the semantic type it does not declare cannot survive a write, so an assignment to it is dead by construction. Grep the writer, the describer and the semantic struct and delete (or re-comment) whatever sets it. MEASURE before deleting — `exec` then `describe` on a real project, with the UNMODIFIED build, so the deletion rests on the stored document rather than on reading the codec. Invert the tests that defended it rather than deleting them, keeping any half still true (escaping coverage belongs on a type that can carry a caption), and check the inverted test fails when the assignment is put back |
 | 33 | A column added to `createTables` without bumping `CatalogSchemaVersion` — the version guard only drops tables when it CHANGES, and `CREATE TABLE IF NOT EXISTS` never adds a column, so every user with a cached catalog keeps a table the new SELECT cannot read. Measured on #1181: `activities_for` yielded 302 on `main` and **0** on the branch against the same cache, `no such column: UseRequestTimeout`, `mxcli lint` exit 1. `mxcli report` runs the same rules and never checks `QueryErrors()`, so there it would score silently | Code correctness | Bump the constant in the same commit — its doc comment says so and `62913741` is the precedent (four columns + 11→12 + a builder test). To REPRODUCE, the cache must actually be reused: build it with the old binary and run the new one with the **same spelling of `-p`**, because a relative-vs-absolute path invalidates on "MPR path changed" and hides the bug; confirm the run says "Loading cached catalog … (from cache)" before believing a green result |
+| 34 | An upstream PR cut from a months-old base is written in conventions `main` has since replaced: its docs, syntax help and bug-test script use `set X = v` (now MDL-DEPR101, `set (X: v)`), and its finding is appended to `findings/<area>.jsonl`, which `main` split into one file per record. It is green on its own base, and the code change itself is correct, so it reads as ready (mendixlabs/mxcli#1229) | Merge hygiene | Port it rather than merge it as-is: cherry-pick onto current `main`, rewrite every new MDL line in the current syntax, and move the finding to `findings/<area>/<date>-<slug>.json`. Re-run the PR's own tests against the ported code AND against `main` without the fix (the control), since a hand-resolved conflict can drop the case it adds |
 
 ---
 

.claude/skills/fix-issue/findings/cmd-mxcli/2026-10-15-mxcli-new-10-24-layout-names-atlas-4-design-properties.json

@@ -0,0 +1 @@
+{"area": "cmd/mxcli", "date": "2026-10-15", "symptom": "`mxcli new --version 10.24.0` printed \"Project created\" and exited 0, but the first build failed: mx check reports 4x CE6083 \"Design property Flex container / Align items Y / Disable row wrap / Grow / shrink (self) is not supported by your theme\" on MyFirstModule.App_Default's topbarContent", "cause": "Two defects. (1) The scaffold layout hardcoded Atlas 4's flex design properties, but Atlas is versioned with the project: 10.24's template ships Atlas Core 3.17, whose design-properties.json has no flex group at all. (2) `new` treated every first-build failure as a warning, including mxbuild refusing the MODEL, so a project that does not build was reported as created with exit 0", "file": "`cmd/mxcli/cmd_new_layout.go` (`topbarDesignProps`, `scaffoldDesignProps`, `renderScaffoldScript`) filtered through `executor.ThemeDeclaresDesignProperty`; `cmd/mxcli/docker/settle.go` (`classifySettleFailure`, `ModelErrorsError`); `cmd/mxcli/cmd_new.go` (`reportFirstBuildFailure`, exit 1 after step 7)", "insight": "Generated MDL that writes design properties must be filtered by the project's own themesource, not by the Mendix major mxcli was tested on. Nothing fails on Atlas 3 without them: its `.topbar-content` rule is already `display: flex; align-items: center`. `mxcli check -p` could not have caught it either: `documentWidgets` covers pages and snippets but not `create layout`, so the test feeds the layout's widget tree to `ValidateDesignPropertiesForStatement` as a snippet, an oracle that reproduced exactly the 4 CE6083 keys. Only a model error is fatal (mxbuild's `ERROR at` lines); a missing JDK says nothing about the project and stays a warning. Measured: 10.24.0 mx check 4 errors before, 0 after; 11.6.6 0 both, flex props kept; with the filter stubbed out, `new` now exits 1 listing the 4 errors", "refs": ["mendixlabs/mxcli#1433"]}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-15-alter-set-rendermode-dynamictext.json

@@ -0,0 +1 @@
+{"area": "mdl/backend", "date": "2026-10-15", "symptom": "`alter page P { set (RenderMode: H1) on <dynamictext> }` is refused: `failed to set RenderMode on compTitle: property \"RenderMode\" not found (widget has no pluggable Object)` (later builds: `not a property of this built-in widget … use alter styling`), while `create page … dynamictext x (RenderMode: H1)` and `replace x with { dynamictext … }` accept it. `check -p` refuses it too, since it dry-runs the same setter", "cause": "setRawWidgetPropertyMut is a hand-kept switch of first-class built-in properties (caption/content/label/class/…); anything not listed falls through to the pluggable-property setter. RenderMode had no case, although the MCP mutator (mdl/backend/mcp/page_mutator.go) has had one all along — the two backends' SET vocabularies are separate lists", "file": "`mdl/backend/pagemutator/mutator.go` (setDynamicTextRenderModeMut)", "insight": "When a CREATE property is refused by ALTER SET on a built-in widget, compare the CREATE builder's property list with the case list in setRawWidgetPropertyMut (and the MCP mutator's) — every such refusal so far (DynamicClasses, lowercase class, RenderMode) was a missing case, not a storage question. Dispatch RenderMode on the stored `$Type` (Forms$DynamicText): containers and ActionButtons store differently-valued RenderMode/RenderType, and a pluggable widget may own a `renderMode` key, so those keep the old path. Validate against pages.TextRenderMode (Text, Paragraph, H1–H6) case-insensitively and store the canonical spelling — the visitor passes `h2` through as typed. Still missing from SET on dynamictext: ContentParams (CREATE accepts it; SET has no case). Control: the unfixed mutator.go makes the new tests fail with the reported refusal; upstream author's real 11.14.0 copy: exec → describe shows H2 → mx check 0 errors", "refs": ["mendixlabs/mxcli#1228", "mendixlabs/mxcli#1229"]}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-15-fileuploader-hidden-item-texttemplate-not-nulled.json

@@ -0,0 +1 @@
+{"area": "mdl/backend/widgetobj", "date": "2026-10-15", "symptom": "File Uploader `allowedfileformat` left at the default `configMode: 'simple'` passes `mxcli check` and exec, then `mx check` reports CE0463 \"The definition of this widget has changed\" on the uploader; `configMode: 'advanced'` on every item avoids it", "cause": "The editorConfig hides an item's `typeFormatDescription` (plus mimeType/extensions) per ITEM via `hideNestedPropertiesIn(..., \"allowedFileFormats\", index, [...])` while that item's configMode is \"simple\". The extractor lifted the rule (ListPropertyKey allowedFileFormats, item-scoped condition), but `ApplyVisibilityRules` only walked top-level properties, so the hidden required TextTemplate kept the populated ClientTemplate the item builder fills it with (#891). Studio Pro wants null there (#574 one level down)", "file": "`mdl/backend/widgetobj/builder.go` (`ApplyVisibilityRules` → new `applyItemVisibilityRules` / `nullHiddenItemTemplates`)", "insight": "Without the real .mpk, a faithful one can be built: sparse-clone mendix/web-widgets `packages/pluggableWidgets/file-uploader-web`, bundle `src/*.editorConfig.ts` with bun (alias `@mendix/pluggable-widgets-tools` to the npm package's `dist/utils/PageEditorUtils.js`), terser it, and rewrite bun's `module.exports=__toCommonJS(...)` to plain `exports.getProperties=...` — with `module.exports` mxbuild silently ignores the editorConfig (CE0642 'Associated images is required' was the tell: hidden properties were being required-checked). `mx update-widgets` on a copy then diffed by PropertyKey isolated the single slot (`typeFormatDescription.TextTemplate` → null). The same fix also cleared the long-standing CE0463 on doctype-tests/32 Accordion `acc2` (groups with HeaderRenderMode custom hide the required `headerText`) — a nested-rule class, so check every widget with object-list TextTemplate rules (`mxcli widget describe` lists them) before and after; DataGrid columns' nested rules agree with emptyClientTemplateRules so 31 stays at 0. Maps map1/map2 CE0463 in fixture 32 are a separate, still-open cause", "refs": ["mendixlabs/mxcli#1198", "#574", "#891"], "ce": ["CE0463"]}

.claude/skills/fix-issue/findings/mdl-backend/2026-10-15-partial-revoke-several-roles-matches-no-rule-1501.json

@@ -0,0 +1 @@
+{"area": "mdl/backend", "date": "2026-10-15", "symptom": "`revoke write (NewAttr) on entity M.E from M.RoleA, M.RoleB, M.RoleC` printed \"Unchanged entity access: M.E (M.RoleA, M.RoleB, M.RoleC) — nothing to revoke\", exited 0, and `show access` still listed NewAttr: ReadWrite in each rule; check and mxbuild clean (mendixlabs/mxcli#1501).", "cause": "The rules were granted one role each, so each stored a single-role ModuleRoles list. RevokeEntityMemberAccess only narrowed a rule whose role set EQUALLED the statement's ({A,B,C}); none did, 0 rules modified, reported as already revoked. RemoveEntityAccessRule (full revoke) had always matched per role, so only the partial form was affected.", "file": "mdl/backend/modelsdk/domainmodel_security_write.go (RevokeEntityMemberAccess: narrow every rule all of whose roles are named; refuse, before writing, a rule shared with an unnamed role)", "insight": "The reporter's hypothesis (write comes from the rule's default member access, no stored entry to narrow) was wrong, and one control settled it: the same revoke naming ONE role narrowed NewAttr on the same project, so the entries existed. When a report pins a multi-target statement, re-run it with a single target before reading the member logic — the variable that changed was the role list, not the member. Grant keys a rule on its exact role set (+ XPath) because that is identity for an upsert; revoke is a filter, and copying grant's key into it made a three-role statement match nothing. A rule shared with a role the statement does not name must be refused, not narrowed: narrowing it would silently revoke the unnamed role's right too. Measured on pedapp (11.13): old binary prints the Unchanged notice with ReadWrite x3; fixed binary narrows all three to ReadOnly, a rerun prints the honest Unchanged notice, and `mx check` reports the same 1002 pre-existing fixture errors as the unfixed copy, none on the entity.", "refs": ["mdl/backend/modelsdk/revoke_multi_role_1501_test.go", "mdl-examples/bug-tests/1501-revoke-write-from-several-roles.mdl", "mendixlabs/mxcli#1225"]}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-12-published-odata-key-missing-or-not-unique.json

@@ -0,0 +1 @@
+{"area":"mdl/executor","date":"2026-10-12","symptom":"Published OData entity with no KEY, or with a single KEY on an attribute without a unique rule, passes `mxcli check` and `exec`; `mx check` reports CE6585 \"Published entity 'ModA.EntA' must have a key defined.\" / CE6624 \"Add a unique validation rule to attribute 'Name' of entity 'ModA.EntA' to be able to use it as the key.\"","cause":"No check-time rule existed. The KEY requirement was known (MDL-ODATA02's suggestion quotes CE6585, the quick reference names CE6624) but only as prose","file":"`mdl/executor/validate_odata_keys.go` (new `ValidateODataKeys`, MDL-ODATA08/09, wired in `validate_program.go` so exec's preflight refuses too); `validate_import_mapping_find.go` `entityFacts` gains `view` + `uniqueAttrs` (script first, project second)","insight":"**Measure the boundary before writing the predicate: the obvious rule ('every KEY attribute must be unique') is a false refusal.** mx 11.6.6, one service per case in one app: no KEY -> CE6585 for persistent, non-persistent AND view entities, also `expose (*)` and no expose clause; single KEY on a persistable entity without a unique VALIDATION RULE -> CE6624 on OData3 and OData4 alike, and `not null` or an index does not count; composite KEY with no unique rule -> clean (OData4; OData3 is CE7238, a different rule); single KEY on a non-persistent or view entity -> clean. **A CE1613 in the same app hid every key error**: an inherited key attribute is written qualified with the child entity (CE1613), and with it present mxbuild reported none of the CE6585s the other services had, so measure each case without unrelated errors in the app. The rule stays silent on inherited attributes rather than guess. Two committed bug-tests (595 `expose (*)`, 1357's keyless intermediate statement) were themselves CE6585 and had to be keyed. Guard `TestODataKeyRules_*` (revert control: 9 script cases + the project case fail); repro `mdl-examples/bug-tests/1426-odata-key-requires-unique-rule.fail.mdl`","refs":["mendixlabs/mxcli#1426","mendixlabs/mxcli#1423"],"ce":["CE6585","CE6624"]}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-13-entity-access-call-mismatch-ce0114.json

@@ -0,0 +1 @@
+{"area": "mdl/executor", "date": "2026-10-13", "symptom": "Mendix 11.14.0, MPR v2: `@applyentityaccess(false)` on `create or modify microflow MyModule.DS_Tile_Count` whose body is `$List = call microflow MyModule.SUB_Scoped_List();` (an `@applyentityaccess(true)` microflow, in the project or created earlier in the script) passed `check -p --references` with \"no flow change exec would refuse … no used flow left without access\" and \"Check passed!\"; mxbuild then reported \"CE0114 A microflow that does not apply entity access can only call microflows that also do not apply entity access.\"", "cause": "No check modelled the rule: it is a consistency rule between two documents' ApplyEntityAccess, not a reference, so reference validation could not see it", "file": "`mdl/executor/validate_entity_access_calls.go` (CheckEntityAccessCalls, MDL-SEC22), wired into the project tier of `cmd/mxcli/cmd_check.go`", "insight": "Measure the direction and the call shapes before modelling — the message names only microflows, but a DECISION on a rule that applies entity access is the same CE0114 with \"rules\" (stored as Microflows$RuleCall.Microflow, the same key as Microflows$MicroflowCall). Measured on mxbuild 11.13.0 and 11.14.0, fresh projects: off->on call and off->rule-on decision -> CE0114; on->off, on->on, off->off, nanoflow->on, EXCLUDED off->on -> nothing; Off and Prototype security alike, so unlike CE0106 it is always an error. A decision is a rule call only if the name is a rule when exec builds the caller (IsRule at build time), so the simulation resolves rule-ness in statement order but microflow callees at the end of the script. An absent @applyentityaccess on create or modify carries the stored value (carriedApplyEntityAccess) — the simulation must use the same function or it false-flags every rewrite of a stored caller that applies entity access. Check-only prediction (exec does not refuse), so not language-version gated, the MDL-SEC21 precedent. Two-variant mxbuild 11.14.0 run on a fresh project with the callee stored: issue script -> check -p MDL-SEC22 exit 1, exec anyway -> docker check 1x CE0114; caller with @applyentityaccess(true) -> check passes, docker check 0 errors. Revert-proof: gate stubbed -> 6 positive tests fail with 'got 0'; callee-setting test removed -> the off->off control fails", "ce": ["CE0114"], "rules": ["MDL-SEC22"], "refs": ["mendixlabs/mxcli#1500"]}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-13-protected-module-hidden-refs-ce1406-ce5400.json

@@ -0,0 +1 @@
+{"area": "mdl/executor", "date": "2026-10-13", "symptom": "in a Protected (add-on) module, a navigation home page / menu item / call microflow / parameter type pointing at a Hidden element, and an `export level api` microflow whose parameter or return type is a Hidden entity of that module, passed check -p --references and exec, then mxbuild refused with CE1406 \"... because project level documents|app modules cannot reference hidden elements in add-on modules\" and CE5400 \"The export level of entity 'M.E' should be 'Usable' because parameter 'p' exposes it\"; describe and show modules never said the module was Protected", "cause": "nothing read Projects$ModuleSettings.ExportLevel for validation, and entityFromGen dropped the entity's ExportLevel, so no check could know what is Hidden", "file": "`mdl/executor/validate_protected_module_refs.go` (`validateProtectedModuleRefs`, `moduleProtections`), `mdl/backend/modelsdk/domainmodel.go` (`entityFromGen`), `cmd_modules.go`/`cmd_entities_describe.go` (comments)", "insight": "Measure with mxbuild before trusting the issue's expectation: a PAGE in a Protected module is refused even with ExportLevel API stored on it (11.13.0 and 11.14.0, navigation and show-page alike), so `export level api` on pages would not have helped — an API microflow in the module that shows the page is the measured way in. CE1406 masks CE5400 (mxbuild reports the CE5400 only once the CE1406 is gone), so a one-shot mx check undercounts; measure each rule in its own copy. A module can be made Protected for measurement with UpdateModuleSettings (ExportLevel 'Protected') — no Studio Pro needed; the scratch helper set it and element ExportLevels by raw BSON", "refs": ["mendixlabs/mxcli#1498"], "ce": ["CE1406", "CE5400"]}

.claude/skills/fix-issue/findings/mdl-executor/2026-10-15-check-not-version-aware.json

@@ -0,0 +1 @@
+{"area": "mdl/executor", "date": "2026-10-15", "symptom": "`mxcli check script.mdl -p app.mpr` printed \"Check passed!\" for a script that `mxcli exec` on the same project then refused for the project's Mendix version, after running the statements before the refused one (on a 9.24 project: `create view entity` -> \"create view entity requires Mendix 10.18.0+\"; the issue's own StableId/CaseValues refusal was the write-time property floor, already cured by #1410)", "cause": "Every version gate exec applies lived inline in its handler as a checkFeature(ctx, area, name, …) call — about two dozen across 17 files, several conditional on the statement's content (send email in the body, a page with parameters, SupportsGraphQL, a timer event sub-process). check -p and exec's pre-flight never run a handler, so neither could see a gate: the project version was consulted only when the handler ran.", "file": "`mdl/executor/version_gates.go` (statementVersionGates: the one statement-to-feature table; checkVersionGates for the handlers; Executor.CheckVersionGates -> MDL-VERSION01 for `cmd/mxcli/cmd_check.go` and `cmd/mxcli/exec_preflight.go`); the handlers in cmd_*.go now call checkVersionGates(ctx, stmt)", "insight": "A refusal only a handler can raise is a check/exec gap by construction (duplicate-resolver-drift, check versus exec): move the decision into a pure function of the statement that the handler and the pre-flight both call, rather than giving check a second copy. TestCheckFeatureIsOnlyCalledFromTheGateTable fails on any new direct checkFeature call, so a future gate cannot bypass the table. Two kinds stay exec-only: gates that depend on stored state (drop/alter of a message definition document that is not there) and the write-time property floor (canon.StripUndeclaredProperties), which needs the encoded BSON and is cured by the writer emitting the version's shape (#1410), not by a check rule. Fixture for any Mendix 9 check: modelsdk/mpr/testdata/v1-project/App.mpr is 9.24.30.", "refs": ["mendixlabs/mxcli#1434", "mendixlabs/mxcli#1410"]}