diff --git a/.claude/skills/fix-issue/findings/mdl-executor.jsonl b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
index ee4a3065d..08ea896a5 100644
--- a/.claude/skills/fix-issue/findings/mdl-executor.jsonl
+++ b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
@@ -246,253 +246,253 @@
 {"area": "mdl/executor", "date": "2026-08-31", "raw": "| An `image` widget mxcli wrote shows nothing, and `mx check` fails with **\"No image selected.\"**; and a `describe` → rename → `exec` copy of an Atlas layout (or any page with a brand image) comes out with the image gone, describe having emitted `image staticImage1 (Responsive: false)` with no reference at all | `mdl/executor/widget_engine.go` (the `image` operation), `mdl/executor/widget_defs.go` + `mdl/executor/widget_registry.go` (`operationForType`, `defaultKnownOperations`), `mdl/backend/widgetobj/builder.go` (`SetImage`, `setImageValue`), `mdl/backend/mutation.go` + `mdl/backend/mcp/widget.go`, `{modelsdk,sdk}/widgets/definitions/image.def.json` (`imageObject` → `Image`), `mdl/executor/cmd_pages_describe_pluggable.go` (`extractCustomWidgetPropertyImage`) + `cmd_pages_describe_output.go` (`describeImageWidgetProps`) | MDL had no spelling for **which** image an image widget shows, so its default source (`ImageType: image`, an image collection entry) could never be satisfied and describe had nothing to emit — mxcli-formula1 FINDINGS §142. The name is three parts like an icon reference, `Module.Collection.Image`, stored as a plain string on the `WidgetValue`'s `Image` key. Both halves are needed: with only the write, a round trip still loses it. `setImageValue` **replaces** the existing `Image` key and never adds one — adding a key the widget definition does not declare is the CE0463 shape. Controls: stub `setImageValue` → `TestSetImageValue_SetsTheQualifiedName` fails; stub the describe emission → `TestDescribeImageWidget_EmitsTheImageReference` fails |", "ce": ["CE0463"]}
 {"area": "mdl/executor", "date": "2026-08-31", "raw": "| `image imgTypo (Image: 'MyFirstModule.Images.NoSuchImage')` passes `mxcli check --references` (\"Check passed!\") and the build then fails **CE1613** \"The selected image '…' no longer exists.\" | `mdl/executor/validate_widget_image_ref.go` (new, `imageRefErrors`, `buildImageQualifiedNames`), `mdl/executor/helpers.go` (`widgetRefCollector.images`, `validateWidgetReferences`) | Wiring `Image:` created a new qualified name and nothing resolved it — every other name a widget carries (microflow, nanoflow, page, snippet, entity) already was. This one has **three** parts, so the two mistakes get two messages: a missing collection sends the reader to `show image collections`, a missing image to that collection's contents (which the diagnostic lists). A **nil** name set means the collections could not be read and nothing is reported; an empty non-nil one is a real answer. No same-script exemption — MDL cannot create an image collection entry, so the reference can only resolve against the project. Control: `TestImageRefErrors_KnownImageIsClean`, and `TestImageRefErrors_NoCollectionsMeansNoOpinion` for the failed-read direction |", "ce": ["CE1613"]}
 {"area": "mdl/executor", "date": "2026-08-31", "symptom": "`main` goes red on a test that passed in **both** PRs that touched it — here `TestDescribeWorkflow_NoAnnotationEmitsNoComment`: `unexpected violations [MDL-WF05] for a plain jump`", "cause": "Two PRs merged in sequence. One added a validator rule (MDL-WF05, dangling `jump to` target); the other's control test asserted `len(violations) == 0` over a fixture that was **not a valid workflow** — a lone jump whose target did not exist. Each CI run was green because neither saw the other's change", "file": "`mdl/executor/issue1007_annotation_emit_test.go` (the fixture), `mdl/executor/validate_workflow_jump.go` (the rule, which is right)", "insight": "**A test fixture that is not a valid instance of the thing under test is a landmine for the next rule.** \"No violations at all\" is only meaningful over input that *should* have none; over an invalid fixture it silently asserts \"no rule has been written yet that notices this\". Fix the **fixture**, not the rule. Generalise: when a test asserts the ABSENCE of diagnostics, make the input something you would be happy to ship. Two green PRs can still merge to red and **neither PR's CI can detect it** — the only protection is a fixture that does not depend on which rules exist today. Found by running `make test` on an unrelated docs branch cut from the merged main, which is an argument for doing that on any branch cut after a batch merge.", "refs": ["#350", "#351"], "rules": ["MDL-WF04", "MDL-WF05"]}
-{"area": "mdl/executor", "symptom": "A generated loop box is drawn far wider than the activities inside it (e.g. 880px around 440px of content), leaving a large empty area — \"the visualization is poor\"", "cause": "`measureStatements` sums each element's full width **and** adds `HorizontalSpacing` between them, but `HorizontalSpacing` is a centre-to-centre *pitch*: the builder centres each activity on `posX` and advances by exactly that. Counting it on top of each width over-measures a run of n simple activities by `(n-1)*ActivityWidth`", "file": "`mdl/executor/layout.go` (`measureStatementsSpan`), used by `addLoopStatement`/`addWhileStatement` in `cmd_microflows_builder_control.go`", "insight": "For a run of only simple activities the true span is `(n-1)*HorizontalSpacing + ActivityWidth`. **Do not guess the advance for a compound element** (IF/split, nested loop) — its `posX` advance comes from merge geometry (`mergeX + MergeSize + HorizontalSpacing/2`), and guessing under-sizes the box so activities land *outside* it, which is worse than a box that is too wide; those runs fall back to the conservative measure. Verify with a containment check: every child of a LoopedActivity must lie within `[0, width] × [0, height]`. Issue #790", "refs": ["#790"]}
-{"area": "mdl/executor", "symptom": "`create or modify external entities` silently resets a per-entity setting the user had changed (e.g. allow-create-change-locally)", "cause": "`applyExternalEntityFields` stamps every field on both the create and the update path, so anything not derivable from the OData contract was overwritten with a default", "file": "`mdl/executor/cmd_contract.go` (`applyExternalEntityFields`)", "insight": "Separate contract-derived fields (Countable/Creatable/Deletable/Skip/Top — refresh from metadata) from local modelling choices (CreateChangeLocally — leave alone; a new entity arrives zero-valued, which is Mendix's default). Issue #782", "refs": ["#782"]}
-{"area": "mdl/executor", "symptom": "`describe page` reports the wrong context entity under a data container bound to a microflow/nanoflow — `-- Context: $currentObject (Module.GetOrders)` names the *flow* instead of the entity it returns", "cause": "`widget.EntityContext = widget.DataSource.Reference` is correct for a database source (reference *is* the entity) and wrong for a flow source (reference is the flow's qualified name)", "file": "`mdl/executor/cmd_pages_describe_flowcontext.go` (`dataSourceEntityContext`, `flowReturnEntity`) + the five assignment sites in `cmd_pages_describe_parse.go`", "insight": "Resolve the flow's return type via `ListMicroflows`/`ListNanoflows` + `getHierarchy().GetQualifiedName`, taking the entity from an Object/List return type; fall back to the reference when the flow is unresolvable or returns a scalar, so the result is never worse than before. Note `GetRawUnitByName` is unimplemented on the modelsdk engine — the list+hierarchy path is the one that works"}
-{"area": "mdl/executor", "symptom": "`describe page` omits a **pluggable** widget's `DataSource` when it is bound to a microflow (`datagrid g1 {` with no DataSource), while a `database from` source describes fine — re-applying the output recreates the grid unbound", "cause": "A `Forms$MicroflowSource` stores the name in the nested `Forms$MicroflowSettings` (`MicroflowSettings` → `Microflow`), which is what the write path and Studio Pro emit; the reader looked up a top-level `Microflow` key, got `\"\"`, and returned no datasource. The describe *formatter* was correct all along — read bug only", "file": "`mdl/executor/cmd_pages_describe_pluggable.go` (`microflowSourceRef`, `nanoflowSourceRef`, `extractDataGrid2DataSource`, `extractGalleryDataSource`, `parseCustomWidgetDataSource`)", "insight": "Read the nested settings with a top-level fallback, via one shared helper — there were four divergent copies of this lookup and two were wrong. `Forms$NanoflowSource` was missing entirely from the DataGrid2/Gallery switches; add it alongside. Do **not** touch `CustomWidgets$CustomWidgetNanoflowSource` (a different metamodel type whose `Nanoflow` really is top-level) or the `Forms$MicroflowAction` reads (actions, not datasources). Repro `mdl-examples/bug-tests/795-datagrid-microflow-datasource-describe.mdl`. Issue #795", "refs": ["#795"]}
-{"area": "mdl/executor", "symptom": "`ALTER SETTINGS` / `CREATE CONFIGURATION` prints \"Updated …\" but `DESCRIBE SETTINGS` shows the old value — an Integer property was given a non-numeric value, or a Boolean anything other than `true`", "cause": "`strconv.Atoi`'s error was discarded (`if v, err := …; err == nil`) so the assignment was skipped while the caller still printed success; the boolean form compared against `\"true\"`, silently mapping every other spelling to false", "file": "`mdl/executor/cmd_settings.go` (`settingsInt`, `settingsBool`) + `mdl/executor/validate_settings.go` (`typedSettingsKeys`, MDL-SET01/MDL-SET02)", "insight": "Parse through a helper that returns a validation error naming the setting and the offending value, and register the property in `typedSettingsKeys` so `mxcli check` and the LSP flag it before the project is opened for writing. `TestTypedSettingsKeys_MatchExecutor` guards the table against drifting from the executor's switch. Repro `mdl-examples/bug-tests/805-alter-settings-typed-values.fail.mdl`. Issue #805", "refs": ["#805"], "rules": ["MDL-SET01", "MDL-SET02"]}
-{"area": "mdl/executor", "symptom": "Retrieve/datasource XPath with a `[%…%]` token (e.g. `[System.owner = '[%CurrentUser%]']` or `[Title = '[%CurrentUser%]']`) fails `mx check` CE0161, but `[Title='abc']` is clean", "cause": "NOT a token-storage bug — tokens store intact and a type-valid token (`[DueDate < '[%CurrentDateTime%]']`) passes. The failures are semantically-invalid XPath: (1) String/scalar attr compared to a User token = type mismatch; (2) `System.owner`/`changedBy`/… referenced on an entity that doesn't store it (needs `alter entity X add attribute owner: autoowner`)", "file": "`mdl/executor/validate.go` (`validateRetrieveConstraints`, `baseSystemMemberRe`) — diagnose with `mxcli bson dump --type microflow` + `mx check`; verify the token alone works", "insight": "Don't \"fix\" storage — it's correct. Add a `--references` check: collect retrieve `(entity, constraint)` in `flowRefCollector`, look up the entity via `buildEntityIndex` (`ListDomainModels`), and flag a base-entity `System.<member>` ref (regex excludes `/`-traversed refs) when the entity flag (`HasOwner` etc.) is off, with the `alter entity … add attribute …: auto…` hint. Same-script-created entities aren't in the project index, so the check only fires against existing project entities. **Also fixed**: a bare `[%token%]` *inside* a bracketed constraint (`[DueDate < [%CurrentDateTime%]]`) stored unquoted (the inline path keeps the raw source) → CE0161. `normalizeXPathTokens` (`mdl/visitor/visitor_page_v3.go`) requotes bare tokens; wired into `buildXPathSourceExpression`, the multi-predicate `predicateSources`, `buildXPathString`, and `bracketedXPathFromExpr` (already-quoted tokens untouched). Issue #641", "refs": ["#641"], "ce": ["CE0161"]}
-{"area": "mdl/executor", "symptom": "`describe` shows `$var = action ...;`", "cause": "Missing formatter case", "file": "`mdl/executor/cmd_microflows_format_action.go` → `formatActionStatement()`", "insight": "Add `case *microflows.XxxAction:` with `fmt.Sprintf` output"}
-{"area": "mdl/executor", "symptom": "`describe` shows `$var = list operation %T;` (with type name)", "cause": "Missing formatter case", "file": "`mdl/executor/cmd_microflows_format_action.go` → `formatListOperation()`", "insight": "Add `case *microflows.XxxOperation:` before the `default`"}
-{"area": "mdl/executor", "symptom": "A `create page` reported success but the built page is EMPTY — every widget gone — and `mx check` fails with CE1613 \"The selected layout 'dummyModule.dummyName' no longer exists\"", "cause": "The page had no `Layout:` clause, so `buildPageV3` created no `LayoutCall`; the widget tree is built into the LayoutCall's placeholder arguments, so with no LayoutCall the widgets have nowhere to attach and are silently dropped. `dummyModule.dummyName` is *Mendix's* placeholder for a missing layout, not something mxcli writes", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`buildPageV3`, the `if page.LayoutCall != nil` block)", "insight": "Reject a page that has body widgets (or placeholder blocks) but no LayoutCall — distinguish \"no Layout: clause\" from \"layout not found\" in the message. A Mendix page always needs a layout; snippets (buildSnippetV3) are layout-less and unaffected. Repro `mdl-examples/bug-tests/266-page-without-layout-drops-widgets.mdl`", "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "`mx check` fails to LOAD the project — `StorageLoadException: ... 'Module.Name' is not a valid AttributeIdentifier` after a `create`/`change` with a `Module.Assoc = …` member, yet `mxcli exec` reported success", "cause": "A one-qualifier member (`Module.Name`) that isn't a known association was written as an *attribute* ref, but a one-qualifier name can't be a valid attribute (attributes are bare or `Module.Entity.Attribute`) → unloadable .mpr. Usually the association's `create` failed earlier (non-idempotent) leaving it absent", "file": "`mdl/executor/cmd_microflows_builder_actions.go` (`resolveMemberChange`, the \"Not an association in the authored module\" branch)", "insight": "When the domain model is available and the one-dot member isn't in `dm.Associations`/`dm.CrossAssociations`, `fb.addError` with an actionable \"create the association first\" message instead of writing an Attribute. Same-script associations are visible via `GetDomainModel`, so no false positive. Repro `mdl-examples/bug-tests/264-create-member-unknown-association.mdl`. FINDINGS #51", "refs": ["#51"]}
-{"area": "mdl/executor", "symptom": "`mxcli check` rejects a **valid** microflow: **MDL048** on `retrieve … where [id = '[%CurrentUser%]']` (the standard signed-in-user idiom) — but `mx check` → 0 errors", "cause": "MDL048 targets constraining `id` against a STORED value (String/Long var or plain literal), which Mendix XPath can't do; it also matched the `'[%CurrentUser%]'` **server token**, which Mendix DOES resolve to a GUID", "file": "`mdl/executor/validate_microflow.go` (`checkXPathIdConstraint`)", "insight": "Skip an operand of the form `'[%…%]'` (a resolved token) before flagging. Case still fires for real stored-id values. Test `TestValidateMicroflow_XPathIdConstraint` (CurrentUser case); repro `mdl-examples/bug-tests/52-53-microflow-check-false-positives.mdl`. FINDINGS #53", "refs": ["#53"], "rules": ["MDL048"]}
-{"area": "mdl/executor", "symptom": "`mxcli check` rejects a **valid** microflow: **MDL045** (\"`/` is division\") on `round($a div $obj/Attr * 100)` — division whose divisor is an association-attribute path — but `mx check` → 0 errors", "cause": "The MDL grammar parses `div`/`*`/`/` at one precedence level, so `$a div $obj/Attr` mis-nests as `($a div $obj) / Attr`; MDL045 saw the `/ Attr` as division. But `Attr` is a bare member name — Mendix has no `/` division operator and re-parses the raw `$obj/Attr` as a path (serialized output preserves the `/`, so the build is clean)", "file": "`mdl/executor/validate_microflow.go` (`exprHasSlashDivision`)", "insight": "Don't flag a `/` BinaryExpr whose RIGHT operand is a bare `IdentifierExpr` (member navigation); real division has a numeric/paren/variable divisor. Test `TestValidateMicroflow_SlashDivision` (div-by-assoc cases); repro `mdl-examples/bug-tests/52-53-microflow-check-false-positives.mdl`. FINDINGS #52", "refs": ["#52"], "rules": ["MDL045"]}
-{"area": "mdl/executor", "symptom": "`create association X …` errors \"association already exists\" on re-run and aborts the script", "cause": "Correct SQL-shaped semantics (like `CREATE TABLE`) — `create` is not idempotent. The idempotent form is `create or modify association`, but it was undiscoverable from the bare error", "file": "`mdl/executor/cmd_associations.go` (the `NewAlreadyExists(\"association\", …)` sites)", "insight": "Not a code bug in the write path — improve the error to name `create or modify association …` and `drop association …`. Repro `mdl-examples/bug-tests/51-create-or-modify-association.mdl`. FINDINGS #51", "refs": ["#51"]}
-{"area": "mdl/executor", "symptom": "`dynamictext x (Content: '')` builds with **CE0720** \"Place holder index 1 is greater than 0\" — `mxcli check` ✓, describe shows `Content: '{1}'` with no params", "cause": "The builder unconditionally defaulted empty content to the template `{1}`, creating a placeholder with no matching parameter (orphaned)", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildDynamicTextV3`, final `content == \"\"` guard)", "insight": "Only default to `{1}` when there IS a parameter (`autoGeneratedParams`/`explicitParams`); empty content with no params is a literal empty template. Test `TestBuildDynamicTextV3_EmptyContent`; repro `mdl-examples/bug-tests/traceops-9-10-17-dynamictext-listview.mdl`. traceops #9", "refs": ["#9"], "ce": ["CE0720"]}
-{"area": "mdl/executor", "symptom": "`dynamictext s (Content: '$318')` builds with **CE0402/CE1613** (\"attribute '$318' no longer exists\") — the literal was turned into an unbound `{1}` param", "cause": "The auto-bind check treated ANY `$`-prefixed content as a variable; `$318` (dollar + digits) is not a valid Mendix variable", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`isDynamicTextVariableRef` / `dynamicTextVariableRe`)", "insight": "Treat `$` as a variable ONLY when followed by a letter/underscore (`^\\$[A-Za-z_]`); `$318` stays literal content. Tests `TestBuildDynamicTextV3_DollarDigitLiteral`, `TestIsDynamicTextVariableRef`. traceops #10", "refs": ["#10"], "ce": ["CE0402", "CE1613"]}
-{"area": "mdl/executor", "symptom": "`listview lv (… PageSize: 200)` always pages at 20 — `mxcli check` ✓, `mx check` ✓, describe shows no PageSize", "cause": "The property parsed into the AST but three layers ignored it: `buildListViewV3` hardcoded `PageSize: 20`, the describe parse never read it, and the listview describe formatter never emitted it", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildListViewV3`) + `cmd_pages_describe_parse.go` (Forms$ListView case) + `cmd_pages_describe_output.go` (listview case)", "insight": "Read `w.GetIntProp(\"PageSize\")` on write; read `w[\"PageSize\"]` on describe; emit a non-default PageSize in the listview formatter. Test `TestBuildListViewV3_PageSize`. traceops #17", "refs": ["#17"]}
-{"area": "mdl/executor", "symptom": "`combobox (Association: Mod.Ref, …)` drops the binding — `mxcli check` ✓ but MxBuild fails **CE0642** \"Property 'Attribute' is required\"", "cause": "The widget engine's `Association` source read the reference only from the `attribute:` keyword (`w.GetAttribute()`), so an explicit `Association:` keyword was ignored and the widget fell back to enumeration mode", "file": "`mdl/executor/widget_engine.go` (`case \"Association\"`) + `mdl/executor/validate_widgets.go` (`validateComboBoxAssociation`)", "insight": "Read the reference from `Association:` OR `attribute:`; and add MDL-WIDGET16 flagging an association combobox that lacks the required `datasource:` (option list). A complete association combobox needs reference + `datasource:` + `CaptionAttribute:`. Tests `TestValidateComboBoxAssociation`; repro `mdl-examples/bug-tests/traceops-23-combobox-association.mdl`. traceops #23", "refs": ["#23"], "ce": ["CE0642"]}
-{"area": "mdl/executor", "raw": "| `grant view on page` / `grant execute on microflow\\|nanoflow` / `grant access on odata\\|published rest service` to a role from **another module** passes `mxcli check`/`exec` but fails the Mendix build with **CE0148 \"reselect roles\"** — the own-module role works | Document access (page/microflow/nanoflow/service `AllowedModuleRoles`) may only reference the document's **own** module roles; Studio Pro's picker only offers those. The grant path wrote `role.Module + \".\" + role.Name` verbatim with no same-module check (only `validateModuleRole` = role-exists-in-its-module), so a cross-module reference reached the model. The MOVE path already guarded this (`remapDocumentAccessRoles`) — GRANT didn't | `mdl/executor/cmd_security_defaults.go` (`checkDocumentAccessRolesSameModule`) + the 5 grant handlers in `mdl/executor/cmd_security_write.go` | Pre-check each grant: reject when any `role.Module != docModule` with an actionable message (name the doc's module + suggest the own-module role). Reject (don't silently remap) — a GRANT is explicit, so a wrong role/doc shouldn't be substituted. Wired into page/microflow/nanoflow/OData/published-REST grants. Repro `mdl-examples/bug-tests/ce0148-cross-module-grant.mdl` |", "ce": ["CE0148"]}
-{"area": "mdl/executor", "symptom": "CE7054 \"parameters updated\" / CE7067 \"does not support body entity\" after `send rest request`", "cause": "`addSendRestRequestAction` emitted wrong BSON: all params as query params, BodyVariable set for JSON bodies", "file": "`mdl/executor/cmd_microflows_builder_calls.go` → `addSendRestRequestAction`", "insight": "Look up operation via `fb.restServices`; route path/query params with `buildRestParameterMappings`; suppress BodyVariable for JSON/TEMPLATE/FILE via `shouldSetBodyVariable`", "ce": ["CE7054", "CE7067"]}
-{"area": "mdl/executor", "symptom": "`CREATE X` returns \"already exists — use create or replace to overwrite\" but OR REPLACE is not valid for that type", "cause": "Error message in executor points to wrong keyword", "file": "`mdl/executor/cmd_<type>_*.go` — find the `NewAlreadyExistsMsg` call", "insight": "Change hint from `or replace` to `or modify`; verify the AST stmt uses `CreateOrModify` not `CreateOrReplace`"}
-{"area": "mdl/executor", "symptom": "`mx check` CE0126 \"Missing value for parameter X\" on `call java action ... ($Param = empty)` for typed (non-entity, non-microflow) parameters", "cause": "Builder emitted `BasicCodeActionParameterValue.Argument: \"\"` instead of the literal `\"empty\"` keyword", "file": "`mdl/executor/cmd_microflows_builder_calls.go` → `addCallJavaActionAction`", "insight": "Capture all resolved BasicParameterType params into `resolvedBasicParams`; when bound to MDL `empty`, emit `Argument: \"empty\"` so Studio Pro recognises an explicit empty literal rather than treating the slot as missing", "ce": ["CE0126"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE microflow` puts shared activities inside an `if … then` block — they should appear after `end if;`", "cause": "Nested guard split inside `traverseFlowUntilMerge` crosses the outer merge boundary", "file": "`mdl/executor/cmd_microflows_show_helpers.go` — guard path in `traverseFlowUntilMerge` (~line 854)", "insight": "Add `if contID != mergeID` guard before the `isMerge` skip-through so the guard continuation never crosses the outer merge"}
-{"area": "mdl/executor", "symptom": "Published OData service: `mx check` reports **CE5016** \"Attribute X has type String(50), but is published as .\" (empty published type) for every exposed attribute — modelsdk engine only (legacy slides by)", "cause": "mxcli never wrote `ODataPublish$PublishedAttribute.EdmType`, the OData EDM type Studio Pro stores on every published attribute. Both engines omitted it, but legacy's `$Type` field order let Studio Pro recompute; modelsdk's order tripped the check. **The legacy output was non-canonical too — don't treat \"legacy passes mx check\" as \"legacy is correct.\"** Found by diffing mxcli BSON vs a Studio-Pro-duplicated-and-fixed copy (the definitive method for these \"empty field\" checks)", "file": "`mdl/executor/cmd_odata.go` (`mendixAttrTypeToEdm`, `lookupEntityMembers`, `astEntityDefToModel`) + both writers (`publishedMemberToGen`, `serializePublishedMember`) + both reads", "insight": "Add `EdmType` to `model.PublishedMember`; derive it from the attribute's Mendix type (inverse of `edmToDomainModelAttrType`: String→Edm.String, Integer→Edm.Int32, Long/AutoNumber→Edm.Int64, Decimal→Edm.Decimal, Boolean→Edm.Boolean, DateTime→Edm.DateTimeOffset, Binary→Edm.Binary); emit + read in both engines", "ce": ["CE5016"]}
-{"area": "mdl/executor", "symptom": "Published OData service: `mx check` reports **CE5022** \"Published association X has changed multiplicity\" for every exposed association — modelsdk engine only", "cause": "Same shape as CE5016 but for `ODataPublish$PublishedAssociationEnd.IsMany` (the exposed navigation's multiplicity), which mxcli never wrote. Confirmed via the same Studio-Pro-duplicate-and-diff method", "file": "`mdl/executor/cmd_odata.go` (`assocMembership.Type`, `astEntityDefToModel`) + both writers/reads", "insight": "Add `IsMany` to `model.PublishedMember`; compute from the association type + exposed side (ReferenceSet ⇒ to-many either end; Reference ⇒ to-many only from the TO/Child side, to-one from the FROM/Parent side); emit + read in both engines", "ce": ["CE5016", "CE5022"]}
-{"area": "mdl/executor", "symptom": "MDL widget property `mxcli check`s clean but Studio Pro renders the default (e.g. `dataview ... (FormOrientation: Vertical)` always Horizontal)", "cause": "V3 grammar generic-property branch parks the value in `w.Properties`, but the V3 builder never reads it and the writer never emits it; the widget struct has no field for it", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildXxxV3`) + `sdk/mpr/writer_widgets_*.go` (`serializeXxx`) + `sdk/pages/pages_widgets_*.go`", "insight": "Add field to `pages.Xxx`; read via `w.GetStringProp` / `w.GetIntProp`; write in `serializeXxx`. If the Studio Pro UI label differs from the BSON storage name (e.g. DataView \"Form Orientation\" → `LabelWidth: 0/N`), confirm by diffing a Studio Pro-saved page against the reflection-data defaults"}
-{"area": "mdl/executor", "symptom": "Pluggable widget datasource property (`optionsSourceAssociationDataSource: Module.Entity`) passes `check` + `exec` but `mx check` reports CE0642 \"Property 'Entity' is required\"", "cause": "A `datasource`-operation property was authored by name; the engine reads the widget's `datasource:` clause (`Properties[\"DataSource\"]`), not the named key, so the value is silently dropped (and `hasDataSource` mode-selection also misfires)", "file": "`mdl/executor/validate_widgets.go` (`datasourceTypedKeys`) — and author via the `datasource:` clause", "insight": "`check` now rejects named datasource-typed props (MDL-WIDGET05); the fix for the user is `datasource: database Module.Entity`. Persisting a *named* datasource property (multi-datasource widgets) needs a Studio-Pro-verified mapping — deferred. Real-but-unmapped props get MDL-WIDGET06 warning via def.json `knownProperties` (not a false MDL-WIDGET01)", "ce": ["CE0642"]}
-{"area": "mdl/executor", "symptom": "CE7247 \"The name 'X' is a reserved word.\" on non-persistent entity attributes (Owner/Type/Context/Id/CreatedDate/ChangedDate/ChangedBy) — mxcli accepts the MDL silently, Studio Pro rejects the project", "cause": "`ValidateEntity` early-returned for NPEs; reserved-word check was not wired into the executor", "file": "`mdl/executor/cmd_enumerations.go` (`ValidateEntity`) and `mdl/executor/cmd_entities.go` (`execCreateEntity`)", "insight": "Drop the `EntityPersistent` early-return; gate only `mendixSystemAttributeNames` (MDL020) to persistent; run `mendixReservedWords` (MDL021) for all kinds; call `ValidateEntity` from `execCreateEntity` before any backend write. Issue #552", "refs": ["#552"], "ce": ["CE7247"], "rules": ["MDL020", "MDL021"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE MICROFLOW` (mdl/json) times out at 300s on a high-McCabe flow, but `--format mermaid` renders in ~1s — extraction is fast, the serializer hangs", "cause": "Exponential path enumeration: `duplicateOutputVariableWarnings` (run during `formatMicroflowActivities`) walked EVERY execution path, cloning the visited map at each branch (`cloneIDBoolMap`), to find output vars assigned twice on one path — O(2^branches). ~20 sequential `if/end if` diamonds already took ~10s. Diagnose with `DBGPROF=… ` CPU profile / add a pprof block to `describeMicroflow`; top-cum names the offender (not the describe traversal, which is linear)", "file": "`mdl/executor/cmd_microflows_show.go` (`duplicateOutputVariableWarnings`)", "insight": "Replace the all-paths walk with **reachability**: a name is a duplicate iff two of its assignments are path-ordered (one reaches the other); exclusive-branch assignments never reach each other. Memoized `reachableFrom` is O(V·E). Loop bodies inherit names assigned by activities that reach the loop node. Went 9.5s→0.1s at 20 diamonds; 120 diamonds completes instantly. Issue #710", "refs": ["#710"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE` of an entity/module emits `grant ... (read (Module.Entity.Attr))` that fails to re-parse with `mismatched input '.'` — breaks the DESCRIBE roundtrip", "cause": "Member emitter used the fully-qualified BY_NAME reference; grant grammar accepts a bare `IDENTIFIER` only", "file": "`mdl/executor/cmd_entities_access.go` → `resolveEntityMemberAccess`", "insight": "Strip `memberName` to the last `.`-segment before appending (bare names have no dot, so it's a no-op for them). Issue #633", "refs": ["#633"]}
-{"area": "mdl/executor", "symptom": "`style:` on a `dynamictext` crashes MxBuild with a NullReferenceException (fails at build, not check)", "cause": "The generic appearance applier wrote an inline Style into the DynamicText's `Forms$Appearance`; Mendix's metamodel can't handle it", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`applyWidgetAppearance`) + `mdl/executor/validate_widgets.go` (`validateStaticWidget`)", "insight": "Reject an inline `style` on a dynamictext as MDL-WIDGET03 (check + executor); the workaround is to wrap it in a container and style the container. Issue #673", "refs": ["#673"]}
-{"area": "mdl/executor", "symptom": "`DYNAMICTEXT (Attribute: X)` (e.g. inside a LISTVIEW) is silently dropped — `describe`/BSON shows `Content: '{1}'` with no parameter binding; Studio Pro throws `System.NullReferenceException` (ClientTemplateFormPart.CollectControls) and MxBuild fails CE0720 \"Place holder index 1 is greater than 0\"", "cause": "`buildDynamicTextV3` read `Content`/`ContentParams` but never read the `Attribute:` property, so the binding was discarded and the template defaulted to the orphaned \"{1}\". `mxcli check` had no orphan detection", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildDynamicTextV3`) + `mdl/executor/validate_widgets.go` (`validateStaticWidget`/`validateDynamicTextPlaceholders`)", "insight": "Treat `Attribute: X` as a single auto-generated template param (route through `resolveTemplateAttributePathFull`, same as `ContentParams: [{1} = X]`; non-String attrs get `toString()`). Add **MDL-WIDGET04**: flag a dynamictext whose `Content` template references `{N}` with fewer than N bound params (counting ContentParams or a single Attribute). Issue #650", "refs": ["#650"], "ce": ["CE0720"]}
-{"area": "mdl/executor", "symptom": "A widget `show_page` whose target page is created later in the same script passes `mxcli check --references` but the executor fails with \"page not found … defined later in this script\"", "cause": "The whole-script scriptContext used by reference validation tolerates forward refs (the page exists *somewhere*); the executor resolves page refs in statement order", "file": "`mdl/executor/validate.go` (`validateForwardPageRefs`)", "insight": "An ordered pass flags a widget page ref that is neither in the project nor created earlier in the script, with the same \"move the create statement earlier\" hint the executor gives — keeping check consistent with execution. Issue #674", "refs": ["#674"]}
-{"area": "mdl/executor", "symptom": "Workflow constructs pass `mxcli check` but MxBuild rejects them: user task without a page (CE1834); a single-outcome user task whose one outcome has a nested activity flow (CE1876); a decision outcome that isn't a valid enum value identifier, e.g. `'Confirmed closed'`", "cause": "`CreateWorkflowStmt` had **no** case in `validateWithContext` and no `ValidateWorkflow` at all — workflows received zero semantic validation", "file": "`mdl/executor/validate_workflow.go` (`ValidateWorkflow`, wired from `cmd/mxcli/cmd_check.go`)", "insight": "Recursively walk `stmt.Activities`: **MDL-WF01** flag a `WorkflowUserTaskNode` with empty `Page`; **MDL-WF02** flag `len(Outcomes)==1 && len(Outcomes[0].Activities)>0`; **MDL-WF03** flag a decision/call-microflow outcome `Value` that isn't `True`/`False`/`Default` and fails the identifier regex (space/punctuation). Syntax-only (no project). The page-context-entity check (CE7412) and enum-membership form of WF03 are `--references` follow-ups. See `PROPOSAL_check_mxbuild_gap_heuristics.md`", "ce": ["CE1834", "CE1876", "CE7412"], "rules": ["MDL-WF01", "MDL-WF02", "MDL-WF03"]}
-{"area": "mdl/executor", "symptom": "A DataGrid **control-bar** button passing `$currentObject` (e.g. `Action: show_page P (Order: $currentObject)`) passes `mxcli check` but MxBuild fails CE1571 \"No argument has been selected for parameter …\"", "cause": "A control bar sits above the grid and is not row-scoped, so `$currentObject` is unbound there; no check distinguished control-bar buttons from row-scoped (column) buttons", "file": "`mdl/executor/validate_page_button_context.go` (`ValidatePageButtonContext`, wired from `cmd/mxcli/cmd_check.go`)", "insight": "**MDL-BUTTON01**: walk the widget tree tracking an `underControlBar` flag (any `controlbar`-typed ancestor, mirroring `checkLayoutGridTree`'s `underGrid`); flag any button action (and its `ThenAction` chain) whose args contain the string `$currentObject`. Row-scoped column buttons are unaffected. Syntax-only", "ce": ["CE1571"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE` of a page/snippet emits `action: call_microflow X` / `call_nanoflow X` (button/widget actions) that fails to re-parse — breaks the DESCRIBE roundtrip", "cause": "Action emitters prefixed `call_`; the page-action grammar (`actionExprV3`) accepts `MICROFLOW`/`NANOFLOW` only", "file": "`mdl/executor/cmd_pages_describe_output.go` (`extractButtonAction`) + `cmd_pages_describe_pluggable.go` (`extractCustomWidgetPropertyAction`)", "insight": "Emit `microflow `/`nanoflow ` without the `call_` prefix. Issue #634", "refs": ["#634"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE` of a Java action (or `describe module … with all`) emits a body-less `create java action …;` that fails with `no viable alternative` and cascades into following statements — happens for add-on/Marketplace actions whose `.java` source isn't on disk", "cause": "Body emitted only when `readJavaActionUserCode` returns non-empty, but the grammar requires `AS DOLLAR_STRING` (body is mandatory)", "file": "`mdl/executor/cmd_javaactions.go` → `describeJavaAction`", "insight": "Always emit the `as $$ … $$;` block; when source can't be read, write a placeholder comment body. Issue #637", "refs": ["#637"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE` of a page emits `column Title (...)` / `column Description (...)` (datagrid columns named after a reserved keyword) that fails with `missing {IDENTIFIER, QUOTED_IDENTIFIER}` — breaks the DESCRIBE roundtrip", "cause": "#619 added `mdlIdent` (quote-if-reserved) for general widget names but missed datagrid column names", "file": "`mdl/executor/cmd_pages_describe_output.go` (`column %s` header, ~line 837)", "insight": "Wrap the column name: `fmt.Sprintf(\"column %s\", mdlIdent(colName))`. Issue #638", "refs": ["#619", "#638"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE` of a page/snippet emits widget-action microflow args as `Param = $value` that fails with `mismatched input '=' expecting ':'` — breaks the DESCRIBE roundtrip", "cause": "Arg emitters used `=`, but `microflowArgV3` accepts `IDENTIFIER COLON expr` (`Param: $value`) or `VARIABLE EQUALS expr` (`$Param = …`) — not `IDENTIFIER EQUALS`", "file": "`mdl/executor/cmd_pages_describe_output.go` → `extractMicroflowParameters` / `extractNanoflowParameters`", "insight": "Emit the canonical colon form: `paramName+\": \"+value`. Issue #640", "refs": ["#640"]}
-{"area": "mdl/executor", "symptom": "DESCRIBE drops `DataSource: selection X` for a DataView bound to a gallery/listview selection (master-detail pages)", "cause": "`extractDataViewDataSource` only handled `Forms$MicroflowSource` / `Forms$NanoflowSource` / `Forms$DataViewSource` / `Forms$DatabaseSource`; `Forms$ListenTargetSource` fell through to `return nil`", "file": "`mdl/executor/cmd_pages_describe_parse.go` (`extractDataViewDataSource`) + `mdl/executor/cmd_pages_describe_output.go` (DataView case) + `mdl/executor/cmd_pages_describe.go` (rawDataSource doc-comment)", "insight": "Add `case \"Forms$ListenTargetSource\":` returning `{Type: \"selection\", Reference: ds[\"ListenTarget\"]}`; add `case \"selection\":` in the DataView output switch emitting `DataSource: selection <ref>`"}
-{"area": "mdl/executor", "symptom": "CE0463 on a pluggable widget whose TextTemplate property is *conditionally hidden* by an enum/boolean toggle (VideoPlayer `videoUrl`/`posterUrl` when `type=expression`; Timeline `title`/`description`/`timeIndication` when `customVisualization=true`) — engine clones the template's populated `ClientTemplate` for a property Studio Pro hides and nulls", "cause": "Engine has no per-property visibility metadata; the hide rules live in the widget's compiled `editorConfig.js` (`hidePropertyIn`/`hidePropertiesIn`), not `widget.xml`", "file": "`mdl/executor/widget_defs.go` `widgetVisibilityRules` table + `mdl/backend/mpr/widget_builder.go` `ApplyPropertyVisibility`", "insight": "Extract the widget's `.mpk` `*.editorConfig.js` (`unzip` + grep `hidePropertiesIn`), transcribe the rule into `widgetVisibilityRules[widgetID]` as `{propertyKey, hiddenWhen:{propertyKey, operator eq/ne/truthy/falsy, value}}`; the engine nulls hidden TextTemplate-typed props at build time. Bump `WidgetDefGeneratorVersion` so stale project `.def.json` auto-refresh. Issue #574", "refs": ["#574"], "ce": ["CE0463"]}
-{"area": "mdl/executor", "symptom": "CE0463 on a `datagrid` whose column uses `ColumnWidth: manual` + `Size: N` — Studio Pro resets the column `size` to `1`", "cause": "The MDL `ColumnWidth:` keyword isn't mapped to the schema `width` enum, so `width` stays at its `autoFill` default; `size` only applies when `width=manual`, so the value is inconsistent. Regression from the Stream B keyword-path consolidation (the deleted `datagrid_builder.go` did `colPropString(col.Properties, \"ColumnWidth\", \"autoFill\")`)", "file": "`mdl/executor/widget_defs.go` `itemPropertyAliases`", "insight": "Add the MDL→schema alias under `[datagrid][\"columns\"]`: `\"width\": {\"ColumnWidth\"}`. Bump `WidgetDefGeneratorVersion` so stale `.def.json` regenerate. General rule when a column/object-list property's MDL keyword differs from the `.mpk` schema key (not just case), add it to `itemPropertyAliases`; cross-check against the pre-B3 `datagrid_builder.go` `colProp*` calls for any other dropped mappings", "ce": ["CE0463"]}
-{"area": "mdl/executor", "symptom": "`describe page` shows a widget's default placeholder text (e.g. the Dutch `'Tekst'` for a DynamicText) instead of the configured content; round-tripping describe→create then overwrites the real caption", "cause": "Text extraction was language-blind: `extractTextContent`/`extractTextCaption`/`extractTextFromTemplate` returned the **first** `Texts$Text` `Items[]` entry, and the page title hardcoded `GetTranslation(\"en_US\")`. In a multi-language project the first Items entry is often a non-default-language placeholder, so the wrong translation is shown. (The MDL surface is single-language regardless — this is display-only; note the real text isn't lost on disk, only mis-displayed)", "file": "`mdl/executor/describe_language.go` (new) + the three extractors in `cmd_pages_describe_output.go`/`cmd_pages_describe_parse.go` + title in `cmd_pages_describe.go`", "insight": "Select the translation by **project default language → en_US → first non-empty** via `selectTranslationText` / `pickTextTranslation`; get the default language from `ctx.Backend.GetProjectSettings().Language.DefaultLanguageCode`, cached on `executorCache` and pre-warmed in `preWarmCache` (race-free for parallel describe). No MDL bug-test possible (MDL can't author >1 translation) — covered by unit tests in `describe_language_test.go`. Issue #702", "refs": ["#702"]}
-{"area": "mdl/executor", "symptom": "Mendix can't resolve the microflow named in `CREATE ODATA CLIENT (ConfigurationMicroflow: microflow X.Y)` / `ErrorHandlingMicroflow:` — error names the literal string `\"MICROFLOW X.Y\"` as the missing microflow", "cause": "Case-mismatched prefix strip: visitor emits uppercase `\"MICROFLOW \"` from `odataValueText`, but `extractMicroflowRef` only trimmed lowercase `\"microflow \"`, so the keyword survived into BSON", "file": "`mdl/executor/cmd_odata.go` → `extractMicroflowRef`", "insight": "Use a case-insensitive strip: `if strings.EqualFold(ref[:10], \"microflow \") { return ref[10:] }`. Whenever a value goes from a visitor that emits a keyword-prefixed form to an executor that strips it, the strip must match the case the visitor produces — grep visitor files for `\"MICROFLOW \" +`/`\"ENTITY \" +`/etc. when adding a new property. Issue #573", "refs": ["#573"]}
-{"area": "mdl/executor", "symptom": "`create [or modify] association ... to System.X` passes `mxcli check --references` and `mxcli diff` but fails at `mxcli exec` with `child entity not found: System.X`", "cause": "Two divergent entity resolvers: the write path's `findEntity` resolved the owning module via `h.FindModuleID(dm.ID)`, but the virtual System domain model is not a real unit, so the hierarchy walk yielded an empty module name and System entities never matched. The validation path (`buildEntityQualifiedNames`) keyed on `dm.ContainerID` and worked, hence the check-passes/exec-fails split", "file": "`mdl/executor/oql_type_inference.go` → `findEntity`", "insight": "Resolve the module from `dm.ContainerID` (the module ID `BuildSystemDomainModel` sets), not by walking up from the DM's own unit ID. When a symptom is \"passes check/diff but fails exec,\" suspect two resolvers and make the write-path one match the validation-path one; add an `exec`-level test, not just a `check` test. Issue #610", "refs": ["#610"]}
-{"area": "mdl/executor", "symptom": "`ALTER STYLING ON PAGE/SNIPPET ... SET ...` fails with `unsupported container type: PAGE` (and `DESCRIBE STYLING` silently shows \"No widgets found\"); even past that, design-property writes never reached builder-created pages", "cause": "Two layered bugs: (1) the visitor emits uppercase `ContainerType` `\"PAGE\"`/`\"SNIPPET\"` but `execAlterStyling`/`execDescribeStyling` compared lowercase, so it fell through to the unsupported-container error; (2) ALTER STYLING used the reflection walker `walkPageWidgets` (legacy `ListPages`/`UpdatePage`), which can't locate widgets in MDL-builder pages and violates the mutator-pattern rule", "file": "`mdl/executor/cmd_styling.go` (`execAlterStyling`, `execDescribeStyling`) + `mdl/backend/mpr/page_mutator.go`", "insight": "Normalise container type with `strings.ToLower`. Route ALTER STYLING through `ctx.Backend.OpenPageForMutation(unitID)` like ALTER PAGE; check `mutator.FindWidget`. Add `SetDesignProperty`/`RemoveDesignProperty`/`ClearDesignProperties` to the `PageMutator` interface, writing the widget's `Appearance.DesignProperties` BSON array (`Forms$DesignPropertyValue` → `Toggle`/`Option`/`Custom` value), preserving an existing custom kind on option updates. When an ALTER uses a container-type discriminator, mirror the casing fix already done for ALTER PAGE (#402). Issue #631", "refs": ["#402", "#631"]}
-{"area": "mdl/executor", "symptom": "`declare $x list of T = empty;` (or any list-typed `declare`) passes `mxcli check` but Studio Pro rejects with CE0053 (\"type not allowed\") + CE0038 (\"value required\")", "cause": "`declare` maps to a Create Variable activity, which Mendix forbids from producing a list — but the validator only flagged an empty list *used as a loop source* (MDL002), never the declaration itself", "file": "`mdl/executor/validate_microflow.go` → `walkBody` `*ast.DeclareStmt` case", "insight": "Emit `MDL040` (SeverityError) for any `stmt.Type.Kind == ast.TypeListOf`, regardless of initializer. Lists must come from a microflow parameter, a `retrieve`, or `$x = create list of T;`. Also fix the synced skills that present declare-list as valid (`write-microflows.md`, `cheatsheet-variables.md`, `check-syntax.md`, `patterns-*`). Issue #607", "refs": ["#607"], "ce": ["CE0038", "CE0053"], "rules": ["MDL002", "MDL040"]}
-{"area": "mdl/executor", "raw": "| `DESCRIBE` of a navigationlist item (`item List`), a fragment widget (`container List`), or a workflow `user task Value` / `jump to Value` emits the name BARE and the output fails `mxcli check` (`mismatched input … expecting IDENTIFIER`) — same root cause as #619 but four further emitter positions the widget-name slice didn't reach | These four output sites interpolated the name directly instead of via `mdlIdent`. Unlike the strict-`IDENTIFIER` cases, the receiving grammar rules already accept `(IDENTIFIER \\| QUOTED_IDENTIFIER)` (`widgetV3` ITEM, `widgetV3`, `workflowUserTaskStmt`, `workflowJumpToStmt`), so **no grammar change is needed** — wrapping the emitted name is sufficient | `mdl/executor/cmd_pages_describe_output.go` (`item %s`, ~line 633), `mdl/executor/cmd_fragments.go` (`outputASTWidgetMDL`, ~line 169), `mdl/executor/cmd_workflows.go` (`jump to %s` ~line 321 + `formatUserTask` ~line 418) | Wrap each name in `executor.mdlIdent(...)`. Regression tests in `mdl/executor/issue619_emitter_quoting_test.go`; roundtrip fixture `mdl-examples/bug-tests/619-quoted-reserved-emitter-names.mdl`. The *other* class of #619 gaps (page-domain `microflowArgV3` show_page/microflow arg param names, `dataSourceExprV3` SELECTION ref, `sortSpec` list-sort attr) also needed a grammar widen — now done: each rule widened to `(IDENTIFIER \\| QUOTED_IDENTIFIER)` (`make grammar`), the visitor unquotes (`buildMicroflowArgV3`, `buildDataSourceV3` SELECTION, both `sortSpec` consumers), and the emitters quote via `mdlIdent` (`extractMicroflowParameters`/`extractNanoflowParameters`/`extractPageParameters`, `DataSource: selection`, list `sort(...)`, plus the fragment `selection` builder). Tests: `mdl/visitor/visitor_page_quoted_test.go` (`TestQuotedReservedSelectionAndArgNames`), `mdl/visitor/visitor_microflow_sort_quoted_test.go`, `cmd_microflows_format_listop_test.go`; fixture `mdl-examples/bug-tests/619-quoted-reserved-grammar-positions.mdl`. NOTE a reserved attribute like `Date` in a list `sort(...)` was *already* emitted bare and broken before this — the fix quotes it. Issue #619 |", "refs": ["#619"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE PAGE` / `DESCRIBE STYLING` silently drops a **compound** (nested) design property — e.g. Atlas `Spacing` → margin-top/bottom — even though it was written to BSON correctly and shows in Studio Pro; only flat toggle/option props survive the read-back", "cause": "The describe-side parser `extractDesignProperties` had no `Forms$CompoundDesignPropertyValue` case (dropped it entirely), and the emitters had no `compound` branch — the write half of #668 was done but the read/roundtrip half wasn't", "file": "`mdl/executor/cmd_pages_describe_parse.go` (`extractDesignProperties` → `parseDesignProperty`) + `cmd_pages_describe_output.go` (`formatDesignPropertiesMDL` → `joinDesignPropertyEntries`) + `cmd_styling.go` (DESCRIBE STYLING emitter)", "insight": "Parse `Forms$CompoundDesignPropertyValue` by recursing over its `Properties` list (each child is again a `Forms$DesignPropertyValue`) into `rawDesignProp.Nested`; emit recursively as `'Key': ['sub': 'v', …]`. Share one formatter (`joinDesignPropertyEntries`) across both describe paths so toggle/option/compound render identically. Verify with a write→`describe`→re-`check` roundtrip (the describe output must re-parse). When a feature writes a construct, always confirm the **describe read-back** too — write-only completeness is the recurring half-shell trap. Issue #668", "refs": ["#668"]}
-{"area": "mdl/executor", "symptom": "`check --references` on a view entity reports `could not parse select clause from OQL query` for a valid OQL query (any `select … from …`), AND MDL031 OQL type-mismatch checks never fire (misses real errors)", "cause": "`extractSelectClause` searched an **uppercased** query (`upperOql`) for the **lowercase** needle `\"select\"`, and compared `strings.ToUpper(oql[i:i+4])` against lowercase `\"from\"`/`\"union\"` — case mismatches that never match, so it returned `\"\"` for *every* query. That single `\"\"` both triggers the false-positive warning (`inferOQLTypes`) and short-circuits `ValidateOQLTypes` (early `return` on empty select clause) so no type checking runs", "file": "`mdl/executor/oql_type_inference.go` → `extractSelectClause`", "insight": "Compare case-consistently: `strings.Index(upperOql, \"SELECT\")` and slice keyword comparisons from `upperOql` (`word := upperOql[i:i+4]; word == \"FROM\"`). The static inferrer stays conservative (division / attribute refs → `TypeUnknown` → skipped), so re-enabling it doesn't over-fire on case/division aggregates. Tests: `TestExtractSelectClause`, `TestValidateOQLTypesNoFalsePositive` in `oql_type_inference_test.go`. Bug 9b", "rules": ["MDL031"]}
-{"area": "mdl/executor", "symptom": "`mxcli widget docs` omits all but the first widget of a bundled multi-widget `.mpk` (e.g. Charts.mpk emits only `areachart.md`; ColumnChart/BarChart/PieChart/LineChart/BubbleChart missing)", "cause": "Same class as #679 in an unfixed code path: `RegenerateWidgetDocs` used `mpk.ParseMPK` (returns `WidgetFiles[0]` only), while the def-generation loop (`RefreshWidgetDefinitions`) already used `ParseMPKAll`. Charts.mpk bundles 10 widgetFiles", "file": "`mdl/executor/widget_defs.go` → `RegenerateWidgetDocs`", "insight": "Swap the per-`.mpk` `ParseMPK` for `ParseMPKAll` and loop over every returned `mpkDef` (mirror the def-gen loop). Test `TestRegenerateWidgetDocsMultiWidgetMPK` (uses the `testdata/expr-checker/widgets/Charts.mpk` fixture). Bug 9a", "refs": ["#679"]}
-{"area": "mdl/executor", "symptom": "`mxcli check --references` flags `attribute 'Type' is a reserved word (CE7247) [MDL021]` even though the attribute is **quoted** (`\"Type\": String`), and the skills say \"always quote to avoid reserved-word conflicts\" — tester assumed quoting should exempt it", "cause": "NOT a bug — the check is correct. Quoting only escapes **MDL parser** keywords (`unquoteString` strips the quotes and the *bare* name is validated). `Type`, `ID`, `GUID`, `CurrentUser`, and the audit names `CreatedDate`/`ChangedDate`/`Owner`/`ChangedBy` are reserved by the Mendix **platform**, so they fail regardless of quoting. The gap was documentation: several skills claimed quoting is \"always safe\" without the platform-name carve-out", "file": "`mdl/executor/cmd_enumerations.go` (`mendixReservedWords`, `mendixSystemAttributeNames`) — no code change needed; docs only", "insight": "Add the carve-out to the \"always quote\" guidance (`check-syntax.md`, `generate-domain-model.md`, `demo-data.md`, docs-site `lexical-structure.md`) and a CLAUDE.md note: quoting is *parser*-safe, not *platform*-safe. Rename `Type`→`ResourceType`; use `AutoCreatedDate`/… pseudo-types for audit fields. Adjacent Mendix rule documented alongside: the after-startup microflow must return `Boolean` (CE0142) — a void seed microflow fails the build", "ce": ["CE0142", "CE7247"], "rules": ["MDL021"]}
-{"area": "mdl/executor", "symptom": "`linkbutton` (a documented CREATE PAGE / ALTER PAGE INSERT widget) fails `exec` with \"unsupported widget type: linkbutton — refresh widget definitions\", even though `actionbutton` works in the same spot", "cause": "`linkbutton` had a grammar token, a `pages.LinkButton` stub, and docs, but **no builder and no serializer** — `buildWidgetV3`'s switch only had `button`/`actionbutton`, so it fell to `default`. Trap: the `Forms$LinkButton` metamodel type requires an `address` (a legacy static hyperlink); the documented `linkbutton (caption, action)` is really a `Forms$ActionButton` with **RenderType \"Link\"** (the toolbox \"link button\"). The `RenderMode` field already existed on `pages.ActionButton` but the serializer hardcoded `RenderType: \"Button\"`", "file": "`mdl/executor/cmd_pages_builder_v3.go` (switch) + `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildButtonV3`) + `sdk/mpr/writer_widgets_display.go` (`serializeActionButton`) + `mdl/backend/modelsdk/widget_write.go` (ActionButton case) + `mdl/executor/cmd_pages_describe_parse.go`/`cmd_pages_describe_output.go`", "insight": "Route `linkbutton` → `buildButtonV3` with `RenderMode = Link`; serialize `RenderType` from `ab.RenderMode` (default \"Button\") on both engines; DESCRIBE reads `RenderType` back and emits the `linkbutton` keyword when it is \"Link\". Reuses the proven `Forms$ActionButton` BSON (only the enum differs), so no CE0463 risk. Tests: `mdl/executor/cmd_pages_linkbutton_test.go`, `sdk/mpr/writer_widgets_linkbutton_test.go`; example in `mdl-examples/doctype-tests/03-page-examples.mdl`", "ce": ["CE0463"]}
-{"area": "mdl/executor", "symptom": "In an interactive REPL running scripts back-to-back, a script that completes fine (e.g. `11-navigation-examples.mdl`, which contains `REFRESH CATALOG FULL`) leaves the session **silently disconnected** — the *next* `execute script` (or any statement) fails with `not connected to a project`. Only reproduces when a `.mxcli/catalog.db` already exists on disk (from a prior session/script) AND the project has since been written to; a from-scratch piped run never hits it", "cause": "`REFRESH CATALOG FULL` finds the on-disk cache stale (`Cache invalid: project file modified`) and calls `reconnect(ctx)`, which swaps `e.backend` for a fresh connection and syncs it back. When that reconnect fires **inside `execute script`**, the *outer* script statement's `ExecContext` was snapshotted before the reconnect, so it still holds the pre-reconnect (now-closed) backend. `executeInner`'s `syncBack` after the script then clobbers `e.backend` with that stale, closed connection → `IsConnected()` false → next statement reports not-connected. Any handler that runs nested statements via `ExecuteFn`/`ExecuteProgramFn` (EXECUTE SCRIPT, SQL connector-gen) is exposed", "file": "`mdl/executor/executor_dispatch.go` → `executeInner`/`syncBack`", "insight": "Before `syncBack`, snapshot `e.backend` prior to dispatch; if the handler didn't change its own `ectx.Backend` (`ectx.Backend == before`) but a nested call swapped `e.backend` (`e.backend != before`), adopt the live connection and its project-scoped caches (`Backend`, `MprPath`, `Cache`, `Catalog`) into `ectx` so `syncBack` preserves the reconnect instead of reverting it. **Diagnosis pattern**: \"works in a from-scratch/piped run, disconnects only in a long interactive session\" + the only state that nils the modelsdk reader is `Disconnect()` → suspect a stale outer `ExecContext` clobbering executor-global state changed by a *nested* statement; the trigger for the reconnect is a pre-existing `.mxcli/catalog.db` + a modified project. Regression: `TestReconnectInsideScript_KeepsConnection` (`reconnect_in_script_test.go`, integration-tagged)"}
-{"area": "mdl/executor", "symptom": "An unrecognized property on a **built-in** (non-pluggable) widget — a typo like `Contnet`, or a genuinely unsupported key — passes `mxcli check`+`exec` with no error and is silently dropped on write (pluggable widgets already got MDL-WIDGET01)", "cause": "`validateStaticWidget` had no unknown-property check; core widgets have no single property registry — builders read keys imperatively, and `describe` even emits keys (`WidthUnit`) the native builder doesn't consume — so a hard reject would false-positive on valid MDL and break the describe→create roundtrip", "file": "`mdl/executor/validate_widgets.go` (`staticWidgetKnownProps`, `validateStaticWidgetUnknownProps`, wired in `validateWidgetTree` gated on `lookupWidgetDef==nil`)", "insight": "Add **MDL-WIDGET07** as a **WARNING** (never an error — the core-widget vocabulary can't be proven complete): flag any `Properties` key not in `staticWidgetKnownProps` (the union of grammar keyword props + builder-consumed keys + the full `describe`-emit vocabulary, harvested by grep), with a `nearestKey` \"did you mean\" hint. Runs only for non-pluggable widgets. Guard the allow-list against describe-vocabulary drift with `TestStaticWidgetKnownPropsCoverDescribe`, and sweep `mdl-examples/**` for zero false positives after any change. Bug-test `mdl-examples/bug-tests/widget-unknown-property.mdl`."}
-{"area": "mdl/executor", "symptom": "Pluggable-widget datasource `sort by <attr> desc` (DataGrid2, Gallery; quoted or unquoted attr) round-trips as `asc` — `describe page` shows the direction flipped, runtime renders oldest-first, no error (silent wrong-order). Reproduces on the **default (modelsdk)** engine", "cause": "A Pages/`Forms$GridSortItem` stores its direction under the BSON key **`SortDirection`** (authoritative: the reflection-generated codec type `modelsdk/gen/pages` GridSortItem writes/reads `SortDirection`). The default engine wrote it correctly, but the DESCRIBE readers looked up the wrong key `SortOrder` (that key is only correct for `Microflows$SortItem` / `DocumentTemplates$GridSortItem`) → always fell back to `asc`. The legacy `sdk/mpr` writer *also* emitted the wrong `SortOrder` key, so under `--engine legacy` Studio Pro ignored it and reverted to ascending at runtime too", "file": "`mdl/executor/cmd_pages_describe_pluggable.go` (`gridSortDirection` helper + 3 call sites) & `cmd_pages_describe_parse.go` (1 call site); writer `sdk/mpr/writer_widgets.go` (`SerializeCustomWidgetDataSource`)", "insight": "Add `gridSortDirection(sortItem)` reading `SortDirection` with a `SortOrder` fallback (keeps pre-fix files readable); route all four grid-sort readers through it. Fix the legacy writer to emit `SortDirection`. When a sort/direction field seems misnamed, check the element's gen type in `modelsdk/gen/*/types.go` — different metamodel types genuinely use different keys (`SortDirection` for Forms/Pages grids, `SortOrder` for microflow/document-template sorts). Tests: `mdl/executor/cmd_pages_describe_sortdir_test.go`; bug-test `mdl-examples/bug-tests/bug8-datagrid-gallery-sort-desc.mdl`. Bug 8"}
-{"area": "mdl/executor", "symptom": "A `use fragment` / `use building block` (or a content `slot`) nested **inside a container/layout/dataview** — not at the page-body top level — fails `exec` with `unsupported widget type: USE_FRAGMENT` (or `USE_BUILDING_BLOCK`). The same ref at the top level of the page body works. So a reusable card/panel can't be placed inside a layout column — the natural usage", "cause": "`expandFragments` (the sentinel-expansion pass) only ran on the **top-level** widget list (the two call sites in `execCreatePage`/`execCreateSnippet`); the layout/container builders build children via `buildWidgetV3` directly, which has no case for the `USE_FRAGMENT`/`USE_BUILDING_BLOCK`/`SLOT` sentinel types → falls to `default` \"unsupported widget type\"", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`expandFragments`)", "insight": "Make `expandFragments` **recurse into each widget's children** after expanding the top sentinel: `for _, e := range expanded { if len(e.Children) > 0 { e.Children, _ = pb.expandFragments(e.Children) }; result = append(result, e) }`. The tree is fully expanded to concrete widgets *before* `buildWidgetV3` runs, so no builder needs a sentinel case. Expansion is idempotent on concrete widgets, so the extra traversal of an already-expanded slot payload is harmless. Verified: nested cards inside a layoutgrid column exec + `mx check` = 0 on 11.12.1. Test `TestExpandFragments_NestedInsideContainer`; bug-test `mdl-examples/bug-tests/nested-fragment-expansion.mdl`. **Diagnosis pattern**: \"works at top level, `unsupported widget type` when nested\" = an AST pre-pass (expansion/normalization) that only walks the root list; make it recurse into `.Children`"}
-{"area": "mdl/executor", "symptom": "An `autonumber` attribute with **no seed** passes `mxcli check` but fails the build with **CE7247 \"Value cannot be empty\"** (`alter entity … add attribute X: autonumber` or in a `create`). Docs showed seedless `autonumber`", "cause": "`ValidateEntity` had no autonumber-seed rule; the writer emits no `AttributeValue` when `!attr.HasDefault`, so Studio Pro has no start value. Sudoku findings #6", "file": "`mdl/executor/cmd_enumerations.go` (`ValidateEntity`)", "insight": "Add **MDL023** (error): `attr.Type.Kind == ast.TypeAutoNumber && !attr.HasDefault` → \"autonumber requires a seed (`default N`)\". Also fixed the skill docs (`mdl-entities.md`, `generate-domain-model.md`) to show `autonumber default 1`. Test `TestValidateEntityAutonumberNeedsSeed`; negative bug-test `f6-autonumber-seed.fail.mdl`", "refs": ["#6"], "ce": ["CE7247"], "rules": ["MDL023"]}
-{"area": "mdl/executor", "symptom": "An AutoX audit pseudo-type declared under a non-matching name — `StartedAt: autocreateddate` — silently becomes the fixed system member `CreatedDate` (declared name discarded), and binding that member in a widget then fails the build with **CE1613 \"attribute … no longer exists\"** (it's a system member, not a bindable attribute)", "cause": "The write path discards the identifier for AutoX types and `ValidateEntity` skipped them with no name check, so the rename + unbindable-member trap was silent. Sudoku findings #7", "file": "`mdl/executor/cmd_enumerations.go` (`ValidateEntity`, `autoMemberNames`)", "insight": "Add **MDL022** (warning): when an AutoX attr's name (case-insensitive) ≠ its canonical member (`owner`/`ChangedBy`/`CreatedDate`/`ChangedDate`), warn that the name is discarded and the member isn't widget-bindable — use a plain attribute you set yourself if a widget must show it. Test `TestValidateEntityAutoMemberRename`", "refs": ["#7"], "ce": ["CE1613"], "rules": ["MDL022"]}
-{"area": "mdl/executor", "symptom": "A **DataGrid2 column bound to an associated attribute** (`column c (attribute: Order_Customer/Name)`) passes `mxcli check` but fails MxBuild **CE1613** \"The selected attribute 'Module.Entity.Order_Customer/Name' no longer exists.\" — an own-entity `attribute: Name` works. (Feature gap: no way to show an associated attribute in a column.)", "cause": "The grammar `attributePathV3` already accepts a bare `Assoc/Attr` path (module-qualified `M.Assoc/Attr` does not — bare only), but the reader flattened it (`resolveAttributePath` just prefixes the entity, leaving the `/` embedded → `Module.Entity.Assoc/Attr`) and both column serializers hardcoded `EntityRef: nil`. So the column stored a flat, unresolvable attribute path with no association step", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`resolveAssociationAttributePath`, extracted from `resolveTemplateAssociationPath`) + `mdl/executor/widget_engine.go` (full-page column `attribute` case) + `cmd_pages_builder_v3_widgets.go` (`buildColumnSpecFromAST`, ALTER) + `mdl/backend/mutation.go` (`ObjectListItemProperty`/`DataGridColumnSpec` gain `AttributeRefSteps`) + `mdl/backend/widgetobj/builder.go` (`setAttributeRefField`+`attributeEntityRefBSON`) + `datagrid_column.go` (`buildColumnAttributeProperty`) + `mdl/executor/cmd_pages_describe_pluggable.go` (`columnAttributeFromRef`)", "insight": "Reuse the DynamicText contentparam machinery: resolve the `/`-path to a final attribute QN + `[]pages.AttributeRefStep` (hop → destination entity via `associationEndpoints`), carry the steps on the column spec, and emit `AttributeRef.EntityRef = IndirectEntityRef` of `EntityRefStep{Association, DestinationEntity}` (raw-BSON `attributeEntityRefBSON`, mirroring the codec-form `attributeRefWithStepsToGen`). DESCRIBE reconstructs the **short** `Assoc/Attr` (short association names — `attributePathV3` rejects module-qualified associations). mxbuild-validated (`mxcli docker check --no-update-widgets` = 0 errors) + describe round-trip. Tests: `mdl/backend/widgetobj/widget_builder_attribute_ref_test.go`, `mdl/executor/cmd_pages_describe_column_assoc_test.go`; bug-test `mdl-examples/bug-tests/datagrid2-associated-attribute-column.mdl`. Bug 7", "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "A DataGrid2 column's `DynamicCellClass: '<expr>'` (per-cell dynamic CSS class) parses, passes `check` + `mxbuild`, but is **silently dropped** — `describe` shows no `DynamicCellClass`, the `columnClass` slot is written as an **empty** expression, runtime cell is unstyled. Both engines", "cause": "The DataGrid `columns` object-list mapping (`itemPropertyAliases`) had aliases for `header←Caption`, `dynamicText←Content`, `width←ColumnWidth` but **none** for `columnClass`. `buildObjectListItem` looks up the schema key + its MDL aliases in the AST property bag (case-insensitive via `lookupProperty`), so `DynamicCellClass` never matched → the property fell through to the template's empty default. Cached `.mxcli/widgets/datagrid.def.json` files also had to regenerate to carry the new alias", "file": "`mdl/executor/widget_defs.go` (`itemPropertyAliases`, `columns.columnClass`) + `mdl/executor/widget_engine.go` (`WidgetDefGeneratorVersion` bump)", "insight": "Add `\"columnClass\": {\"DynamicCellClass\"}` to the datagrid `columns` aliases (schema property is `type: \"expression\"` → `operationForType` → written via the expression branch). **Bump `WidgetDefGeneratorVersion`** (5→6) so existing projects' cached def.json auto-regenerate via `RefreshStaleWidgetDefinitions` and pick up the alias — a code-only alias add is invisible until the stamped def is refreshed. DESCRIBE already reads `columnClass`→`DynamicCellClass` (`cmd_pages_describe_pluggable.go`). Test: `TestObjectListItemAliases`; bug-test `mdl-examples/bug-tests/bug10-dynamic-css-classes.mdl`. Bug 10a"}
-{"area": "mdl/executor", "symptom": "A `dynamictext` contentparam over an association fails mxbuild (\"No value specified\") — **re-reported as still-broken after the modelsdk fix**. Investigation: the contentparam is actually **already correct on the default (modelsdk) engine** in every *valid* container (datagrid custom-content column, `listview + database`, `dataview` over a page parameter — all mx check 0 errors). The only failing repro is a `dataview (datasource: database …)`, which is an **invalid Mendix construct** — a data view shows one object, so Mendix offers only Context/Microflow/Nanoflow/Listen sources, never Database (that's for list widgets). mxcli wrongly accepted it: modelsdk errored \"not yet supported — rerun with legacy\", and legacy silently wrote a `Forms$DataViewSource` that mxbuild rejects with **CE7007** \"Selected value is not valid for entity\"", "cause": "mxcli had no check for a DataView database source (only the association case, MDL-WIDGET08). So the invalid construct routed users to the deprecated legacy engine, which produced a broken page. **Do not \"fix\" legacy** (`LEGACY_ENGINE_KNOWN_ISSUES.md`: legacy is being removed, not patched) and **do not implement dataview+database in modelsdk** (Mendix doesn't allow it) — reject it at check, sibling to MDL-WIDGET08", "file": "`mdl/executor/validate_widgets.go` (`validateStaticWidget`, MDL-WIDGET09) + `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildDataViewV3` exec refusal)", "insight": "Add **MDL-WIDGET09**: `dataview` + `database` source → error steering to a microflow/nanoflow source (or page parameter), or a list widget. Refuse it in `buildDataViewV3` too (both engines) so a bare `exec` can't create a broken page. When a construct fails only on legacy, first check whether it's valid on modelsdk in a *valid* container — the fix is usually a check-time rejection of the invalid form, not a legacy patch. Tests: `TestValidateStaticWidget_DataViewDatabaseSource`; bug-test `mdl-examples/bug-tests/dataview-database-source-rejected.fail.mdl` (negative). Bug 3 (re-report)", "ce": ["CE7007"]}
-{"area": "mdl/executor", "symptom": "A `dynamictext` contentparam (or DataGrid2 column) navigating an association still fails mxbuild **CE0402 \"No value specified\"** — the *actually unsolved* Bug 3 case. Reproduces only when the widget's entity context is a **specialization** of the entity that declares the association: a grid over `SpecialExpense extends Expense` with `contentparams: [{1} = Expense_Employee/Name]` (the `Expense_Employee` association is on the base `Expense`). An exact-endpoint context (grid over `Expense`) works. `describe` shows `[{1} = <unbound>]`; the binding is dropped. **Very common in real apps** (entities inherit from a base, associations on the base) — which is why the earlier fixes looked incomplete", "cause": "`resolveAssociationAttributePath` → `associationDestination` matched the context against the association's FROM/TO **by exact string equality**. A subclass context equalled neither endpoint, so it returned `ok=false` and the caller fell back to the flat, unresolvable `Assoc/Attr` path → no valid AttributeRef → CE0402. Affects both engines (shared builder) and both the contentparam and Bug 7 column-attribute paths", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`associationDestination`, new `entityIsOrDescendsFrom` + `entityGeneralizations`)", "insight": "Match the endpoint the context **is or descends from**: walk the generalization chain (`Entity.GeneralizationRef`, qualified parent name) so an association declared on a base entity resolves from a subclass context. Diagnose association-binding drops by checking whether the widget's entity context exactly equals the association endpoint — inheritance is the usual culprit. mxbuild-verified 0 errors across grid-over-base, listview, and grid-over-subclass. Tests: `TestResolveAssociationAttributePath_InheritedContext`; bug-test `mdl-examples/bug-tests/bug3-contentparam-inherited-association.mdl`. Bug 3 (inheritance)", "ce": ["CE0402"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE` of a generic pluggable widget (chart) omits its object-list child blocks — `series`/`line`/`scalecolor` items are dropped, so describe→exec loses the chart's data. (Pre-existing; SERIES always had it.) DataGrid2/Gallery were unaffected — they have specialized column output", "cause": "The generic `pluggablewidget` DESCRIBE branch only emitted scalar `ExplicitProperties`; nothing walked the widget's `WidgetObject` lists. (The DataGrid2 column reconstruction, `extractDataGrid2Columns`, was the only object-list reader and is hard-coded to `columns`.)", "file": "`mdl/executor/cmd_pages_describe_objectlist.go` (`extractObjectLists`, `buildObjectListNestedKeyMap`, `extractObjectListItem`, `objectListMDLKey`) + wired into `cmd_pages_describe_parse.go` (generic-pluggable branch) + `cmd_pages_describe_output.go` (emit child blocks)", "insight": "Generalize the column-reconstruction pattern: `buildObjectListNestedKeyMap` (like `buildColumnPropertyKeyMap` but for any list key) resolves the item's `TypePointer→sub-key` map from `Type.ObjectType.PropertyTypes[listKey].ValueType.ObjectType.PropertyTypes`; per item, read datasource / AttributeRef / Expression / TextTemplate / PrimitiveValue and map the schema key to PascalCase MDL (`staticXAttribute`→`StaticXAttribute`). Keyword via `deriveObjectListKeyword` (lowercased). Only runs for the generic branch (`!isKnownCustomWidgetType`), so DataGrid2/Gallery keep their specialized output — no double-emission. Verified: describe→exec→describe is byte-identical on bar/line/heatmap. Tests: `TestExtractObjectListItem_ChartSeries`, `TestObjectListMDLKey`."}
-{"area": "mdl/executor", "symptom": "A HeatMap `scalecolor` entry's `ColorValue: '#rrggbb'` parses and passes `check` but the colour is **silently dropped on write** — describe shows only `ValuePercentage`, and the runtime scale has no colour. `valuePercentage` persists fine", "cause": "The schema property is spelled **`colour`** (British), and `scaleColors` had no `ColorValue` MDL alias, so the engine looked up `colour`, didn't find `ColorValue`, and wrote the template default (empty). Identical mechanism to Bug 10a (`columnClass`←`DynamicCellClass`) — a missing `itemPropertyAliases` entry", "file": "`mdl/executor/widget_defs.go` (`itemPropertyAliases`, `heatmap.scaleColors.colour`) + `mdl/executor/widget_engine.go` (`WidgetDefGeneratorVersion` bump)", "insight": "Add `\"colour\": {\"ColorValue\"}` to the HeatMap `scaleColors` aliases and **bump `WidgetDefGeneratorVersion`** so cached `.mxcli/widgets/heatmap.def.json` regenerate. DESCRIBE reconstructs it as `Colour:` (the PascalCase schema key — round-trips case-insensitively). Verified: `#rrggbb` now in BSON; describe→exec byte-stable. Test: `TestObjectListItemAliases_HeatMapColour`. Bug 10a class"}
-{"area": "mdl/executor", "symptom": "A **PieChart/HeatMap** (charts that bind data at the WIDGET level, no series object-list) fails MxBuild **after `mx update-widgets`** with **CE0642** \"Value attribute is required\" and (PieChart) **CE4899** \"Series name is required\" — even though `mxcli check` + `exec` are clean. The datasource persists; the value attribute + series name don't. Only surfaces once CE0463 version-drift is cleared by update-widgets", "cause": "These widgets expose several attribute-typed top-level properties (`seriesValueAttribute`, `seriesSortAttribute`) plus a required `seriesName` texttemplate. The engine's `resolveMapping` `\"Attribute\"` case read a single generic `w.GetAttribute()` — ambiguous across multiple attribute props and blind to the friendly MDL names — so `ValueAttribute:` never reached `seriesValueAttribute`; and `GenerateDefJSON` **skips all top-level texttemplate props**, so `seriesName` had no mapping. Item 1b", "file": "`mdl/executor/widget_defs.go` (`propertyAliases`, `GenerateDefJSON` attribute-alias + gated texttemplate case) + `mdl/executor/widget_engine.go` (`PropertyMapping.MdlAliases`, `namedPropValue`, `resolveMapping` `\"Attribute\"`/`\"TextTemplate\"`, version bump)", "insight": "Add `PropertyMapping.MdlAliases` (top-level analog of `ItemPropertyMapping.MdlAliases`) + a `propertyAliases` map (piechart/heatmap `seriesValueAttribute`←`ValueAttribute`, piechart `seriesName`←`SeriesName`). `resolveMapping` `\"Attribute\"` now reads via `namedPropValue` (property key + aliases) and resolves against the widget datasource entity (the DataSource mapping is ordered first), falling back to `w.GetAttribute()` for single-attribute widgets. Emit a top-level texttemplate mapping **only** when an alias is registered (keeps the broad skip). Bump `WidgetDefGeneratorVersion`; the example must supply the required `SeriesName:`. mxbuild-verified: whole chart file = 0 errors after update-widgets. **Diagnose \"required property\" CE0642/CE4899 by running `mx update-widgets` first (clears CE0463), then check which schema key is missing from the BSON.** Tests: `TestResolveMapping_NamedAttribute`, `TestGenerateDefJSON_PieChartNamedProperties`. Widget-level DESCRIBE of `seriesName`/datasource is a separate gap. Item 1b", "ce": ["CE0463", "CE0642", "CE4899"]}
-{"area": "mdl/executor", "symptom": "A view entity whose attribute is named after a Mendix OQL keyword — most often a date-part word like `Quarter`/`Month`/`Year` — passes `mxcli check`/`exec` but fails **MxBuild CE0174** \"The 'Quarter' part is incomplete or incorrect. You could use here: … OPEN_QUOTE, or IDENTIFIER\". A `Region`/`Period` column is fine", "cause": "OQL reads the bare word as the keyword, not the attribute. **This row previously said mxcli cannot escape it and that `s.\"Quarter\"` is a parse error — both are wrong**, and the error text quoted in the row disproves the first (it lists `OPEN_QUOTE` among what is valid there)", "file": "`mdl/executor/oql_type_inference.go` (`ValidateOQLSyntax`, `oqlReservedWords`, **MDL032**, **MDL072**); `mdl/executor/validate_oql_reserved_names.go` (**MDL071**)", "insight": "**Quote it in a SOURCE position** — `select s.\"Quarter\" …`, `from Module.\"Year\" as s` — measured at 0 errors on 11.13.0, with the quotes passed through verbatim (`RawQuery` via `extractOriginalText`). The **alias** is the one position OQL will not take a quote in, for any name at all, so a view entity's own attribute — whose name IS its alias — has to be renamed; that is the only case that does. Read the two CE0174 texts side by side before concluding anything about quoting: the source position lists `ASTERISK, AT_SIGN, OPEN_QUOTE, or IDENTIFIER` and the alias position lists only `IDENTIFIER`. MDL071 warns at CREATE (where a rename is still cheap), MDL032 inside a view's OQL, MDL072 on the quoted-alias spelling.", "ce": ["CE0174"], "rules": ["MDL032", "MDL071", "MDL072"]}
-{"area": "mdl/executor", "symptom": "A view entity with a **derived string column** — `cast(x as string)`, a string-returning `CASE`, or a string expression — passes `mxcli check`/`exec` but fails **MxBuild CE6770** \"View Entity is out of sync with the OQL Query\" whenever the declared attribute length is anything other than **200** (e.g. `string(30)`, `string(50)`, unlimited). The OQL itself runs fine, so it looks like a serialization gap but is a **platform rule**: Mendix normalizes a derived string column to the default length String(200); a plain pass-through column (`c.Name as Name`) instead inherits its source length", "cause": "Two parts. (1) The rule: only *derived* string columns are forced to 200 — a bare attribute ref infers `TypeUnknown` and is skipped, so any concretely-typed String the static inferrer sees is derived → 200. (2) The checker was **dead**: `inferTypeStatic`/`inferTypeFromExpression`/`inferCaseType` uppercased the expr (`upper := ToUpper(...)`) then compared against **lowercase** literals (`HasPrefix(upper, \"cast(\")`, `\"count(\"`, `\"case\"`, `== \"true\"` …), so every prefix check failed and only `DATEPART(` (uppercase literal) ever matched — CAST/CASE/COUNT/SUM/AVG/MIN/MAX/LENGTH inference all returned Unknown. Sibling of Bug 9b's `extractSelectClause` case bug", "file": "`mdl/executor/oql_type_inference.go` (`inferTypeStatic` CAST/CASE + case-fixed prefixes, `castTargetType`, `derivedStringLength=200`, `ValidateOQLTypes` string-length normalize, `typesStrictlyCompatible` length compare, `inferCaseType`, `inferTypeFromExpression`) — **MDL031**", "insight": "Infer `cast(expr AS string)` and string CASE as `String(200)`; in `ValidateOQLTypes` normalize any inferred `TypeString` length to 200 (derived); `typesStrictlyCompatible` compares String **length** (not just kind), so `string(30)` vs `String(200)` is flagged with `Fix: change to 'X: String(200)'`. **Fix the case-comparison bug** (lowercase→UPPERCASE literals) so the checker actually runs. **Guard against false positives**: `SUM(` over an un-inferable inner (a bare attribute ref → Unknown) returns **Unknown**, not a guessed Decimal — otherwise `sum(s.Units)` declared `integer` false-fires (caught on `34-chart-widget-examples.mdl`). mxbuild-confirmed on 11.6.6: `string(30)`→CE6770, `string(200)`→0 errors. Tests: `TestValidateOQLTypesDerivedString`, `TestValidateOQLTypesNoFalsePositive`; bug-test `mdl-examples/bug-tests/view-entity-derived-string-length.mdl`", "ce": ["CE6770"], "rules": ["MDL031"]}
-{"area": "mdl/executor", "symptom": "A view entity with a **pass-through string column** — a bare source-attribute reference like `select c.Name as CategoryName` — declared with a length **different from the source attribute** (most often an unbounded `string` against a `string(100)` source) passes `mxcli check` but fails **MxBuild CE6770** \"View Entity out of sync\". This is the counterpart of the *derived*-column rule (which forces 200): a pass-through column inherits the source length **exactly**", "cause": "The references-mode validator (`validateViewEntityTypes`) compared with `typesCompatible`, whose String rule only guards **truncation** (`declared.Length >= inferred.Length`), so an unbounded `string` (Length 0) or a wider `string(200)` against a `string(100)` source slipped through. Only *derived* columns (via `ValidateOQLTypes`/`typesStrictlyCompatible`, syntax mode) were length-exact", "file": "`mdl/executor/oql_type_inference.go` (`passthroughStringLengthMismatch`, called in `validateViewEntityTypes` before the generic `typesCompatible`)", "insight": "For a pass-through column (`col.SourceAttr != \"\"`, set only for a bare `alias.attr` ref — aggregates use a throwaway col so it stays empty) require **exact** String length match; emit the source entity/attr + inherited length in the message. **References-mode only** (needs the domain model to resolve the source attribute's length), so the repro is not a `.fail.mdl` (the syntax-only `make check-mdl` harness can't see it). Test `TestPassthroughStringLengthMismatch`; example `mdl-examples/bug-tests/ledger-36-view-passthrough-length.mdl`; mxbuild-confirmed on 11.12.1 (`string`→CE6770, `string(100)`→clean). Ledger finding #36", "refs": ["#36"], "ce": ["CE6770"]}
-{"area": "mdl/executor", "raw": "| A microflow `declare $x Module.Entity [= $obj];` (object/entity-typed local variable) passes `mxcli check` but mxbuild rejects it with **CE0053** \"Selected type is not allowed\" (+ CE0038 \"Value required\", + CE7247 on a following `set`) — a silent trap. The declare-entity attribute qualifier is a red herring: the whole construct is invalid, bare or initialized | Mendix's Create Variable activity (what `declare` maps to) only holds **primitive** types; there is no object/list Create Variable form (same restriction as MDL040 for lists). Objects must come from a parameter, a `retrieve … limit 1`, a `create` object, or a loop iterator. The check was missing; the microflow parser records a bare `Module.X` declare type as the ambiguous `TypeEnumeration` (`EnumRef`, `ExplicitEnum=false`), an explicit `Enumeration(Module.X)` sets `ExplicitEnum=true` | `mdl/executor/validate_microflow.go` (`walkBody` `*ast.DeclareStmt` case, next to the MDL040 list check) | Add **MDL043**: flag `Type.Kind == TypeEntity \\|\\| (TypeEnumeration && EnumRef != nil && !ExplicitEnum)`; error points to parameter/retrieve/create/loop and notes \"if it's an enum, write `Enumeration(...)`\". Reliable connection-free (no backend) because bare object names resolve to a distinct AST shape from explicit enums. Also fix the skills that wrongly taught `declare $x Module.Entity;` / `declare $x as …` as valid (`write-microflows.md`, `cheatsheet-variables.md`, `cheatsheet-errors.md`, `check-syntax.md`, `patterns-crud.md`, `patterns-data-processing.md`, `business-events.md`, `resolve-forward-references.md`, `migrate-k2-nintex.md`, `README.md`). Test: `TestValidateMicroflow_DeclareObjectIsRejected`; bug-test `mdl-examples/bug-tests/declare-object-variable-rejected.fail.mdl`. mxbuild-confirmed (11.12.0) |", "ce": ["CE0038", "CE0053", "CE7247"], "rules": ["MDL040", "MDL043"]}
-{"area": "mdl/executor", "symptom": "`alter entity M.E add attribute X: autonumber;` (no seed) or `... add attribute Created: AutoCreatedDate;` (renamed AutoX) passes `mxcli check` \"Check passed!\" but fails the build (CE7247) / silently discards the name — while the SAME attribute in `create entity` is correctly flagged (MDL023 / MDL022)", "cause": "The per-attribute checks (MDL021/022/023) only ran on `CreateEntityStmt`; the ALTER ENTITY ADD ATTRIBUTE path had no validation at all, so an attribute added later escaped every rule", "file": "`mdl/executor/cmd_enumerations.go` (`ValidateAlterEntity`, `validateEntityAttribute`) wired from `cmd/mxcli/cmd_check.go` + `cmd/mxcli/lsp_diagnostics.go`", "insight": "Extract the CREATE loop body into `validateEntityAttribute(attr, persistent, entityName)`; add `ValidateAlterEntity(stmt)` that runs it on `AlterEntityAddAttribute`. The entity kind isn't known from ALTER, so the persistent-only MDL020 is skipped; the kind-independent MDL021/022/023 all run. Bug-test `mdl-examples/bug-tests/f6-autonumber-seed-alter.fail.mdl`. Findings #6 (alter path)", "refs": ["#6"], "ce": ["CE7247"], "rules": ["MDL020", "MDL021", "MDL022", "MDL023"]}
-{"area": "mdl/executor", "symptom": "`create or modify entity M.E ( <subset> )` on an entity that already has more attributes **silently drops** every attribute not re-listed (36→2 attrs seen in practice), then widgets/microflows still bound to them fail the build with CE1613 — and the \"already exists\" error that leads users here recommends the destructive `create or modify` for a partial edit", "cause": "`create or modify` rebuilds the entity from the statement alone and REPLACEs the stored one, so any omitted attribute is deleted with no warning; the `NewAlreadyExistsMsg` hint pointed at `create or modify` without distinguishing \"replace whole\" from \"add one\"", "file": "`mdl/executor/cmd_entities.go` (`droppedEntityMembers`, the warn block before `UpdateEntity`, and the `execCreateEntity` already-exists message)", "insight": "Warn-only (non-blocking, the user asked to modify): before `UpdateEntity`, diff existing vs replacement members (`droppedEntityMembers` — named attrs case-insensitive + the four audit flags) and print what's dropped + point at `alter entity … add attribute` for incremental edits. Fix the already-exists message to recommend `alter entity` for a member change and reserve `create or modify` for a full replace. Bug-test `mdl-examples/bug-tests/f24-create-or-modify-dataloss.mdl`. Findings #24", "refs": ["#24"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "Design properties are written free-form: a `ColorPicker`/`ToggleButtonGroup` value serializes as a plain option (wrong `$Type` for Studio Pro's Appearance tab), and a typo'd key/value (they're case-sensitive) passes `mxcli check`. Also `show design properties <widget>` reports \"No design properties found for widget type container\" for a valid widget", "cause": "Root bug: `resolveDesignPropsKey` upper-cased the MDL keyword but the lookup map is **lowercase-keyed**, so `container`→`DivContainer` never resolved — leaving `resolveDesignPropertyValueType` dead code and the theme registry unused on the write/validate paths", "file": "`mdl/executor/theme_reader.go` (`resolveDesignPropsKey` case fix) + `mdl/executor/cmd_pages_builder_v3.go` (`astDesignPropToValue` takes theme props) + `mdl/executor/validate_design_properties.go` (new, MDL-WIDGET11/12) wired from `cmd/mxcli/cmd_check.go` + `cmd/mxcli/lsp_diagnostics.go` (cached `themeRegistry`)", "insight": "Fix `resolveDesignPropsKey` to lower-case the lookup. On write, resolve each flat value's type from the registry **by matching the value against the property's declared options** (see the CE6084 correction below — the control type alone does NOT decide it). On check (`-p` only, when themesource defines properties), walk page/snippet/alter-page widget trees and warn: **MDL-WIDGET11** unknown key (case-sensitivity hint / valid-key list), **MDL-WIDGET12** invalid value (lists allowed values). Warnings, not errors — a newer theme may add keys/values (forward-compat, per `page-styling-support.md:402`). Skip compound (registry doesn't model sub-props) and widgets with no type-specific metadata (pluggable). Bug-test `mdl-examples/bug-tests/typed-design-properties.mdl`", "ce": ["CE6084"]}
-{"area": "mdl/executor", "symptom": "Follow-up regression from the row above: after typed design properties merged, `mx check` fails **CE6084** \"Expected design property _Flex container_ / _Column gap_ / _Align items Y_ … to be of type **Toggle button group**, but found **Custom**\" on any page using a flat `ToggleButtonGroup` value (Atlas flex/spacing/typography, e.g. `'Column gap': 'Medium'`). Broke `TestMxCheck_DoctypeScripts` on `12-styling`, `15c-fragment-bindings`, `31-pluggable-datagrid-gallery-v010` (both engines) — green on unit tests, red only in `make test-integration`", "cause": "`resolveDesignPropertyValueType` mapped `ToggleButtonGroup`→`custom` by control type. But a ToggleButtonGroup selection picks one of a **fixed option set**, so Studio Pro stores it as an **Option** — a `Custom` value type mismatches the declaration. Only a ColorPicker's **off-list** value (a free-form hex) is genuinely Custom. The value type is decided by the **value**, not the control", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`resolveDesignPropertyValueType`, now takes the value and reuses `themeOptionAllowed`)", "insight": "Make it value-aware: value ∈ declared options → `option` (Dropdown, ToggleButtonGroup, predefined ColorPicker swatch alike); off-list **and** `ColorPicker` → `custom`; else `option`; no metadata → `option`. Verified: the three doctype examples pass `mx check` = 0 errors on both engines. Test `TestAstDesignPropToValue_Typed` extended with the `Column gap: Medium` + ColorPicker swatch/hex cases. **Diagnosis pattern**: a value-type/BSON-`$Type` mapping keyed on a *declared control type* is a trap — verify it against `mx check`, never assert it from the type name alone (this is exactly how the original bug slipped in). **Process lesson**: this shipped red because `make test-integration` (mx-check doctype roundtrips) was not run before merge — run it, not just unit tests, for any page/widget-serialization change", "ce": ["CE6084"]}
-{"area": "mdl/executor", "symptom": "`create or modify persistent entity` (even a byte-for-byte identical re-run) NULLs every column value on the next runtime DB sync — rows survive, values gone. Reports success (`Modified entity`), `mx check` = 0 errors; the loss only surfaces when something reads the data. Diagnose via the DB-sync count in `runtime.log` (\"Executing N database synchronization command(s)\") on an unchanged model", "cause": "`execCreateEntity` minted a FRESH attribute ID for EVERY attribute each run, even unchanged ones. Mendix's DB synchronizer keys off attribute identity — a new ID reads as \"attribute departed + new attribute added\", so it drops and re-adds the column. Only the entity's own ID was preserved; ALTER ENTITY (the safe path) mutates loaded attributes in place, keeping IDs", "file": "`mdl/executor/cmd_entities.go` (`execCreateEntity`)", "insight": "On CREATE OR MODIFY of an existing entity, build a name→ID map from `existingEntity.Attributes` and reuse the existing ID for retained attributes (only new attributes get a fresh ID); `attrNameToID` propagates the reused ID into validation rules + indexes. Also steer the \"already exists in project\" hint (`validate_duplicates.go`) toward `alter entity … add attribute` for entities. Test `TestCreateOrModifyEntity_PreservesAttributeIDs`; repro `mdl-examples/bug-tests/create-or-modify-preserves-attribute-ids.mdl`. Findings #13", "refs": ["#13"]}
-{"area": "mdl/executor", "symptom": "A widget EXPRESSION property (`dynamicclasses`/`visibleif`/`editableif`) that walks an association passes `mxcli check --references` but fails `mx check` with CE0117 \"Error(s) in expression.\" Easy to trip: a data binding (`contentparams`) on the SAME widget can traverse the same association legitimately", "cause": "No check inspected expression-typed widget property values for association steps (MDL-WIDGET04/07/etc. check placeholders/keys, not expression contents). Mendix client-side expressions cannot follow associations — only data bindings can", "file": "`mdl/executor/validate_widgets.go` (`validateWidgetExpressionAssociations`, called from `validateStaticWidget`)", "insight": "New MDL-WIDGET13: for `DynamicClasses`/`VisibleIf`/`EditableIf`, regex `exprAssociationStepRe` (`/Ident.Ident/`) flags a module-qualified step between slashes; a plain attribute (`$obj/Slug`) or enum literal (`Mod.Enum.Val`, no leading slash) doesn't match. Fix for the user: denormalise the attribute onto the bound entity (calculated attribute) or use a data binding. Test `TestValidateWidgetExpressionAssociations`. Findings #4", "refs": ["#4"], "ce": ["CE0117"]}
-{"area": "mdl/executor", "symptom": "Checker HINTS send the author the wrong way: MDL001 (nested loop) recommends `retrieve $Match from $List where … limit 1` (a parse error — can't filter a list variable); MDL044 flags `count()` in an expression with \"Did you mean 'round()'?\" (count is an aggregate, not a typo); MDL044's hint cites `mxcli syntax expressions` (no such topic)", "cause": "Message-only defects in the linter", "file": "`mdl/executor/validate_microflow.go` (MDL001 message ~216; `checkExprFunctions` ~283; `mendixAggregateFuncs`)", "insight": "MDL001 → recommend `$Match = FIND($List, <cond>)` (in-memory O(N); also fix CLAUDE.md idiom #2); MDL044 → for `count/sum/average/minimum/maximum` emit \"aggregate activity, not an expression function — assign to a variable first: `$n = count($List);`\" instead of a did-you-mean; point the generic hint at `mxcli syntax microflow`. Findings #7/#8/#14c", "refs": ["#14", "#2", "#7", "#8"], "rules": ["MDL001", "MDL044"]}
-{"area": "mdl/executor", "symptom": "A microflow-CALL output variable reused across a fallback chain (`$S = call M.Inner(...); if … then $S = call M.Inner(...) end if;`) — the natural \"try A else try B\" — fails the build CE0111 \"Duplicate variable name\"", "cause": "Each `$Var = call microflow/create/retrieve …` is a *fresh* variable creation; reusing the name (even inside an if) is a duplicate. `check --references` runs the flowBuilder validation (`validateOutputVariable`) which catches it — bare `check` (no project) does not", "file": "`mdl/executor/cmd_microflows_builder_validate.go` (`validateOutputVariable`, `validateScopedStatements`)", "insight": "Already caught by the shared create-output-var check (same fix as the retrieve/create case); locked in by `TestValidateDuplicateMicroflowCallOutputVar` (same-scope + nested-in-if). Fix for the user: one variable per call, then a plain `set` picks the winner (documented in write-microflows.md). Finding #5 (2nd trigger)", "refs": ["#5"], "ce": ["CE0111"]}
-{"area": "mdl/executor", "symptom": "`call javascript action` / `call java action` with a wrong-cased or misspelled PARAMETER name passes `check --references` (the action itself resolves) but writes a dangling reference that fails the build with CE1613 \"The selected … parameter … no longer exists\". E.g. `NanoflowCommons.OpenURL(url = …)` when the parameter is `Url`", "cause": "The reference checker resolved only the action NAME (`buildJava*ActionQualifiedNames` returns names, discarding params); the call's `CallArgument` names were never compared to the action's declared parameters", "file": "`mdl/executor/validate.go` (`flowRefCollector` → `codeActionCallRef`, `validateCodeActionParams`)", "insight": "Carry the call's `argNames` on the collector; after the name-exists check, `ReadJavaScriptActionByName`/`ReadJavaActionByName` → `.Parameters[].Name`, diff case-sensitively; casing-only mismatch → did-you-mean. Skip `System.*` (runtime-provided) and degrade to no-error when the backend reports no params. References-mode only (needs `-p`). Tests `TestValidateCodeActionParams`. RSS-reader follow-up finding", "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE PAGE` omits a textbox's `placeholder`/`onchange` even though they are written correctly (present in the .mxunit, live app works) — so a DESCRIBE round-trip is not a reliable way to confirm the write landed", "cause": "The describe read path (`parseRawWidget`) only read `LabelTemplate` + `AttributeRef` for a textbox; `PlaceholderTemplate` and `OnChangeAction` were never read back into `rawWidget`", "file": "`mdl/executor/cmd_pages_describe_parse.go` (`extractPlaceholderText`), `cmd_pages_describe.go` (`rawWidget` fields), `cmd_pages_describe_output.go` (`renderClientActionMDL`/`extractOnChangeAction` + TextBox emit)", "insight": "Add `Placeholder`/`OnChange` to `rawWidget`; read `PlaceholderTemplate` via `extractTextFromTemplate` (same as label) and `OnChangeAction` via a key-agnostic `renderClientActionMDL` (refactored out of `extractButtonAction`, since OnChangeAction is the same client-action type under a different key); emit `Placeholder:`/`OnChange:` in the TextBox case. Single describe path serves both engines (reads raw BSON via `GetRawUnit`). Test `TestParseRawWidget_TextBoxPlaceholderAndOnChange`. RSS-reader follow-up (verification note on #9)", "refs": ["#9"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE PAGE` of a `dynamictext` bound to a NON-STRING attribute (Integer/DateTime/…) emits `ContentParams: [{1} = toString($currentObject/Attr)]`; re-applying that output fails the build with CE1613 \"attribute '…toString($currentObject/Attr)' no longer exists\" — the rendered expression is treated as an attribute NAME. A string binding round-trips fine (bare attribute name)", "cause": "The write side converts a non-String attribute binding to `toString($currentObject/Attr)` (`resolveTemplateAttributePathFull`), stored as a ClientTemplateParameter `Expression`; the describe reader emitted the Expression verbatim instead of reversing the transform", "file": "`mdl/executor/cmd_pages_describe_output.go` (`unwrapToStringAttrParam` in `extractClientTemplateParameters`)", "insight": "When a ContentParam Expression is exactly `toString($currentObject/<path>)` or `toString($param/<attr>)` (the auto-generated forms), emit the bare `<path>` / `$param.attr`; the write side re-derives the toString on the next apply, so it round-trips. Any other expression (extra text, hand-written toString) is left untouched. Tests `TestUnwrapToStringAttrParam`, `TestParseRawWidget_DynamicTextNonStringAttribute`. RSS-reader follow-up finding", "ce": ["CE1613"]}
-{"area": "mdl/executor", "raw": "| A `contentparams`/`captionparams` value bound to a client EXPRESSION (`[{1} = formatDateTime($obj/LastImport, 'd MMM yyyy')]`) passes `mxcli check` but Studio Pro rejects the page with CE1613 \"attribute … no longer exists\" — the whole expression is stored as a bogus attribute name. A plain attribute path (`$obj/Attr`) or quoted literal (`'text'`) works | **mxcli** treats a template-parameter slot as a data binding: `buildClientTemplateParams` stores any unquoted value as an attribute path (`resolveTemplateAttributePathFull`), so an expression becomes a bogus attribute name. No check inspected the value for expression syntax. NOTE the original row said a template parameter *is* a data binding \"not an expression\" — that is a claim about MENDIX and it is **false**: Studio Pro's Edit Template Parameter dialog offers `Parameter type: Value | Expression`, with its own editor, variable list and wizard, and `Pages$ClientTemplateParameter` carries `Expression` beside `AttributeRef` and `SourceVariable`. The limit is mxcli's | `mdl/executor/validate_widgets.go` (`validateTemplateParamExpressions`, called from `validateStaticWidget`) | New **MDL-WIDGET14**: for each `ContentParams`/`CaptionParams` value, skip quoted string literals, then regex `templateParamExprRe` (`Ident(` function call or an arithmetic/comparison operator) flags an expression; an attribute path never matches. Fix for the user: set the parameter's type to Expression in Studio Pro, or bind an attribute path / quoted literal in MDL — do NOT send them to build a calculated attribute for something the platform already offers (the message used to, which is unnecessary modelling). Test `TestValidateTemplateParamExpressions`; bug-test `mdl-examples/bug-tests/contentparam-expression-rejected.fail.mdl`. Ledger finding #26 |", "refs": ["#26"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "A microflow expression using `dateTime(2026, $Month, $Day)` (a variable/computed arg) passes `mxcli check` but fails the build with CE0117 — Mendix builds `dateTime()`/`dateTimeUTC()` from hardcoded numeric constants only", "cause": "No check inspected date-construction arguments; the function name resolves so the unknown-function check (MDL044) is silent", "file": "`mdl/executor/validate_microflow.go` (`checkDateTimeLiterals`/`exprHasNonLiteralDateTime`, MDL046)", "insight": "New **MDL046**: walk the expression for a `FunctionCallExpr` named `dateTime`/`dateTimeUTC` with any non-`LiteralExpr` argument. Fix for the user: step off a literal anchor date — `addDays(addMonths(dateTime(2026,1,1), $Month-1), $Day-1)` (addDays/addMonths take variables). Test `TestValidateMicroflow_DateTimeLiterals`; repro `mdl-examples/bug-tests/ledger-21-datetime-literals.fail.mdl`. Ledger finding #21", "refs": ["#21"], "ce": ["CE0117"], "rules": ["MDL044", "MDL046"]}
-{"area": "mdl/executor", "symptom": "A retrieve constraint `where [Ledger.Transaction_Category = empty]` (an ASSOCIATION `= empty`) passes `mxcli check` but fails the build with CE0161 \"Error(s) in XPath constraint\" — XPath `= empty` tests attribute nullability, not association nullability", "cause": "No check inspected constraint strings for an association compared to `empty`; a bare attribute `= empty` IS valid, so a blanket ban would false-positive", "file": "`mdl/executor/validate_microflow.go` (`checkXPathAssociationEmpty`/`xpathAssocEmptyRe`, MDL047)", "insight": "New **MDL047**: on a `RetrieveStmt.Where` (via `expressionToXPath`), regex a **module-qualified** name (one dot) directly `= empty`, with a leading boundary class that excludes `/` (so `Assoc/Attr = empty` — a valid attribute-over-association test — is NOT flagged) and `.`/word (so a 3-part enum literal tail isn't grabbed). Fix for the user: `[not(Assoc/Module.Target)]`. **Also covers page/widget datasource where-clauses** (`validateDatasourceXPathAssociationEmpty` on `DataSourceV3.Where`, shared regex via `xpathAssociationEmptyMatches`) — the ledger project hit it there first. Tests `TestValidateMicroflow_XPathAssociationEmpty`, `TestValidateDatasourceXPathAssociationEmpty`; repros `ledger-25-xpath-assoc-empty.fail.mdl` (retrieve) + `ledger-25-page-datasource-assoc-empty.fail.mdl` (datagrid). Ledger finding #25", "refs": ["#25"], "ce": ["CE0161"], "rules": ["MDL047"]}
-{"area": "mdl/executor", "symptom": "Two sibling `dynamictext` widgets in a container render as `€ 310Last import: 7/24/2026` — concatenated with no separator, regardless of each one's RenderMode", "cause": "A Mendix DynamicText is always an inline `<span>`; RenderMode does not make it block-level. Not a build error — a silent layout surprise, so a non-fatal advisory fits", "file": "`mdl/executor/validate_widgets.go` (`validateConsecutiveDynamicText`, called from `validateWidgetTreeIn`)", "insight": "New **MDL-WIDGET15** (info): scan each sibling list; emit once when a run of ≥2 adjacent **inline** dynamictexts occurs. **Only H1–H6 are block-level** (`headingRenderModeRe`) — `Text`/unset AND `Paragraph` both render as an inline `<span>` (verified on Mendix 11.12.1 + Atlas), so `inlineDynamicText` excludes only headings. A heading+subtitle pair is NOT flagged; a Paragraph+Paragraph pair IS (it fuses). Fix for the user: merge into one dynamictext, wrap each in a container, or use a **heading** RenderMode — NOT Paragraph. Info severity so it never fails the build. Test `TestValidateConsecutiveDynamicText`; repro `mdl-examples/bug-tests/ledger-27-consecutive-dynamictext.mdl`. **Lesson: verify Mendix render behavior empirically — `Paragraph` sounds block-level but isn't; don't infer `display` from a name.** Ledger findings #27/#29", "refs": ["#27", "#29"]}
-{"area": "mdl/executor", "symptom": "`create association … from/to <ViewEntity>` passes `mxcli check --references` and `mxcli exec` creates it, but `mx check` rejects it with **CE6771** \"It is not possible to create associations to/from View Entities.\" Both directions are invalid", "cause": "Associations to/from a view entity are statically impossible, but the reference checker only validated that the endpoint modules exist — it never inspected whether an endpoint was a view entity", "file": "`mdl/executor/validate.go` (CreateAssociationStmt case) + `mdl/executor/cmd_entities.go` (`isViewEntity`)", "insight": "Resolve both endpoints via `findEntity`; if either `isViewEntity` (Source `DomainModels$OqlViewEntitySource`, or OqlQuery/SourceDocumentRef set), reject with CE6771 and point at a non-persistent entity carrying a real reference. Same-script endpoints are skipped (validated on their own statement). **References-mode only** (needs the domain model). Tests `TestIsViewEntity`; example `mdl-examples/bug-tests/ledger-41-view-entity-association.mdl`. Verified on Mendix 11.12.1. Ledger finding #41", "refs": ["#41"], "ce": ["CE6771"]}
-{"area": "mdl/executor", "symptom": "A `create or modify entity` that omits (drops) an INDEXED attribute leaves the entity's index orphaned — its column references a GUID that no longer exists. `mxcli` prints only the attribute-drop warning; `mx check` then **CRASHES loading the project** with `System.AggregateException` \"The given key '<guid>' was not present in the dictionary\" (DESCRIBE shows a dangling `index ()`)", "cause": "Two parts. (1) The executor rebuilt the entity from the statement (no index clause → empty `entity.Indexes`), so the existing index wasn't reconciled against the surviving attributes. (2) The write path: `entityToGen` produced an **empty, untouched** Indexes PartList, which the codec treats as \"clean\" and passes the raw (orphaned) index through — an empty typed list does NOT override raw bytes for an existing element", "file": "`mdl/executor/cmd_entities.go` (`reconcileDroppedIndexes`, before `UpdateEntity`) + `mdl/backend/modelsdk/domainmodel_alter.go` (`UpdateEntity` empty-index dirtying)", "insight": "(1) When the statement lists no indexes, carry existing indexes forward, pruning columns for dropped attributes (attr IDs survive by name via #13) and dropping empty indexes — a **partial** drop (`index (A,B)` → drop B → `index (A)`) works via this non-empty list. (2) For the **all-removed** case, force the empty Indexes list dirty (`AddIndexes(NewIndex())` + `RemoveIndexes(0)` — `PartList.Remove` calls `markDirty`) so the codec re-emits it as empty, clearing the raw orphan. **Codec insight: an untouched empty PartList is `clean` → raw passthrough; only a *dirtied* list (even if empty) overrides raw for an existing element.** Tests `TestReconcileDroppedIndexes`; example `mdl-examples/bug-tests/ledger-39-drop-indexed-attribute.mdl`. **Verified end-to-end: `mx check` → 0 errors on Mendix 11.12.1** (previously crashed). Ledger finding #39", "refs": ["#13", "#39"]}
-{"area": "mdl/executor", "symptom": "`retrieve … where [id = $Var]` (constraining on the object id) passes `mxcli check` but fails the build with **CE0161** \"Error(s) in XPath constraint\" — whether `$Var` is String or Long. Mendix XPath has no id operator reachable from a microflow expression", "cause": "No check inspected retrieve constraints for an id comparison; `id` is a reserved member so it resolves loosely", "file": "`mdl/executor/validate_microflow.go` (`checkXPathIdConstraint`/`xpathIdConstraintRe`, MDL048)", "insight": "New **MDL048**: on `RetrieveStmt.Where`, regex a bare `id` (word-boundaried, case-insensitive) before a comparison, **capturing the operand**, and flag only when the operand is a VALUE — a `$`-var whose kind is a primitive (in `varKinds`; objects aren't) or a string/number literal. **Comparing `id` to an OBJECT variable (`[id != $obj]`, the valid \"exclude self\" pattern) is NOT flagged** — verified valid on mx check; an over-broad `\\bid\\b\\s*[=…]` regex false-positived `16-xpath-examples.mdl`'s exclude-self example. Fix for the user: a marketplace GUID action (GetObjectByGuid), **or** expose the id as a String on a view entity (`cast(id as string) as ObjectId`) and constrain on that String column. Test `TestValidateMicroflow_XPathIdConstraint`; repro `mdl-examples/bug-tests/ledger-42-retrieve-by-id.fail.mdl`. **Lesson: `[id = $x]` splits on the operand type — value → CE0161, object → valid; a checker that ignores the operand mislabels the valid case.** Ledger finding #42", "refs": ["#42"], "ce": ["CE0161"], "rules": ["MDL048"]}
-{"area": "mdl/executor", "symptom": "A call argument bound to an association-object path (`call M.Consume(B = $Edit/M.Edit_Budget)` — the object reached over an association) passes `mxcli check` but fails the build with **CE0117** \"Error(s) in expression.\" An attribute value over the same association (`$Edit/M.Edit_Budget/Name`) is fine", "cause": "Mendix does not treat an association path as a value — it must be materialized (`retrieve`) first. No check inspected call arguments for an association-object path", "file": "`mdl/executor/validate_microflow.go` (`checkAssociationObjectArgs`/`exprIsAssociationObjectPath`, MDL049; wired for CallMicroflowStmt + CallNanoflowStmt)", "insight": "New **MDL049**: an argument whose value is an `AttributePathExpr` whose FINAL segment is module-qualified (a `.` → an association, yielding an object) is flagged; a final bare segment (an attribute) is not. Fix for the user: `retrieve $x from $Edit/M.Edit_Budget;` then pass `$x`. Test `TestValidateMicroflow_AssociationObjectArg`; repro `mdl-examples/bug-tests/ledger-44-assoc-path-as-value.fail.mdl`. Ledger findings #43/#44", "refs": ["#43", "#44"], "ce": ["CE0117"], "rules": ["MDL049"]}
-{"area": "mdl/executor", "symptom": "~~MDL050 \"format function + association navigation\"~~ **REMOVED — it was a false positive.** MDL050 flagged `formatDateTime($obj/Mod.Assoc/Date, …)` and `formatDecimal(…) + $obj/Mod.Assoc/Attr` as CE0117. Re-verification against `mx check` on 11.12.1 (once the real #48 root cause — the dropped association target-entity step — was fixed) showed the premise was wrong on BOTH cases", "cause": "The earlier \"format-function + association\" correlation was an artifact of TWO unrelated bugs, neither of which is about format functions: (1) **association navigation dropped its target-entity step** → CE0117 for ANY `$obj/Assoc/Attr` in an expression (see the \"#48 root cause\" row above), which happened to include the formatDateTime example; (2) **`formatDecimal($x, 2)` fails CE0117 on a PLAIN local decimal** with no association at all — a `formatDecimal`-signature bug, not an association issue. With (1) fixed, `formatDateTime($obj/Assoc/Date, …)` builds clean → MDL050 rejected valid code", "file": "`mdl/executor/validate_microflow.go` (removed `checkFormatWithAssociation`/`exprHasRenderFunc`/`exprHasAssociationNav`/`renderFuncsIncompatibleWithAssoc`)", "insight": "Deleted the check, its call sites, its test (`TestValidateMicroflow_FormatWithAssociation`), and its bug-test. **Lesson (reinforced): even after \"reproducing the failing neighbours\", a rule can still be mis-premised if the neighbours share a DIFFERENT hidden bug — here the missing entity step. Verify a check is still valid after every related write-path fix; a correlation-based rule is fragile.** The remaining real issue — `formatDecimal($x, precision)` failing CE0117 regardless of associations — is a **separate open finding** (likely a wrong function signature/arity; investigate against `mx` and fix in the executor or flag via the function checker). Ledger finding #48 (root cause corrected; MDL050 retired)", "refs": ["#48"], "ce": ["CE0117"], "rules": ["MDL050"]}
-{"area": "mdl/executor", "symptom": "An action property on a pluggable widget — e.g. `onClick: microflow …` on a DataGrid2 — passes `mxcli check --references` AND `mx check`, builds and runs, but is **silently discarded**: `DESCRIBE PAGE` omits it and the model round-trips minus the action, with no error or warning", "cause": "The .def.json **generator** never emitted an `action` operation for `type=\"action\"` properties (across 42 generated defs, no action operation existed at all). The writer reads only `propertyMappings` from the def, so with no action mapping it had nothing to write. The `.mpk` correctly declares the action slot; the gap is purely in generation", "file": "`mdl/executor/widget_defs.go` (`GenerateDefJSON` `case \"action\"` + `actionSourceForKey`); `mdl/executor/widget_engine.go` (`resolveMapping` `case \"OnChange\"`; `WidgetDefGeneratorVersion` bump 12→13)", "insight": "Emit an `action` `PropertyMapping` for the action slots MDL can author: `onClick`→source `OnClick` (reads the widget's `Action` property, i.e. the `onClick:`/`Action:` alias) and `onChange`→source `OnChange`. The engine's **existing** `applyOperation \"action\"` → `builder.SetAction` path (nil-guarded) then serializes the `ClientAction` with its parameter mapping. Non-authorable action slots (DataGrid2 `onSelectionChange`/`onConfigurationChange`) return `\"\"` from `actionSourceForKey` → no mapping (no MDL surface yet). Bump the generator version so existing projects regenerate. Tests `TestGenerateDefJSON_ActionMapping`; example `mdl-examples/bug-tests/ledger-67-pluggable-widget-action.mdl`. **Verified end-to-end: `mx check` → 0 errors on 11.12.1**, and the DataGrid2 persists the onClick microflow action with its `Thing: $currentObject` mapping (the raw page unit carries `L67.OnClick` + `L67.OnClick.Thing`). Ledger finding #67 (write path)", "refs": ["#67"]}
-{"area": "mdl/executor", "symptom": "**General guard for the #67 class:** a real widget property that the generator doesn't map to a write path could be silently dropped (or, via an alias, slip through) with no diagnostic — the same failure mode as #67 for any unmapped property type (`expression`, `icon`, a future type, an action slot with no MDL surface)", "cause": "The `WidgetDefinition.KnownProperties` field + the `MDL-WIDGET06` \"recognized but not persisted\" path already existed, but the **generator never populated `KnownProperties`**, so the warning never fired: an unmapped property either false-errored as MDL-WIDGET01 \"no such property\" or (via an alias like `Action`) passed silently", "file": "`mdl/executor/widget_defs.go` (`GenerateDefJSON` — populate `KnownProperties`); `WidgetDefGeneratorVersion` bump 13→14", "insight": "Compute `KnownProperties` purely from the two artifacts mxcli already has — **every `.mpk`-declared property key with no mapping in the generated def** (subtract PropertyMappings + aliases + ChildSlots + ObjectLists + mode mappings from the full key set). No per-widget knowledge. The existing `knownUnmappedProperties`/MDL-WIDGET06 check then WARNS \"recognized but not persisted — the value will be dropped.\" **Three-way discrimination verified on DataGrid2 (11.12.1): a mapped property (`onClick`) is silent, a real-but-unmapped one (`rowClass`) warns MDL-WIDGET06, a truly-unknown one (`totallyBogusProp`) still errors MDL-WIDGET01.** Test `TestGenerateDefJSON_KnownPropertiesUnmapped`. **This is the tester's suggested general check — it catches the whole class without guessing which widgets support what; the `action` mapping remains the specific fix for onClick.** Ledger finding #67 (general guard)", "refs": ["#67"]}
-{"area": "mdl/executor", "symptom": "**DESCRIBE read gap (follow-up to #67):** after the write fix, `DESCRIBE PAGE` still omitted a DataGrid2's `onClick` action — a describe round-trip silently lost it", "cause": "The datagrid2 describe parse/output paths read datasource + columns + paging but never read the widget-level action; the param-aware `renderClientActionMDL` reader (used for button/onchange) was never called for a pluggable widget's action", "file": "`mdl/executor/cmd_pages_describe_pluggable.go` (`customWidgetPropertyActionMap`), `cmd_pages_describe.go` (`rawWidget.OnClick`), `cmd_pages_describe_parse.go` (datagrid2 branch), `cmd_pages_describe_output.go` (datagrid2 emit)", "insight": "New `customWidgetPropertyActionMap` returns the raw `Forms$*ClientAction` map for a CustomWidget property (NoAction → nil); the read is wired in **two** describe paths — the `datagrid2` branch AND the **generic `pluggablewidget '…'` branch** (`!isKnownCustomWidgetType`, where **CustomChart — the finding's actual widget — is described**). Each renders it via `renderClientActionMDL` (param-aware) into `rawWidget.OnClick`; the output emits `onClick: <action>` (the generic branch's guard also fires on `w.OnClick != \"\"` so an action-only widget still gets its `pluggablewidget` header). **Verified end-to-end on BOTH DataGrid2 and CustomChart: describe → re-exec → `mx check` 0 errors, round-trip preserves the full `onClick: microflow …(param: $currentObject)` including the parameter mapping** (CustomChart quotes the param name, `\"Data\":`, which re-parses fine). Test `TestCustomWidgetPropertyActionMap`. Ledger finding #67 (DESCRIBE read gap closed for datagrid2 + generic pluggable/CustomChart)", "refs": ["#67"]}
-{"area": "mdl/executor", "symptom": "Two loops in the same microflow reusing the same iterator name (`loop $R in … end loop; loop $R in … end loop`) pass `mxcli check` but `mx check` fails with **CE0111** \"Duplicate variable name 'R'.\" at Loop", "cause": "A Mendix loop iterator is scoped to the **whole microflow**, not to its loop — so the second loop re-creates an existing variable. No check tracked loop iterator names across a microflow", "file": "`mdl/executor/validate_microflow.go` (`checkDuplicateLoopVariables`, MDL052)", "insight": "New **MDL052**: walk the microflow body (recursing through if/case/while/loop bodies) collecting `LoopStmt.LoopVariable` names; flag any name used by a second loop. Catches sequential AND nested reuse (a nested loop reusing an outer iterator is also CE0111). Distinct iterators, a single loop, and the same name across DIFFERENT microflows are fine. Fix for the user: give each loop a distinct iterator (`$R`, `$C`, `$M`). Test `TestValidateMicroflow_DuplicateLoopVariable`; repro `mdl-examples/bug-tests/ledger-64-duplicate-loop-variable.fail.mdl`. Ledger finding #64", "refs": ["#64"], "ce": ["CE0111"], "rules": ["MDL052"]}
-{"area": "mdl/executor", "symptom": "A `break` nested inside an `if`/`case` within a loop passes `mxcli check` but serializes a **dangling sequence-flow reference** — `mx check` then **CRASHES loading the project** with an unhandled `System.AggregateException` (\"key … not present in the dictionary\"), an unrecoverable failure. A break placed **directly** in the loop body serializes fine", "cause": "The flow builder (`addBreakEvent`) creates the Break event but the sequence flow connecting it from inside a conditional dangles — a write-path (flow-graph serialization) bug, still open. `break` directly in the loop body wires correctly", "file": "`mdl/executor/validate_microflow.go` (`loopBodyHasConditionalBreak`/`stmtsContainBreak`, MDL051) — **interim check**, pending the serialization fix", "insight": "New **MDL051**: on a `LoopStmt`, scan its body for a `break` inside an if/case/inheritance-split (not descending into nested loops — a nested loop traps its own break); a direct-child break is not flagged. Since the pattern currently produces a *crash*, a check-time rejection is a strict improvement. Fix for the user: a guard variable (`declare $Done Boolean = false; … if not($Done) then … set $Done = true`) — **verified clean on mx check**. Test `TestValidateMicroflow_ConditionalBreak`; repro `mdl-examples/bug-tests/ledger-52-break-in-conditional.fail.mdl`. Verified on 11.12.1: conditional break → KeyNotFound crash, direct break + guard-var workaround → 0 errors. **The real fix is the break-in-conditional flow serialization (write path) — MDL051 is the interim guard.** Ledger finding #52", "refs": ["#52"], "rules": ["MDL051"]}
-{"area": "mdl/executor", "symptom": "A datagrid **column** with an explicit empty caption (`Caption: ''`) passes `mxcli check` but `mx check` rejects the page with **CE0463** \"The definition of this widget has changed\" on the Data grid 2 (error points at the widget version, not the caption). Omitting the caption, or a non-empty string, both build clean", "cause": "The pluggable widget engine's column-header fallback treated a **present-but-empty** header property as \"has header\" and skipped the attribute-name default — so `Caption: ''` emitted an empty header (which Studio Pro rejects) while an **absent** caption got the fallback. The keyword datagrid path already handled it (`if caption == \"\" { caption = col.Attribute }` in `datagrid_column.go`)", "file": "`mdl/executor/widget_engine.go` (`applyColumnHeaderFallback`)", "insight": "**Write-path fix.** Detect an empty header (a `texttemplate` op with empty `TextTemplate` and no `Parameters`) and treat it like an absent one: fill it **in place** with the bound attribute's leaf name (not appended — that would duplicate the `header` prop). A header WITH params (`Caption: '{1}'`) is left untouched. Result: `Caption: ''` now behaves like omitting it. **Round 2 (custom-content columns):** the first fix left a column with **no bound attribute** (an action/custom-content column) untouched — it had nothing to derive a header from, so an empty OR absent caption still tripped CE0463 (a custom-content column requires a non-empty header). Fixed by falling back to the **column's own name** when there's no attribute, and **gating the whole fallback on the item template having a `header` slot** (`mapping.ItemProperties`) so header-less object-list items (chart series, accordion groups) are never given a spurious header. `applyColumnHeaderFallback(spec, columnName, hasHeaderSlot)`. Test `TestApplyColumnHeaderFallback` (cases 1–8); examples `ledger-54-empty-column-caption.mdl` + custom-content verified via exec. **Verified: `mx check` → 0 errors on 11.12.1 for attribute columns AND custom-content columns (empty + absent caption)** (previously CE0463). Ledger finding #54 (custom-content columns)", "refs": ["#54"], "ce": ["CE0463"]}
-{"area": "mdl/executor", "symptom": "`CREATE CONFIGURATION` (or any `ALTER SETTINGS`) reports success and `mx check` passes, but Studio Pro throws `System.InvalidOperationException: Sequence contains no matching element` at `MprProperty.cs:25` when the changed unit is opened (e.g. from the version-control status grid). Silently, the same write also resets **HttpPortNumber/ServerPortNumber to 0** on every *existing* configuration", "cause": "Three storage-name/enum defects in the settings write, all invisible to mxbuild (its deserializer tolerates unknown properties; Studio Pro resolves each stored property against the type's property list and throws when there is no match). (1) `createConfiguration` hardcoded `DatabaseType: \"HSQLDB\"` — the enum member is `Hsqldb`. (2) The gen `Configuration` binds the ports as `RuntimePortNumber`/`AdminPortNumber` (SDK names) while Studio Pro stores `HttpPortNumber`/`ServerPortNumber`, so the read returned 0 and the overlay wrote that 0 back. (3) Mendix renamed the runtime Java version property between 11.6 (`JavaVersion` = `\"Java21\"`) and 11.12 (`JavaMajorVersion` = `\"21\"`); mxcli wrote the 11.6 name unconditionally, leaving `JavaMajorVersion` stale and adding a property 11.12 does not define", "file": "`mdl/executor/cmd_settings.go` (`settingsDatabaseType`, `createConfiguration` defaults), `mdl/backend/modelsdk/settings_read.go` (`rawInt`, `javaVersionOf`), `mdl/settingsoverlay/settingsoverlay.go` (`JavaVersionKey`/`SetJavaVersion`, `newServerConfiguration`), `sdk/mpr/parser_settings.go` + `writer_settings.go`", "insight": "Canonicalise enum-valued settings against `generated/metamodel` and reject the rest (executor **and** `mxcli check`, via a `settingsKind*` entry so the drift guard covers it). Read version-renamed properties off the stored document and write them back to the key they came from — **never invent a key the document does not already have** (the same reasoning removed the hardcoded `Tracing: nil` from the no-sibling fallback: 11.12 spells it `OpenTelemetry`). **Diagnose without Studio Pro**: dump the `Settings$ProjectSettings` unit before and after the command and diff key-by-key against the project `mx create-project` produced — the write must be purely additive. A \"no matching element\" *property* lookup means a key Mendix does not know; an enum member mismatch is a different exception. Repro: `create configuration 'X'` on an 11.12 project. Issue #759", "refs": ["#759"]}
-{"area": "mdl/executor", "symptom": "`mxcli check … --references` reports **\"All references valid\" / \"Check passed!\"** for a script whose GRANT names a module role from a different module than the document; `exec` then fails with **CE0148** — after the preceding statements have already been applied, leaving the project half-modified", "cause": "The guard (`checkDocumentAccessRolesSameModule`) existed and was wired into all five exec paths, but **no validate path ever called it**. mxcli does not run a script in a single transaction, so a failure that only surfaces at exec time is exactly what a pre-flight check exists to prevent", "file": "`mdl/executor/validate_grant_roles.go` (`ValidateGrantRoles`, MDL-GRANT01), `mdl/executor/cmd_security_defaults.go` (`validateCrossModuleGrant`), wired in `cmd/mxcli/cmd_check.go`", "insight": "Reuse the existing exec-time guard from the **no-project** violations pass, covering all five document-access grants (microflow, nanoflow, page, OData service, published REST service). Take the document's module from the **statement's own qualified name**, not the resolved document — same comparison, and it works before the document exists (it is often created earlier in the same script). **Put it in the no-project pass, not under `--references`**: the check compares two names already in the script, so requiring `-p` withholds an answer mxcli can always give, and a plain `mxcli check` now catches it. **Generalisable — the shape to look for**: when exec rejects something a checker accepts, the bug is usually not a missing rule but a rule wired into only one of the two paths — grep the guard's callers before writing a new one. Repro `mdl-examples/bug-tests/836-check-cross-module-grant.fail.mdl`; verified end-to-end (check exits 1 naming the statement and CE0148, project left untouched; same-module variant still passes and gives 0 errors under mx check). Issue #836", "refs": ["#836"], "ce": ["CE0148"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE MICROFLOW` emits **`on error rollback`** on activities authored with no error-handling clause at all, growing the diff on every round-trip. No checker flags it — `\"Rollback\"` is structurally valid, so `mx check` and every mxcli validator pass", "cause": "`Rollback` is what `convertErrorHandlingType(nil)` stores for an activity with no clause **and** what the parser falls back to when `ErrorHandlingType` is absent from the BSON. The stored value therefore cannot distinguish an authored clause from the default, and read-back guessed \"authored\"", "file": "`mdl/executor/cmd_microflows_show_helpers.go` (`formatErrorHandlingSuffix`)", "insight": "Drop the `Rollback` case so it falls through to no suffix. **The asymmetry is the whole argument**: omitting it is lossless (re-executing stores `Rollback` again, so the model is unchanged), while emitting it is lossy in the direction that matters — it puts a clause in the user's script that they never wrote. `Continue` / `Custom` / `CustomWithoutRollback` are never defaults, so they still round-trip. **Generalisable — the shape to look for**: when a formatter renders an enum whose zero/fallback value is also a legal authored value, read-back cannot invert the write; render only the values that are *never* defaults. Ask \"what does the parser fall back to?\" before trusting a stored enum to mean the author chose it. Repro `mdl-examples/bug-tests/840-describe-invents-on-error-rollback.mdl`; verified end-to-end (describe → exec → describe byte-identical, `mx check` 11.13.0 0 errors). Issue #840", "refs": ["#840"]}
-{"area": "mdl/executor", "symptom": "A `create rest client` operation reports success, but `describe rest client` omits `Query:`, `Parameters:` and `Headers:` and always prints `Response: none`. BSON shows the query parameters/headers stored **correctly** while `ResponseHandling` is `Rest$NoResponseHandling` — the response mapping is gone. `mx check` passes (0 errors), so nothing anywhere complains", "cause": "**Two unrelated defects with one symptom.** *Write*: `model.RestClientOperation` documents `BodyType`/`ResponseType` as UPPER-case tokens and every consumer compares against that spelling, but the MDL executor stored the visitor's lower-case source text — so `op.ResponseType == \"MAPPING\"` never matched and the mapping fell through to the else-branch, which legitimately writes `NoResponseHandling`. *Read*: `restOperationFromGen` populated only Name/HttpMethod/Path/Timeout and type-asserted `*genRest.RestParameter` for **both** parameter lists, while the writer emits `Rest$OperationParameter` and `Rest$QueryParameter` — two different gen types, so both assertions failed silently", "file": "`mdl/executor/cmd_rest_clients.go` (`buildRestClientOperation` normalization + `checkInlineMappingBody`), `mdl/backend/modelsdk/integration_read.go` (`restOperationFromGen` + response/body/mapping-tree readers), `mdl/backend/modelsdk/consumed_rest_write.go` and `modelsdk/mpr/serialize_web_services.go` (`EqualFold`), `mdl/executor/validate_rest_mapping.go` (MDL-REST01)", "insight": "Normalize with `strings.ToUpper` at the one place the AST becomes the semantic model, and make the two serializer comparisons `EqualFold` so the landmine is not left armed for the next producer. **Generalisable — the shape to look for**: a case-sensitive comparison against a *documented-but-unenforced* string constant, where the non-matching branch is a **legitimate** outcome. Nothing errors, because \"no response handling\" is a real thing an operation can have — the else-branch launders a producer/consumer mismatch into a plausible-looking model. Grep every comparison against the constant, expect one per engine, and check whether the false branch is silent. **Second shape**: a reader that type-asserts one concrete type for two lists the writer builds from two *different* types; the assertion fails to `ok=false` and `continue`s, so a stub reader is indistinguishable from an empty document. The pre-existing round-trip test even created a query parameter — but only asserted the operation *count*, never that the parameter survived. **Third, separate half (#843's headline)**: `Response: mapping Mod.IMM_X` names an import mapping **document**, which Mendix cannot reference — `Rest$RestOperationResponseHandling` has exactly two implementations, inline and none. The clause parsed, contributed no entries, and was written as \"none\". Now refused at exec *and* `mxcli check` (MDL-REST01, no project needed). **Note** `Rest$QueryParameter` stores no DataType at all, so the MDL type is decorative and `describe` re-emits every query parameter as `String` — do not \"fix\" that by inventing the authored type back (see the #840 row). Repros `mdl-examples/bug-tests/843-rest-response-mapping.mdl` + `843-rest-response-mapping-no-body.fail.mdl`; verified end-to-end (`mx check` 11.13.0 0 errors, BSON now `Rest$ImplicitMappingResponseHandling` with a full `ImportMappings$ObjectMappingElement` tree, describe → exec → describe byte-identical). Issue #843", "refs": ["#840", "#843"]}
-{"area": "mdl/executor", "symptom": "`loop { if <cond> then break; }` where the `if` is the **last** statement builds a Decision with only its `true` outgoing flow (→ break). `mxcli check` passes but `mx check` reports **CE0079** \"the 'false' condition value should be configured in properties for an outgoing sequence flow\", and the microflow won't deploy. (Distinct from the earlier #791 crash — that was a dropped Break/Continue *event*; this is a missing *flow*.) `continue` and break-not-last behaved likewise", "cause": "The loop-body flow builder (`addLoopStatement`) is a simplified copy of `buildFlowGraph` that connected body statements with a plain `newHorizontalFlow` and **never honoured the deferred `nextFlowCase`** a merge-less split leaves for its FALSE branch. So the split's false case was dropped: mid-body it wired the next statement with no case; as the last statement it wired nothing at all", "file": "`mdl/executor/cmd_microflows_builder_control.go` (`addLoopStatement` body loop)", "insight": "Mirror `buildFlowGraph`: track `pendingCase` between body statements and apply it to the connecting flow; then, for a leftover `pendingCase` at the end of the loop body (a decision whose non-terminal branch falls off the end), synthesize a **ContinueEvent** and wire the split's false flow to it — the valid Mendix representation of \"didn't break/return → next iteration\". **Trap**: the check-time acceptance test (`TestValidateMicroflow_ConditionalBreakAccepted`) only asserted MDL051 doesn't fire — it never ran `mx check` on the *output*, so the CE0079 microflow shipped green. Assert the produced BSON, not just that check accepts the source. Repro `mdl-examples/bug-tests/ledger-52-break-in-conditional.mdl`; verified raw `mx check` 0 errors (was 1× CE0079) and the split now carries both a true→Break and a false→Continue flow. Ledger #52", "refs": ["#52", "#791"], "ce": ["CE0079"], "rules": ["MDL051"]}
-{"area": "mdl/executor", "symptom": "A workflow containing a standalone `annotation '...'` writes a project Mendix **cannot load**: `System.InvalidOperationException: Type ...Workflows.Model.Annotation does not contain a constructor with a parameter of type ...Workflows.Model.Flow`. Not a build error — Studio Pro will not open the project and `mx check` dies before validating anything. `mxcli check` passed and `exec` succeeded", "cause": "mxcli writes the annotation into the workflow's **activity flow**. Mendix loads that list by constructing every child with a `Flow` parent, and no annotation type takes one: `Workflows$Annotation` carries only `Description` (it attaches to a Flow) and `Workflows$FloatingAnnotation` (the canvas sticky note, which has exactly the `RelativeMiddlePoint`/`Size` fields mxcli was already writing) is not a flow element either. **Placement is the defect, not the storage name** — swapping the `$Type` to FloatingAnnotation reproduces the identical error with the new type name", "file": "`mdl/executor/validate_workflow.go` (new `MDL-WF04`), `mdl/executor/cmd_workflows_write.go` (`execCreateWorkflow` guard + `hasStandaloneWorkflowAnnotation`), skill `.claude/skills/mendix/write-workflows.md` (which had documented the construct)", "insight": "**Refuse rather than emit an unopenable unit** — at check time *and* at exec time, because a user who skips `check` otherwise still loses the whole project. The correct container is not determinable from the gen model (no struct owns a `FloatingAnnotation` list) and CLAUDE.md's rule applies: when the BSON shape is unknown, get a Studio Pro reference rather than guess. **Generalisable**: verify a storage-name hypothesis by *swapping only the name* — if the error is byte-identical with the new type, the bug is where the element is attached, not what it is called. Repro `mdl-examples/bug-tests/it-15-workflow-annotation-refused.fail.mdl`; A/B: pre-fix binary writes it and `mx check` cannot load the project, fixed binary refuses and the project checks 0 errors. issuetracker #15 **Follow-up (CI):** three `-tags integration` round-trip tests asserted this construct *works* and went red on the guard. They exercised mxcli's own write → read → describe → re-execute loop, which a structurally invalid document survives — the loop never loaded the project in Mendix, so it proved nothing about validity. Re-settled by stubbing the guard and running real `mx check`: the project fails at \"Loading the mpr file\". The tests were pinning the defect, and now assert the refusal (`TestCreateWorkflow_StandaloneAnnotationRefused`). **Second instance in one PR** of a green test codifying a bug (see the `jump to` row) — when a pre-existing test contradicts a new guard, re-derive the ground truth from the layer the symptom lives in before believing either.", "refs": ["#15"], "rules": ["MDL-WF04"]}
-{"area": "mdl/executor", "symptom": "A page datasource navigating an association writes `DestinationEntity: \"\"`, and the project becomes **unloadable**: `An error occurred when trying to set the 'DestinationEntity' property of a Entity ref step ... ---> System.ArgumentNullException` at `EntityRefStep.set_DestinationEntityId`. Studio Pro will not open it and `mx check` dies before validating anything. `mxcli check` and `exec` both succeed", "cause": "`resolveAssociationDestination` resolves both ends via `entityQNByID`, which only sees the **project's own** domain models — an association ending in a **System** entity (`from W.Issue to System.Workflow`) yields `\"\"` for that side. The context then matched neither end, and the fallback `return childEntity` returned the empty one. An empty by-name reference is not \"absent\", it is a reference Mendix resolves to null", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`resolveAssociationDestination` fallbacks + a hard guard in the `association` case of `buildDataSourceV3`)", "insight": "Prefer whichever end actually resolved and is not the context; then **refuse** an unresolved destination rather than write it, pointing at the explicit `Assoc/Module.Entity` form (verified to build 0 errors — it is the construct the reporter had abandoned). **Narrower than reported**: the finding blamed *nesting*, but a one-step probe with the same association reproduces it identically — nesting was incidental. Always re-derive the trigger with the smallest case before fixing the reported shape. **Generalisable**: a resolver that returns `\"\"` on failure will silently produce a null by-name reference; make the write path refuse empty rather than trusting the resolver. Repro `mdl-examples/bug-tests/it-14-assoc-destination-entity.mdl`; A/B: pre-fix binary leaves the project unopenable, fixed binary refuses and the project checks 0 errors. issuetracker #14", "refs": ["#14"]}
-{"area": "mdl/executor", "symptom": "`describe workflow` renders a plain `jump to Review;` as `jump to Review comment 'Review';` — a comment clause the author never wrote, which then round-trips back into the model as a real caption", "cause": "`buildJumpTo` defaults the activity's `Caption` to the **target name**, and the DESCRIBE emitter echoed `Caption` unconditionally (falling back to the activity `Name` when empty). Both are derived values carrying no authored information", "file": "`mdl/executor/cmd_workflows.go` (`JumpToActivity` case in `formatWorkflowActivities`)", "insight": "Emit `comment '...'` only when the caption is genuinely authored — non-empty **and** different from both the target name and the activity name. **Watch for tests that codify the bug**: `TestFormatJumpTo_CaptionCommentFormat` had a \"name fallback when caption empty\" case asserting the phantom comment, and two issue-619 quoting tests were incidentally coupled to it; a green suite was pinning the defect in place. Tests `mdl/executor/cmd_workflows_describe_test.go`, `mdl/executor/issue619_emitter_quoting_test.go`. issuetracker #16", "refs": ["#16"]}
-{"area": "mdl/executor", "symptom": "A workflow `decision '<expr>'` referencing the context passes `mxcli check`, executes, then the build fails `[error] [CE0117] \"Error(s) in expression.\" at Decision 'Decision'`. `$WorkflowContext/X` (exact casing) works; `$workflowContext/X` — the spelling this repo's own skill documented — and `$Ctx/X` from the author's `parameter $Ctx:` header both fail", "cause": "mxcli always stores the context parameter as `WorkflowContext` and Mendix expressions are **case-sensitive**. `normalizeWorkflowContextExpr` already existed but was wired into `autoBindCallMicroflow` only, so `with (...)` mappings were normalized while a decision's condition was written through verbatim. Separately, the header's declared variable name was parsed into `ast.CreateWorkflowStmt.ParameterVar` and then **never consumed** — a field populated but read nowhere, so `$Ctx` resolved to nothing", "file": "`mdl/executor/cmd_workflows_write.go` (`contextExprNormalizer` + threading it through `autoBindActivitiesInFlow`), `mdl/executor/cmd_alter_workflow.go`, skill `.claude/skills/mendix/write-workflows.md` (whose examples were the failing spelling)", "insight": "One normalizer applied to **every** expression an author can write in a workflow — decision conditions, user task due dates and XPath targeting, wait-for-timer delays, call-microflow mappings — rather than a second point fix. The declared name is aliased onto the stored one (whole-word, so `$CtxItem` is not mangled) instead of documenting it as meaningless. **Generalisable**: grep for an AST field that is written by the visitor and read nowhere — that is a silently-discarded user intent, not dead code. Repro `mdl-examples/bug-tests/it-17-workflow-context-expression.mdl`; A/B: pre-fix binary writes it and `mx check` reports CE0117, fixed binary checks 0 errors. issuetracker #17", "refs": ["#17"], "ce": ["CE0117"]}
-{"area": "mdl/executor", "symptom": "A page widget bound through an association — `Attribute: Issue_Assignee/Name` — passes `mxcli check`, executes, then fails `[error] [CE1613] \"The selected attribute 'IT.Issue.Issue_Assignee/Name' no longer exists.\"`. The error text is the raw MDL path glued onto the context entity. Same-module paths (`Issue_Project/Code`) work", "cause": "A domain model keeps associations in **two** lists. `Associations` holds intra-module ones (both ends BY_ID); an association targeting another module is a `DomainModels$CrossAssociation` in **`CrossAssociations`**, where only the local end is BY_ID and the remote end is the BY_NAME `ChildRef`. `associationEndpoints` searched only the first list, so every cross-module hop returned ok=false and the writer fell back to a flat attribute path instead of an `AttributeRef` with an `IndirectEntityRef` of steps", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`associationEndpoints`, `resolveAssociationDestination`), `mdl/executor/widget_engine.go` + `cmd_pages_builder_input.go` (`resolveAssociationPathIn`, `storedSystemMemberName`)", "insight": "**Scope correction — the reported trigger was wrong.** The finding blamed the *System module*; a plain second app module reproduces it identically, so the trigger is cross-module. Fixing \"System\" alone would have left the commoner case broken — always re-derive the trigger with a neutral variant before fixing the reported one. Two sibling defects in the same finding: (a) a ComboBox's `Association:` was qualified with the module of its **own option list**, because the `DataSource:` mapping runs first and moves `pageBuilder.entityContext` — an association belongs to the *containing* entity, so it now resolves against the context saved at `Build` entry (`outerEntityContext`); (b) `CreatedDate: AutoCreatedDate` is the spelling mxcli **requires** when declaring an audit member, but the member is stored as `createdDate`, so binding the name you just declared failed — `storedSystemMemberName` now maps declared→stored. **Generalisable**: when a resolver reads one collection off a model object, check whether the model splits that concept across two (intra- vs cross-module, own vs inherited). Repro `mdl-examples/bug-tests/it-19-cross-module-attribute-path.mdl`; A/B on Mendix 11.12.1: pre-fix binary → 4 × CE1613, fixed binary → 0 errors. issuetracker #19", "refs": ["#19"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "GRANT rejects members Mendix does recognise — `entity M.Label has no member(s) Issue_Label` for the non-owning end of an `OWNER Both` reference set, and `has no member(s) createdDate, changedDate` for audit members — and a `read * / write *` rule that looks complete still fails `[error] [CE0066] \"Entity access is out of date.\"`, so partial coverage is worse than none", "cause": "Two unrelated gaps in \"what counts as a member\". (a) `OWNER Both` makes an association a member of **both** ends, but the writer emitted the MemberAccess only for the FROM entity (`ParentID`) **and** `ReconcileMemberAccesses` independently applied the same FROM-only rule — so it stripped the entry back out on the next write even if the executor had added it. Two places had to agree. (b) Audit members are entity **flags** (`HasCreatedDate`/`HasChangedDate`), not entries in `entity.Attributes`, so the member walk never yielded them", "file": "`mdl/executor/cmd_security_write.go` (`execGrantEntityAccess`, `storedAuditMembers`, `otherModuleBothOwnerAssociations`), `mdl/backend/modelsdk/domainmodel_security_write.go` (`ReconcileMemberAccesses`)", "insight": "**Ask mxbuild what it wants instead of inferring symmetry.** Emitting a MemberAccess for `createdDate` seemed like the obvious fix for (b) — mxbuild **rejects** it with CE0066, and an entity storing audit members checks clean with no entry. So audit members are accepted as names but per-member rights on them are **refused with the reason** rather than silently dropped; only the `OWNER Both` association actually needed a new entry. **When a symptom has two spellings (a rejection and a build error), check whether they are one bug or two** — here they were two, and fixing them the same way would have introduced a new CE0066. **Generalisable**: a writer and a reconciler that both compute \"the expected member set\" are one invariant in two places; changing one alone is silently undone. Repro `mdl-examples/bug-tests/it-20-grant-member-coverage.mdl` (+ `it-20-grant-audit-member-rights.fail.mdl`); A/B on Mendix 11.12.1, same module same project: pre-fix binary → CE0066 + the bogus rejection, fixed binary → 0 errors. Controlled: the identical model with `OWNER Default` checks clean pre-fix, so the owner mode is the trigger. issuetracker #20", "refs": ["#20"], "ce": ["CE0066"]}
-{"area": "mdl/executor", "symptom": "A loop's variable used after `end loop;` passes `mxcli check`, then `mx check` fails `[error] [CE0108] \"Variable 'item' is defined but not in scope at this location.\"` at the referencing activity. Applies to the **iterator** and to anything the body introduces (a `retrieve`, a `$X = create …`, a call output)", "cause": "Nothing tracked loop-variable *visibility*. MDL052 already covered the sibling rule — names are unique across the whole microflow (CE0111) — and the wording of that rule (\"scoped to the WHOLE microflow\") reads as if the variable is readable flow-wide. Uniqueness and visibility are different: the name is reserved everywhere, readable only inside the loop body", "file": "`mdl/executor/validate_microflow_loop_scope.go` (new `MDL053`, wired from `microflowValidator.validate`), skill `.claude/skills/mendix/write-microflows.md`", "insight": "Map each loop-scoped name to the loop whose **own** body introduces it (nested loops keep their own names), then walk the flow with the set of enclosing loops and flag any reference from outside the owner. **A name claimed by two loops is dropped, not reported** — that is the MDL052/CE0111 case, and without the guard the MDL052 negative example started failing for the wrong reason: the first loop's own use of `$R` was blamed on the second loop's claim. **Generalisable**: a rule keyed by variable *name* needs an ambiguity escape hatch whenever another rule exists precisely because names can collide. Both flavours verified against mxbuild 11.12.1 (2 × CE0108 in one probe). Repro `mdl-examples/bug-tests/loop-variable-out-of-scope.fail.mdl`; tests `mdl/executor/validate_microflow_loop_scope_test.go`. Found while working the sudoku findings, but **not** one of them — the numbered finding it was filed under is an app bug in that project, not an mxcli defect", "ce": ["CE0108", "CE0111"], "rules": ["MDL052", "MDL053"]}
-{"area": "mdl/executor", "symptom": "A page bound to an attribute the entity **inherits** (`Person extends Administration.Account`, page binds `FullName`) passes `mxcli check --references` AND `mxcli lint`, then the real MxBuild fails `[error] [CE1613] \"The selected attribute 'TaskBoard.Person.FullName' no longer exists.\"` The message reads as a deletion; it never existed there", "cause": "Mendix stores a page's attribute reference against the entity that **declares** the attribute. `resolveAttributePath` qualified a bare name with `pb.entityContext` unconditionally, so a specialization that merely inherits the attribute got a dangling reference. Two independent resolvers had the same bug: the direct binding, and the final attribute of an association path (`resolveAssociationAttributePath`)", "file": "`mdl/executor/cmd_pages_builder_input.go` (`declaringEntityFor`, `entityAttributeOwners`), `mdl/executor/cmd_pages_builder_v3.go` (final attribute of the association path)", "insight": "Walk the generalization chain and qualify with the first entity that declares the name. **Fix both resolvers** — a probe that only tested the direct case would have shipped half a fix; the reporter's own table already showed the associated case failing, and it did still fail after the first patch. Unknown names keep today's context qualification rather than being re-pointed, and a cyclic chain terminates. **Watch the new dependency**: attribute resolution now consults the domain models, and `getDomainModels` panics on a nil backend — several unit tests build a `pageBuilder` with neither backend nor cache, so the lookup bails out early instead. A/B on Mendix 11.12.1: pre-fix binary → CE1613 for the inherited column and 0 errors for the own column; fixed binary → 0 errors for both shapes. Repro `mdl-examples/bug-tests/todo-12-inherited-attribute-on-page.mdl`; tests `mdl/executor/cmd_pages_builder_inheritance_test.go`. mxcli-todo #12", "refs": ["#12"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "A decision written with **uppercase** keywords — `IF $T/Status != M.Status.Done AND $T/CompletedOn != empty` — passes `mxcli check` and then fails the build with `[error] [CE0117] \"Error(s) in expression.\"`, quoting the expression back with `AND` still uppercase. The same condition written with `=` builds fine, which makes it look like `!=` cannot be an operand of `AND`", "cause": "Mendix requires its word operators lowercase. A rebuilt `BinaryExpr` gets `strings.ToLower(e.Operator)`; a condition kept as an `ast.SourceExpr` (original text **plus** the parsed tree) returned `e.Source` verbatim and skipped it. The `=` form parses to a BinaryExpr and the `!=` form to a SourceExpr — hence the operator-shaped illusion", "file": "`mdl/executor/cmd_microflows_helpers.go` (`normalizeMendixOperatorCase`, applied in the `SourceExpr` branch)", "insight": "Lowercase `and/or/not/div/mod` in preserved source, leaving everything else byte-identical: a scanner that tracks single-quoted literals (with `''` escapes) and skips any word preceded by `.`, `/` or `$`, so `'AND'`, `M.Enum.And`, `$Task/Mod` and `$Android` are untouched. **The reporter's own probe table is the cautionary bit** — nine builds established a rule (\"any `!=` inside `AND` fails\") that was real in every observation and wrong about the cause, because every failing probe was uppercase and the control was not. When a table's rule tracks a token, check what ELSE differs between the rows. Reproduced and fixed against mxbuild 11.12.1: stored `AND` → CE0117, stored `and` → 0 errors. Repro `mdl-examples/bug-tests/todo-14b-uppercase-and-operator.mdl`; tests `TestNormalizeMendixOperatorCase`. mxcli-todo #14b", "refs": ["#14"], "ce": ["CE0117"]}
-{"area": "mdl/executor", "symptom": "`CREATE DEMO USER` reports success and `SHOW PROJECT SECURITY` reports `Demo Users Enabled: true`, yet the running app has **zero** accounts — `SELECT Name FROM Administration.Account` returns 0 rows, there is no login page, and none of the row-level XPath rules are enforced", "cause": "A blank mxcli template ships with **Security Level: Off**, and with it off the runtime creates no accounts at all. The demo users are written to the model correctly; nothing connected the two facts, so the model said yes and the app said nothing", "file": "`mdl/executor/cmd_security_write.go` (`warnDemoUsersInert`, called after a successful create)", "insight": "Say it at the moment the user would otherwise believe it worked, and name the one statement that fixes it (`alter project security level prototype`). A *warning*, not a refusal: authoring demo users before raising the level is legitimate ordering. **Generalisable**: when a write succeeds but a project-level setting makes it inert, the write path is the only place with both facts in hand. Tests `TestWarnDemoUsersInert`. mxcli-todo #15", "refs": ["#15"]}
-{"area": "mdl/executor", "symptom": "Wiring a microflow that takes parameters to a **BEFORE CREATE** event handler passes `mxcli check` (and `--references`), and the build then fails `[error] [CE7247] \"Microflow should not have parameters\" at Event handler of entity …`", "cause": "Mendix passes no object to a before-create handler — the object does not exist yet — so the handler is called with no arguments. Nothing compared the handler's moment against the microflow's signature; the pairing is only invalid for this one moment/event combination", "file": "`mdl/executor/cmd_entities.go` (`checkBeforeCreateHandlerHasNoParameters`, called from `buildEventHandlers`)", "insight": "Guard where the two paths converge — `buildEventHandlers` is shared by `CREATE ENTITY`'s inline handlers and `ALTER ENTITY ADD EVENT HANDLER`, so one check covers both. It refuses **before the model is written**, and the message carries the build code plus the way out (AFTER CREATE, which does receive the object). **A microflow created earlier in the same script is not readable back yet, so an unreadable microflow is skipped rather than refused** — mxbuild still catches the real case, and failing on the read would break legitimate scripts. Note this is an exec-time guard: `mxcli check` without a project cannot see the microflow's signature at all. A/B on 11.12.1: pre-fix binary writes it and mxbuild reports CE7247; fixed binary refuses, and both AFTER CREATE and a no-parameter BEFORE CREATE still work. Tests `mdl/executor/cmd_entities_before_create_test.go`. mxcli-todo #14a", "refs": ["#14"], "ce": ["CE7247"]}
-{"area": "mdl/executor", "symptom": "A wrong `icon:` reference passes `mxcli check` (including `--references`) and first surfaces as a **build** error: `[error] [CE1613] \"The selected custom icon 'Atlas_Core.Atlas_Filled.no-such-icon' no longer exists.\" at Action button 'btnBad'`", "cause": "Nothing resolved the reference — the name was written straight through to BSON. Icon-collection lookup existed only for `show`/`describe` (`cmd_iconcollections.go`), never in a validation path", "file": "`mdl/executor/validate_icon_refs.go` (`validateIconRefs`), wired into `validateProgram`", "insight": "Index the project's icon collections once per run and resolve every reference in the program. **Put it in the `--references` pass, not the no-project one** — the collections are documents *in the project* (a blank 11.13 app ships three, ~770 icons), so unlike the #836 grant check there is genuinely nothing to resolve against without `-p`. **Report the two failures differently**: an unknown *icon* in a known collection gets near-match suggestions plus `describe icon collection <name>`; an unknown *collection* gets the list of collections that exist, because that is where the typo usually is. **Generalisable — the shape to look for**: a string property that names a model element but is stored as a plain string is invisible to every reference checker; grep for properties whose value is a qualified name yet whose type is `string`. **Test the silence, not just the noise**: the risk in a new check rule is false positives, so sweep the repo's own examples (all 9 `mdl-examples` scripts using icons) before shipping — a rule that fires on valid input is worse than the gap it closes. **Repro cannot be a `.fail.mdl`**: `make check-mdl` runs `mxcli check` with no `-p`, so a bad-icon script would pass there and be reported as a negative test unexpectedly passing; the repro carries valid icons and the rejection cases live in unit tests. Repro `mdl-examples/bug-tests/icon-reference-validation.mdl`; verified end-to-end (bad reference reported before any write; `mx check` 11.13.0 0 errors on the valid script)", "refs": ["#836"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "`mxcli check` reports `✓ Syntax OK` / `Check passed!`, then `mxcli exec` on the same script fails partway through with `failed to resolve page: page not found: Module.Page` — a button targeting a page the script creates further down. `exec` is not transactional, so the statements before the failure are already written to the .mpr", "cause": "Page references are resolved in statement order at exec time. `check --references` already had an ordered pass (`validateForwardPageRefs`), but it needs `-p`; plain `check` had nothing, and plain `check` is what gets run", "file": "`mdl/executor/validate_page_order.go` (`ValidateScriptPageOrder`, MDL-PAGE01), wired in `cmd/mxcli/cmd_check.go` beside the other project-free validators", "insight": "The soundness argument is what makes this work without a project: a **plain** CREATE later in the script would fail if the page already existed, so the script itself asserts the page does not exist yet and the earlier reference cannot resolve against the project either. `CREATE OR MODIFY`/`OR REPLACE` assert nothing, so they stay with `--references`, which can look. **Generalisable**: an ordering rule that seems to need project state often does not, once you find the statement that already asserts what you were going to look up. Two things the diagnostic must say and does: a cycle cannot be fixed by ordering (create one page without the linking widget, add it with `ALTER PAGE … INSERT`), and commit before executing a large script. Verified against all `mdl-examples/**/*.mdl` for false positives (0). Tests `mdl/executor/validate_page_order_test.go`, example `mdl-examples/bug-tests/todo-9-forward-page-reference.fail.mdl`. mxcli-todo #9", "refs": ["#9"]}
-{"area": "mdl/executor", "symptom": "`create non-persistent entity X ( A: String not null error '…' )` (or `unique`) passes `mxcli check` AND `mxcli exec`, then the build fails **CE0070** \"Validations rules are not allowed on entity 'X', because it is not persistable\"", "cause": "`not null` / `unique` ARE validation rules — Studio Pro models \"required\" and \"uniqueness\" as rules on the entity, not as column constraints — so Mendix rejects them on a non-persistable entity. Nothing in mxcli connected the attribute constraint to the entity's persistence kind", "file": "`mdl/executor/cmd_enumerations.go` (`validateNPEValidationRules`, called from `ValidateEntity`)", "insight": "Add **MDL054**, error severity, fired from the CREATE path only. **Establish the construct matrix against mxbuild before writing the rule, not from the issue text** — verified on 11.6.6 that `not null` with a message, `not null` bare, AND `unique` each produce CE0070 while a plain attribute does not, so the bare form (easy to miss, since the reporter only showed the message form) is flagged too. The CREATE path is the only one that can run this: `ALTER ENTITY … ADD ATTRIBUTE` does not carry the persistence kind, the same limitation MDL020 has. Sweep `mdl-examples/` + `scripts/check-skill-mdl.sh` after adding any error-severity rule — a false positive there breaks every user with that shape. Negative test `mdl-examples/bug-tests/832-npe-validation-rules.fail.mdl` (`.fail.mdl` = must fail check, enforced by `make check-mdl`) plus `-ok.mdl` pinning the other edge; tests `TestValidateEntityNPEValidationRules`. Issue #832", "refs": ["#832"], "ce": ["CE0070"], "rules": ["MDL020", "MDL054"]}
-{"area": "mdl/executor", "symptom": "`retrieve $L from Mod.Entity where [Attr = $Var/Mod.Assoc/Attr]` passes `mxcli check` AND `mxcli exec`, then the build fails **CE0161** \"Error(s) in XPath constraint\"", "cause": "Mendix XPath reaches at most ONE hop off a variable, and nothing checked the hop count", "file": "`mdl/executor/validate_microflow.go` (`checkXPathVariableTraversal`, `xpathVarTraversalRe`), called from the `*ast.RetrieveStmt` arm beside MDL047/MDL048", "insight": "Add **MDL055**, error severity, matching a `$var`-rooted path with **2+ segments**. **Establish the boundary against mxbuild first — it is narrower than it looks**: `$Var/Attr` VALID, `$Var/Mod.Assoc` VALID (one hop to the associated object), `$Var/Mod.Assoc/Attr` CE0161. A rule keying on \"a module-qualified segment follows a variable\" would reject the middle form, which is legal; key on hop count instead. Verified on 11.6.6 by building all three and dropping the offender to confirm the other two are clean. **Reject, don't try to serialize** — there is no valid XPath for the two-hop form, so the constraint must be restructured and only the author knows which way. **Verify the suggestion you emit**: both recommended rewrites (`retrieve $Related from $Var/Mod.Assoc;` then constrain on `$Related/Attr`; or invert to `[Mod.Assoc/Mod.Entity = $Var]`) were built and confirmed at 0 errors before the message claimed \"both forms build clean\". Negative test `mdl-examples/bug-tests/831-xpath-variable-traversal.fail.mdl` + `-ok.mdl`; test `TestXPathVariableTraversal`. Issue #831", "refs": ["#831"], "ce": ["CE0161"], "rules": ["MDL047", "MDL048", "MDL055"]}
-{"area": "mdl/executor", "symptom": "`mxcli check` reports a microflow rule (e.g. MDL048 `[id = $StringVar]`) but `mxcli exec` writes the same script silently — a script that skips `check` produces a project the build rejects", "cause": "Two different validators. The exec path called `ValidateMicroflowBody` (semantic errors); the MDL0xx rule set lives in `ValidateMicroflow`, which was wired only into `cmd/mxcli/cmd_check.go` and the LSP. Same shape as #836, where a guard existed on every exec path but was never reached from validate", "file": "`mdl/executor/validate.go` (`validateMicroflowRules`, `execEnforcedMicroflowRules`) called from `mdl/executor/cmd_microflows_create.go` — the handler, mirroring `ValidateEntity` in `cmd_entities.go` (NOT `validateWithContext`, which would double-report under `check --references`)", "insight": "Promote an **explicit allowlist** of rules verified against a real mxbuild, never the whole set. **Blanket promotion was tried and reverted**: it turns every error-severity rule into a write barrier, and `MDL009` (\"enumeration splits require exactly one value per branch\") was a **false positive** — a multi-value branch covering every enum value builds at 0 errors on 11.6.6, and the shipped `write-microflows` skill documents that very form (since retired, see the MDL056 row). It also broke an existing repo test whose fixture uses `else` on an enum split. `MDL008` by contrast IS correct (mxbuild: CE0079 per uncovered value + CE0773) — so before promoting any rule, build its construct and read the verdict. Warnings are never promoted. Tests `TestValidateMicroflowRules_ReachedFromExec` and `…_UnverifiedRulesNotPromoted` (the latter fails if the allowlist is widened carelessly). Issue #833", "refs": ["#833", "#836"], "ce": ["CE0079", "CE0773"], "rules": ["MDL008", "MDL009", "MDL048", "MDL056"]}
-{"area": "mdl/executor", "symptom": "`mxcli check` errors **MDL009** \"enumeration splits require exactly one value per branch\" on `when Open, Pending then` — but Mendix accepts it, so check rejects valid MDL and contradicts the shipped `write-microflows` skill", "cause": "The rule asserted the opposite of the platform's behaviour. Nobody had built the construct: a multi-value branch covering every value **plus `(empty)`** builds at 0 errors on 11.6.6", "file": "`mdl/executor/validate_microflow.go` (the `*ast.EnumSplitStmt` arm; `checkEnumSplitEmptyBranch`)", "insight": "Retire the assertion and replace it with what actually fails: an enum split needs an outgoing flow per condition value, so a missing branch is **CE0079**. **MDL056** checks the `(empty)` branch — universal, verified to hold even on a `not null` enum attribute, so it needs no enumeration lookup and works from the statement alone. Full value coverage (the other half of CE0079) is deliberately NOT implemented: it needs the enum's member list, i.e. resolving the split variable's type against script or project, which `ValidateMicroflow` cannot see — guessing would trade one false positive for another. **Use a NEW rule ID rather than repurposing**, so anything citing the old number still means the old, wrong thing. `MDL008` (no `else`) is correct and stays — mxbuild gives CE0079 per uncovered value **plus** CE0773 on the else flow. Fix the skill in the same change: it documented the invalid `else` form. Tests `TestValidateMicroflow_EnumSplitMultipleValuesAllowed` / `…RequiresEmptyBranch`; repro `mdl-examples/bug-tests/mdl009-enum-split-empty-branch.fail.mdl` + `-ok.mdl`", "ce": ["CE0079", "CE0773"], "rules": ["MDL008", "MDL009", "MDL056"]}
-{"area": "mdl/executor", "symptom": "A published OData service created purely from MDL passes `mxcli check` and then fails the build — `[CE0729] \"The service name should not be empty.\"` and `[CE7375] \"Attribute ID for entity 'X' must be published and be the key when associations are exposed as an associated object id.\"` — the second firing even with no associations exposed at all", "cause": "Two defaults `CREATE ODATA SERVICE` never set. (1) `Name` (the document) and `ServiceName` (the name in the OData metadata document) are different properties and only the first was set; the CONSUMED path had defaulted this for CE0339 all along. (2) `PublishAssociations` defaults to false = \"associations as an associated object id\", which Mendix only allows when the system `ID` is published as the key — but MDL's `expose (Attr (KEY))` publishes an ordinary attribute", "file": "`mdl/executor/cmd_odata.go` (`serviceName` fallback + heal on create-or-modify; `publishAssociationsFor`; `nonPersistablePublishedEntities` warning), `mdl/ast/ast_odata.go` + `mdl/visitor/visitor_odata.go` (`PublishAssociationsSet`)", "insight": "**Wider than reported**: the finding framed CE7375 as a non-persistable-entity problem. Measured on 11.12.1, the identical service with a PERSISTENT entity and a unique key builds 0 errors with `true` and CE7375 with `false` — so the default broke *every* published service, and non-persistable was just where it could not be worked around. Defaulting to true does not pick a preference; it picks the only value that can build from the MDL people write. Needs tri-state (`PublishAssociationsSet`) so an explicit `false` is still honoured, and `create or modify` no longer flips a stored value the author did not mention. **Why nothing caught it**: `mdl-examples/doctype-tests/10-odata-examples.mdl` sets both properties explicitly, so the repo's own example worked around both defaults. Tests `cmd_odata_service_name_test.go`, `cmd_odata_publish_associations_test.go`; examples `f1-10.1-…`, `f1-10.4-…`. mxcli-formula1 #10.1/#10.4", "refs": ["#10"], "ce": ["CE0339", "CE0729", "CE7375"]}
-{"area": "mdl/executor", "symptom": "`describe odata service Module.Api` emits MDL that will not parse — `ReadMode: CallMicroflow:Module.Read` matches no value, `expose (Module.Entity.Attr ...)` where the clause takes a bare member name — and quietly renames the entity set, printing the entity TYPE's exposed name in the `as '…'` position where the entity SET's belongs", "cause": "Three independent slips in one emit block. The backend stores a microflow-backed mode as `CallMicroflow:<qn>` and a member fully qualified; DESCRIBE printed the stored forms verbatim. The set/type name confusion is invisible in a single-word case and only shows when the two differ (Studio Pro's convention is singular type, plural set)", "file": "`mdl/executor/cmd_odata.go` (`odataModeToMDL`, `bareMemberName`, entity-set exposed name, `KEY` over `IsPartOfKey`)", "insight": "Storage form ≠ input form: anywhere DESCRIBE prints a value read back from the backend, ask whether the *parser* accepts that spelling — `mx check` and the linter never see DESCRIBE output, so nothing else can catch it. Proved by round trip rather than by eye: describe → check (parses) → drop → exec the output → describe again → **byte-identical**, and the rebuilt model reports 0 errors from mxbuild. Tests `cmd_odata_describe_roundtrip_test.go`. mxcli-formula1 #10.5", "refs": ["#10"]}
-{"area": "mdl/executor", "symptom": "A `create database connection … type 'Redshift'` (or `'SQLServer'`) executes, builds **0 errors**, and the connection does not work. The skill's own table listed both, and omitted the one value that matters for an unsupported driver", "cause": "mxcli passes the type string straight to BSON (`addStr(e,\"DatabaseType\",…)`) and **mxbuild does not validate it either** — verified on 11.12.1 — so nothing between the author and the runtime says the type is not real. Studio Pro's picker (read from `modeler/ide-client/database-connector-editor/`, identical on 11.10.0/11.12.1/11.13.0) is MSSQL, MySQL, Oracle, PostgreSQL, Snowflake, **BYOD** (\"Other\") — no Redshift, no SQLServer", "file": "`mdl/executor/validate_database_type.go` (`ValidateDatabaseConnectionType`, MDL-DB01), wired in `cmd/mxcli/cmd_check.go`; `.claude/skills/mendix/database-connections.md`", "insight": "**A warning, not an error**: the value set is version-specific and mxcli cannot prove a string wrong on a Mendix version it has not seen — but silence is worse when the build is green and the connection is dead. **`BYOD` is the discovery worth keeping**: it forces connection-string config and *skips the driver-presence check*, so any JDBC driver Mendix has no entry for (DuckDB, SQLite, ClickHouse) works by dropping the JAR in `userlib/`. **Generalisable**: when a doc lists enum values, the shipped Studio Pro editor bundle is the authority — grep `id:\"…\",label:\"…\"` out of `ide-client/`, and diff across cached versions to see whether the set moved. Tests `validate_database_type_test.go`. mxcli-formula1 #6", "refs": ["#6"], "rules": ["MDL-DB01"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE microflow` prints a bare `else` on a `split type` the author never wrote one for, and each describe→exec pass accumulates another", "cause": "An object-type decision always carries an `(empty)` outgoing flow (the null-object case), emitted by the builder whether or not an `else` was written. DESCRIBE rendered that flow as `else`. Invisible until the `InheritanceCase` writer landed — before that every branch degraded to `NoCase`, so nothing distinguished it from a real case", "file": "`mdl/executor/cmd_microflows_show_helpers.go` (the `elseFlow` block in the inheritance-split traversal)", "insight": "Drop the `else` line when its body renders empty — the same `elseLineIdx`/truncate pattern the if/else emitters already use. Exec re-creates the flow, so the omission is lossless and the roundtrip is stable. **Do NOT 'fix' this in the builder**: removing the empty-entity branch there fails the build with **CE0089** \"The '(empty)' value should be configured for an outgoing flow\" — that flow is load-bearing and is why `else` cannot substitute for the base entity's case (CE0090); `(empty)` and the base type cover different things. That wrong fix was implemented first and caught only because every shape was re-run through mxbuild, not because a unit test failed. Tests `TestBuilder_InheritanceSplitKeepsEmptyCaseFlow` (builder must KEEP it) and `TestTraverseFlow_InheritanceSplitOmitsEmptyElse` (describe must not print it)", "ce": ["CE0089", "CE0090"]}
-{"area": "mdl/executor", "symptom": "A published service will not build: every whole-number attribute is `[CE5016] \"Attribute … has type Integer, but is published as Edm.Int32\"`, and an exposed enumeration adds CE5016 plus `[CE4583] \"Enumeration 'X' is not published in this service.\"`", "cause": "`mendixAttrTypeToEdm` mapped Integer→Int32 (Mendix publishes it as **Int64**, same as Long), and the enum path wrote `Edm.String` while `EnumerationAsString` was hardcoded `false` — the one combination Mendix rejects, since with the flag false it wants the enumeration published as its own EDM enum type. The function's own comment flagged the unverified rows, and the existing unit test *pinned the wrong answer*", "file": "`mdl/executor/cmd_odata.go` (`mendixAttrTypeToEdm`, `enumPublishedAsString`, `publishedAttrType`), `model/types.go` (`PublishedMember.EnumerationAsString`), `mdl/backend/modelsdk/odata_write.go` + `sdk/mpr/writer_odata.go` (stop hardcoding the flag)", "insight": "**Let mxbuild adjudicate the whole table at once**: publish one attribute of every Mendix type in one service and read the CE5016s off the build. That found Integer (reported) *and* Enumeration (only suspected), and confirmed String/Long/Decimal/Boolean/DateTime were already right — five verified rows for one build. Binary turns out to be unpublishable at all (CE5013), whatever type you give it. **A type and a flag that only work as a pair must travel as a pair** — `Edm.String` is ambiguous between String and a flattened enum, so the flag is the only thing distinguishing them and it belongs on the same struct. Watch for an existing test that encodes the bug: this one asserted `Edm.Int32`, so the fix *failed the suite* until the assertion was corrected. Tests `cmd_contract_test.go`, `cmd_odata_edm_type_test.go`. mxcli-formula1 #16", "refs": ["#16"], "ce": ["CE4583", "CE5013", "CE5016"]}
-{"area": "mdl/executor", "symptom": "`create odata client` against a service behind `authentication basic` prints `Warning: could not fetch $metadata: … HTTP 401`, creates the client anyway, and the following `create external entities from …` imports nothing — from a script that reports success", "cause": "The statement's `HttpUsername`/`HttpPassword`/`HEADERS` are stored for the runtime, but the design-time fetch was a bare `client.Get`. The fetch failure is only a warning, so the empty client propagates silently", "file": "`mdl/executor/cmd_odata.go` (`metadataFetchAuth`, `metadataAuthFromStmt`, `fetchODataMetadata`), `mdl/ast/ast_odata.go` + `mdl/visitor/visitor_odata.go` (`HttpUsernameIsLiteral` / `HeaderDef.ValueIsLiteral`)", "insight": "**Only a literal is usable at design time.** The visitor strips a quoted literal's quotes, so `'f1api'` and `Module.ApiUser` both arrive as bare strings — the AST has to record which was written, or mxcli sends a *constant's name* as the password. Unresolved names are reported instead, which is also the honest answer: mxcli has no runtime to resolve a constant against. **A warning on a step something else silently depends on needs to say what breaks next** — the message now names the empty client and the import that will do nothing. Verified against a real basic-auth server that 401s without credentials and 403s without the custom header, so both had to arrive. Tests `cmd_odata_metadata_auth_test.go`. mxcli-formula1 #23", "refs": ["#23"]}
-{"area": "mdl/executor", "symptom": "Re-running `create or modify odata service` after editing a `publish entity` block changes nothing — the served `$metadata` is identical, and only `drop odata service` + create picks the edit up", "cause": "The modify branch updated the service's scalar properties and never touched `EntityTypes` / `EntitySets`", "file": "`mdl/executor/cmd_odata.go` (modify branch rebuilds published entities via `astEntityDefToModel`, and carries `AllowedModuleRoles` through)", "insight": "**Replace, don't merge**: a member removed from the script has to leave the service, which merging cannot express — the script is the description of the service. **Carry through what the statement cannot express**: role grants come from a separate `grant access on odata service` and would otherwise be dropped by a modify (reported; *not* reproduced on 11.12.1 — kept as a guard, and the commit says so rather than claiming a fix). Verified: same script yields `Label as 'label'` before and `Label as 'label' (Filterable, Sortable)` after, build stays at 0 errors. Tests `cmd_odata_modify_members_test.go`. mxcli-formula1 #26", "refs": ["#26"]}
-{"area": "mdl/executor", "symptom": "A contract property called `name` is generated as `Stg_Drivername` / `Circuitname` — prefixed with the remote type. A page written against the published `$metadata` then fails with `The selected attribute 'F1Live.Drivers.name' no longer exists`, and the *same* field carries a different name in every module because the remote type names differ", "cause": "`attrNameForOData` disambiguates any name in `reservedEntityAttrNames`, and `name` was on that list with the comment \"Mendix system-managed attribute for the object name\". It is not: Mendix builds an external entity with an attribute literally named `name`", "file": "`mdl/executor/cmd_contract.go` (`reservedEntityAttrNames` loses one entry; the import now reports the renames it does make)", "insight": "**Test the whole list at once, not the reported entry.** One contract with a property per listed name, prefixing disabled, then `mx check`: CE7247 \"The name 'x' is a reserved word\" for `id`/`owner`/`changedBy`/`changedDate`/`createdDate`/`type`/`context`, and silence for `name`. That turns \"is the list wrong?\" into \"which rows are wrong?\" for the cost of a single build, and it *earns* the seven entries that stay rather than leaving them as folklore. Two existing tests pinned the old behaviour and had to be corrected — a hand-maintained list of platform rules will accrete guesses unless each row can point at an error code. **Migration**: a re-import renames the attribute back, so references to the prefixed name must follow. Tests `cmd_contract_reserved_test.go`. mxcli-formula1 #28", "refs": ["#28"], "ce": ["CE7247"]}
-{"area": "mdl/executor", "symptom": "`create odata client` with credentials given as constants (`HttpUsername: '@Module.ApiUser'`) still gets HTTP 401 and an empty client, after the fix that made literal credentials work. Sharpened by the same release making a constant `ServiceUrl` mandatory — the shape the tool insists on is the shape whose credentials it will not read", "cause": "`resolveCredential` trusted the visitor's isLiteral flag. `'@Module.ApiUser'` **is** a STRING_LITERAL, so the flag said \"literal\" and the previous code sent the fifteen characters `@Module.ApiUser` as the username — and the unresolved-credential note did not fire either, because as far as the code knew nothing was unresolved", "file": "`mdl/executor/cmd_odata.go` (`resolveCredential`, `constantReference`, `designTimeConstants`)", "insight": "**A syntactic classification is not a semantic one.** The visitor can say \"this was a quoted string\"; only the executor can say \"this quoted string names a constant\". Any flag of the form isLiteral needs the consumer to ask what the literal *contains* before treating it as a value. **The fix is to resolve, not to refuse**: a constant's design-time default is exactly what Studio Pro sends on the same fetch, so reading it is the value rather than a workaround — and mxcli already has the project open. Three spellings must all work (`'v'`, `@M.C`, `'@M.C'`); a dotted literal like a password containing a dot must not be mistaken for a reference. Tests `cmd_odata_metadata_auth_test.go`. mxcli-formula1 #23 follow-up", "refs": ["#23"]}
-{"area": "mdl/executor", "symptom": "A `MOVE` cannot be confirmed and a module's layout cannot be reviewed: `SHOW STRUCTURE` groups by document type at every depth and never names a folder, `DESCRIBE` answers for one document at a time, so checking where things ended up means opening the `.mpr` as SQLite", "cause": "The read side of folders was simply never built. `MOVE`/`DROP FOLDER` write containment; nothing read it back", "file": "New `mdl/executor/cmd_list_folders.go` + grammar (`FOLDERS` lexer token, `showOrList FOLDERS (IN …)?` in `MDLCatalog.g4`, `FOLDERS` added to the `keyword` rule so it stays usable as an identifier), `mdl/ast/ast_query.go`, `mdl/visitor/visitor_query.go`, `mdl/executor/executor_query.go`", "insight": "**A layout listing must show what is *not* there**: empty folders (`[0]`) and documents still at the module root, or it cannot be diffed against an intended layout — that is the whole use. Documents are indexed by `ContainerID` across every list call the backend offers, each best-effort, so a backend that cannot answer one kind yields a listing missing that kind rather than no listing. **Do not stub the hierarchy in the test** — `mkHierarchy` populates `moduleNames` but not `folderNames`, so `BuildFolderPath` returns `\"\"` and every folder silently collapses into the module root, which looks exactly like the bug. Build it from the mock's `ListModules`/`ListUnits`/`ListFolders`, as `getHierarchy` does. Tests `cmd_list_folders_test.go`, example in `18-folder-examples.mdl`. mxcli-formula1 issue #2", "refs": ["#2"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE PAGE` reports a drill-down button as `linkbutton b (Caption: 'Weekend', Action: show_page Mod.Page)` — the `(Race: $currentObject)` argument is gone. The model is fine (`mx check` is clean, and an unmapped required page parameter is a consistency error, so it could not have built), but the description reads as a diagnosis mid-hunt and costs cycles fixing a button that was correct", "cause": "mxcli deliberately writes `ParameterMappings` as an empty array for a page action, because Studio Pro infers the row object from the enclosing widget and rejects an explicit `$currentObject` Argument as CE0115 (#296). That decision was right; its other half was missing. `renderClientActionMDL` read only explicit mappings, and the writer's comment *asserted* DESCRIBE recovered the implicit one — it never did", "file": "`mdl/executor/cmd_pages_describe_output.go` (`pageActionParameters`, `targetPageParameterNames`), stale comment corrected in `sdk/mpr/writer_widgets_action.go`", "insight": "**When a writer stores something implicitly, the reader owes it an explicit reconstruction — and a comment claiming the reader already does is worth nothing until a test says so.** Recover from the *target page's* declared parameters, not from the action, since that is where the information actually lives. Guard both ends: an explicit mapping still wins (recovery fills a gap, it does not override Studio Pro), and an unresolvable page yields no arguments rather than invented ones — a description that omits an argument is recoverable, one that names a parameter that does not exist is not. **A lossy DESCRIBE is costliest exactly when it is most used**, because DESCRIBE is what you reach for once you have stopped trusting the model. Tests `cmd_pages_describe_pageparams_test.go`; the control (explicit-only) reproduces the reported output verbatim. mxcli-formula1 §39", "refs": ["#296"], "ce": ["CE0115"]}
-{"area": "mdl/executor", "symptom": "A published OData resource backed by a read microflow silently returns the wrong thing: `?$top=5` yields the whole collection with a 200, and a client re-reading a held row by key gets the collection default and adopts the FIRST row as that object's identity. No error anywhere — well-formed request, valid collection, correct `$count`, 200", "cause": "Two promises the service makes on the microflow's behalf and nothing checked: the `KEY` in `expose (…)`, and the `TopSupported`/`SkipSupported` annotations (which default to **true** when unspecified). Mendix applies no query options to a read-microflow resource — it hands over the request and returns what comes back", "file": "New `mdl/executor/validate_odata_read_contract.go` (MDL-ODATA02 key promise, MDL-ODATA03 capability over-claim), wired in `cmd/mxcli/cmd_check.go`; the response contract documented in `.claude/skills/mendix/odata-data-sharing.md`", "insight": "**A read microflow cannot answer 400** — unlike an OData action or an insert/update/delete microflow, the read capability has no `System.HttpResponse` parameter ([docs](https://docs.mendix.com/refguide/published-odata-entity/#custom-http-response)). Its contract is therefore *declarative*: declaring `TopSupported: No` is the read path's only substitute for the refusal it cannot send. **Pick a trigger you can prove**: both rules fire only when the microflow takes no `System.HttpRequest` parameter, because then it provably cannot see a key or a query option; a microflow that does take it gets the benefit of the doubt, since proving *which* options it parses needs real analysis and a rule that guesses gets switched off. **Verify a check rule against a real parse, never a hand-built AST** — the visitor stores `ReadMode` as `MICROFLOW Module.Name` **upper-cased**, so a case-sensitive prefix match made the whole rule dead while it still looked right; the casing is now pinned by its own test. Tests `validate_odata_read_contract_test.go`, examples in `10-odata-examples.mdl` (both correct shapes: request-aware, and honestly declared). mxcli-formula1 §37/§20, suggested issues 2 and 3"}
-{"area": "mdl/executor", "symptom": "A published OData entity with no `KEY` fails the build with **CE6585** \"Published entity 'X' must have a key defined.\" — so any advice of the form \"drop the KEY\" is impossible to follow", "cause": "Mendix requires every published entity to have a key. MDL-ODATA02's suggestion offered \"…or drop the KEY\" as the alternative to answering a key lookup, and a doctype example demonstrated that non-existent option", "file": "`mdl/executor/validate_odata_read_contract.go` (suggestion text), `mdl-examples/doctype-tests/10-odata-examples.mdl`, `.claude/skills/mendix/odata-data-sharing.md`", "insight": "**Query options you may decline; the key you may not.** A microflow-backed resource whose rows a client can hold *must* answer the key lookup — there is no opt-out, which makes MDL-ODATA02's real remedy singular rather than a choice. **Verify the remedy a diagnostic recommends, not just the diagnosis** — the rule correctly identified an unanswerable KEY and then proposed something mxbuild rejects, which is worse than saying nothing. This is the second time in one session that a doctype example was validated with `mxcli check` (parse-only) instead of the integration gate; `mxcli check` cannot see CE-codes at all, so **any change to `mdl-examples/doctype-tests/` needs `go test -tags integration -run TestMxCheck_DoctypeScripts/<script>` before it is called done** — the two-minute run that would have caught both. mxcli-formula1 §37 follow-up", "ce": ["CE6585"]}
-{"area": "mdl/executor", "raw": "| A page written by mxcli will not open in Studio Pro, and `mx check` dies during *load* with `ArgumentNullException` at `EntityRefStep.set_AssociationId` — no page error, no CE code, the whole project is down rather than one document | An association DATASOURCE wrote the association name exactly as authored. Both halves of an `EntityRefStep` are BY_NAME and Mendix resolves either one it cannot find to null, but only `DestinationEntity` was guarded (issuetracker #14) — a bare `Order_Line` reached BSON unqualified. The **explicit-destination** form is the live trap: supplying the destination satisfies that guard, so nothing stood between a bare name and the crash — and `Assoc/Module.Entity` is exactly what the guard's error tells the author to write | `mdl/executor/cmd_pages_builder_v3.go` (`buildDataSourceV3`, `case \"association\"`: qualify via `resolveAssociationPathIn`, then verify an author-supplied destination's association exists via `associationEndpoints`) | **Guard every BY_NAME half of a ref, not the one that was reported.** #854 reported the destination; the association beside it failed identically and was reachable through the fix's own advice. **Diff the two properties in the dump** (`grep -A1 '\"Key\": \"(Association\\|DestinationEntity)\"'`) rather than reading the exception name — the loader reports whichever it touches first. **Hold the input constant across builds**: the pre-fix binary was first run with bare names and post-fix with qualified ones, which \"reproduced\" nothing; re-running the *same qualified* script on both is what isolated cross-module (`\"\"`) from same-module (resolved). `mx check` exits 0 on this failure — assert on the `contains: N errors` line, never `$?`. Tests `cmd_pages_builder_assoc_datasource_test.go`, example `mdl-examples/bug-tests/854-assoc-datasource-qualified-name.mdl`. upstream #854 follow-on |", "refs": ["#14", "#854"]}
-{"area": "mdl/executor", "symptom": "`MDL-ODATA03` (\"advertises TopSupported … so no paging is applied\") is silenced by giving the read microflow a `System.HttpRequest` parameter — even when the parameter was added for the **KEY** and no paging was implemented. The half-fixed resource, which is the one still shipping unpaged 200s, is exactly the one the rule stops warning about", "cause": "MDL-ODATA02 (KEY) and MDL-ODATA03 (paging) shared a single test — `takesHTTPRequest(decl)` — and answering either concern satisfied both. The rule could see whether the microflow *could* read the request, not whether it *did*", "file": "`mdl/executor/validate_odata_read_contract.go` (`capabilityViolations` now takes the declaration; `pagingEvidence`/`walkForPaging` reflect-walk the reachable body), `mdl-examples/doctype-tests/10-odata-examples.mdl`", "insight": "**When one input satisfies two rules, the rules will silence each other.** The tell is a shared precondition that means something different to each check — grep for other validators keyed on the same `takesX()` helper before adding one. **The wire spelling is the evidence.** An OData query option is literally named `$top`, so a microflow implementing it must contain that text; presence of the text is weak evidence of handling, absence is strong evidence against — which is the only direction a rule that reports absences needs. **Reflect-walk, do not type-switch per statement**: MDL gains activity types regularly and a walker that misses one converts a false negative into a false *positive* (\"nothing reads $top\" about a body it never looked at). Reflection also picks up new nesting — loop bodies, if-branches, error handlers — for free. **Exclude `Annotations`/`Documentation`/`Comment` fields from the walk**: an `@annotation '$top is not applied here'` is prose admitting the defect, and counting it as implementation silences the rule on the one resource that documents the bug. **Keep an escape hatch and make it outrank the evidence**: a call into a Java action, a JavaScript action, a nanoflow, or a microflow the script does not define ends the analysis with silence — same stance the rule already took toward out-of-script read microflows. Follow calls into helpers the script *does* define, since real code factors paging out. **Report per option, not per resource** — flagging `SkipSupported` while `$top` is genuinely handled avoids advising an author to withdraw working support. **Shipped examples are part of the blast radius**: the doctype example's variant (a) was written to the old rationale (\"taking `$Request` is enough to earn its silence\") and started warning the moment the rule tightened — a changed rule needs `mxcli check` over `mdl-examples/` and then the integration gate, not just its own unit tests. Each guard has its own revert control (restore benefit-of-the-doubt / drop the annotation skip / drop `opaque` / stop following helpers), and all four reproduce. Tests `mdl/executor/validate_odata_read_contract_test.go`. mxcli-formula1 §42"}
-{"area": "mdl/executor", "symptom": "`create database connection` with literal credentials succeeds, then the project will not open in Studio Pro and `mx check` dies during *load* with `StorageLoadException: ... is not a valid ConstantIdentifier` — no CE code, no document named, the whole project down rather than one unit", "cause": "`connection string` / `username` / `password` are ConstantIdentifier properties (`generated/metamodel` types all three as `model.QualifiedName`; gen binds them as `property.ByNameRef`) — BY_NAME references to a Constant document with **no literal alternative**. The grammar offers a `STRING_LITERAL` alternative anyway, and the executor passed it straight through into the ref", "file": "New `mdl/executor/validate_dbconnection.go` (`ValidateDatabaseConnection`, MDL058), wired into `cmd/mxcli/cmd_check.go` **and** `mdl/executor/cmd_dbconnection.go`", "insight": "**Refuse, do not auto-create.** Minting a Constant from the literal would be a silent side effect, and for `password` it would bake a secret into the model as a design-time default — which is the exact thing the constant indirection exists to prevent. **Wire both paths**: `check` catching it does not help a script that never ran `check` (the #833 lesson), so the exec handler runs the same rule before the write. **Report all three at once, in fixed order** — one literal per exec run is a miserable loop. **A grammar alternative is not proof a form is legal**: the literal spelling parsed, executed, and only died at load. Tests `validate_dbconnection_test.go`, negative example `mdl-examples/bug-tests/dbconn-literal-credentials.fail.mdl`. Found while verifying the #863 ExecuteDatabaseQueryAction fix", "refs": ["#833", "#863"], "rules": ["MDL058"]}
-{"area": "mdl/executor", "symptom": "`alter page … set DataSource = $Param` fails with \"unsupported DataSource type for alter page set: parameter\", while the same retype through `replace` works", "cause": "Two gaps stacked, both silent about the other path: the executor's `convertASTDataSource` had no `parameter` case, and the mutator's `serializeDataSourceBson` had no `*pages.DataViewSource` case. REPLACE works because it rebuilds the widget through the CREATE PAGE builder, which handles every type — so the capability existed all along, just not in SET", "file": "`mdl/executor/cmd_alter_page.go` (`convertASTDataSource`), `mdl/backend/pagemutator/mutator.go` (`serializeDataSourceBson`, `SetWidgetDataSource`, `lookupParameter`)", "insight": "**A parameter source has TWO by-name halves** — `EntityRef` (DirectEntityRef naming the entity) and `SourceVariable` (PageVariable naming the parameter). Mendix nulls either one it cannot find, which is the #854 unopenable-project shape, so an unknown parameter name must be refused, not written unresolved. **Resolve the entity in the mutator, not the executor**: the entity is not in the statement, and the mutator is the only layer holding the document that carries `Parameters`. **Read snippet-vs-page off the stored parameter's `$Type`** (`SnippetParameter` vs `PageParameter` key) rather than the mutator's container kind — same fact, taken from the document that must agree with it. **When a path genuinely cannot do something, name the one that can**: the bare \"unsupported\" message was half the complaint, so the remaining types now point at REPLACE. Tests `mutator_datasource_test.go`, example `mdl-examples/bug-tests/855-alter-page-set-parameter-datasource.mdl`. upstream #855", "refs": ["#854", "#855"]}
-{"area": "mdl/executor", "symptom": "A microflow expression navigating an association builds as `[CE0117] \"Error(s) in expression.\"`, with `exec` and `check --references` both silent, and the same path written fully qualified building clean", "cause": "Two independent defects in the step that inserts the association's target entity. (a) **Cross-module**: `lookupAssociation` walked only `dm.Associations`, so an association whose target is in another module (a `DomainModels$CrossAssociation`, remote end = BY_NAME `ChildRef`) never resolved and nothing was inserted — the author's short form went through unchanged. (b) **Same-module with the entity named bare**: the skip guard only fired when the next segment was already *qualified*, so `Mod.Assoc/Tag/Label` got the resolved step inserted **in addition**, yielding the four-segment `Mod.Assoc/Mod.Tag/Tag/Label`", "file": "`mdl/executor/cmd_microflows_builder_actions.go` (`lookupAssociation` gains the CrossAssociations pass), `mdl/executor/cmd_microflows_builder.go` (`resolvePathSegments` consumes a bare target-entity segment instead of duplicating it)", "insight": "**Third occurrence of the two-list trap** (#854, issuetracker #19): any code reading associations from a domain model must read `CrossAssociations` too, or every cross-module hop silently no-ops. Grep for `range dm.Associations` before assuming a lookup is complete. **Test the shape the author wrote, not just the shape you expect** — the report was only about cross-module, and the same-module-with-bare-entity case was broken in the opposite direction (over-insertion) and would have survived a cross-module-only fix. **Build a control into one project**: two microflows, short and fully-qualified, gives `1 errors` and names which one; dropping the short one and getting `0 errors` proves it. Cross-module `childPersistable` is unknowable from the local document — the remote entity is not in it — so it must not be read as a fact. Tests `cmd_microflows_assoc_path_test.go`, example `mdl-examples/bug-tests/829-cross-module-assoc-expression.mdl`. upstream #829", "refs": ["#19", "#829", "#854"], "ce": ["CE0117"]}
-{"area": "mdl/executor", "symptom": "A `SNIPPETCALL` for a snippet with parameters has no working spelling: omitting `Params:` is refused by mxcli (\"requires parameter $X\"), and supplying `params: {X: $currentObject}` is accepted and then fails the build with `[CE0115] \"The arguments that are passed to snippet … do not match the expected parameters and need to be refreshed.\"` — Studio Pro's \"Refresh snippet parameters\" then deletes what mxcli wrote", "cause": "`$currentObject` was translated into `Forms$PageVariable{PageParameter: \"currentObject\"}` — a by-name reference to a page parameter that does not exist. \"Satisfied by the enclosing data context\" is not a variable in Mendix; it is the **absence** of a mapping, which is exactly why Studio Pro emits an empty `ParameterMappings` and why its refresh removes the invented entry", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildSnippetCallParams`, `isContextArgument`)", "insight": "**Test the form the report calls \"working\" too** — passing a REAL page parameter built at 0 errors all along, which narrows the bug from \"SNIPPETCALL params are broken\" to \"`$currentObject` is not a variable\" and changes the fix entirely. **An empty list and a missing key are different models**: the fix is to emit `ParameterMappings: [3]`, not to skip the property. **Keep the refusal where it is still right** — omission is legal only when `pb.entityContext` equals the parameter's entity; a context of a different entity gets the guidance rather than a CE0115 later, so the error survives for the case it was written for. Tests `cmd_pages_snippetcall_params_test.go`, example `mdl-examples/bug-tests/868-snippetcall-context-parameter.mdl`. upstream #868", "refs": ["#868"], "ce": ["CE0115"]}
-{"area": "mdl/executor", "symptom": "`describe Module.Name` reports `no describable document named \"...\"` for a document that plainly exists and that `describe building block Module.Name` / `describe icon collection Module.Name` describes fine when the type is named explicitly", "cause": "Two lists in different packages drifted apart. Bare DESCRIBE resolves the type by looking the qualified name up in the catalog `objects` view and mapping its `ObjectType` through `objectTypeToDescribeKind`. Building blocks were built into `building_blocks_data` but never joined into the `objects` view union, so the lookup returned no row; icon collections had **no catalog table at all**, leaving the `ICON_COLLECTION` entry in the map as dead code that nothing could ever emit. Measured on a stock 7-module marketplace project: 43 of 251 documents (40 building blocks + 3 icon collections) were unreachable this way — auto-detect coverage 81%, explicit-type coverage 98%", "file": "`mdl/executor/describe_auto.go` (`objectTypeToDescribeKind`), `mdl/catalog/tables.go` (the `objects` view union + the `*_data` table), `mdl/catalog/builder.go` (`buildSimpleNamedDocs` call), `mdl/catalog/catalog.go` (the `CATALOG.*` table list)", "insight": "Add the type in **all four** places — a map entry alone does nothing if the view never emits the `ObjectType`, and a view row alone does nothing if the map has no kind. For a document with just name/folder/documentation, the builder is one `buildSimpleNamedDocs(\"<Unit$Type>\", \"<table>\", \"<Label>\")` line; get the unit `$Type` from the MPR itself (`Images$ImageCollection` vs `CustomIcons$CustomIconCollection`), not from the catalog, which only knows types it already models. **Do not measure coverage from the catalog** — the `objects` view indexes only describable types, so it reports 100% by construction; enumerate raw unit `$Type`s instead. Guard is `TestDescribeAutoCoversCatalogObjectTypes` in `mdl/executor/describe_auto_test.go`, which reads the `ObjectType` literals out of the view's own SQL and fails when one has neither a describe kind nor an entry in `notAutoDescribable`. Watch for **new ambiguity**: adding types to a name-keyed index can make a qualified name match two kinds (verified none here). Issue: marketplace-diff DESCRIBE coverage spike"}
-{"area": "mdl/executor", "symptom": "`mxcli check` reports `[MDL044] … calls 'currentDeviceType()', which is not a Mendix expression function`, `mxcli exec` writes the microflow anyway, and the build then fails `[error] [CE0117] \"Error(s) in expression.\" at Create variable activity`", "cause": "MDL044 was not in `execEnforcedMicroflowRules`, so it fired only on the `check` path — the #833 shape, one rule at a time. Promoting it was blocked by a false positive of its own: exprcheck's `funcTable` is MDL044's sole allow-list and was missing three REAL built-ins (`isNew`, `isSynced`, `isSyncing`), so a write barrier would have refused valid MDL", "file": "`mdl/executor/validate.go` (`execEnforcedMicroflowRules`), `mdl/exprcheck/func_checker.go` (`funcTable`), `mdl/exprcheck/unknown_funcs.go` (`roundingFuncs`)", "insight": "**Sweep for false positives BEFORE promoting a check-only rule** — a rule that merely reports may be wrong for years without anyone noticing, and promotion converts every one of those into a refusal. Diff the rule's allow-list against the full published function list, then **build each candidate**: `isNew`/`isSynced`/`isSyncing` came back 0 errors (genuine gaps), while `trunc` — which *looked* like a sibling of round/floor/ceil and was even listed in `roundingFuncs` — came back CE0117, so it is correctly flagged. Adding names on resemblance is how a write barrier stops catching anything. **`funcTable` also contains unverified entries** (the `dayOfYear`/`hour`/`minute` extraction family, flagged in its own comment); those are false NEGATIVES and promotion does not worsen them, but do not add more. **Prove the promotion is the cause**: build a control binary with the rule removed from the map, exec the bad script, and confirm mxbuild reports CE0117 — `check` alone rejecting it proves nothing about the exec path. Tests `validate_microflow_rules_exec_test.go`, `validate_microflow_expr_test.go`, examples `mdl-examples/bug-tests/828-unknown-expression-function.fail.mdl` + `828-object-state-functions-ok.mdl`. upstream #828", "refs": ["#828", "#833"], "ce": ["CE0117"], "rules": ["MDL044"]}
-{"area": "mdl/executor", "symptom": "A datagrid column bound to an association — `column c (attribute: Order_Customer)` — reports success from `mxcli exec` and then fails the build with `[error] [CE1613] \"The selected attribute 'Mod.Order.Order_Customer' no longer exists.\" at Columns (1/1) of data grid 2`. Separately, there is no MDL spelling for the drop-down filter's association mode: `mxcli check` says `[MDL-WIDGET01] has no property \\`refEntity\\``", "cause": "Two unrelated defects behind one report. (1) The reference is **not representable**: `CustomWidgets$WidgetValue.AttributeRef` is typed `AttributeRef`, not the polymorphic `MemberRef`, so the association was qualified like an attribute and written as a dangling `AttributeRef`. (2) `dropdownfilter.def.json` mapped only `attrChoice`/`attributes`/`defaultFilter`, so every `baseType: 'ref'` property was unmapped and dropped", "file": "`mdl/executor/cmd_pages_builder_input.go` (`rejectAssociationAsAttribute`, `entityInChain`) wired into `mdl/executor/widget_engine.go` (the objectlist `attribute` case and the `Attribute` source); `sdk/widgets/definitions/dropdownfilter.def.json` (association mode); `mdl/executor/cmd_pages_describe_parse.go` + `_pluggable.go` + `_output.go` (round-trip)", "insight": "**Establish that a shape is unrepresentable before designing a fix for it** — hand-patch the BSON and run `mx check`. A `DomainModels$AssociationRef` in that slot makes the project **UNLOADABLE** (`ArgumentException: Object of type 'AssociationRef' cannot be converted to type 'AttributeRef'`), and the assembly defining the type (`Mendix.Modeler.WebUI.dll`) has no `AssociationRef` member at all — so the only correct outcome is a refusal carrying both working forms. **`<associationTypes>` on an ATTRIBUTE-typed widget property is permission to TRAVERSE a reference, not to bind one** — `attribute: Assoc/Attr` already worked and is what the XML is advertising; the DataGrid column is the only shipped widget where the two are easy to confuse. **A def.json `mode` is the whole feature** for an unauthorable widget mode — the engine already had the `association` operation and the `hasDataSource` condition, so the second half was a data change plus its DESCRIBE reader (without which describe→edit→exec silently reverts the filter to attribute mode). **0 errors from `mx check` does not prove the properties landed** — an unmapped property is silently dropped and the build is just as green; read them back with `mx dump-mpr`. Tests `cmd_pages_builder_assoc_as_attribute_test.go`, `widget_dropdownfilter_assoc_test.go`, example `mdl-examples/bug-tests/830-datagrid-association-filter.mdl`. upstream #830", "refs": ["#830"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "A microflow call bound to a task queue in Studio Pro loses that binding on `create or replace microflow` — silently, and `mx check` goes from `[CE1613] \"The selected task queue no longer exists\"` to **0 errors**, because the configuration the error was about has been deleted", "cause": "Two defects behind one report. (1) `Microflows$MicroflowCall` has `QueueSettings` in `NullFields` of `codec.RegisterTypeDefaults` (and the legacy writer hardcodes null too) — correct for a newly authored call, destructive for a stored one, and since a CREATE OR REPLACE rebuilds the whole microflow it fires on every rewrite. (2) MDL had **no queue surface at all**, so a script could not restate the binding even in principle", "file": "`mdl/executor/validate_queued_calls.go` (new: the refusal), `mdl/executor/cmd_microflows_create.go` (call site), `mdl/types/queue.go` + `mdl/backend/infrastructure.go` (`QueueBackend`), `mdl/backend/modelsdk/queue_write.go` + `sdk/mpr/queues.go` (both engines), `mdl/grammar/domains/MDLDomainModel.g4` + `MDLCatalog.g4`, `mdl/executor/cmd_queues.go`", "insight": "**A green build can be the bug**: the fix made `mx check` report MORE errors than before (CE1613 came back), because the binding it complains about now survives. Any \"error count went down\" check would have scored the data loss as a fix. **`describe` showing nothing is not evidence of nothing** — the binding was invisible from every angle (describe omitted it, check went quiet, the write reported success), which is why it needed a stored-BSON probe: inject `Queue`+`QueueSettings` into a stored call, rewrite, and dump. **Isolate which property Mendix acts on before guarding on it**: a call carrying only `Queue` (with `QueueSettings` null) draws NO complaint from `mx check` — `QueueSettings` is the load-bearing one, so a guard keyed on `Queue` alone would have both missed the real case and fired on inert ones. **Get the BSON shape from a Mendix-authored model, not from the metamodel**: `mxcli marketplace download 202649` (Business Events 3.12.1) has four real queues, and all four agree — `Config` is a `Queues$BasicQueueConfig` whose `ParallelismExpression` is a **STRING**, with the sibling int32 `Parallelism` absent in every one. Writing the int (which the metamodel makes look equally valid) is inventing a property Mendix does not write. **Refuse, do not half-author** (ADR-0005): `in queue` on a call is deliberately still unimplemented, because the `Retry` shape has no Studio-Pro-authored sample to diff against, and guessing it would put a second unverified shape into user projects. **Adding a keyword costs an identifier** — `QUEUE`/`QUEUES` had to go into the `keyword` rule or `queue` would have stopped working as an attribute name. Tests `mdl/backend/modelsdk/queue_write_test.go`, `mdl/executor/validate_queued_calls_test.go`, `mdl/executor/cmd_queues_mock_test.go`, `mdl/visitor/visitor_queue_test.go`, example `mdl-examples/bug-tests/queue-authoring-and-rewrite-guard.mdl`", "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "`GRANT <role> ON Module.Specialization (READ (…, SomeAssociation))` is refused with \"entity X has no member(s) SomeAssociation; grant only names members of the entity or of an entity it inherits from\" — when the association *is* declared on an entity it inherits from", "cause": "The member walk resolved inherited **attributes** through the generalization chain (#758) but collected associations only from the entity's own domain model where `ParentID == entity.ID`. An association declared on an ancestor was therefore invisible, which made the rule OpenAIConnector ships impossible to express in MDL (`OpenAIDeployedModel extends GenAICommons.DeployedModel`)", "file": "`mdl/executor/cmd_security_write.go` (`inheritedAssociations`, `domainModelHasEntity`)", "insight": "**Find the declaring domain model by looking for the entity, not by matching module names** — the module-name lookup goes through the hierarchy cache and returns \"\" often enough that filtering on it silently collected nothing; the first cut of this fix looked right and did nothing. **Qualify the ref against the module that DECLARES the association**, as the attribute walk does. **Test that an unrelated entity does not get the entry** — a walk collecting every association in the module passes the positive tests and puts entries exactly where Mendix reports CE0066 for having them. Tests `mdl/executor/cmd_security_inherited_assoc_test.go`; the mock needs `GetModuleByNameFunc`, without which even own attributes fail to resolve. Reported in mxcli-chat FINDINGS §26. (The emitted entry then did not reach storage; that half is the FINDINGS §25 row below.)", "refs": ["#758"], "ce": ["CE0066"]}
-{"area": "mdl/executor", "symptom": "`mxcli check --references` reports \"java action not found: M.X (referenced by call java action)\" for an action the **same script** creates a few statements earlier. Entities, microflows, pages and nanoflows in the same position are accepted", "cause": "`scriptContext` — the set of objects a script defines, consulted so a script can be checked against its own output — had categories for modules, entities, enumerations, microflows, nanoflows, pages and snippets, but not for java or JavaScript actions. The java-action branch of `validateFlowBodyReferences` went straight to the project lookup", "file": "`mdl/executor/validate.go` (`scriptContext.javaActions`/`javaScriptActions`, `collectDefinitions`, `collectSingle`, `allNames`, `has`, `validateFlowBodyReferences`)", "insight": "**Store the declared parameter names, not a bool.** Exempting the action from \"not found\" must not also exempt it from the parameter-name check — the script declares the parameters, so a typo is still catchable, and a bool would have silently dropped that. **`allNames()` and `has()` move together**: `annotateForwardRef` reads both, so adding a category to one and not the other makes a *created* object look \"defined later in this script\" forever. Tests `mdl/executor/validate_script_javaactions_test.go` (including the control that a misspelled parameter still errors). Reported in mxcli-chat FINDINGS §37"}
-{"area": "mdl/executor", "raw": "| `CREATE IMPORT MAPPING` is reported to \"not preserve JSON member names\": `total` becomes `Total`, `camelCase` becomes `CamelCase`, `__Value` becomes `__ValueItem`. The import then fails at runtime with `key not found: Path(QName(None,),None,)` at `MappingCache.storeValueMappingElement` | The capitalisation is **Mendix's own** and not the defect. A `JsonStructures$JsonElement` stores TWO names — `Path` (the raw JSON key, `(Object)\\|uuid`, which the RUNTIME resolves by) and `ExposedName` (derived by capitalising the initial, and suffixing `Item` on an array's item object, which Studio Pro DISPLAYS). The real defect: mxcli's DESCRIBE emits `ExposedName` while its builder resolved only raw keys, so mxcli's own output did not round-trip — re-executing a DESCRIBE FABRICATED a path (`(Object)\\|Total`; for arrays the `\\|(Object)` item marker vanished entirely, leaving `(Object)\\|EntityInstances\\|__ValueItem`) and zeroed MaxOccurs. Export mappings had the identical bug. Separately, mxcli wrote `IsDefaultType` on every `ValueMappingElement` (a property only the OBJECT element types own) and cloned the JSON structure's `OriginalValue` — the SAMPLE value from the snippet — onto every mapping element, where Studio Pro leaves it empty | `mdl/executor/cmd_import_mappings.go` (`jsonSchemaIndex`, `newJSONSchemaIndex`, `resolve`, `memberNames`; `buildImportMappingElementModel` now returns an error), `mdl/executor/cmd_export_mappings.go` (same), `mdl/backend/modelsdk/mapping_write.go` + `sdk/mpr/writer_import_mapping.go` + `sdk/mpr/writer_export_mapping.go` (drop `IsDefaultType` from the value writers); `cmd_import_mappings.go` again for the `OriginalValue` clone | **A blank Mendix app is a free Studio-Pro-authored fixture** — `FeedbackModule.IMM_PostResponse` + `JSON_AppInsightsResponse` settle \"what does Studio Pro actually write?\" with no Studio Pro and no marketplace download: they store `ExposedName \"Uuid\"` against `Path \"(Object)|uuid\"`. Author the SAME mapping over the SAME structure in the SAME module with mxcli and diff the two units — the only variable left is which tool wrote it. **Run the reporter's repro as written before believing the diagnosis**: theirs produced paths byte-identical to the structure's, so their MDL was not the failing input; the corruption needed a DESCRIBE in the middle. **DESCRIBE emitting a different name than the parser accepts is a round-trip bug even when both are \"correct\"** — the fix is to accept BOTH spellings, not to change what DESCRIBE prints, because the exposed name is the one Studio Pro shows. **Never fabricate a path for an unresolved member**: the invented path passed `mxcli check` and surfaced only in mxbuild (CE5015) or at runtime, so the tool that wrote it reported success — refuse, and list the spellings that would have worked. **`generated/metamodel` decides property ownership**: `isDefaultType` is declared on `Import/ExportObjectMappingElement` and on neither `ValueMappingElement`, and per CLAUDE.md's overlay rule an extra property is the shape mxbuild tolerates and Studio Pro will not open — so a green build proves nothing here. **Count the samples before calling a difference a defect**: two Studio-Pro-authored mappings in a blank app (~15 value elements) all write `OriginalValue: \"\"` while their structures carry 17 non-empty samples, which is what makes \"the sample belongs to the structure\" a measurement rather than an opinion. **Running the reporter's repro is how you find out it is not a reproduction**: theirs PASSED at runtime on 11.6.6 and 11.13.0, so the runtime error they see needs something their standalone file does not carry — say so instead of claiming the fix. And **control the harness before believing its failure**: an early runtime run failed until the control (Studio Pro's own mapping, same harness) failed identically, which located the fault in the test's missing module-role grants, not in the mapping. Tests `mdl/executor/cmd_mappings_member_resolution_test.go`, `mdl/backend/modelsdk/mapping_isdefaulttype_test.go`, example `mdl-examples/bug-tests/882-mapping-member-names.mdl`. upstream #882 |", "refs": ["#882"], "ce": ["CE5015"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE PAGE` output will not re-parse for any page carrying a **pluggable widget**: `mxcli check` on it fails with `extraneous input ':'` / `extraneous input '('` from the first widget onward. Separately, a boolean property the author set is missing from the description entirely", "cause": "Two independent defects in the same path. **Emit**: explicit properties were written with a raw `%s`, so every string lost its quotes — a JSON `spec: {\"a\": 1}` then broke the parse at its first brace. **Read**: `extractExplicitProperties` skipped any value of `\"true\"`/`\"false\"` as a \"common default\", so booleans never reached the output", "file": "`mdl/executor/cmd_pages_describe_output.go` (`explicitPropValue`, `isBareLiteral`), `mdl/executor/cmd_pages_describe_pluggable.go` (`buildPropertyValueTypeMap`, `extractExplicitProperties`), `mdl/executor/cmd_pages_describe.go` (`rawExplicitProp.ValueType`)", "insight": "**Fixing one half alone is worse than the bug.** Quote without emitting booleans and the description re-parses cleanly while silently dropping a property — a wrong page that validates. Both halves ship together or neither. **Quote by the DECLARED type, never the value's shape**: `ValueType.Type` sits in the widget's `Type.ObjectType.PropertyTypes`, the same array `buildPropertyTypeKeyMap` already walks for `PropertyKey` and throws away; a String property holding `\"30\"` or `\"true\"` is indistinguishable from a number once it is a string in BSON, and must still come back quoted. Where no type is declared, fall back to the value's shape and quote anything not plainly numeric or boolean — quoting is the safe direction, since an unquoted arbitrary string may not parse at all. **The round trip is the test, not the output**: describe → `check` → `exec` → describe must be byte-identical and leave `mx check` at 0 errors. Tests `mdl/executor/cmd_pages_describe_pluggable_roundtrip_test.go`; example `mdl-examples/bug-tests/pluggable-describe-roundtrip.mdl`, verified end to end on 11.12.1. **Uncovered while verifying, NOT fixed**: giving a property in a conditionally shown group a non-default value writes a widget Mendix rejects with CE0463 — ProgressCircle's `showLabel: true` and `labelType: 'percentage'` both do it with no DESCRIBE involved, while the same widget's General-group properties take non-default values happily. Reported in mxcli-ledger FINDINGS #104", "refs": ["#104"], "ce": ["CE0463"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE PAGE` output will not re-parse for any page carrying a **pluggable widget**: `mxcli check` on it fails with `extraneous input ':'` / `extraneous input '('` from the first widget onward. Separately, a boolean property the author set is missing from the description entirely", "cause": "Two independent defects in the same path. **Emit**: explicit properties were written with a raw `%s`, so every string lost its quotes — a JSON `spec: {\"a\": 1}` then broke the parse at its first brace. **Read**: `extractExplicitProperties` skipped any value of `\"true\"`/`\"false\"` as a \"common default\", so booleans never reached the output", "file": "`mdl/executor/cmd_pages_describe_output.go` (`explicitPropValue`, `isBareLiteral`), `mdl/executor/cmd_pages_describe_pluggable.go` (`buildPropertyValueTypeMap`, `extractExplicitProperties`), `mdl/executor/cmd_pages_describe.go` (`rawExplicitProp.ValueType`)", "insight": "**Fixing one half alone is worse than the bug.** Quote without emitting booleans and the description re-parses cleanly while silently dropping a property — a wrong page that validates. Both halves ship together or neither. **Quote by the DECLARED type, never the value's shape**: `ValueType.Type` sits in the widget's `Type.ObjectType.PropertyTypes`, the same array `buildPropertyTypeKeyMap` already walks for `PropertyKey` and throws away; a String property holding `\"30\"` or `\"true\"` is indistinguishable from a number once it is a string in BSON, and must still come back quoted. Where no type is declared, fall back to the value's shape and quote anything not plainly numeric or boolean — quoting is the safe direction, since an unquoted arbitrary string may not parse at all. **The round trip is the test, not the output**: describe → `check` → `exec` → describe must be byte-identical and leave `mx check` at 0 errors. Tests `mdl/executor/cmd_pages_describe_pluggable_roundtrip_test.go`; example `mdl-examples/bug-tests/pluggable-describe-roundtrip.mdl`, verified end to end on 11.12.1. Reported in mxcli-ledger FINDINGS #104", "refs": ["#104"]}
-{"area": "mdl/executor", "symptom": "`DROP FOLDER 'x' IN Module` reports success, then Studio Pro / `mx check` fails **CE1613** \"The selected import mapping 'Module.X' no longer exists\" for documents that are still in the project. `LIST FOLDERS` had shown that folder as `[0]`", "cause": "Two halves of one blind spot. (a) `execDropFolder`'s doc comment claimed \"the folder must be empty\" but **nothing checked** — it called `DeleteFolder` unconditionally, and the children were left pointing at a container that no longer existed. Nothing is *deleted*: every document is **orphaned**, losing its module qualification (`FeedbackModule.IMM_PostResponse` → `.IMM_PostResponse`), so it survives as a unit that nothing can resolve. (b) `documentsByContainer` is a hand-maintained list of twelve document kinds; JSON structures, import/export mappings, regular expressions and image collections were missing, so the folder rendered `[0]` — which is what made the drop look safe", "file": "`mdl/executor/cmd_folders.go` (`execDropFolder`, `folderContentSummary`), `mdl/executor/cmd_list_folders.go` (`documentsByContainer`)", "insight": "Guard on **`ctx.Backend.ListUnits()`**, never on the per-kind lists — `ListUnits` is type-agnostic, so it cannot inherit the blind spot that caused the bug, whereas a guard built on `documentsByContainer` would wave through exactly the kinds it forgets. Folders are units too (`Projects$Folder`), so one containment scan covers documents *and* sub-folders. **Fail closed**: if `ListUnits` errors, refuse — for a destructive op \"I could not check\" must never mean \"go ahead\". Note the mock's `ListUnits` defaults to `nil, nil` rather than an error, so a test that forgets to stub it sees an empty project and the guard silently passes; stub it explicitly. Separately add the missing kinds to `documentsByContainer` so the count stops lying. Repro `mdl-examples/bug-tests/892-drop-folder-not-empty.fail.mdl`. Issue #892", "refs": ["#892"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE PAGE` renders an **Accordion group** (or any pluggable widget's object-list item) **empty** — the group's own properties print, its nested widgets do not — so a describe→exec round-trip silently DELETES whatever was inside", "cause": "An object-list item can carry child widgets in a **Widgets-typed sub-property** (the group's `content` / `headerContent` slot). `extractObjectListItem` handled only scalar sub-properties (datasource, attribute, expression, text template, primitive) and fell through on everything else, so children were never read; and the emitter always closed an item with `\"\\n\"`, so they had nowhere to go even once read. Both halves must change — reading without emitting still prints an empty group", "file": "`mdl/executor/cmd_pages_describe_objectlist.go` (`rawObjectListItem.Children`, `extractObjectListItem`), `mdl/executor/cmd_pages_describe_output.go` (the object-list item loop)", "insight": "Parse a `Widgets` array with `parseRawWidget` — the same recursion the rest of DESCRIBE uses — and emit the item with a `{ … }` body, recursing through `outputWidgetMDLV3` so nesting and indentation stay consistent. Also relax the \"keep this item\" test to include `len(item.Children) > 0`, or a group whose only content is widgets is dropped wholesale. **The Accordion ships in every blank app** (`widgets/com.mendix.widget.web.Accordion.mpk`) — do not conclude it needs a marketplace install because `modelsdk/widgets/definitions/` has no `accordion.def.json`; that is mxcli's *bundled* registry, while project widgets are discovered from the MPK into `.mxcli/widgets/`. Author one with `PLUGGABLEWIDGET 'com.mendix.widget.web.accordion.Accordion'` (`ACCORDION` is the catalog's MdlName but not a parser keyword). Repro `mdl-examples/bug-tests/891-accordion-group-nested-widgets.mdl`. Issue #891", "refs": ["#891"]}
-{"area": "mdl/executor", "symptom": "A DataGrid 2 column named in MDL (`column colLabel (...)`) cannot be addressed by that name: `ALTER PAGE … ON dg1.colLabel` says not found, and `describe page` shows a name the author never wrote", "cause": "Working as designed and undiscoverable. Mendix stores no name on a pluggable DataGrid 2 column — the schema has no name key, and `backend.DataGridColumnSpec` has no field for one — so the MDL name is dropped and everything downstream uses a derived name (bound attribute → sanitized caption → `colN`)", "file": "`mdl/executor/validate_widgets.go` (`validateDataGrid2ColumnName`, `derivedDataGrid2ColumnName`)", "insight": "Warn at authoring time (MDL-WIDGET16) naming the addressable name, instead of leaving the author to discover it from a failed ALTER. **Warn, not reject**: the name reads as documentation in the source and rejecting it would break every existing script — mxcli's own doctype tests name every column. Stay silent when the derivation cannot be known (no attribute, no caption → `colN`, which depends on position), because naming the wrong one is worse than naming none. Note this is specific to the **pluggable** DataGrid 2; legacy `Forms$DataGridColumn` does store a Name"}
-{"area": "mdl/executor", "symptom": "Four MDL scripts pass `mxcli check` with 0 errors and execute cleanly; `mx check` then reports CE0156 (user role cannot sign in) and CE5601 (page URL missing a parameter segment)", "cause": "Both are decidable from the MDL alone and neither had a rule. A user role built only from application module roles has no System module role, so nobody holding it can sign in or read System entities; a page with parameters and a `Url` needs a `{Name}` segment per parameter or Mendix cannot bind it", "file": "`mdl/executor/validate_role_and_url.go` (new — `ValidateUserRoleSystemModuleRole` MDL-SEC20, `ValidatePageURLParameters` MDL-PAGE20, `urlBindsParameter`), `mdl/executor/validate_program.go` (wiring)", "insight": "Add both as model-free rules so `check` catches them without a project. **The URL matcher is the subtle half**: Mendix binds a parameter by an attribute path, so `url: 'p006/{Customer/Name}'` is the ordinary shape and an exact `{Customer}` match would flag correct pages — match the segment's leading identifier instead. Verified against mxcli's own page examples at 0 false positives, which is the control that matters for a new rule. **MDL-SEC20 shipped too strict and CI caught it**: `make check-mdl` runs `mxcli check` over every example, and an error-severity rule broke two of them. Measured against mxbuild 11.13 rather than argued about — CE0156 fires at security level Prototype and **not at all** at Off, which a blank project ships, so the rule warns by default and is an error only when the script itself enables security. CE5601 fires either way, so MDL-PAGE20 stays an error and the one example it flagged was genuinely broken (fixed). **Generalisable**: `make test` is not the CI gate — `make check-mdl` runs the rules against real scripts, which is exactly where a new rule's false-positive rate shows up. Run it before shipping a rule. A role declared with no module roles at all is left alone: that is a placeholder for ALTER USER ROLE, not a missing System role. mxcli-dbreplication F10", "ce": ["CE0156", "CE5601"], "rules": ["MDL-SEC20"]}
-{"area": "mdl/executor", "symptom": "`MDL-WIDGET16` fires 44 times on one project, once per DataGrid 2 column, all saying the same thing", "cause": "The rule was written per column when the fact — this grid stores no column names — belongs to the grid. Correct but chatty enough to bury the rest of the report", "file": "`mdl/executor/validate_widgets.go` (`validateDataGrid2ColumnNames`, now called per widget rather than per object-list item)", "insight": "Emit one violation per grid listing each `written → addressable` mapping. **Generalisable**: an advisory rule's unit should be the thing the advice is about, not the thing that triggered it — N identical infos train the reader to skip the category. Feedback on a rule shipped days earlier, from the project using it. mxcli-dbreplication F6"}
-{"area": "mdl/executor", "symptom": "`combobox cb (Association: …, Caption: Name)` passes `mxcli check`, executes, and the caption is **gone** — `describe page` does not show it and the build fails `CE0642 \"Property 'Caption' is required.\"` The reporter concluded the association combo box was unusable and redesigned the UI around it", "cause": "`Caption` is in `isBuiltinPropName`'s universal allow-list, so MDL-WIDGET01 never questions it on a widget the engine has no route for — while `OptionCaption` *is* correctly rejected. The working spelling is `CaptionAttribute:`, which round-trips cleanly, so the feature was never broken: the author was one property name away with nothing to tell them", "file": "`mdl/executor/validate_widgets.go` (`builtinPropertyMisuse`, `misusedBuiltinProperty`, rule MDL-WIDGET17)", "insight": "Flag the builtin names that are wrong on a specific widget and name the one that works. Deliberately an **explicit list**, not inference: whether a builtin is routed lives in the engine's dispatch, not the .def.json (the combobox def declares `optionsSourceAssociationCaption{Type,Expression}` and nothing called `Caption`), so inferring it would mean reimplementing that dispatch and getting it wrong the other way — the universal allow-list exists precisely to stop false positives on `Label:`/`Class:`. **Generalisable**: a permissive allow-list added to prevent false positives converts every unrouted name into a silent drop; the cost is invisible until a build error names a property the author did write. mxcli-owid #38", "refs": ["#38"], "ce": ["CE0642"]}
-{"area": "mdl/executor", "symptom": "CE7375 \"must be published and be the key when associations are exposed as an associated object id\" on a service publishing no associations", "cause": "`PublishAssociations` is the representation, not a yes/no — `No` selects \"as an associated object id\", which needs the system ID as key", "file": "`mdl/executor/validate_odata_service_shape.go`", "insight": "Set `PublishAssociations: Yes` (\"as a link\", and the default when omitted). MDL-ODATA06 warns at check time", "ce": ["CE7375"]}
-{"area": "mdl/executor", "symptom": "`mx check` exits with `System.ArgumentOutOfRangeException: length ('-1')` and no error code", "cause": "an OData service `Path` with no slash in it; mxbuild throws out of its own validator", "file": "`mdl/executor/validate_odata_service_shape.go`", "insight": "Path must not start with `/` and must end with one (CE6550/CE6552). MDL-ODATA05 catches all three", "ce": ["CE6550", "CE6552"]}
-{"area": "mdl/executor", "symptom": "`alter entity Mod.Ent rename attribute Old to New;` reports success, and `mx check` then fails the app with one **CE1613 \"The selected attribute 'Mod.Ent.Old' no longer exists.\"** per create/change activity member, page attribute widget, validation rule and access rule that named it. Studio Pro still opens the project, so nothing looks wrong until a build", "cause": "The handler renamed the attribute inside the domain model and stopped. Everywhere else Mendix stores an attribute reference it stores the **fully qualified name as a string**, so none of them followed. `mxcli rename` already had the project-wide scanner (entity, enumeration, association, module, microflow, page, constant, java action) — attributes were the one kind never wired to it", "file": "`mdl/executor/cmd_entities.go` (`ast.AlterEntityRenameAttribute`), `mdl/executor/alter_entity_rename_attribute_test.go`", "insight": "Call `ctx.Backend.RenameReferences(Mod.Ent.Old → Mod.Ent.New, false)` and report the count. **Order is load-bearing: scan AFTER `UpdateEntity`, never before.** The scan is a raw-BSON pass over every unit *including the domain model*, while `UpdateEntity` re-serializes the whole domain model from the parsed entity — so scanning first hands the model write the last word and silently undoes the scan's edits inside the domain model, which is exactly where a validation rule's `Attribute` string and a `MemberAccess.Attribute` live. `execRenameEntity` gets away with the opposite order only because entity refs *within* the domain model are binary pointers, not strings. Also added the missing collision guard (renaming onto an existing attribute name made two attributes no reference could tell apart). **Scope, stated rather than hidden**: uses inside expressions (`$obj/Attr`) and XPath constraints (`[Attr = ...]`) are free text where a bare name is only resolvable from the type of what precedes it — they are NOT rewritten, mxbuild reports them as CE0117 / CE0161, and the command now says so instead of reading as complete. Controls on Mendix 11.13.0 with `mdl-examples/bug-tests/910-rename-attribute-updates-references.mdl`: pre-fix build 3 errors, post-fix 0. mendixlabs/mxcli#910 (problem 2)", "refs": ["mendixlabs/mxcli#910"], "ce": ["CE0117", "CE0161", "CE1613"]}
-{"area": "mdl/executor", "symptom": "`ALTER ENTITY … MODIFY ATTRIBUTE X SET DEFAULT <v>` (or any unrecognised word in the type position, including a typo like `Integr`) silently retypes the attribute to `Enumeration(<word>)`, and the project then **cannot be loaded at all** — `mx check` dies before validating with `System.ArgumentNullException: Value cannot be null. (Parameter 'value') at EnumerationAttributeType.set_EnumerationId`", "cause": "`MODIFY ATTRIBUTE` requires a `dataType`, whose last grammar alternative is a bare `qualifiedName` (entity reference), so any word matches and the visitor maps it to `TypeEnumeration`. The executor wrote it with no enumeration behind it. CREATE ENTITY had guarded this since #552; the guard was **inline in the create handler** and never applied to MODIFY", "file": "`mdl/executor/attribute_type_ref.go` (new), `mdl/executor/cmd_entities.go` (`AlterEntityModifyAttribute` case)", "insight": "Extract the create-path guard to `validateAttributeTypeRef` and call it from the modify path **before** mutating the attribute. Add `DROP DEFAULT ON ATTRIBUTE <name>` so clearing a default has a spelling that does not go through the type slot, and point the refusal at it. Check `mxcli syntax` too: the topic documented `MODIFY ATTRIBUTE AttrName SET DEFAULT val` — the corrupting form — which is how the reporter got there. When a guard is added inline to one handler, grep for sibling handlers that take the same input. mendixlabs/mxcli#910", "refs": ["#552", "mendixlabs/mxcli#910"]}
-{"area": "mdl/executor", "symptom": "An `OnChange:` on a `checkbox`, `radiobuttons`, `combobox`, `dropdown`, `textarea` or `datepicker` does nothing. The MDL parses, `mxcli check` passes, `exec` reports success, and `describe page` shows the widget with its Label + Attribute and **no OnChange**. In the browser the control changes state and issues **zero `/xas/` requests** — no server round-trip at all. `textbox` and `actionbutton` keep their actions, so it reads as a page problem rather than a per-widget one", "cause": "Three independent drops, any one of which is sufficient: (1) the page builder read `w.GetOnChange()` in `buildTextBoxV3` **only**, so the property died between AST and model for the other five; (2) the legacy writer hardcoded `serializeClientAction(nil)` for TextArea/DatePicker/CheckBox/RadioButtons/DropDown; (3) for pluggable widgets `actionSourceForKey` matched only the bare keys `onClick`/`onChange`, but Mendix's Combobox names its slot **`onChangeEvent`**, so no action mapping was emitted — and the shipped `combobox.def.json`, which **overrides any .mpk-derived def**, had none either", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`applyOnChangeV3`), `sdk/mpr/writer_widgets_input.go`, `mdl/executor/widget_defs.go` (`actionSourceForKey`), `sdk/widgets/definitions/combobox.def.json` + `modelsdk/widgets/definitions/combobox.def.json`, `mdl/executor/cmd_pages_describe_parse.go` + `_output.go`", "insight": "Route every input widget's OnChange through one helper rather than repeating the block, so the next widget added cannot forget it. Strip **one** `Event`/`Action` suffix before matching an action slot — narrowly: a Combobox also carries `onChangeFilterInputEvent` and `onChangeDatabaseEvent`, which have no MDL surface and must stay unmapped or one `OnChange:` writes three actions. A hand-written built-in `.def.json` beats the generator, so fixing the generator alone changes nothing for COMBOBOX/GALLERY/DATAGRID/filters — patch both, and put the mapping in **every** mode (modes are exclusive). Wire DESCRIBE at the same time: DESCRIBE is how a dropped property gets *found*, and it could only see this one on `textbox`. `dropdown` has no DESCRIBE case at all (separate gap). Repro `mdl-examples/bug-tests/widget-onchange-dropped.mdl`. **Sequel caught by CI:** mapping a slot also makes its storage key pass `allowedWidgetProperties`, so `onChangeEvent: …` became an accepted MDL keyword that `resolveMapping` never reads — the same silent drop one layer up. An `action` mapping is authorable by its **Source** only (`OnChange`/`OnClick`/`Action`), never by its PropertyKey; `addMappingNames` enforces that and `actionStorageKeys` reports the storage key with the spelling that works. FINDINGS #14", "refs": ["#14"]}
-{"area": "mdl/executor", "symptom": "`mxcli exec` applies a script that `mxcli check` rejects with an error — e.g. a page written with an invalid widget property, which is then silently dropped, so the widget renders but does nothing", "cause": "`exec` ran no semantic checks at all. Parse errors stopped it; the ~24 `Validate*` checks lived inline in `cmd/mxcli/cmd_check.go` and had exactly one caller. \"Run check before exec\" was a convention nothing enforced, on a tool built for unattended agent use", "file": "`mdl/executor/validate_program.go` (the shared list), `cmd/mxcli/cmd_exec.go` (the gate), `cmd/mxcli/cmd_check.go`", "insight": "`executor.ValidateProgram` is now the single definition of what `check` checks, and `exec` refuses to run when it reports an **error** (warnings print and do not block). `--no-check` opts out. **A check wired into nothing is invisible** — it reports no violations and reads as a clean project — so `TestValidateProgram_WiresEveryWholeProgramValidator` asserts structurally that every exported `Validate*(prog *ast.Program, …)` is called from `ValidateProgram`; per-statement helpers take a statement and are excluded. When adding a check, add it to `ValidateProgram` and both commands get it"}
-{"area": "mdl/executor", "symptom": "`mxcli check` reports **MDL003** *\"microflow returns X but not all code paths have a return statement\"* on a microflow that is correct and builds cleanly. Since `exec` began refusing scripts whose checks report an error, the script also will not run without `--no-check` — so a false positive became a hard block. Seven shipped `mdl-examples` scripts were in this state", "cause": "The microflow uses the documented `RETURNS T AS $Var` form and assigns `$Var` instead of writing an explicit `RETURN`. `buildFlowGraph` sets the final EndEvent's `ReturnValue` to `\"$\"+Var` **whenever the AS clause is present** (`cmd_microflows_builder_graph.go`), so the return is synthesized either way — that is what the clause is for. The check demanded a `RETURN` statement in the source on top of it", "file": "`mdl/executor/validate_microflow.go` (Check 5 in `microflowValidator.validate`)", "insight": "Skip MDL003 when `returnType.Variable != \"\"`, mirroring the builder's own condition exactly rather than inventing a second rule. **Verify against mxbuild, not intuition**: the flagged microflow builds with **0 errors** on 11.13.0, `describe microflow` renders the synthesized `return $Found;`, and the stored EndEvent carries a `ReturnValue` — three independent confirmations the check was wrong, not the script. Keep a companion test for the no-AS-clause case, or a fix that simply disables the rule passes. **Sweeping examples as a control**: exclude `*.test.mdl` (those are `mxcli test` files with `@test`/`@expect` blocks, unparseable by `check` by design) and `*.fail.mdl`, and diff failure SETS rather than counts", "rules": ["MDL003"]}
-{"area": "mdl/executor", "raw": "| A guard that walks a stored BSON document works on the **modelsdk** engine and is a **silent no-op on legacy** (or vice versa) — same project, same document, opposite behaviour. Here `checkNoQueuedCalls` refused a rewrite that would drop a task-queue binding under modelsdk, and let it through under `--engine legacy`, destroying the binding exactly as the guard existed to prevent | The two readers return **different Go shapes for the same BSON**: `modelsdk` yields `[]interface{}` for arrays, the legacy `mpr` reader yields **`bson.A`**. `bson.A` is a NAMED slice type (`type A []interface{}`), so a type switch `case []any:` does **not** match it and the walk never descends into `ObjectCollection.Objects` | `mdl/executor/validate_queued_calls.go` (`queuedCallTargets`, `storedQueueRetries`); the same blind spot exists in `mdl/backend/mcp/page.go`, `mdl/backend/mcp/page_mutator.go`, `mdl/executor/widget_sync_apply.go` | Add `case bson.A:` alongside `case []any:` in every raw-BSON walk. The house pattern already does this (`mdl/backend/bsonnav`, `mdl/catalog/builder_pages.go`, `mdl/xpathrefs/scan.go` and ~7 more) — the ones missing it are the outliers: `for f in $(grep -rln \"case \\[\\]any:\" --include=*.go mdl/); do grep -q \"bson.A\" $f \\|\\| echo $f; done`. **Test both shapes of the same document in one test**, not just the one your engine returns. **A unit test alone is not enough to find this**: it only surfaced by running the same command under `MXCLI_ENGINE=legacy` and diffing against modelsdk — engine parity has to be exercised, not assumed. Reported as FINDINGS #25 |", "refs": ["#25"]}
-{"area": "mdl/executor", "symptom": "A generated loop/while box does not fit its contents: activities sit outside the container, or the box is far wider than what is in it. An explicit `@position` on a loop child moves the child but not the box", "cause": "The container's `Size` came from `measureStatementsSpan`, a pre-pass over the AST run BEFORE the body was built, so it was a function of statement COUNT alone. Varying only the children's positions changed nothing: 2 activities at x=150/310, at x=1500/2000 and at x=160/170 all produced `480;160`, and in the second case both children sat entirely outside their own container. Nothing catches it — the model carries no geometry rules, so `mx check` is silent", "file": "`mdl/executor/layout.go` (`containerBounds`, `fitContainerSize`), called from `addLoopStatement` / `addWhileStatement` in `cmd_microflows_builder_control.go`", "insight": "Size the box AFTER the body is built, from the real child bounding box (`Position ± Size/2`). Nesting needs no extra code — an inner loop is sized when its own `addLoopStatement` returns, so the outer measures a correct inner box. **Do NOT translate the children to fit**, however tempting: their positions round-trip through DESCRIBE as `@position`, so moving them makes a describe→exec cycle store different coordinates than it read, which under ADR-0008 turns a quiet re-run into a write. Grow the box instead. **Two measurement traps hit while verifying this.** A helper that sets an annotation via `ast.StatementAnnotations` is a silent no-op when the field is nil (it returns nil rather than allocating) — the explicit-`@position` test passed while testing nothing until the field was assigned directly. And an idempotence check over `mprcontents` proved blind because the re-run script began with `create module`/`create entity` and aborted at \"already exists\" before reaching the microflow; the `MXCLI_ALWAYS_WRITE=1` control is what exposed it, so never assert \"nothing changed\" without it. Repro `mdl-examples/bug-tests/container-autosize-884.mdl`. Issue #884 problem 1", "refs": ["#884"]}
-{"area": "mdl/executor", "symptom": "A `describe microflow` → `exec` round-trip moves the **StartEvent**: a Studio-Pro-authored flow whose start sat at `145;200` comes back at `100;200`, while every other coordinate in the flow survives exactly", "cause": "The start has no MDL statement to annotate and DESCRIBE cannot emit its position, so the builder always derives one — `(first annotated activity X) − spacing`, i.e. `260 − 160 = 100`. Studio Pro's `145` is not derivable from anything in the description", "file": "`mdl/executor/cmd_microflows_create.go` (`storedStartPosition`), `mdl/executor/cmd_microflows_builder.go` (`flowBuilder.startPosition`), `mdl/executor/cmd_microflows_builder_graph.go` (the StartEvent construction)", "insight": "Carry the position over from the microflow being replaced, the way the folder and the allowed module roles already are on CREATE OR MODIFY — read it off the stored document and let it win over the derived value. Nil on a fresh CREATE keeps the existing derivation, so only a rebuild of an existing flow is affected. Best-effort: a backend that cannot read the stored flow yields the derived placement rather than failing the statement. **Verify with the whole coordinate set, not just the start** — dump every `RelativeMiddlePoint` before and after and diff, or a fix that pins the start while shifting something else reads as success. Control: stub the `fb.startPosition` branch and the `100;200` drift returns. Issue #884 follow-up", "refs": ["#884"]}
-{"area": "mdl/executor", "symptom": "`create or replace` on a document whose module holds a same-named **excluded** twin edits the WRONG one — the live document keeps its old body and the script looks like a no-op — and the rewrite also clears the twin's `Excluded` flag, so a project that built at 0 errors fails **CE0122** \"Duplicate document name\". Also `describe` returns the excluded document's body", "cause": "Studio Pro's \"Exclude from project\" makes a document name non-unique: Mendix allows the duplicate as long as at most one is active (measured on 11.13.0 — excluded pair = 0 errors, both active = CE0122). Every by-name lookup took the FIRST match, so which document it hit depended on enumeration order; and every rebuild wrote `Excluded` from the AST default (`false`) instead of carrying the stored value. `@excluded` exists and round-trips through DESCRIBE, so absence of the annotation must mean \"the script does not say\", never \"make it active\"", "file": "`mdl/executor/excluded_docs.go` (`pickLive`) + the create paths: `cmd_microflows_create.go`, `cmd_nanoflows_create.go`, `cmd_pages_create_v3.go` (pages **and** snippets), `cmd_enumerations.go`, `cmd_queues.go`, `cmd_workflows_write.go`, `cmd_javaactions.go`, `cmd_javascript_actions_write.go`, `cmd_businessevents.go`, `cmd_published_rest.go`, `cmd_dbconnection.go`, `cmd_datatransformer.go`, `cmd_import_mappings.go`, `cmd_export_mappings.go`, `cmd_jsonstructures.go`, `cmd_imagecollections.go`, `cmd_agenteditor_*.go`, plus `cmd_microflows_show.go` for DESCRIBE", "insight": "Route every by-name lookup through `pickLive` (live match wins; an all-excluded set still resolves to the first, so lookups do not start reporting \"not found\") and carry the stored flag next to the ID/roles each path already preserves. Four types had **no** `Excluded` field to carry — `model.Enumeration`, `types.JavaAction`, `types.ImageCollection`, `pages.Snippet` — so the field had to be added and populated in BOTH engines' readers (`TestFieldCountDrift` catches the `mdl/types` half and requires `convert.go` + the expected counts to be updated). Backends that hardcoded `SetExcluded(false)` (enumeration, snippet, image collection) are the same bug wearing a different hat. **Measure, do not read**: queues looked correct (their reader and writer both carry the flag) and still dropped it, because the executor built a fresh struct — the matrix run is what found it. Pages/snippets additionally collected ALL name matches and DELETED the extras, which destroyed the excluded twin outright. Tests `TestPickLive`, `TestCreateOrModifyMicroflow_PreservesStoredExclusion`, `TestCreateOrModifyMicroflow_TargetsLiveTwin` (both fail with the reported symptoms when the fix is reverted); fixture `mdl-examples/bug-tests/914-excluded-document-preserved.mdl`. Issue #914", "refs": ["#914"], "ce": ["CE0122"]}
-{"area": "mdl/executor", "symptom": "`mxcli check` reports `✓ Syntax OK`, `exec` writes the microflow, and the defect appears only when a human opens Studio Pro's Errors pane: CE0038 on a value-less `declare`, CE0068 on a `return` inside a loop, CE0111 on `declare $X` followed by `$X = call microflow …`", "cause": "Nothing in the MDL rule set covered them — each is a Mendix consistency rule with no MDL counterpart. CE0111's real scope is far wider than the reported case: a microflow's variable namespace is **flat**, so parameters, loop iterators and every activity output share it, and neither a branch nor a loop body opens a scope (all seven combinations measured on mxbuild 11.6.6)", "file": "`mdl/executor/validate_microflow_ce_gaps.go` (MDL061/062/063), wired from `validate_microflow.go`; fixtures `mdl-examples/bug-tests/893-check-gaps-*.mdl`", "insight": "Error severity alone closes the gap — `exec` pre-flights the whole script and refuses with nothing written; they are deliberately kept OUT of `execEnforcedMicroflowRules` so `--no-check` still works. **Run any new rule over `mdl-examples/` before wiring it up**: this one hit 4 of 374 files and 3 were FALSE positives, because the rule reads the AST while the outcome depends on what the BUILDER emits — `while true` becomes an ExclusiveMerge back-edge and not a loop object (#350), `returns T as $Var` routes the End event elsewhere, `set $x = contains($str,$str)` parses as a ListOperationStmt that the builder rewrites to a Change Variable (ledger #53/#63), and an `@excluded` document is never checked by mxbuild at all. The 4th was a genuine CE0111 in a shipped example. The shared predicate `stringOverloadedListOp` keeps rule and builder from drifting. Issue #893 items 1/2/6", "refs": ["#350", "#53", "#63", "#893"], "ce": ["CE0038", "CE0068", "CE0111"], "rules": ["MDL061"]}
-{"area": "mdl/executor", "raw": "| `DESCRIBE IMPORT MAPPING` output does not reproduce the script that made it: `Total = total` comes back as `Total = Total`, an array binding as `= ItemItem`, `LineId = id` as `LineId = _id` — and the output cannot be re-run at all, failing with \"import mapping already exists\". Export mappings identically (unreported) | DESCRIBE printed the element's **ExposedName** (Mendix's display name — capitalised initial, `Item` suffix on an array's item object) instead of the raw JSON key from `JsonPath`, and emitted a bare `create` header where every other DESCRIBE emits `create or modify` | `mdl/executor/cmd_import_mappings.go` (`mappingMemberName`, the four print sites, the header) + `cmd_export_mappings.go` (same four + header) | Print the raw key derived from `JsonPath` — strip a trailing `\\|(Object)` first, because an array's mapping element sits at the ITEM object while the script addressed the array (that suffix is what produced `ItemItem`). Fall back to ExposedName when there is no JsonPath (XML-schema / message-definition mappings have none). Safe by construction: the raw path is `jsonSchemaIndex.resolve`'s FIRST lookup, so it cannot regress #882. **Do NOT \"fix\" ExposedName itself** — the capitalisation is Mendix's own, confirmed against a Studio Pro-authored document in the blank app (`ExposedName \"Uuid\"` vs `Path \"(Object)|uuid\"`); rewriting it would diverge from Studio Pro. The `Item` suffix could NOT be confirmed the same way (a blank app has no Studio Pro array structure) and was left alone — with a separate `ExposedItemName` property in the BSON, that is worth checking against a marketplace module before anyone touches storage. Note the issue's framing was half wrong: the mapping DID round-trip semantically (re-executing the old output rebuilt byte-identical JsonPaths), so this was a text/diff defect, not a broken mapping — measure before agreeing with a title. Tests `TestMappingMemberName`, `TestDescribe{Import,Export}Mapping_RoundTripsMemberNames` (fail with the reported symptoms when reverted); two existing header assertions needed updating with the intentional change; fixture `mdl-examples/bug-tests/915-mapping-describe-roundtrip.mdl` is a DESCRIBE fixed point. Issue #915 |", "refs": ["#882", "#915"]}
-{"area": "mdl/executor", "symptom": "A widget property is accepted by `mxcli check`, written by `exec`, and does nothing: a pluggable widget's `imageUrl: '{1}', contentparams: [...]` builds as **CE0720** (\"place holder index greater than parameter count\"), and `editable:` on a button silently leaves it enabled with no warning at all", "cause": "Both allow-lists are widget-type AGNOSTIC. `isBuiltinPropName` (`widget_engine.go`) is ONE flat list holding both `ContentParams` and `Editable`, and it backs both MDL-WIDGET01 (pluggable) and MDL-WIDGET07 (static): it answers \"is this a real MDL property name anywhere\", and both validators read it as \"is this valid on THIS widget\". The engine then only acts on each for the widget kinds that support it", "file": "`mdl/executor/widget_engine.go` (`numericTemplatePlaceholderRe`, the TextTemplate case), `mdl/backend/mutation.go` + `widgetobj/builder.go` + `mcp/widget.go` (`SetTextTemplateWithClientParams`), rules in `validate_widget_editability.go` (MDL-WIDGET20) and `validate_widget_contentparams.go` (MDL-WIDGET21)", "insight": "For the template: the engine took the parameters path only for mxcli's `{AttrName}` spelling, so Mendix's own numeric `{1}` had no route and the template was written with `Parameters=[2]` (empty). A `dynamictext` with identical syntax is the control that localises it. For editability: **check the metamodel before implementing** — `PagesActionButton` has `ConditionalVisibilitySettings` but no `Editability`, and exactly 11 Pages types have editability (10 inputs + DataView) against 14 button types with none, so the request was impossible and the fix is to WARN. Both MDL spellings must be caught: `editable:` lowers to `Editable`, the bracket form `editable: [expr]` to **`EditableIf`** — dump the parsed `w.Properties` rather than assuming the key. Neither rule can be a `.fail.mdl`: they are warnings, `check` exits 0, and the fixture would report \"negative test unexpectedly passed\". Issue #928", "refs": ["#928"], "ce": ["CE0720"]}
-{"area": "mdl/executor", "symptom": "`import from mapping M.IMM($json)` builds cleanly and then throws at runtime: `MicroflowException: key not found: Path(QName(None,),None,)` at `com.mendix.integration.importer.mapping.MappingCache.storeValueMappingElement`. Reported as \"import mapping documents are broken / JSON path resolution is broken in mxcli's serialization\"", "cause": "**Not the mapping document — the ACTIVITY.** The Range and the result variable's cardinality are separate axes (#881), but an **unauthored** range set neither pointer, so `ForceSingleOccurrence` and `ConstantRange.SingleObject` both fell back to `SingleObject` — true for an object-rooted mapping. That is Studio Pro's **First** (\"take one of a list\"), a different activity. Studio Pro writes **both flags false** for a plain single-object import and expresses \"one object\" solely through `VariableType=ObjectType`. `all` and `first` and limit/offset all set the pointers explicitly, so only the **bare** form — the one every doc and example uses — was broken", "file": "`mdl/executor/cmd_microflows_builder_calls.go` (`addImportFromMappingAction`: add the `else` branch writing both pointers false); tests `mdl/executor/cmd_microflows_import_range_test.go`; fixture `mdl-examples/bug-tests/import-mapping-single-object-runtime.mdl`", "insight": "**A valid model that fails only at runtime**: `mxcli check`, `mx check` (0 errors) and mxbuild all pass — the document is well-formed, it just means something else. The repo had **no runtime coverage of import mappings at all**; every existing test stopped at `mx check`, which is exactly the gap `.claude/skills/verify-in-runtime.md` exists for. **Get a Studio Pro-authored app and cross the variables** — `ako/TestApp` settled this in minutes after days of BSON diffing: run the SP microflow and an mxcli one *in the same boot*, then cross them (mxcli microflow → SP mapping, and mxcli mapping → SP structure+entity). The cross-test is what separated the activity from the document; an \"isolation\" where BOTH artifacts are mxcli's isolates nothing, and I asserted the wrong culprit twice before running it. **A control is only evidence if its harness is known good** — an earlier run had Studio Pro's own mapping failing too, which \"exonerated\" mxcli, but the probe app was independently broken. **Diff the ENCODING, not just the values**: `bson.M` loses key order and non-canonical extended JSON hides `int32` vs `int64`; dump with `MarshalExtJSONIndent(doc, true, …)` and compare raw key order via file order. Four differences found that way were all real and none causal (int32-vs-int64 on 14 numerics, root `MinOccurs` 0 vs 1, missing `MessageDefinition2`, blanked `OriginalValue`) — chasing document differences was the wrong tree entirely. Also: #882's \"Studio Pro leaves `OriginalValue` empty\" is contradicted by a second app, so it was generalised from too small a sample", "refs": ["#881", "#882"]}
-{"area": "mdl/executor", "symptom": "`Body: file from $Doc` on a consumed REST operation sends the literal text `$Doc` instead of the file. `mxcli check` passes, `mx check` reports 0 errors, the request returns **HTTP 200** — and the payload is 4 bytes where the document held 8090", "cause": "Mendix has **no binary request body**. `generated/metamodel` has exactly three: `Rest$JsonBody`, `Rest$StringBody`, `Rest$ImplicitMappingBody`. Both engines folded `FILE` into the `TEMPLATE` branch and wrote a `Rest$StringBody` whose `ValueTemplate` is the **expression text** — `mdl/backend/modelsdk/consumed_rest_write.go:218` (default engine) and `sdk/mpr/writer_rest.go:250` (legacy). `describe` shows it straight back as `Body: template '$Doc'`, so the round trip looks consistent", "file": "`mdl/executor/cmd_rest_clients.go` (`checkFileRequestBody`, called from `buildRestClientOperation`); `mdl/executor/validate_rest_mapping.go` (MDL-REST02); tests `mdl/executor/cmd_rest_clients_file_body_test.go`; fixture `mdl-examples/bug-tests/rest-file-request-body.fail.mdl`", "insight": "**Refuse; do not write a different type** — there is no correct type for a CONSUMED OPERATION body. Binary POST is expressible, on the microflow REST CALL activity (`Microflows$BinaryRequestHandling`), which is where the refusal now points. A silent downgrade that returns 200 is the worst outcome available: every signal a user or an agent checks says success. Same shape as MDL-REST01, and one function is called from **both** the check pass and exec so `mxcli check` and `mxcli exec` cannot disagree. **Fix both engines, not just the one the reporter cited** — the report named only `sdk/mpr`, but the default engine is `modelsdk` and had the identical branch; a legacy-only fix would have left the default path broken. Keep the refusal **narrow**: `Response: file as $Doc` downloads correctly and is untouched (its own defect is a `CHANGE` on the result, which is separate). Judge an upload by what the server **echoes** (httpbingo `/post` returns `Content-Length` and the body), never by \"the call did not throw\" — a 200 proved nothing here"}
-{"area": "mdl/executor", "raw": "| A pluggable widget authored by MDL passes `mxcli check` and then fails **CE0463** \"the definition of this widget has changed\" on `mx check`, so `mx create-module-package` refuses the whole module. mxcli's own MDL-WIDGET10 warns about several properties — all of them harmless — and says nothing about the one that breaks the build | mxbuild evaluates the widget's compiled `editorConfig.js#getProperties()`, and a property that function **hides** must hold its **default** value. mxcli lifted only the top-level `hidePropertyIn`/`hidePropertiesIn` calls: `hideNestedPropertiesIn` and the 5-argument nested form were skipped by design (#574 Phase 1), which is exactly where the Accordion hides its group's `initialCollapsedState`/`initiallyCollapsed`. Two further gaps in the same extractor: a comparison guard read from a `\\|\\|` connector or a ternary's ELSE branch was recorded with the WRONG polarity (`eq` where the code means `ne`), and the shipped compilation is `forEach((function(n,o){…}))` — a double paren the callback-parameter regex read as the parameter name, so every nested condition was scoped to the widget instead of the item | `mdl/executor/editorconfig_extract.go` (`hideTargetKeys`, `parseGuard`, `enclosingForEachParam`); `mdl/executor/validate_widget_hidden.go` (`validateWidgetItemVisibility`, `hiddenPropertySeverity`); `mdl/types/widget_visibility.go` (`ListPropertyKey`, `Scope`); bump `WidgetDefGeneratorVersion` in `mdl/executor/widget_engine.go`; tests `mdl/executor/editorconfig_nested_test.go`, `mdl/executor/validate_widget_hidden_test.go`; fixture `mdl-examples/bug-tests/931-accordion-hidden-property.mdl` | **Split the severity on the VALUE, not the property** — the same hidden property is harmless at its default (Studio Pro ignores it) and a build failure otherwise, which is why four warnings fired on defaults while the two real failures were silent. **Measure the rule instead of reading the JS**: a matrix of eight one-property variants through `mx check` (`collapsible` on/off × default/non-default) pinned it in minutes and became the test oracle — mxcli's verdict now matches mxbuild on all nine measured cases. Note `\"web\" !== platform` evaluates TRUE under mxbuild, so guards behind it never fire; the conjunct rule below is what makes the Accordion's compound guard liftable anyway. **`X && Y \\|\\| hide(…)` soundly implies \"hide when Y falsy\"** whatever X is, so a compound guard with one unresolvable operand is still liftable — but `X && Y && hide(…)` is not (hiding needs both), and lifting it would over-fire. **Widget defs are cached per project** in `.mxcli/widgets/*.def.json`; a rules change is invisible until `WidgetDefGeneratorVersion` is bumped, and the refresh happens during `exec`, so the run that regenerates them still validates against the old set. Issue mendixlabs/mxcli#931 |", "refs": ["#574", "mendixlabs/mxcli#931"], "ce": ["CE0463"]}
-{"area": "mdl/executor", "symptom": "An `else` branch on a `split type` \"never fires\" — the author expects it to catch object types with no `case`, and it only runs when the object is **null**. Often surfaces as CE0090 \"The '<Entity>' value should be configured for an outgoing flow\" on a split that visibly has an `else`", "cause": "Not a bug: `else` on an inheritance split IS the `(empty)` flow (a null object), not a default. Mendix requires a separate outgoing flow for **every** concrete subtype and the base entity; an `else` contributes nothing to that coverage. The keyword is misleading, which is the defect", "file": "`mdl/executor/cmd_microflows_builder_actions.go` (the `addBranch(\"\", s.ElseBody)` call and its CE0089/CE0090 comment)", "insight": "Add a `case` for every subtype **and** the base entity, keeping the `else`. Do NOT drop the `else` to \"fix\" CE0090 — that flow is load-bearing and its absence is CE0089. Measured on mxbuild 11.13.0: `case Dog` + `else` → CE0090 for `Cat` and `Animal`; every type cased, `else` kept → 0 errors. The branch is now spelled `when (empty) then`, which says what it does; `else` still parses and warns **MDL065**. Background in [the #913 report](../../docs/12-bug-reports/2026-08-20-issue-913-split-statement-syntax.md)", "refs": ["#913"], "ce": ["CE0089", "CE0090"], "rules": ["MDL065"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE microflow` output for a split cannot be read: a branch body sits at the SAME column as its `when`/`case` keyword, so a nested `if`'s `else` lands exactly where a case branch would — in output where `else` on a `case` is an MDL008 error. The enum split and the type split are wrong in OPPOSITE directions (enum indents the branch but not the body; type indents the body but not the branch), and `if/else` is right", "cause": "Both emitters wrote the branch keyword at `indentStr+\"  \"` and then traversed the body at `indent+1` — the same column. No test caught it because `assertLineContains` matches substrings and never sees leading whitespace", "file": "`mdl/executor/cmd_microflows_show_helpers.go` (`emitEnumSplitStatement`, `emitInheritanceSplitStatement`) **and** `mdl/executor/cmd_diff_mdl.go` (`microflowStatementToMDL`)", "insight": "Traverse branch bodies at `indent+2`. **There are two MDL emitters, not one** — the diff renderer had the identical bug and is only found by grepping for the pattern rather than fixing the file the report names. Prove it with the control: revert one `indent+2` and the test must fail with `branch body indent = 4, want 6`; a test written only against fixed code detects nothing. Test `TestSplitBranchBodiesIndentFromTheirBranchKeyword` (includes an `if is the reference` sub-test, so the splits follow `if` rather than a hardcoded number)", "rules": ["MDL008"]}
-{"area": "mdl/executor", "symptom": "`CREATE OR MODIFY … FOLDER 'x'` on a document that already exists reports success (\"Modified json structure: …\") and the document does not move. The folder itself *does* appear, empty, which makes it look like a partial write rather than a no-op. Reported for JSON structures and mappings", "cause": "Not doctype-specific — **every** doctype with a FOLDER clause did this. A document's folder is its unit's `ContainerID`, a column in the `Unit` row, and every `Update*` on both engines rewrites only the unit's *contents*. So the handlers resolved the folder, stored it on the model object, and had it dropped one layer down. `resolveFolder` creates missing folders as a side effect, which is where the empty folder comes from. The typed `Move*` methods that do reparent were only ever called from `cmd_move.go` / `cmd_folders.go`; `MoveImportMapping` and `MoveExportMapping` existed on the interface, both engines and the mock, and **nothing called them**", "file": "`mdl/executor/document_placement.go` (new: `resolveRequestedFolder` + `applyDocumentFolder`), wired into every CREATE OR MODIFY handler that resolves a folder (`cmd_jsonstructures.go`, `cmd_microflows_create.go`, `cmd_nanoflows_create.go`, `cmd_enumerations.go`, `cmd_constants.go`, `cmd_pages_create_v3.go`, `cmd_odata.go` ×2, `cmd_published_rest.go`, `cmd_businessevents.go`, `cmd_rest_clients.go` ×2); primitive in `modelsdk/mpr/writer_core.go` (`MoveUnit`) + `sdk/mpr/writer_domainmodel.go` (`moveUnitByID`); interface `mdl/backend/placement.go`", "insight": "Fix the **class**, with one type-agnostic `MoveDocument(unitID, containerID)` on the backend, not a `Move<Doctype>` each — placement is the same row update whatever the document is, and a per-doctype method means the next document type inherits the bug by not having one written for it. **The counting is half the fix**: a move changes no byte of the document, so it is invisible to content-based no-op elision (ADR-0008) — without `writesOffered`/`writesLanded` on the row update, `ReportMutation` calls a real move \"Unchanged\", and without the equality check re-running an in-sync script dirties the `.mpr`. Both directions have controls (strip either and `TestMoveDocumentPersistsAndIsIdempotent` fails). **The control that decides fix-vs-new-bug**: an omitted FOLDER must leave placement alone. `resolveFolder(\"\")` answers with the *module root*, so a handler that passes it through unfiles every foldered document on the next `CREATE OR MODIFY` — far worse than the no-op. `resolveRequestedFolder` returns `\"\"` for \"not asked\" and `applyDocumentFolder` ignores `\"\"`, so the distinction cannot be forgotten per-site. Doctypes rewritten as **delete+create** (snippets, rest clients) had the *inverse* bug already live — they really do re-apply the container, so a silent statement filed them into the module root; they need `existingContainerID` carried forward, not a move. **Diagnose against storage, not mxcli's own reads** (cf. #722/Bug 12b, where the same symptom was a read illusion): diff `Documents in Modules` / `Documents in Folders` counts from the raw `Unit` table, with an explicit `MOVE` of a supported doctype as the positive control. Repro `mdl-examples/bug-tests/932-folder-on-modify.mdl`; tests `mdl/executor/document_placement_test.go`, `mdl/backend/modelsdk/placement_test.go`. Issue #932", "refs": ["#722", "#932"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE PAGE` renders a List View as though it had one plain body, and re-executing that output **destroys** the page's specialization templates — measured on ako/TestApp: 4 templates before a describe → exec round trip, 0 after, with `mx check` reporting **0 errors both times**", "cause": "`Forms$ListViewTemplate` was write-only and entity-less across the whole stack. `parseListViewContent` read only `w[\"Widgets\"]`, so DESCRIBE never saw the sibling `Templates` array; the typed parser never populated `ListView.Templates` either, so a rebuild wrote zero; `sdk/pages.ListViewTemplate` had no entity field at all; and `modelsdk/gen` bound the entity under the SDK name `Specialization` where every Studio Pro document stores `Entity`", "file": "`mdl/executor/cmd_pages_describe_parse.go` (`parseListViewTemplates`), `cmd_pages_describe_output.go`, `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildListViewTemplateV3`), `sdk/pages/pages_widgets_data.go`, `sdk/mpr/writer_widgets_display.go`, `modelsdk/gen/pages/types.go`", "insight": "Add the MDL surface (`template for Module.Entity { … }`) and read the array on the way back out. Four traps. (1) **`modelsdk/gen` is wrong about the key** — `Entity`, not `Specialization`; patch `init<Type>` AND `InitFromRaw`, per the STORAGE-NAME OVERRIDE rule. (2) **Order is authored, not derived** — TestApp's is Bus, Truck, Car, SUV, so a DESCRIBE that sorted would not round-trip. (3) **Inside a template the context object is the specialization**, not the list view's entity, or an attribute only the specialization has fails to resolve. (4) **`FOR` is in the parser's `keyword` rule**, so the new alternative must come FIRST in `widgetV3` or it collides with Gallery's pre-existing `template <name>` content slot — which is a different construct and must keep working. **Generalisable**: `mx check` is no signal for a dropped container — the document stays valid, it just holds less. Control on a **round trip through the real project** with the previous binary (`4 → 0`), not on the validator. mendixlabs/mxcli#940", "refs": ["mendixlabs/mxcli#940"]}
-{"area": "mdl/executor", "symptom": "`describe page` emits MDL that will not re-execute for any non-database datasource. Three shapes: a chart series bound to a microflow comes back as `DataSource: database from Module.TheMicroflow` (→ `entity not found: Module.TheMicroflow`); a pluggable list whose source carries no entity comes back as `DataSource: database from ` with an empty slot (→ `entity not found: from`, the parser reading `from` as the entity); and a **gallery** bound over an association loses its datasource **entirely** while a **listview** bound the same way keeps it", "cause": "One cause, three faces: the datasource switch was copied per widget family — five copies on the read side (`extractDataViewDataSource`, `extractListViewDataSource`, `extractDataGrid2DataSource`, `extractGalleryDataSource`, `parseCustomWidgetDataSource`) and six on the write side — and they drifted apart. The pluggable read copy, which every Gallery/DataGrid2/chart goes through, knew `Forms$MicroflowSource` and `Forms$NanoflowSource` but **not** `Forms$AssociationSource`, `Forms$ListenTargetSource` or the context forms, so those were dropped; its `CustomWidgets$CustomWidgetXPathSource` case returned `{database, \"\"}` unconditionally where its own near-twin guarded on a non-empty reference; and the object-list item emitter had **no type switch at all**", "file": "new `mdl/executor/cmd_pages_describe_datasource.go` (`parseDataSource`, `dataSourceExpr`, `appendDataSourceProp`); the five readers in `cmd_pages_describe_parse.go` / `cmd_pages_describe_pluggable.go` now delegate; all six emit sites in `cmd_pages_describe_output.go` go through one renderer", "insight": "**One reader and one renderer, because a datasource means the same thing wherever it sits.** The per-widget copies were the defect, not the individual missing cases — patching the pluggable switch alone would have left five copies to drift again. Take the `$Type` set from `generated/metamodel`'s `DataSource` interface rather than from the copies. **Read sorting from whichever shape is present** (`SortBar.SortItems` for grid-like sources, `Sort.Paths` for list views) so the reader stays container-agnostic. **Distinguish \"unknown type\" from \"known type, empty payload\"**: the first is mxcli's gap and is reported as a `-- DataSource (…) has no MDL spelling` comment (never dropped, never guessed into a `database from` that cannot re-execute); the second is the model's own incompleteness and yields nil, which an existing test deliberately pinned (`TestExtractDataViewDataSource_ListenTargetSourceEmptyTarget`) — collapsing the two broke it. **Verify with a whole-project describe diff, not a unit test alone**: running `describe page` over every page before and after showed the four intended changes and nothing else — and it surfaced two WHERE/SORT clauses the combobox emitter had been silently dropping, which no unit test would have found. Controls: stub `dataSourceExpr`'s switch to `\"database\"` and the tests report the issue's own string, `got \"database from Mod.DS_GetItems\"`; drop the association/selection cases and they report `datasource was dropped`. **Note what the fix does NOT fix**: 10 of 21 pages in the probe project still fail `describe`→`check`, identically before and after — unquoted XPath containing `[`, duplicate generated widget names, context errors. Those are separate round-trip gaps; counting the failures on both sides is what tells them apart from a regression. **Generalisable measurement trap, and it invalidated this fix's first control**: copying a project for an `mx check` baseline with `cp rp.mpr mprcontents/` is NOT a copy of the project. The theme lives in `theme/`, so a copy without it reports **924 CE6083** \"Design property … is not supported by your theme\" plus CE0535 for the missing `widgets/` — a baseline of ~950 errors where the real project has **0**. Before/after still compares equal, so the check looks like it passed, but it has no power: a genuine new error is one line in a thousand and the theme-dependent checks never ran at all. Copy the whole directory (`cp -r project/. dest/`) and expect the baseline to be 0 — a non-zero baseline on a healthy project means the copy is incomplete, not that the project is broken. Repro `mdl-examples/bug-tests/941-describe-page-datasources.mdl`; tests `mdl/executor/cmd_pages_describe_datasource_test.go`. Issue #941", "refs": ["#941"], "ce": ["CE0535", "CE6083"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE PAGE` output that **used to parse stops parsing** after a fix that restores a WHERE clause — reported against stock `Administration.Account_New`, which every project from the Mendix template carries", "cause": "Two older gaps the restored clause collided with. The constraint was emitted **raw** (`expr += \" where \" + xpath`), so a stored XPath carrying an inner predicate — `System.grantableRoles[reversed()]/…` — ended the MDL `expression` parse at the `[`. The grammar takes either a bare expression or a bracketed `xpathConstraint`, and only the second is safe for arbitrary XPath. The same six lines also stripped the outer brackets by testing the first and last byte, turning `[a][b]` into `a][b`, and guarded on `strings.Trim(s, \"\")` — an empty cutset trims nothing, so a whitespace-only constraint emitted a bare `where`", "file": "`mdl/executor/cmd_pages_describe_datasource.go` (`xpathConstraintClause`)", "insight": "**Emit the bracketed production always, and stop deciding.** The bare form reads better but parses only for simple comparisons, and \"is this XPath also a valid MDL expression\" is not a question an emitter can answer — a bracketed group is accepted for every constraint. Reuse `visitor.SplitXPathPredicateGroups` (the quote- and nesting-aware splitter written for #772) rather than keeping a second, simpler copy: the naive strip is exactly the bug that helper exists to prevent. **Measure the round trip as a SET, not a count.** The claim this regression contradicted came from counting failing pages before and after, seeing 10 both times, and concluding nothing had changed — but an equal count hides a page flipping each way, and here a template page flipped from parse to fail while the total held. `join` the pass-sets: `join <(grep PASS before) <(grep FAIL after)` names the regressions directly. Control: revert the bracketing and `Account_New` stops parsing again. Reported in mxcli-formula1 §57.1/§57.3", "refs": ["#772"]}
-{"area": "mdl/executor", "symptom": "A widget datasource bound to a microflow **loses its arguments** through `describe`: `microflow Mod.DS(Race: $Race)` describes as `microflow Mod.DS`, and replaying that description fails the build with **CE1571** \"No argument has been selected for parameter 'Race' and no default is available\" — the very error #835 fixed on the write side. `check --references` calls the argument-less form valid, so nothing catches it before mxbuild", "cause": "The write side stores the mappings correctly; **no describe path ever read them**. Not confined to pluggable widgets — a plain `dataview` loses them too. Older than #941, which merely printed the whole line wrong so the loss hid behind a larger bug", "file": "`mdl/executor/cmd_pages_describe_datasource.go` (`flowSourceArgs`, and the `case \"microflow\", \"nanoflow\"` renderer)", "insight": "Storage puts the bindings in `<Flow>Settings.ParameterMappings`, each `{Parameter, Expression}` behind typed-array marker 3, with **Parameter qualified by the flow** (`Mod.DS_Filtered.Term`) while MDL names the parameter alone — the flow is already left of the parentheses. **Strip that prefix by matching the flow's own qualified name, not by cutting at the last dot**: a document storing the name bare would otherwise lose its first segment. The value is in `Expression` for both a variable ref and a literal; `Variable` is the older spelling and is honoured when present. A parameterless flow must render **without** parentheses — the grammar makes the list optional and empty parens would churn every existing description. **Get the BSON shape from a real unit, not from the writers**: the two serializers here disagree in spelling (gen's `SetParameterQualifiedName` vs legacy's `Parameter`), and only a dump settles which key is on disk. Verify by replaying a description and counting CE1571 (4 → 0 on a two-widget page), not by eyeballing the text. Reported in mxcli-formula1 §57.2; same family as §39, where `SHOW_PAGE` drops `(Race: $currentObject)`", "refs": ["#835", "#941"], "ce": ["CE1571"]}
-{"area": "mdl/executor", "symptom": "`use building block X (datasource: …)` starts failing with \"datasource override supplied, but the block has no datasource widget to rebind\" — on both engines, for a stock Atlas block, immediately after a fix that made DESCRIBE stop emitting malformed datasources", "cause": "The rebind expands the block by **re-rendering it to MDL through the describe emitter and re-parsing that text**, then looked for a widget already carrying a `DataSource` property. A reusable block is a *template*: its datasource is unbound. That used to render as the malformed `DataSource: database from ,` — the exact output #941 fixed — and the re-parse turned it into a `DataSource` property, so the rebind found its target. Emitting nothing for an empty datasource, which is correct, left it with nothing to match", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`isDataSourceWidget`, and the `DataSourceOverride` branch)", "insight": "Match the target by **widget type — what can carry a datasource, not what does**. The sibling `ActionOverride` branch already did exactly this, and its comment says why: Atlas blocks \"ship placeholder buttons with no action\". Same fact about the same blocks; the datasource branch just hadn't learned it. **The generalisable shape**: a consumer that re-parses another component's *rendered output* silently depends on that output's bugs, so fixing a renderer can break something that never reads the model. Grep for callers of the emitter (`outputWidgetMDLV3` here) before changing what it emits — unit tests on the emitter cannot see this, and the failure surfaced only in the integration suite. Control: restore the property-based predicate and the stock-block rebind fails again. Tests `mdl/executor/cmd_pages_builder_bb_rebind_test.go`; CI repro `mdl-examples/doctype-tests/15c-fragment-bindings-examples.mdl`", "refs": ["#941"]}
-{"area": "mdl/executor", "symptom": "A `SHOW_PAGE` widget action **silently ignores an argument that is not the context object**: `action: show_page Mod.Detail(Car: $Other)` inside a data view bound to `$Car` opens the page with **`$Car`**. Nothing reports it — `mx check` is **0 errors**, the build is green, and `describe page` prints `(Car: $currentObject)`, so the description looks like a *diagnosis* of a lost mapping rather than an accurate report of a model that never held one", "cause": "mxcli stores a widget show-page action with an **empty** `ParameterMappings` array and lets Mendix infer the argument from the enclosing widget's context object. That part is deliberate and twice-confirmed — an explicit `Forms$PageParameterMapping` whose `Argument` is `$currentObject` is rejected as **CE0115** \"parameters do not match\" (#296, re-confirmed on mxbuild 11.12.1 for §56). The missing half was the case where the author names something *else*: the builder built `PageClientParameterMapping` objects and both engines dropped them on the floor (`formSettingsToGen` takes only the page name; the legacy writer hardcodes `bson.A{int32(2)}`)", "file": "`mdl/executor/cmd_pages_showpage_args.go` (new: `pageArgumentBindsContextObject`, `contextVarFor`, `validateShowPageArguments`); the guard in `cmd_pages_builder_v3.go`'s `case \"showPage\"`; `contextVarName` threaded through `cmd_pages_builder.go`, `cmd_pages_builder_v3_widgets.go`, `widget_engine.go`, `validate_widgets.go`", "insight": "**Refuse, don't author.** The instinct is to write the mapping the user asked for, but #296 already established that Mendix rejects an explicit one — so the only honest options are \"bind the context object\" or \"say no\", and silently doing the first while the author wrote the second is what caused the bug. **To refuse without false positives you need the context *variable*, not its entity.** `pb.entityContext` carries only `Module.Entity`, and both `$Car` and `$Other` have it — a type check cannot tell them apart. Track the name the data source gives the context object (`contextVarFor`: a `parameter` source names it, a database/association/microflow source leaves it `$currentObject`-only) and allow the argument when it matches either spelling. That keeps the **documented** form working — `create-page.md`'s `show_page Mod.EditPage(Product: $Product)` inside a data view on `$Product` is the arg-equals-context case — while catching only arguments that are provably discarded. **`mx check` is worthless as a control here** and that is the whole point of the bug: an inferred mapping is a *valid* mapping, so mxbuild reports 0 errors on the corrupted page. The control is the guard itself — stub `pageArgumentBindsContextObject` to `return true` and the probe writes silently again, describing as `$currentObject`. Mirrored at check time as **MDL-PAGEARG01** so the LSP and `mxcli check` catch it with no project, the same pairing as MDL-WIDGET09. **\"No context variable\" and \"context unknown\" are different states, and conflating them is a false positive that bites immediately**: `ALTER PAGE … SET Action = SHOW_PAGE P(Car: $Car) ON btnGo` builds the action against a *stored* page the pass never traverses, so `contextVarName` is empty for a reason that has nothing to do with the argument — the first cut refused that statement, which is correct code. A separate `contextKnown` flag, set only on entering a data-bound widget, keeps the guard to what it can prove; ALTER PAGE behaves exactly as it did before. Caught by trying the ALTER form by hand, not by any test in the suite. Found while verifying §39, whose *reported* half (DESCRIBE omitting the inferred mapping entirely) was already fixed by `4551a4e`", "refs": ["#296"], "ce": ["CE0115"]}
-{"area": "mdl/executor", "symptom": "`DROP ATTRIBUTE` succeeds, but Studio Pro / `mx check` reports **CE1613** \"The selected attribute 'Mod.Ent.Attr' no longer exists.\" at *Validation rule of entity 'Mod.Ent'*. The executor even prints `Removed 1 validation rule(s)`", "cause": "**Two independent bugs on the same statement, and each hides the other.** (1) The executor's cleanup compared `vr.AttributeID` against the dropped attribute's **element ID**, but a validation rule and a MemberAccess reference their attribute by **BY_NAME qualified name** (`Mod.Ent.Attr`) — both arrive in the same `model.ID` field, so the comparison matched nothing and every rule was kept. Both engines feed the qualified name (`sdk/mpr/parser_domainmodel.go` stores the string verbatim; `mdl/backend/modelsdk/domainmodel.go` says so in a comment). (2) With (1) fixed the rule was removed in memory and **still not written**: `entityToGen` only appends to a child list when it is non-empty, so a list emptied by the update stays *clean* and the codec passes the **stored raw bytes** through — the removal silently does not happen", "file": "`mdl/executor/cmd_entities.go` (`AlterEntityDropAttribute` cleanup) and `mdl/backend/modelsdk/domainmodel_alter.go` (`UpdateEntity`, the emptied-child-list loop)", "insight": "Match **both reference forms** (element ID *or* qualified name built as `Module.Entity.Attr`, exactly what `serializeValidationRule` writes), and dirty **every** emptied child list, not one at a time. The list bug already had a precedent — Indexes, ledger #39 — so `ValidationRules`, `Attributes`, `AccessRules` and `EventHandlers` are all covered in one loop rather than rediscovered one error code at a time. **The trap is that it only bites on the LAST member**: removing one of two rules dirties the list and works fine, so any two-member fixture passes against the broken writer — the `Attributes` case is worse than a dangling reference (dropping an entity's *only* attribute reported success and wrote nothing at all) and had gone unnoticed for the same reason. Index references really are element IDs (`AttributePointer`), which is why that one path always worked and makes the positive control. Verify with `mx check`, not the executor's own output: it reported `Removed 1 validation rule(s)` while CE1613 persisted. Repro `mdl-examples/bug-tests/drop-attribute-orphaned-validation-rule.mdl`. Reported in the banking-app feedback", "refs": ["#39"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "A workflow that calls a microflow existing nowhere passes `mxcli check --references` with \"All references valid\" and is written by `exec` with exit 0; only native `mx check` catches it (**CE1613** \"The selected microflow ... no longer exists\"). The identical mistake inside a plain microflow body IS caught", "cause": "`validateWithContext`'s `CreateWorkflowStmt` case called only `validateWorkflowParameterMappings`, whose own comment defers a target that is not in the project to \"the missing-reference check\" — **which was never written**. `validateFlowBodyReferences` (which does catch it) is wired only to `CreateMicroflowStmt`/`CreateNanoflowStmt`. `AlterWorkflowStmt` had **no case at all** and fell to `default: skip validation`", "file": "`mdl/executor/validate_workflow_refs.go` (`validateWorkflowReferences`, `validateWorkflowStatementRefs`, `validateAlterWorkflowRefs`); `mdl/executor/validate.go` (both switch cases, `scriptContext.workflows`, `collectDefinitions`/`collectSingle`/`allNames`); `mdl/executor/helpers.go` (`buildWorkflowQualifiedNames`); exec-side guards in `cmd_workflows_write.go` + `cmd_alter_workflow.go`", "insight": "**The gap is never one reference kind** — probe them all before fixing. Here *every* reference in a workflow was unvalidated: call microflow, call workflow, user task page, targeting microflow, context entity, and the workflow's own module (checked for a microflow, not for a workflow — and `exec` auto-creates a module, so `check` was the only guard against a typo silently making one). **`check` and `exec` run different passes**: `check --references` runs `validateProgram`, `exec` does not, so a validator wired only into the switch leaves exec writing the broken model — the guard must ALSO be called from the statement handler, before `findOrCreateModule` (same shape as #833). Pass `nil` for the scriptContext there: exec applies statements one at a time, so an earlier statement's output is already in the project. **The real risk is false positives** — verify by diffing error counts against a baseline binary over every workflow script in `mdl-examples/`, with the referenced modules actually present, and exempt `System.*` (`isBuiltinModuleEntity`) or every built-in target is reported missing. Issue #943", "refs": ["#833", "#943"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "`CREATE OR MODIFY ODATA CLIENT` reports `Unchanged OData client` after the contract file was refreshed from the running backend — `SHOW CONTRACT ENTITIES` keeps listing the old entity types, and the `CREATE OR MODIFY EXTERNAL ENTITIES` that follows imports the old shape with no warning. `DROP ODATA CLIENT` + recreate is the only way out, and it invalidates the client ID the existing external entities point at", "cause": "The modify branch updated every property **except the cached contract**. Only the create path fetched `$metadata`; `svc.Metadata` / `svc.MetadataHash` kept the snapshot taken when the client was first created. The same branch also stored `stmt.MetadataUrl` raw, skipping the `NormalizeURL` the create path applies, so a relative `./contracts/x.xml` ended up as a URL neither Studio Pro nor `fetchODataMetadata` can open", "file": "`mdl/executor/cmd_odata.go` (`refreshCachedMetadata`, `normalizeMetadataURL`, `contractSummary`, called from the `stmt.CreateOrModify` branch of `createODataClient`); test `mdl/executor/cmd_odata_metadata_refresh_test.go`; repro `mdl-examples/bug-tests/odata-client-stale-contract-on-modify.mdl`", "insight": "**Refresh from the *effective* URL, not the statement's** — a `CREATE OR MODIFY` that omits `MetadataUrl` still has to converge the cache, or the idiomatic re-run silently keeps the stale contract. **A failed fetch must keep what is cached** (warning, not error): losing a contract that was merely unreachable is worse than serving a stale one, and there is nothing to fall back on. **Leave `svc` untouched when the hash matches**, or ADR-0008 elision breaks and every re-run churns the document — the unchanged-contract control is what proves this, and it passes both before and after the fix, so it is the half of the test that keeps the other half honest. `ALTER ODATA CLIENT SET MetadataUrl` has the same staleness and is deliberately **not** fixed here: it carries no design-time credentials, so a blind re-fetch of an authenticated URL would warn where it used to be silent. `mx check` is no oracle for any of this — the stale project builds with 0 errors, because a client caching an old contract is perfectly valid"}
-{"area": "mdl/executor", "symptom": "A microflow rewritten by `CREATE OR MODIFY MICROFLOW` is drawn with its **StartEvent stranded** — every activity where the script asked, the start left behind, joined to its own first activity by a long mostly-empty line across the canvas. Reproduces on every rewrite, and copying a working script's `@position` pattern does not help", "cause": "The fix for the OPPOSITE report. #884 was a describe→exec round-trip MOVING a hand-placed start (145;200 → 100;200), fixed by carrying the stored position over on every rewrite; that then **pinned** the start of every rewritten flow, so it no longer followed activities the same script had just moved. Both reports are real and neither is answerable without asking where the stored value came from", "file": "`mdl/executor/cmd_microflows_start_position.go` (`authoredStartPosition`, `derivedStartPosition`, `startAnnotationLines`), `mdl/executor/cmd_microflows_create.go` (`storedStartPosition`), `mdl/executor/cmd_microflows_builder_graph.go` (StartEvent construction)", "insight": "Carry the stored position over **only when it is not where the layout would have put it** — a start at `first.X − spacing` on `first.Y` is mxcli's own arithmetic handed back and carries no intent, so re-derive it; anywhere else, a person put it there, so keep it. Add `@start(x, y)` on the first statement (the `@merge` precedent — it positions the other node with no statement of its own) so the position can be *stated* rather than inferred, and have DESCRIBE emit it **only for a non-derived start**, which is what makes the round-trip exact without pinning every described flow. **`mx check` is not the oracle, and neither is a green build**: the Mendix model carries no geometry rules, so a stranded start is a valid document — 0 errors on mxbuild 11.13.0 before and after. Verify by reading the coordinates back off the stored document. **Emit from BOTH describers**: `formatMicroflowActivities` and `formatMicroflowActivitiesWithSourceMap` are near-duplicates, and the first cut of this fix patched only the second, so `describe microflow` silently dropped the line. Controls: reverting the narrowing reproduces the stranded start, reverting the builder arm reproduces \"@start does nothing\", reverting either describer reproduces the lossy round-trip. Repro `mdl-examples/bug-tests/951-microflow-start-event-position.mdl`. Issue #951", "refs": ["#884", "#951"]}
-{"area": "mdl/executor", "symptom": "`SPLIT TYPE … END SPLIT` followed by any statement draws that statement **on top of the merge** in Studio Pro, joined by a zero-length sequence flow, and the merge itself sits far to the right of the branches it joins (branches at x=720, merge at x=1480). `CASE` and `IF/ELSE` with the same graph shape lay out correctly. `mx check` reports 0 errors either way", "cause": "Two defects in `addStructuredInheritanceSplit`. (1) It ended with `fb.posX = mergeX` — the merge's own centre — where `addEnumSplit` steps to `mergeX + HorizontalSpacing/2` and `addIfStatement` to `mergeX + MergeSize + HorizontalSpacing/2`; three builders, three conventions, and the type split's was zero. (2) Branch width came from `measureStatements(appendInheritanceBodies(s))`, which concatenated every branch body into ONE list and measured it as a single left-to-right run — so the merge slid right by an activity-plus-spacing per **extra branch**, not per branch *width*. `layout.go`'s own `measureInheritanceSplitStatement` always took the max, so the builder disagreed with its measurer", "file": "`mdl/executor/cmd_microflows_builder_actions.go` (`addStructuredInheritanceSplit`; `appendInheritanceBodies` → `inheritanceBranchBodies`); tests `mdl/executor/cmd_microflows_builder_split_geometry_test.go`; repro `mdl-examples/bug-tests/953-split-type-merge-overlap.mdl`", "insight": "**Geometry is invisible to every automatic check below Studio Pro** — the model is valid, so `mx check` passes, the build passes, and `describe` output looks right until you read the coordinates. `describe` printing `@position`/`@merge` IS the headless oracle: diff those, don't open the modeler. **The split builders had zero positional coverage** before this (grep `Position` in the enum-split and inheritance-split tests: nothing), which is the same gap behind the loop-box sizing bugs #790 and #884. **Pick the IF convention, not the CASE one**: the constants are centre-to-centre for a 40px edge gap, and `CASE`'s `+HorizontalSpacing/2` leaves a following activity's left edge exactly touching the merge (measured: merge 890, activity 970, both edges at 910) — a lesser pre-existing nit deliberately left alone, because changing it re-lays-out every enum split ever written. **`@merge(x,y)` was not a workaround**: `fb.posX = mergeX` read the overridden value, so moving the merge by hand moved the stacked element with it. A fix needs a control that the neighbouring construct did NOT move — `TestEnumSplitGeometryIsUnchanged` — or \"the type split matches CASE now\" can be achieved by breaking CASE. Issue #953", "refs": ["#790", "#884", "#953"]}
-{"area": "mdl/executor", "symptom": "`mxcli check --references` prints \"Check passed!\" (exit 0) and `mxcli exec` then fails (exit 1) on the same script, over the order things are created *in the script* — with earlier statements already written, because exec is not transactional. exec's own message is already right (\"… is defined later in this script — move its create statement before this one\")", "cause": "`validateProgram` calls `sc.collectDefinitions(prog)` over the **whole program up front**, so every name in the script is \"defined\" for every statement and a forward reference is indistinguishable from a backward one. `annotateForwardRef` computes the diagnosis, but only in `ExecuteProgram`, *after* a statement has failed. `exec`'s pre-flight runs the package-level `ValidateProgram` (the no-project tier) and not the reference tier, so it was no safety net either", "file": "`mdl/executor/validate_definition_order.go` (`ValidateScriptDefinitionOrder`, MDL-ORDER01), wired into `mdl/executor/validate_program.go` beside `ValidateScriptPageOrder`; tests `mdl/executor/validate_definition_order_test.go`; repros `mdl-examples/bug-tests/955-forward-definition-order{,.fail,-tolerated,-or-modify-not-flagged}.mdl`", "insight": "Put it in the **no-project tier**, not under `--references`: that is what makes `exec`'s pre-flight refuse the script too, which turns a half-applied project into \"Nothing was written\" — the actual harm, and the part a `check`-only fix leaves in place. **Do not flag every forward reference**: measure which ones the executor resolves eagerly, because several do not fail — an entity's `EXTENDS`, `CALL JAVA ACTION`, `RETRIEVE … FROM`, and `CREATE <entity>` in a body all execute correctly with the definition after them (measured on 11.6.6), and a blanket rule rejects working scripts. **Only a plain CREATE later is sound with no project** (the MDL-PAGE01 argument: a plain CREATE asserts the document is absent, so the earlier reference could not have resolved against the project either); a later `CREATE OR MODIFY` fails exec just the same but cannot be judged without `-p`, and is deliberately left as known residue. Key by **kind as well as name** — Mendix namespaces documents by type — and skip `at == i` or a recursive microflow call reports itself. A bare `Module.Name` written as a type lands in `EnumRef` whether it means an entity or an enumeration (the TypeEnumeration/TypeEntity ambiguity), so accept both kinds unless `ExplicitEnum`. **`exec` exit 0 is not proof a forward reference is safe** — describe the result and check the reference actually got wired before adding it to the tolerated list. Regression probe that matters: run `check` over all of `mdl-examples/` and expect **zero** new findings (it found exactly one, a fixture whose GRANT genuinely preceded its entity). Issue #955", "refs": ["#955"]}
-{"area": "mdl/executor", "symptom": "A pluggable widget's `onClick:` / `OnChange:` is a **one-way write**: the action lands in the `.mxunit` and builds at 0 errors, but `describe page` omits it, so describe→exec deletes the wiring. Or `OnChange:` is refused outright by **MDL-WIDGET01** with the self-contradicting *\"property `OnChange` is the widget's internal storage name … use `OnChange:` instead\"*", "cause": "A widget's **storage key is not MDL's name** for the slot, and only the writer knew. Mendix's own widgets suffix theirs — BadgeButton stores `onClickEvent`, HeatMap `onClickAction`, Combobox `onChangeEvent` — while Slider/RangeSlider/StarRating store the bare `onChange`. `actionSourceForKey` strips one `Event`/`Action` suffix (ledger #14); the reader looked up the literal string `\"onClick\"`, the generic describe path read no OnChange at all, and `OnChange` was missing from `isBuiltinPropName` (where `Action` was present) so MDL's own spelling collided with the storage-name check", "file": "`mdl/executor/cmd_pages_describe_pluggable.go` (`customWidgetActionForSource`), `mdl/executor/cmd_pages_describe_parse.go` (both custom-widget branches), `mdl/executor/cmd_pages_describe_output.go` (the generic pluggable branch condition + emission), `mdl/executor/widget_engine.go` (`isBuiltinPropName`)", "insight": "Resolve the stored key **through `actionSourceForKey`** rather than a second copy of the rule, so the reader cannot drift from the writer again; read **both** sources, not just OnClick; add `OnChange` beside `Action` in `isBuiltinPropName`. **`mx check` is not the oracle** — a page that lost its action is a valid document, 0 errors before and after; verify by describing the page back and by `strings`-ing the `.mxunit`. **Controls**: restore the literal `\"onClick\"` lookup → only the suffixed widgets fail; drop `OnChange` from `isBuiltinPropName` → only the same-spelling widgets fail. **Idempotence trap**: re-running the whole repro aborts at `module role already exists` before reaching a page, so an \"Unchanged\" check passes vacuously — re-run only the page statements, with `MXCLI_ALWAYS_WRITE=1` as the control. **Slider is not a usable fixture**: it raises CE0463 when mxcli writes it at all (measured with an action-free control), unrelated to action slots — use StarRating, which stores the same bare `onChange` and builds clean. Repro `mdl-examples/bug-tests/956-pluggable-widget-action-slot-names.mdl`. Issue #956", "refs": ["#14", "#956"], "ce": ["CE0463"]}
-{"area": "mdl/executor", "symptom": "A pluggable widget's action slot has **no MDL surface** — `mxcli check` says *\"property `X` is recognized but not yet persisted by mxcli — a non-default value will be dropped; set it in Studio Pro if needed\"* (**MDL-WIDGET06**), so a widget can be placed but not wired. File Uploader's six slots, DataGrid2's `onSelectionChange`, Switch's `action`", "cause": "`actionSourceForKey` recognises only `onclick`/`onchange` (after stripping one `Event`/`Action` suffix) and `GenerateDefJSON` emitted a mapping **only** when it returned non-empty, so every other action-typed property got none and the engine had nothing to write", "file": "`mdl/executor/widget_defs.go` (`GenerateDefJSON` `case \"action\"`), `mdl/executor/widget_named_action_slot.go`, `mdl/executor/widget_engine.go` (`resolveMapping`'s no-Source branch), `mdl/grammar/domains/MDLPage.g4` (`widgetPropertyV3`), `mdl/visitor/visitor_page_v3.go`, `mdl/executor/validate_widgets.go` (`readsFixedASTSlot`)", "insight": "Emit a mapping for **every** action-typed property; one with no MDL alias carries **no `Source`** and is addressed by its own `PropertyKey` — the shape object-list item mappings already use, so it adds no concept. `microflow`/`nanoflow` on such a slot parse as a **DataSourceV3**: `dataSourceExprV3` and `actionExprV3` overlap and the datasource alternative must keep winning (else a chart series' `staticDataSource: microflow M.X` becomes an action), so the executor converts it — the same split `fragmentArgValue` resolves. Add the grammar alternative AFTER the datasource one for the unambiguous forms. **A `readsFixedASTSlot` that takes only the operation is wrong now**: an action mapping reads a fixed AST slot only when it HAS a Source. **Test the engine wiring separately from the AST reader** — stubbing out `resolveMapping`'s call left every reader test green. **Watch for conditional slots**: DataGrid2's `onSelectionChange` is `hidden when itemSelection = None` and writing into a pruned slot is CE0463 — control is the same page with the slot unset, which builds clean; `mxcli widget describe <name>` lists the conditions. Repro `mdl-examples/bug-tests/956-named-action-slots.mdl`. Issue #956", "refs": ["#956"], "ce": ["CE0463"]}
-{"area": "mdl/executor", "symptom": "A pluggable widget mxcli writes fails **CE0463** even with no action and nothing but `Attribute:` set, while the SAME widget placed by hand in Studio Pro in the same project is clean. Slider and RangeSlider both", "cause": "**Two causes, and neither alone is enough.** (A) The bare `Attribute:` keyword filled EVERY attribute-typed mapping — a Slider declares four (`valueAttribute`, `min/max/stepAttribute`), so one keyword wrote the same AttributeRef into all of them, and Studio Pro leaves min/max/step unset unless the matching `*ValueType` is \"attribute\". (B) `tooltip` got a populated `Forms$ClientTemplate` where Studio Pro stores `TextTemplate: nil` — the #574 class — because the visibility extractor lifted only the ELSE branch of `showTooltip ? \"value\"===tooltipType && hide(\"tooltip\") : hide([\"tooltip\",…])`, so a tooltip hidden by the widget's own DEFAULTS read as visible and `ApplyVisibilityRules` took its *visible* branch and FILLED an empty template", "file": "`mdl/executor/widget_engine.go` (`isPrimaryAttributeMapping`, `currentDef`), `mdl/executor/editorconfig_extract.go` (`ternaryThenCandidate`, `splitTernaryThenGuard`, `negate`, `?` boundary case in `parseGuard`); tests `mdl/executor/editorconfig_ternary_then_test.go`, `mdl/executor/widget_primary_attribute_test.go`", "insight": "**Diff the two widgets in ONE project file, and diff the `Type` first to eliminate it**: here the whole `Type` — 27 PropertyTypes, their order, their nested ValueType maps, the metadata — was **byte-equivalent** once random `$ID`s were normalised, which rules out schema/order/template-version and leaves only the stored `Object`. **A conjunction is not expressible** as one `WidgetVisibilityCondition`, so the then-branch's inner condition is emitted ONLY when another rule hides the same property under the negation of the outer one — the else branch — making the pair a correct disjunction (`hidden ⟺ ¬showTooltip ∨ tooltipType==\"value\"`); without that cover, skipping is safe (degrades to \"not hidden\") and guessing is CE0463's mirror image. **Why Slider and not ProgressCircle**, whose shape looks identical: ProgressCircle parenthesises the branch, which the existing grouping-paren strip removes; Slider does not, so the guard arrived as `e.showTooltip?\"value\"===e.tooltipType` and `lastGuardExpr` handed back a `?` boundary nothing handled. **A hidden list can be COMPUTED and then nothing is liftable** — Slider's min/max/step hides are `[].concat(n(v[e.minValueType]), …)`, table lookups with no string literal — so the hidden-property guard cannot cover cause A at all; not writing the property is the only fix that does not depend on that data. Issue #238", "refs": ["#238", "#574"], "ce": ["CE0463"]}
-{"area": "mdl/executor", "symptom": "A pluggable widget's property-visibility rule is **wrong rather than missing**: `.def.json` gains a rule for a key that is not a property at all, and two mutually-exclusive properties are both recorded under the same guard. Downstream, `MDL-WIDGET10` stays silent and the widget serializes a value into a slot Studio Pro prunes → **CE0463**", "cause": "`hideTargetKeys` scanned a `hidePropertiesIn([...])` array with `stringLitRE.FindAll`, harvesting **every** string literal in it. For `[\"files\"===e.uploadMode?\"associatedImages\":\"associatedFiles\", …]` that yields three keys — `files` (the *comparison value*), plus BOTH branches — all attributed to the enclosing guard, with the ternary's own condition lost. The extractor already handled a ternary wrapped **around** a hide call, which is why sibling properties in the same file (`onUploadSuccessImage`) were gated correctly and these were not", "file": "`mdl/executor/editorconfig_extract.go` (`ternaryKey`, `ternaryElement`, the conditional-element branch in `hideTargetKeys`, and per-branch emission in `extractVisibilityRulesFromJS`); test `mdl/executor/editorconfig_ternary_test.go`", "insight": "**A wrong rule is worse than no rule** — `SkippedComplex` degrades to \"not hidden\", which is safe; a mis-attributed rule prunes the wrong property in the wrong configuration. Reuse `guardToCondition` with its `falsy` flag rather than writing a second comparison parser: then-branch is `eq`, else-branch is `ne`, and the polarity logic already exists for the ternary-around-a-call case. **Verify against a regenerated `.def.json`, not just the unit test** — `mxcli widget init` then read `propertyVisibility` back; the observable effect is that the bogus key disappears and the two branches carry opposite conditions. Visibility is applied at **serialization** time (`widget_engine.go` → `ApplyPropertyVisibility`), not only in validation, so a wrong rule reaches the stored BSON. Measured on File Uploader 2.5.0 (marketplace 235351): before, `associatedImages` carried only `readOnlyMode truthy`; after, `uploadMode eq files` — and MDL-WIDGET10 fires where it was silent. Issue #956", "refs": ["#956"], "ce": ["CE0463"]}
-{"area": "mdl/executor", "symptom": "An action written on an object-list **item** — a chart series' `StaticOnClickAction:`, a popupmenu item's `action:`, a maps marker's `onClick:`, an accordion group's `onToggleCollapsed:` — is accepted by `mxcli check`, the page is written, `mx check` reports 0 errors, and the slot is **empty**. `DESCRIBE` does not mention it either, so nothing reveals the loss", "cause": "The executor's item-property switch had no `action` case and fell to `default: continue`, carrying `TODO(#538 follow-up)`. Everything under it was already in place — the `.def.json` carries the mapping (`operationForType` returns `\"action\"`), `backend.ObjectListItemProperty` has an `Action` field, and `widgetobj/builder.go` writes `Value.Action` — so the action reached the AST, matched a mapping, and fell off the end of a switch. `mdl/backend/mcp/widget.go`'s item switch had no `action` case either", "file": "`mdl/executor/widget_engine.go` (item switch → `namedActionSlotValue` + `buildClientActionV3`), `mdl/executor/cmd_pages_describe_objectlist.go` (the `Action` branch in `extractObjectListItem`), `mdl/backend/mcp/widget.go` (`SetObjectList` → `customWidgetClientAction`); tests `mdl/executor/widget_item_action_slot_test.go`, `mdl/backend/mcp/widget_item_action_test.go`; example `mdl-examples/bug-tests/956-object-list-item-action-slots.mdl`", "insight": "**Read the slot through `namedActionSlotValue`, not off the AST's `Action` field.** `microflow M.X` in a property position parses as a **`*DataSourceV3`** — `dataSourceExprV3` wins in `widgetPropertyV3`, deliberately, or a series' `DataSource: microflow M.X` would become an action — so a direct read misses the form people actually write **and** takes the `datasource` branch of the same switch on the way past. Only the widget definition knows the slot is an action. **Three switches, not one**: executor write, DESCRIBE read, MCP builder — patching the first alone gives a page that holds the action and describes as though it does not, which is the lossy round trip wearing the right answer. **A NoAction is the unset default** and must be skipped on read and never written on an unset slot, or every untouched item grows a line and re-exec clears what the widget had. `mx check` is no oracle in either direction — a series with no click action is a normal series, 0 errors before and after; verify by describing back and reading the `.mxunit`. When faking stored BSON in a test, the `$Type` is the **storage** name: `Forms$MicroflowAction`, not `Forms$MicroflowClientAction` (`sdk/mpr/writer_widgets_action.go` is the arbiter) — a wrong one makes the reader silently skip and reads as the fix not working. Issue #956", "refs": ["#538", "#956"]}
-{"area": "mdl/executor", "symptom": "An MDL keyword that several widget properties share writes into **all** of them, including one the widget's configuration hides — **CE0463**. Naming the keyword once is then also reported by `MDL-WIDGET10` as having set a property the script never mentions, so the statement is refused even though it is correct", "cause": "Two causes, one in each direction. `widgetValueMap` marked a property `explicit` whenever it was reached through `m.Source`, so a keyword routed to several properties counted as naming each of them. And the write path had nothing that skipped a hidden property: `ApplyVisibilityRules` is scoped to **TextTemplate**-typed properties (it was built for #574), so a hidden DataSource or primitive was written normally", "file": "`mdl/executor/validate_widgets.go` (`sharedSource` in `widgetValueMap`), `mdl/executor/widget_engine.go` (`hiddenUnnamedProperties`, consulted in the mapping loop); test `mdl/executor/widget_hidden_shared_source_test.go`", "insight": "**Skip the mapping; do not clear the property afterwards.** Measured on a Studio Pro-authored File Uploader 2.5.0: **34 of 34** declared properties are stored, the hidden ones at their DEFAULT — so \"hidden\" means default-valued, not absent, and letting the widget template's default survive reproduces Studio Pro exactly while post-hoc nulling would not. **Only skip a property the script did not name** — naming a hidden property outright stays an MDL-WIDGET10 error, which is the DataGrid2 `onSelectionChange` case and must keep firing; the discriminator is whether the source is shared by more than one mapping, not whether the property is hidden. `mx check` is the only oracle: the wrong write is a valid document until Studio Pro loads it, and the MDL-WIDGET10 false positive looks like a correct refusal. Issue #956", "refs": ["#574", "#956"], "ce": ["CE0463"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE PAGE` omits a pluggable widget's own **datasource**, so `describe → exec` drops it. Measured: a Studio Pro-authored File Uploader at **0 errors** comes back as **CE0642** \"Property 'Associated files' is required\" plus **2× CE1571** \"no argument has been selected for parameter\" — and the DESCRIBE text is **byte-identical** before and after, so the round trip looks lossless", "cause": "The generic pluggable-widget renderer emitted `Label`, explicit properties, `onClick`, `OnChange`, named actions and appearance — and never `w.DataSource`. The parse side had been populating a field nothing printed. Only the per-widget branches (ComboBox, DataGrid2, Gallery, drop-down filter) emitted one, via their own extractors", "file": "`mdl/executor/cmd_pages_describe_output.go` (`appendDataSourceProp` in the generic pluggable branch), `mdl/executor/cmd_pages_describe_parse.go` (generic fallback), `mdl/executor/cmd_pages_describe_pluggable.go` (`anyCustomWidgetDataSource`)", "insight": "**The CE1571s are a consequence, not a second bug** — an action's parameter loses its default once the datasource providing the object is gone, so all three errors clear together; chasing the parameter mappings separately is wasted work. **`firstObjectPropertyDataSource` is not a substitute**: it returns as soon as a property's DataSource parses to a non-nil value, even one carrying no reference, and a File Uploader has such a property AHEAD of its real one — so the caller got an empty datasource, discarded it, and described the widget as having none. Keep scanning until one names something. **Verify with `mx check`, never with a describe diff**: the text matched exactly while the model lost data, and an exec that fails to parse re-describes identically too — so confirm the exec actually ran (`Replaced …`) before believing a round-trip test. Issue #956", "refs": ["#956"], "ce": ["CE0642", "CE1571"]}
-{"area": "mdl/executor", "raw": "| A `describe → exec` round trip on a page whose object-list item carries a **text template with a placeholder** turns a building page into **CE0720** \"Place holder index 1 is greater than 0, the number of parameter(s)\". The DESCRIBE text is identical before and after | Two bugs, one on each side. DESCRIBE emitted the template's TEXT and discarded its parameters — `extractTextTemplateText` already returns the template map and `extractObjectListItem` threw it away. And the engine read the companion with a **case-sensitive map index**, `child.Properties[matchedAlias+\"Params\"]`, where `matchedAlias` is the SCHEMA key (`buttonCaption`) while the script and DESCRIBE write the widget's own casing (`ButtonCaptionParams`) | `mdl/executor/cmd_pages_describe_objectlist.go` (emit `<Key>Params`), `mdl/executor/widget_engine.go` (`lookupProperty` for the companion), `mdl/grammar/domains/MDLPage.g4` + `mdl/visitor/visitor_page_v3.go` (a generic `<Name>Params` form); tests `mdl/executor/widget_item_template_params_test.go` | **Fix both sides or neither shows**: emitting the params without the lookup fix still drops them, and the lookup fix alone has nothing to read — each half has its own control. **The grammar had no generic form**: only `ContentParams`/`CaptionParams` have tokens, so emitting `ButtonCaptionParams` first requires `(IDENTIFIER | keyword) COLON paramListV3`, placed BEFORE the generic `propertyValueV3` alternatives — which also admit `[...]`, and `{N} = expr` inside is what separates them. Render through `formatParametersV3`: `extractClientTemplateParameters` returns bare expressions and `paramListV3` needs `{N} = expr`, so a raw join produces `['abc']`, which parses as an ARRAY and silently sets the wrong thing. **The case-sensitivity agreed by luck for a DataGrid column** (`Caption` → `CaptionParams` matches what MDL writes), which is why the defect survived — any test using a column passes. Issue #956 |", "refs": ["#956"], "ce": ["CE0720"]}
-{"area": "mdl/executor", "symptom": "`rest call … returns mapping M.IMM as Module.Entity` builds cleanly — `mxcli check`, `mx check` 0 errors, mxbuild fine — and throws the moment the activity runs, over a valid response body: `MicroflowException: key not found: Path(QName(None,),None,)` at `MappingCache.storeValueMappingElement`. `as list of` instead fails the BUILD with CE0243, so an object-rooted mapping has no working `returns mapping` form at all", "cause": "The REST branch mirrored BOTH of the ImportMappingCall's flags onto the result variable's cardinality. They are three axes, not one: `SingleObject` types the VARIABLE, `ForceSingleOccurrence` means \"the mapping yields many, bind one\", `Range.SingleObject` is Studio Pro's First/All. `as Entity` set all three true, so an OBJECT-rooted mapping was told to force an occurrence it does not have. #192 fixed the identical conflation in the sibling `import from mapping` branch and never reached this one", "file": "`mdl/executor/cmd_microflows_builder_calls.go` (`addRestCallAction`'s `ast.RestResultMapping` case + the shared `mappingRootIsList` helper); tests `mdl/executor/cmd_microflows_rest_mapping_occurrence_test.go`; example `mdl-examples/bug-tests/242-rest-mapping-single-object-runtime.mdl`", "insight": "**Measure the flags one at a time before fixing.** All four combinations were run in one boot over the same mapping and JSON: `FSO=true/Range=true` FAIL, `FSO=true/Range=false` FAIL, `FSO=false/Range=false` PASS, `FSO=false/Range=true` PASS — so `ForceSingleOccurrence` alone drives the exception and `Range` is innocent, which is NOT what reading the code suggests. **Do not write `ForceSingleOccurrence=false` unconditionally**: that fixes the object-rooted case and silently strips the flag from `PrivateCloudData.REST_GetEnvironmentByUUID`, a Studio Pro document that binds one object out of a LIST-rooted mapping and stores it true (recorded in `mdl-examples/bug-tests/519-rest-mapping-as-list-of.mdl`). Infer it from the MAPPING's root instead — true only when the mapping yields many AND the call site binds one. An unresolvable mapping must read as object-rooted: guessing \"list\" fails at RUN time, guessing \"object\" is caught by mxbuild as CE0243 at BUILD time. **A unit test on the flags is not enough** — every static check passes on the broken document, so the regression example has to be driven through `mxcli test --local` with a real JSON endpoint (`python3 -m http.server`), and the generated test wrapper swallows the exception text: call `MxTest.Test_*` directly through `/mxtest/run` with the token from `<project>/.mxcli/test-endpoint.json` to read it. Issue #242", "refs": ["#192", "#242"], "ce": ["CE0243"]}
-{"area": "mdl/executor", "symptom": "Someone translates the whole app into a language with `create translations`, every run reports success, `mx check` is clean — and the app shows not one translated string", "cause": "The project had not ENABLED that language. Enabled languages (`Settings$LanguageSettings.Languages`) decide what the build emits; a translation for any other language is stored in the model, survives every check, and is discarded at build time. Measured on mxbuild 11.13.0: a caption translated into de_DE on a blank app (which enables en_US only) builds at 0 errors and the German string appears NOWHERE under `deployment/` — no `translations_de_DE.properties`, and \"de_DE\" does not occur in the built model at all; the English control appears in three files. A stock app invites the mistake: it enables ONE language while its marketplace modules ship translations in NINE, so \"other languages already have translations here\" is true and misleading", "file": "`mdl/executor/language_enablement.go` (`languageIsEnabled`, `unenabledLanguageWarning`), wired into `mdl/executor/cmd_translations.go` and surfaced by `mdl/executor/cmd_settings.go` (both `show` and `describe`)", "insight": "Warn, do not refuse: Mendix tolerates the state at **both** layers — measured live over PED, Studio Pro loads the unenabled language's translation and keeps it beside the enabled one (`{\"languageCode\":\"sv_SE\",\"text\":\"Etikett\"}` next to the en_US entry on a caption in an en_US-only project), reporting no error; only the BUILD drops it — and refusing would break the legitimate order of \"translate now, enable when the review lands\". **Unknown must not read as disabled** — with no settings, or a settings part carrying no `Languages`, a warning would be a guess, and a false warning about a language that IS enabled trains people to ignore the true one. DESCRIBE lists the enabled languages as a **comment**, because MDL cannot author the list (`alter settings LANGUAGE` carries `DefaultLanguageCode` only) and a statement that does not re-execute is worse than a comment that does not. The measurement that settles any doubt is `mxbuild --target=deploy` plus a same-page control string in the default language — `mx check` says nothing either way. Repro `mdl-examples/bug-tests/translations-unenabled-language.mdl`"}
-{"area": "mdl/executor", "raw": "| `describe settings` output does not replay onto another project: it stops at `Error: configuration not found: <name>`, and before that it silently lost every enabled language | DESCRIBE emitted the verbs that read best rather than the ones that re-execute — `alter settings configuration` for a configuration the target may not have, and a COMMENT for the language list. Round-trip was never asserted, so both were invisible: the output looks correct and cannot be run | `mdl/executor/cmd_settings.go` (`describeSettings`, `writeSettingsConfiguration`), `mdl/executor/cmd_settings_languages.go`, plus the upserts that make replay possible: `alterSettingsLanguageUpsert` and `CreateConfigurationStmt.CreateOrModify` (`mdl/ast/ast_settings.go`, `mdl/visitor/visitor_settings.go`, `createConfiguration`) | Emit **upsert** verbs — `create or modify configuration`, `alter settings LANGUAGE add or modify` — because the plain CREATE/ADD forms refuse what is already there, which is right for a hand-written script and wrong for a described project replayed onto itself. Note `CREATE (OR (MODIFY\\|REPLACE))?` was **already** in the grammar generically, so `create or modify configuration` parsed and silently behaved as a plain CREATE: a documented upsert that answered \"already exists\". Order matters — `DefaultLanguageCode` is validated against the enabled list, so it must come AFTER the languages — and every option must be named, because MODIFY touches only what it names. **Test both directions**: replay onto the SAME project (unit byte-identical, and the run reports `Unchanged`, not `Updated`) and onto a BLANK one (settings document identical field for field). The same-project replay is what exposes verb dishonesty; the blank-project replay is what exposes a missing upsert. Known boundary: settings that REFERENCE module documents (`AfterStartupMicroflow`, a constant override) legitimately dangle on a project without them — mxbuild says CE1613 — and mxcli neither warns nor validates those references, which is tracked separately. Example `mdl-examples/doctype-tests/languages.mdl` |", "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "A Java action, JavaScript action or microflow **silently loses its Studio Pro toolbox entry** on an unrelated rewrite. Two shapes: with `exposed as …` kept, the icon and image PNGs come back as empty binaries; with the clause omitted, the whole entry disappears — caption, category, icon and image — and the action vanishes from the palette. `mx check` reports **0 errors** in both cases", "cause": "`CodeActions$MicroflowActionInfo` has six fields (Caption, Category, IconData, IconDataDark, ImageData, ImageDataDark) and MDL's clause names two, so the write path *constructed* the sub-document from the clause instead of merging onto the stored one. Compounded on the default engine by a read that never loaded the bitmaps: `modelsdk/gen` declares all four as `string` while Mendix stores BSON **binary**, so `DecodeString` returned `\"\"` for every real icon — the same gen/storage mismatch class as scheduled events and regular expressions", "file": "`mdl/executor/expose_action_info.go` (`mergeMicroflowActionInfo`, `applyExposeClauses`, `applyExposeBitmaps`), `mdl/executor/cmd_javaactions.go`, `mdl/executor/cmd_javascript_actions_write.go`, `mdl/executor/cmd_microflows_create.go`, `mdl/backend/modelsdk/java_read.go` (`readActionInfoBitmaps`, `actionInfoFromGen`), `mdl/backend/modelsdk/microflow_write.go` (`patchMicroflowToolboxEntries`); tests `mdl/executor/cmd_javaactions_expose_preserve_test.go`, `mdl/executor/expose_action_bitmaps_test.go`; example `mdl-examples/doctype-tests/39-expose-as-toolbox-action.mdl`", "insight": "**Silence is preservation, not removal** — an absent clause must carry the stored value, so removing needs its own syntax (`NOT EXPOSED`, `DROP ICON`). Rebuilding a sub-document from the subset MDL can express is the general shape of this bug (ADR-0005); look for `X = &T{...}` where `X` is a stored polymorphic child. **Check the READ before blaming the write**: a merge cannot carry what the reader never loaded, and a gen accessor typed `string` over a BSON binary fails silently to `\"\"`. **Two microflow renderers exist** in `cmd_microflows_show.go` (`describeMicroflow` and `renderMicroflowMDL`) — patching one leaves DESCRIBE unchanged on the path the CLI actually takes. A test fixture generating two same-sized PNGs produces **identical bytes**, so an \"each target is routed separately\" assertion passes vacuously unless the fixtures differ"}
-{"area": "mdl/executor", "symptom": "`alter settings` writes a microflow, entity or constant name that does not exist, reports success, and `mxcli check --references` calls the script valid — the build then fails with **CE1613** *\"The selected microflow/constant no longer exists\"*. A misspelled constant is worse than a dangling pointer: the override is **created** for a constant that does not exist, leaving dead configuration data", "cause": "Settings were the ONLY statement family that resolved nothing. `--references` walks `validateWithContext`, whose switch had no `*ast.AlterSettingsStmt` case at all, so the qualified names in `AfterStartupMicroflow` / `BeforeShutdownMicroflow` / `HealthCheckMicroflow`, workflow `UserEntity` and the constant override went straight to the writer", "file": "`mdl/executor/validate_settings_refs.go` (`validateSettingsReferences`, `validateSettingsConstantRef`), wired into `mdl/executor/validate.go` (the `AlterSettingsStmt` case + `scriptContext.constants`) and into `alterSettings` itself; index helper `buildConstantQualifiedNames` in `mdl/executor/helpers.go`", "insight": "Put the guard in the **handler**, and have check call the same functions — that is what makes `exec` refuse exactly what `check` reports, including under `--no-check`, and it is why the exec-time call passes a **nil script context**: by then the earlier statements have run, so anything the script created is really in the project. Three cases a naive resolver gets wrong, each with a test: an **empty value clears** the setting (Studio Pro's \"(none)\") and must not be resolved; a document **created earlier in the same script** is not missing (the escape hatch every other family has, which is why the fixture pair is a `.fail.mdl` AND a passing control); and **dropping** a constant override must stay legal even when the constant is gone, or there is no way to tidy up after deleting one. Note the two `ValidateProgram`s are different passes — the package-level one (which `exec` runs) has only a project PATH, while the reference pass has a connected backend, so a check needing project reads cannot live in the first. Repro `mdl-examples/bug-tests/274-settings-reference-validation.fail.mdl` + `274-settings-reference-valid.mdl`. Issue #274", "refs": ["#274"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "`alter settings` writes a microflow, entity or constant name that does not exist, reports success, and `mxcli check --references` calls the script valid — the build then fails with **CE1613** *\"The selected microflow/constant no longer exists\"*. A misspelled constant is worse than a dangling pointer: the override is **created** for a constant that does not exist, leaving dead configuration data", "cause": "Settings were the ONLY statement family that resolved nothing. `--references` walks `validateWithContext`, whose switch had no `*ast.AlterSettingsStmt` case at all, so the qualified names in `AfterStartupMicroflow` / `BeforeShutdownMicroflow` / `HealthCheckMicroflow`, workflow `UserEntity` and the constant override went straight to the writer", "file": "`mdl/executor/validate_settings_refs.go` (`validateSettingsReferences`, `validateSettingsConstantRef`), wired into `mdl/executor/validate.go` (the `AlterSettingsStmt` case + `scriptContext.constants`) and into `alterSettings` itself; index helper `buildConstantQualifiedNames` in `mdl/executor/helpers.go`", "insight": "Put the guard in the **handler**, and have check call the same functions — that is what makes `exec` refuse exactly what `check` reports, including under `--no-check`, and it is why the exec-time call passes a **nil script context**: by then the earlier statements have run, so anything the script created is really in the project. Three cases a naive resolver gets wrong, each with a test: an **empty value clears** the setting (Studio Pro's \"(none)\") and must not be resolved; a document **created earlier in the same script** is not missing (the escape hatch every other family has, which is why the fixture pair is a `.fail.mdl` AND a passing control); and **dropping** a constant override must stay legal even when the constant is gone, or there is no way to tidy up after deleting one. Note the two `ValidateProgram`s are different passes — the package-level one (which `exec` runs) has only a project PATH, while the reference pass has a connected backend, so a check needing project reads cannot live in the first. Repro `mdl-examples/bug-tests/274-settings-reference-validation.mdl` + `274-settings-reference-valid.mdl` — a plain `.mdl`, NOT `.fail.mdl`: `make check-mdl` runs `mxcli check` without a project, and a rule that resolves names against the model cannot decide anything there, so the file checks clean and `.fail.mdl` would report \"negative test unexpectedly passed\" — a working rule made to look regressed. The Makefile documents this above `check-mdl` (#891/#892); CI caught it here. Issue #274", "refs": ["#274", "#891", "#892"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "A decision inside `while` is written with only its **true** flow — Studio Pro reports **CE0079** *\"the 'false' condition value should be configured on an outgoing sequence flow\"*. `mxcli check` reports \"Syntax OK\" and exit 0, so the broken microflow is written by `exec` and surfaces only in the Errors pane. The same body inside `loop` is correct", "cause": "A merge-less split (`if X then break` / `then continue`) defers its FALSE case to the next flow. `addLoopStatement` tracks that deferred case through the body and wires whatever is left over to a synthesized `ContinueEvent` (ledger #52); `addWhileStatement` had **neither** the `pendingCase` variable nor the trailing block, so the case was dropped. Four shapes affected: break-last, continue-last, either with a trailing statement, either after a leading statement", "file": "`mdl/executor/cmd_microflows_builder_control.go` (`addWhileStatement`, the `pendingCase` loop + trailing `addContinueEvent` block)", "insight": "Mirror `addLoopStatement` **verbatim** — a WHILE body is a loop body, and the divergence was the whole defect. The durable guard is the **parity test**: assert LOOP and WHILE agree on the same body, which is what would have caught the ledger #52 fix landing in only one of two builders. Grep for the sibling before fixing any loop-body defect. Note `return`-in-a-loop is refused by MDL062, so `break` and `continue` are the only live shapes. Not expressible as a `.fail.mdl`: the MDL is **valid** and `check` is right to accept it (this is a writer defect, not a check gap), so the guards are unit tests in `mdl/executor/cmd_microflows_while_break_test.go`. Repro `mdl-examples/bug-tests/893-while-break-false-edge.mdl`. Issue #893 case 3 — note the reported shape (`IF` first in a WHILE body) did **not** reproduce; this was found by probing its neighbourhood, and cases 1/2/6 were already fixed by MDL061/062/063", "refs": ["#52", "#893"], "ce": ["CE0079"], "rules": ["MDL061", "MDL062"]}
-{"area": "mdl/executor", "symptom": "`describe microflow` renders a loop with an **empty body** — `loop $X in $L begin end loop;` — when the body carries an `@annotation`. Silent, exit 0, and the truncated script passes `check`, so the documented describe → exec round trip **deletes the loop body**. `bson dump` and `--format mermaid` both still show the activity", "cause": "`emitLoopBody` picks the body's start as \"no incoming sequence flow, leftmost then topmost\" (`preferLoopBodyStart`). A `*microflows.Annotation` **is** an object in `ObjectCollection.Objects` but connects via `AnnotationFlows`, never `Flows`, so its incoming count is permanently 0 and it was always a start candidate. When it won, traversal began at a node with no outgoing sequence flow and emitted nothing. Only loops: the top level starts from its `StartEvent`, and mermaid iterates objects directly rather than traversing", "file": "`mdl/executor/cmd_microflows_show_helpers.go` (`isFlowNode`, and the `incomingCount` candidate loop in `emitLoopBody`)", "insight": "**The defect is positional, and that is the trap**: annotation LEFT / ABOVE-same-X / ABOVE-LEFT lose the body, annotation RIGHT renders correctly *including* the annotation — so a fixture that puts it on the right passes against broken code. Cover all four. **Not Studio Pro-only**, which was the first wrong reading: mxcli's own builder emits the annotation at the same X and above (measured activity (150,80), annotation (150,-20)), the losing shape, so mxcli destroyed loop bodies it authored itself. **Why #330 missed it**: that fixture covers the same construct, but its Go regression tests the AST→BSON *build* path and its describe assertion is a manual procedure in a comment — `make check-mdl` runs without a project, so CI only syntax-checked it. Nothing had ever *described* an annotated loop body. The durable guard is a **build → describe round trip** using the builder's real positions, asserting its own premise so it fails loudly if layout changes stop it exercising the defect. Not expressible as `.fail.mdl` (the MDL is valid; the bug was in describe). Repro `mdl-examples/bug-tests/965-loop-body-lost-to-annotation.mdl`, guards `mdl/executor/cmd_microflows_describe_loop_annotation_test.go`. Issue #965", "refs": ["#330", "#965"]}
-{"area": "mdl/executor", "symptom": "`create association … comment 'text'` reports success and stores **no documentation**, and a `/** … */` doc comment before the statement is dropped too — so an association is the one domain-model element with no working way to document it on create. `mx check` passes (an undocumented association is valid), and `describe association` simply shows nothing", "cause": "Both halves sit upstream of the writer, which has emitted `Documentation` all along. (1) `mdl/visitor/visitor_association.go` never called `findDocCommentText(ctx)`, the way the entity and enumeration visitors do, so `stmt.Documentation` was always empty. (2) The **plain-CREATE** branches of `execCreateAssociation` built the `Association` / `CrossModuleAssociation` literal without a `Documentation` field at all — while the `OR MODIFY` branches a few lines above them *do* set it, which is what makes the field look wired when the file is read casually", "file": "`mdl/executor/cmd_associations.go` (`associationDocumentation`, both plain-CREATE literals, both OR MODIFY branches), `mdl/visitor/visitor_association.go`; tests `mdl/executor/cmd_associations_documentation_test.go`", "insight": "**A field set on the OR MODIFY path is not evidence it is set on the CREATE path** — the two construct the element separately and sit next to each other. Grep for the struct literal, not for the field name. This is also why `comment` was *kept* on `create association` when it was removed from entity/enumeration/module/microflow/nanoflow/rule: there the doc comment already worked so the dead option was redundant, but here **neither** spelling worked, and removing the option would have left nothing at all. Check both spellings before deciding whether an option is dead or load-bearing"}
-{"area": "mdl/executor", "raw": "| Every member of an **array-rooted** import/export mapping is rejected: `\"id\" is not a member of the JSON structure at (Object), which has no members there` — while the identical body over an object-rooted structure works | Both executors hardcoded the root lookup to `\"(Object)\"`, and an array-rooted structure is built at `\"(Array)\"` with its item at `\"(Array)|(Object)\"` (`buildElementFromRawRootArray`). The root resolved to nothing, so the child lookup reported members \"at (Object)\" — a node that structure never had, which reads as \"your key is wrong\" rather than \"the root was looked up in the wrong place\". 122 of the 327 mapping documents in the demo apps are array-rooted, the single largest gap in the mapping surface | `mdl/executor/cmd_import_mappings.go` (`buildImportMappingElementModel`, `jsonSchemaIndex.root`), `mdl/executor/cmd_export_mappings.go` (`buildExportMappingElementModel`, `buildExportRootArrayElement`, `exportRootToPrint`) | Take the root FROM the structure instead of assuming it. No new syntax: the structure decides, and Studio Pro does not ask either. The import side then needs nothing more — the array branch was already stepping `\"(Array)\"` → `\"(Array)|(Object)\"` for NESTED arrays. **The two sides store different shapes and the difference is not guessable**: an array-rooted IMPORT mapping is ONE element at `(Array)|(Object)` (the container collapses), an array-rooted EXPORT mapping is a bare `Array` container at `(Array)` whose single child carries the entity with `ObjectHandling=Parameter`. Pin both against Studio Pro documents before writing either (`Teamcenter.IMM_ItemRevision`, `FactoryManagement.IMM_ScenarioList`, `SnowflakeIntegration.EXM_SensorData` — Evora demo app, 11.13). A second export shape exists (`DigitalTwin.EMM_EntityQuery`: entity on the container, `Find` on the item, for a parameter that OWNS the list) and MDL cannot say which is meant, so it stays unauthorable — #262. **Adding an authorable shape means teaching DESCRIBE about it in the same change**, or the newly writable mapping joins the 112 silent-loss cases of #260: the export container is not `Kind==\"Object\"`, so it fell into the value branch and printed `Root = ` with its whole subtree dropped. Discriminate the container on its stored **JsonPath**, not on `Kind` — the two engines' readers label it differently (\"Array\" vs \"Object\") and only the path is in the document. Controls: revert the root lookup and the repro returns verbatim, while the object-rooted control still passes; `mdl-examples/bug-tests/519-rest-mapping-as-list-of.mdl` goes from dying on its own mapping statement to executing. `mx check` needs the base project's own error count as the control (a blank app carries a pre-existing CE0495). Repro `mdl-examples/bug-tests/248-array-rooted-mappings.mdl`, tests `TestImportMappingArrayRoot` / `TestExportMappingArrayRoot`. Issue #248 |", "refs": ["#248", "#260", "#262"], "ce": ["CE0495"]}
-{"area": "mdl/executor", "raw": "| A mapping sourced from a **message definition** cannot be authored at all — MDL has `with json structure` and `with xml schema` and no third form — and `describe` of an existing one silently omits the source clause while still producing output that PARSES, so `describe` → `exec` rebuilds the mapping bound to nothing | 74 of the 327 mapping documents in the demo apps use one (the second-largest gap after the array root), 70 of them in the silent-loss class. The document is `MessageDefinitions$MessageDefinitionCollection` — a COLLECTION, which is why the reference is three parts (`Module.Collection.Definition`) — and it is derived from the **domain model**, not a payload sample: every node names an entity or an attribute and carries two names, its own (`Emails`) and the singular one its items take (`Email`) | `mdl/executor/mapping_messagedefinition.go` (`findMessageDefinition`, `messageDefPaths`, the two builders), `mdl/backend/modelsdk/messagedefinition_read.go`, `model/types.go` (`MessageDefinitionCollection`, and `XmlPath` on both mapping element types) | **A message-definition mapping stores BOTH path families** — that is the whole reason it needs its own builder rather than a branch of the JSON one: `json=(Array)\\|(Object)\\|From` beside `xml=Emails\\|Email\\|From`. The rules, measured on AgentCore.MesDef_Email / .MesDef_WorkflowDetails and Email_Connector.MD_EmailTemplate: an unbounded node contributes `ExposedName\\|ExposedItemName` to the XML path and `ExposedName\\|(Object)` to the JSON one, a single node contributes `ExposedName` to both, and the ROOT is the asymmetry — its own name is in the XML path but the JSON one is just `(Array)\\|(Object)`. `model.ImportMappingElement`/`ExportMappingElement` had **no XmlPath field** and every writer hardcoded `\"\"`, so that had to be added and carried on both engines' read and write paths first. **Do not \"helpfully\" drop the body**: the definition fixes entity, attributes and names, so a bodyless \"map everything\" form is tempting — measured, six of the ten real message-definition mappings map every exposed node and four map a strict subset (58 of 96, 27 of 30, 28 of 30, 26 of 27), so it would be lossy for 40% of them. `modelsdk/gen/messagedefinitions` already models the whole tree and decodes real documents unchanged (zero entries in `keyaudit_test.go`), so the read is one `mprread.ListUnitsWithContainer` call; the legacy engine has no parser and **refuses rather than returning an empty list**, because empty reads as \"this project has no message definitions\" and turns a real reference into a bogus \"not found\". The oracle is a Studio Pro mapping over the SAME definition: authoring `AgentCore.MesDef_Email.Email` from MDL reproduces `AgentCore.Email_Import` element for element. Repro `mdl-examples/bug-tests/263-message-definition-source.mdl`, tests `mdl/executor/mapping_messagedefinition_test.go`. Issue #263 |", "refs": ["#263"]}
-{"area": "mdl/executor", "symptom": "A value **converter microflow** — `Attr = Module.MF(jsonField)` — is accepted, the mapping is created, and the transform is silently absent; DESCRIBE prints the element as a plain `Attr = jsonField`", "cause": "The grammar and the AST already carried it (`Converter`, `ConverterParam` in `ast_import_export_mapping.go`) and nothing downstream read either: the model element had no `Converter` field and every writer hardcoded the BSON key to `\"\"`. The visitor also never set `JsonName` for that alternative, so even with a model field the member had no name to resolve against. 39 of the 327 demo-app mapping documents use one, including the two a blank app ships (`FeedbackModule.IMM_PostResponse`, `.EXM_PostFeedback`)", "file": "`mdl/executor/mapping_messagedefinition.go` (`setMappingConverter`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go` (build + describe), `mdl/visitor/visitor_import_export_mapping.go`, `model/types.go`, and the four writers + four readers", "insight": "**A half-wired feature is worse than a missing one** — the syntax parsed, so scripts using it looked correct and produced mappings without the transform. When the grammar already has a form, check the whole chain (AST → model → both writers → both readers → describe) before assuming it works. The stored element carries **one** property, `Converter`, and no separate parameter path: the microflow's input IS the member the element binds, which is why the member belongs inside the call and there is nothing to cross-validate. The export side had **no spelling at all** (22 export value elements use one), so the mirrored `jsonKey = Module.MF(Attr)` was added — note the argument is the ATTRIBUTE there, since the direction is reversed. An unresolvable microflow is refused, same rule as an unresolvable schema source (#259). Control that matters: assert the sibling element WITHOUT a converter carries an empty one, or the test passes against a writer that stamps every element. Repro `mdl-examples/bug-tests/266-converter-microflow.mdl`, tests `mdl/executor/mapping_converter_test.go`. Issue #266", "refs": ["#259", "#266"]}
-{"area": "mdl/executor", "symptom": "A mapping element whose object handling is **Custom** — a microflow resolves the object instead of Create/Find — cannot be authored, and `describe` of one drops the handler while still producing output that executes, so the rebuilt mapping CREATES objects where the original called a microflow", "cause": "56 of the 327 demo-app mapping documents use it. Both writers hardcoded `CustomHandlerCall` to nil, and gen models the call but not the property: `Import/ExportObjectMappingElement` has no `CustomHandlerCall` accessor at all", "file": "`mdl/executor/mapping_customhandler.go`, `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`, `mdl/backend/modelsdk/mapping_write.go` (`customHandlerToGen`, list marker + TypeDefaults) and `mapping_read.go` (`customHandlerFromRaw`), `modelsdk/gen/mappings/types.go` (STORAGE-NAME OVERRIDE), `mdl/backend/mpr/backend.go` (legacy refusal)", "insight": "**Three shapes `mx check` caught that reading the document did not**, in the order they appeared: (1) `CE0281 \"Unknown value element 'idx' selected for parameter\"` — a value-path parameter needs the value to EXIST as an attribute-less value mapping element under the object being resolved; Studio Pro adds it when you pick the value, so mxcli must too. (2) `CE5015 \"Attribute type 'String' does not match schema type 'Integer'\"` — that added element's type must mirror the schema element, since there is no attribute to derive it from. (3) the element then has to be **hidden from DESCRIBE**, because it is derived from the `by (Param: member)` clause and printing it emits ` = idx` with no attribute, which does not parse. Also: the parameter element's stored `$Type` is `Mappings$MicroflowCallParameterMappingImpl` where gen says `MappingMicroflowParameter` (161 of 161 documents) — a STORAGE-NAME OVERRIDE, patched on both the encode and decode halves; `ParameterMappings` is written even when the microflow takes **no** parameters, as the bare `[2]` (a MandatoryLists entry, like a rule's `Flows`); and `ObjectHandlingBackup` must NOT inherit \"Custom\", which is not in the `{Create, Error, Ignore}` enum — import documents store Create, export ones Error. gen declares a `ValueElementPath` that Studio Pro writes in 0 of 161 documents, so the writer builds the sub-document with the generic element helpers rather than gen. Read back from **raw BSON**, since gen has no accessor. Legacy **refuses** rather than dropping the microflow. Repro `mdl-examples/bug-tests/264-custom-object-handling.mdl`, tests `mdl/executor/mapping_customhandler_test.go`. Issue #264", "refs": ["#264"], "ce": ["CE0281", "CE5015"]}
-{"area": "mdl/executor", "raw": "| An export mapping's **array container** is written with an entity and association, so the MDL makes the author declare `Assoc/Entity` twice and the result matches no Studio Pro document | Studio Pro leaves the container BARE — 93 of the 93 entity-less object elements in the demo apps are array containers of the shape `et=Array entity=- assoc=- oh=Find` over `et=Object entity=… assoc=… oh=Find` at the `\\|(Object)` step (AgentCommons.EM_Agent, MxGenAIConnector.EM_ConverseRequest, SnowflakeIntegration.Export_AnyChart_Heatmap) | `mdl/executor/cmd_export_mappings.go` (the array branch of `buildExportMappingElementModel`, `exportArrayItemToPrint`) | Declare an array like a plain nested object — `Assoc/Entity as items { values }` — and GENERATE the container, the same rule #248 applied to a root array; only the object handling differs (Parameter on the root's item, Find on a nested one). **Keep honouring the old two-level spelling as written**: `Assoc/Entity as items { ItemAssoc/ItemEntity as ItemsItem { … } }` names TWO entities, one per level, which the bare-container shape cannot express — rewriting it produced **CE0295** \"Association … is not allowed\" because the item's association no longer reached its parent. It is also what DESCRIBE emitted before the change, so the doctype suite and any script in the wild use it; the integration run caught this, a unit test would not have. DESCRIBE unwraps only the BARE container (discriminate on the stored paths — the item's is the container's plus `\\|(Object)` — never on `Kind`, which the two engines' readers label differently), so an old-form mapping still round-trips to its own shape. **An entity-less PLAIN object element is a different thing**, written `group as toolConfig { … }`, and it may hold **object elements only** — a value under one is **CE0061 \"No entity selected.\"**, because a value has no entity to bind its attribute to. That constraint cost a detour worth copying: the first attempt put a value there, mxbuild refused it, and the syntax was withdrawn on the assumption that the SHAPE was unsupported. Transplanting the shipped document (`MxGenAIConnector.EM_ConverseRequest`) into an 11.13 project and checking it — **0 errors** — showed the shape was fine and the reproduction was not. **When a build error contradicts a shipped marketplace module, check the module itself before believing the construct is unsupported**; the demo corpus is a ready-made oracle for exactly that. Two traps in setting that check up: a base project another session has **upgraded** (local-test-app moved to 11.14) makes mxbuild refuse the whole file, and renaming a v2 `.mpr` needs `mprcontents/mprname` updated or the loader throws `StorageMprNameDiscrepancyException`. Repro `mdl-examples/bug-tests/262-export-array-container.mdl`, test `TestExportNestedArrayContainerIsBare`. Issue #262 |", "refs": ["#248", "#262"], "ce": ["CE0061", "CE0295"]}
-{"area": "mdl/executor", "raw": "| A mapping rooted at a **nested schema element** cannot be authored, and `describe` prints it as if it were rooted at the document root — output that PARSES and executes, producing a mapping whose members do not exist at that level | Studio Pro lets the author start a mapping at any element and stores that as the root element's `JsonPath`; 13 of the 327 demo-app documents do (`OpenAI_API.IM_OpenAI` at `(Object)\\|choices\\|(Object)\\|message`, `Teamcenter.Import_ChildrenParent`, `MxGenAIConnector.IM_Collection_RetrieveNearestNeighbors`). Both executors resolved the root from the structure and had nowhere to put a selection | `mdl/executor/mapping_customhandler.go` (`resolveSchemaRoot`, `schemaRootClause`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`, `mdl/grammar/MDLLexer.g4` (`ROOT`), `mdl/grammar/domains/MDLDomainModel.g4` | `root a/b/c` on the source clause, in member names. **The path may pass through an array where a value reference may not**: the mapping is then rooted at the array's ITEM (`root choices/message` → `(Object)\\|choices\\|(Object)\\|message`), which is why this walks the index itself instead of reusing `resolvePath` — that one refuses an intermediate array because many items cannot collapse into one value (CE0256). Thread the selection through as the root's `parentPath` rather than adding a parameter: the isRoot branch already takes its lookup from there, so `\"\"` keeps meaning \"the structure's own root\" and #248's fix is untouched. DESCRIBE **derives** the clause from the stored path rather than remembering it — drop the leading segment and every `(Object)`/`(Array)` marker, the inverse of how it resolves — so a Studio-Pro-authored mapping prints one too. The round-trip proof to aim for is `Unchanged import mapping …`: the rebuild is semantically equal and ADR-0008 elides the write entirely. Repro `mdl-examples/bug-tests/267-nested-schema-root.mdl`, tests `mdl/executor/mapping_schema_root_test.go`. Issue #267 |", "refs": ["#248", "#267"], "ce": ["CE0256"]}
-{"area": "mdl/executor", "raw": "| Every member of an **array-rooted** import/export mapping is rejected: `\"id\" is not a member of the JSON structure at (Object), which has no members there` — while the identical body over an object-rooted structure works | Both executors hardcoded the root lookup to `\"(Object)\"`, and an array-rooted structure is built at `\"(Array)\"` with its item at `\"(Array)|(Object)\"` (`buildElementFromRawRootArray`). The root resolved to nothing, so the child lookup reported members \"at (Object)\" — a node that structure never had, which reads as \"your key is wrong\" rather than \"the root was looked up in the wrong place\". 122 of the 327 mapping documents in the demo apps are array-rooted, the single largest gap in the mapping surface | `mdl/executor/cmd_import_mappings.go` (`buildImportMappingElementModel`, `jsonSchemaIndex.root`), `mdl/executor/cmd_export_mappings.go` (`buildExportMappingElementModel`, `buildExportRootArrayElement`, `exportRootToPrint`) | Take the root FROM the structure instead of assuming it. No new syntax: the structure decides, and Studio Pro does not ask either. The import side then needs nothing more — the array branch was already stepping `\"(Array)\"` → `\"(Array)|(Object)\"` for NESTED arrays. **The two sides store different shapes and the difference is not guessable**: an array-rooted IMPORT mapping is ONE element at `(Array)|(Object)` (the container collapses), an array-rooted EXPORT mapping is a bare `Array` container at `(Array)` whose single child carries the entity with `ObjectHandling=Parameter`. Pin both against Studio Pro documents before writing either (`Teamcenter.IMM_ItemRevision`, `FactoryManagement.IMM_ScenarioList`, `SnowflakeIntegration.EXM_SensorData` — Evora demo app, 11.13). A second export shape exists (`DigitalTwin.EMM_EntityQuery`: entity on the container, `Find` on the item, for a parameter that OWNS the list) and MDL cannot say which is meant, so it stays unauthorable — #262. **Adding an authorable shape means teaching DESCRIBE about it in the same change**, or the newly writable mapping joins the 112 silent-loss cases of #260: the export container is not `Kind==\"Object\"`, so it fell into the value branch and printed `Root = ` with its whole subtree dropped. Discriminate the container on its stored **JsonPath**, not on `Kind` — the two engines' readers label it differently (\"Array\" vs \"Object\") and only the path is in the document. Controls: revert the root lookup and the repro returns verbatim, while the object-rooted control still passes; `mdl-examples/bug-tests/519-rest-mapping-as-list-of.mdl` goes from dying on its own mapping statement to executing. `mx check` needs the base project's own error count as the control (a blank app carries a pre-existing CE0495). Repro `mdl-examples/bug-tests/mapping-248-array-rooted-mappings.mdl`, tests `TestImportMappingArrayRoot` / `TestExportMappingArrayRoot`. Issue ako/mxcli#248 |", "refs": ["#260", "#262", "ako/mxcli#248"], "ce": ["CE0495"]}
-{"area": "mdl/executor", "raw": "| A mapping sourced from a **message definition** cannot be authored at all — MDL has `with json structure` and `with xml schema` and no third form — and `describe` of an existing one silently omits the source clause while still producing output that PARSES, so `describe` → `exec` rebuilds the mapping bound to nothing | 74 of the 327 mapping documents in the demo apps use one (the second-largest gap after the array root), 70 of them in the silent-loss class. The document is `MessageDefinitions$MessageDefinitionCollection` — a COLLECTION, which is why the reference is three parts (`Module.Collection.Definition`) — and it is derived from the **domain model**, not a payload sample: every node names an entity or an attribute and carries two names, its own (`Emails`) and the singular one its items take (`Email`) | `mdl/executor/mapping_messagedefinition.go` (`findMessageDefinition`, `messageDefPaths`, the two builders), `mdl/backend/modelsdk/messagedefinition_read.go`, `model/types.go` (`MessageDefinitionCollection`, and `XmlPath` on both mapping element types) | **A message-definition mapping stores BOTH path families** — that is the whole reason it needs its own builder rather than a branch of the JSON one: `json=(Array)\\|(Object)\\|From` beside `xml=Emails\\|Email\\|From`. The rules, measured on AgentCore.MesDef_Email / .MesDef_WorkflowDetails and Email_Connector.MD_EmailTemplate: an unbounded node contributes `ExposedName\\|ExposedItemName` to the XML path and `ExposedName\\|(Object)` to the JSON one, a single node contributes `ExposedName` to both, and the ROOT is the asymmetry — its own name is in the XML path but the JSON one is just `(Array)\\|(Object)`. `model.ImportMappingElement`/`ExportMappingElement` had **no XmlPath field** and every writer hardcoded `\"\"`, so that had to be added and carried on both engines' read and write paths first. **Do not \"helpfully\" drop the body**: the definition fixes entity, attributes and names, so a bodyless \"map everything\" form is tempting — measured, six of the ten real message-definition mappings map every exposed node and four map a strict subset (58 of 96, 27 of 30, 28 of 30, 26 of 27), so it would be lossy for 40% of them. `modelsdk/gen/messagedefinitions` already models the whole tree and decodes real documents unchanged (zero entries in `keyaudit_test.go`), so the read is one `mprread.ListUnitsWithContainer` call; the legacy engine has no parser and **refuses rather than returning an empty list**, because empty reads as \"this project has no message definitions\" and turns a real reference into a bogus \"not found\". The oracle is a Studio Pro mapping over the SAME definition: authoring `AgentCore.MesDef_Email.Email` from MDL reproduces `AgentCore.Email_Import` element for element. Repro `mdl-examples/bug-tests/mapping-263-message-definition-source.mdl`, tests `mdl/executor/mapping_messagedefinition_test.go`. Issue ako/mxcli#263 |", "refs": ["ako/mxcli#263"]}
-{"area": "mdl/executor", "symptom": "A value **converter microflow** — `Attr = Module.MF(jsonField)` — is accepted, the mapping is created, and the transform is silently absent; DESCRIBE prints the element as a plain `Attr = jsonField`", "cause": "The grammar and the AST already carried it (`Converter`, `ConverterParam` in `ast_import_export_mapping.go`) and nothing downstream read either: the model element had no `Converter` field and every writer hardcoded the BSON key to `\"\"`. The visitor also never set `JsonName` for that alternative, so even with a model field the member had no name to resolve against. 39 of the 327 demo-app mapping documents use one, including the two a blank app ships (`FeedbackModule.IMM_PostResponse`, `.EXM_PostFeedback`)", "file": "`mdl/executor/mapping_messagedefinition.go` (`setMappingConverter`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go` (build + describe), `mdl/visitor/visitor_import_export_mapping.go`, `model/types.go`, and the four writers + four readers", "insight": "**A half-wired feature is worse than a missing one** — the syntax parsed, so scripts using it looked correct and produced mappings without the transform. When the grammar already has a form, check the whole chain (AST → model → both writers → both readers → describe) before assuming it works. The stored element carries **one** property, `Converter`, and no separate parameter path: the microflow's input IS the member the element binds, which is why the member belongs inside the call and there is nothing to cross-validate. The export side had **no spelling at all** (22 export value elements use one), so the mirrored `jsonKey = Module.MF(Attr)` was added — note the argument is the ATTRIBUTE there, since the direction is reversed. An unresolvable microflow is refused, same rule as an unresolvable schema source (#259). Control that matters: assert the sibling element WITHOUT a converter carries an empty one, or the test passes against a writer that stamps every element. Repro `mdl-examples/bug-tests/mapping-266-converter-microflow.mdl`, tests `mdl/executor/mapping_converter_test.go`. Issue ako/mxcli#266", "refs": ["#259", "ako/mxcli#266"]}
-{"area": "mdl/executor", "symptom": "A mapping element whose object handling is **Custom** — a microflow resolves the object instead of Create/Find — cannot be authored, and `describe` of one drops the handler while still producing output that executes, so the rebuilt mapping CREATES objects where the original called a microflow", "cause": "56 of the 327 demo-app mapping documents use it. Both writers hardcoded `CustomHandlerCall` to nil, and gen models the call but not the property: `Import/ExportObjectMappingElement` has no `CustomHandlerCall` accessor at all", "file": "`mdl/executor/mapping_customhandler.go`, `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`, `mdl/backend/modelsdk/mapping_write.go` (`customHandlerToGen`, list marker + TypeDefaults) and `mapping_read.go` (`customHandlerFromRaw`), `modelsdk/gen/mappings/types.go` (STORAGE-NAME OVERRIDE), `mdl/backend/mpr/backend.go` (legacy refusal)", "insight": "**Three shapes `mx check` caught that reading the document did not**, in the order they appeared: (1) `CE0281 \"Unknown value element 'idx' selected for parameter\"` — a value-path parameter needs the value to EXIST as an attribute-less value mapping element under the object being resolved; Studio Pro adds it when you pick the value, so mxcli must too. (2) `CE5015 \"Attribute type 'String' does not match schema type 'Integer'\"` — that added element's type must mirror the schema element, since there is no attribute to derive it from. (3) the element then has to be **hidden from DESCRIBE**, because it is derived from the `by (Param: member)` clause and printing it emits ` = idx` with no attribute, which does not parse. Also: the parameter element's stored `$Type` is `Mappings$MicroflowCallParameterMappingImpl` where gen says `MappingMicroflowParameter` (161 of 161 documents) — a STORAGE-NAME OVERRIDE, patched on both the encode and decode halves; `ParameterMappings` is written even when the microflow takes **no** parameters, as the bare `[2]` (a MandatoryLists entry, like a rule's `Flows`); and `ObjectHandlingBackup` must NOT inherit \"Custom\", which is not in the `{Create, Error, Ignore}` enum — import documents store Create, export ones Error. gen declares a `ValueElementPath` that Studio Pro writes in 0 of 161 documents, so the writer builds the sub-document with the generic element helpers rather than gen. Read back from **raw BSON**, since gen has no accessor. Legacy **refuses** rather than dropping the microflow. Repro `mdl-examples/bug-tests/mapping-264-custom-object-handling.mdl`, tests `mdl/executor/mapping_customhandler_test.go`. Issue ako/mxcli#264", "refs": ["ako/mxcli#264"], "ce": ["CE0281", "CE5015"]}
-{"area": "mdl/executor", "raw": "| An export mapping's **array container** is written with an entity and association, so the MDL makes the author declare `Assoc/Entity` twice and the result matches no Studio Pro document | Studio Pro leaves the container BARE — 93 of the 93 entity-less object elements in the demo apps are array containers of the shape `et=Array entity=- assoc=- oh=Find` over `et=Object entity=… assoc=… oh=Find` at the `\\|(Object)` step (AgentCommons.EM_Agent, MxGenAIConnector.EM_ConverseRequest, SnowflakeIntegration.Export_AnyChart_Heatmap) | `mdl/executor/cmd_export_mappings.go` (the array branch of `buildExportMappingElementModel`, `exportArrayItemToPrint`) | Declare an array like a plain nested object — `Assoc/Entity as items { values }` — and GENERATE the container, the same rule #248 applied to a root array; only the object handling differs (Parameter on the root's item, Find on a nested one). **Keep honouring the old two-level spelling as written**: `Assoc/Entity as items { ItemAssoc/ItemEntity as ItemsItem { … } }` names TWO entities, one per level, which the bare-container shape cannot express — rewriting it produced **CE0295** \"Association … is not allowed\" because the item's association no longer reached its parent. It is also what DESCRIBE emitted before the change, so the doctype suite and any script in the wild use it; the integration run caught this, a unit test would not have. DESCRIBE unwraps only the BARE container (discriminate on the stored paths — the item's is the container's plus `\\|(Object)` — never on `Kind`, which the two engines' readers label differently), so an old-form mapping still round-trips to its own shape. **An entity-less PLAIN object element is a different thing**, written `group as toolConfig { … }`, and it may hold **object elements only** — a value under one is **CE0061 \"No entity selected.\"**, because a value has no entity to bind its attribute to. That constraint cost a detour worth copying: the first attempt put a value there, mxbuild refused it, and the syntax was withdrawn on the assumption that the SHAPE was unsupported. Transplanting the shipped document (`MxGenAIConnector.EM_ConverseRequest`) into an 11.13 project and checking it — **0 errors** — showed the shape was fine and the reproduction was not. **When a build error contradicts a shipped marketplace module, check the module itself before believing the construct is unsupported**; the demo corpus is a ready-made oracle for exactly that. Two traps in setting that check up: a base project another session has **upgraded** (local-test-app moved to 11.14) makes mxbuild refuse the whole file, and renaming a v2 `.mpr` needs `mprcontents/mprname` updated or the loader throws `StorageMprNameDiscrepancyException`. Repro `mdl-examples/bug-tests/mapping-262-export-array-container.mdl`, test `TestExportNestedArrayContainerIsBare`. Issue ako/mxcli#262 |", "refs": ["#248", "ako/mxcli#262"], "ce": ["CE0061", "CE0295"]}
-{"area": "mdl/executor", "raw": "| A mapping rooted at a **nested schema element** cannot be authored, and `describe` prints it as if it were rooted at the document root — output that PARSES and executes, producing a mapping whose members do not exist at that level | Studio Pro lets the author start a mapping at any element and stores that as the root element's `JsonPath`; 13 of the 327 demo-app documents do (`OpenAI_API.IM_OpenAI` at `(Object)\\|choices\\|(Object)\\|message`, `Teamcenter.Import_ChildrenParent`, `MxGenAIConnector.IM_Collection_RetrieveNearestNeighbors`). Both executors resolved the root from the structure and had nowhere to put a selection | `mdl/executor/mapping_customhandler.go` (`resolveSchemaRoot`, `schemaRootClause`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`, `mdl/grammar/MDLLexer.g4` (`ROOT`), `mdl/grammar/domains/MDLDomainModel.g4` | `root a/b/c` on the source clause, in member names. **The path may pass through an array where a value reference may not**: the mapping is then rooted at the array's ITEM (`root choices/message` → `(Object)\\|choices\\|(Object)\\|message`), which is why this walks the index itself instead of reusing `resolvePath` — that one refuses an intermediate array because many items cannot collapse into one value (CE0256). Thread the selection through as the root's `parentPath` rather than adding a parameter: the isRoot branch already takes its lookup from there, so `\"\"` keeps meaning \"the structure's own root\" and #248's fix is untouched. DESCRIBE **derives** the clause from the stored path rather than remembering it — drop the leading segment and every `(Object)`/`(Array)` marker, the inverse of how it resolves — so a Studio-Pro-authored mapping prints one too. The round-trip proof to aim for is `Unchanged import mapping …`: the rebuild is semantically equal and ADR-0008 elides the write entirely. Repro `mdl-examples/bug-tests/mapping-267-nested-schema-root.mdl`, tests `mdl/executor/mapping_schema_root_test.go`. Issue ako/mxcli#267 |", "refs": ["#248", "ako/mxcli#267"], "ce": ["CE0256"]}
-{"area": "mdl/executor", "raw": "| A mapping rooted below an array (`root choices/message`) builds a project mxbuild rejects with **CE0243** \"The mapping used to return a value of type 'X', but now returns a value of type 'List of X'\" | Such a mapping yields ONE OBJECT PER ITEM, so the import activity must bind a list. `mappingRootIsList` answered from the JSON **structure**'s root element, which for `root choices/message` is the document root — an Object — so it reported a single object. The mapping DOCUMENT is correct and cannot decide this: Studio Pro's own `OpenAI_API.IM_OpenAI` stores `MaxOccurs 1` on exactly that root (verified against the fixture), so list-ness lives only in the root's PATH | `mdl/executor/cmd_microflows_builder_calls.go` (`mappingRootIsList`, `mappingRootPathCrossesArray`) | An array contributes a marker segment for its item, so **any `(Object)`/`(Array)`/`(Wrapper)` segment after the first** means the root sits inside an array: `(Object)|choices|(Object)|message` and `(Array)|(Object)` are lists, `(Object)|data` is not. Skip the first segment — it is always the document's own root marker. Keep the existing structure-root and MaxOccurs checks as the fallback for XML-schema and message-definition mappings, which carry no JsonPath. **Found by building an app and running `mx check` on it** — every unit test in the package passed while this was broken, and so did the whole mapping fixture round-trip suite, because the defect is in the CALLER of the mapping, not the mapping. The wider lesson is the one #294 taught: a mapping that serializes correctly and builds cleanly can still do nothing at run time, so a mapping feature is not proven until data has moved through it. Repro + assertions: `mdl-examples/bug-tests/mapping-runtime-proof.mdl` and its `.test.mdl`, run with `mxcli run --local --test-endpoint` + `mxcli test --attach`. Tests `mdl/executor/cmd_microflows_nested_root_cardinality_test.go`. Follow-up to ako/mxcli#267 |", "refs": ["#294", "ako/mxcli#267"], "ce": ["CE0243"]}
-{"area": "mdl/executor", "symptom": "The nightly is green on recent Mendix versions and fails on older ones with `<mapping> now round-trips faithfully — remove it from knownLossy`", "cause": "`TestMappingFixtureRoundTrip`'s `knownLossy` is a version-blind expectation, but the document it is asserted against is not always version-stable. `loadMappingFixture` uses the **base project's own copy** whenever the blank app already ships a document of that name (FeedbackModule ships two), instead of the pinned `.bson` — and that copy changes with the Mendix version. `FeedbackModule.IMM_PostResponse` loses exactly one property, `MessageDefinition2`, which `modelsdk/gen/mappings/version.go` records as `Introduced: \"11.10.0\"`, so below 11.10 there is nothing to drop and the staleness guard fires", "file": "`mdl/executor/mapping_fixture_roundtrip_test.go` (`knownLossyFrom`, and the base-project log line in `loadMappingFixture`)", "insight": "Gate the entry with `knownLossyFrom` — `ProjectVersion().IsAtLeast(major, minor)` — rather than deleting it, or the real defect (#279) stops being caught on the versions that have it. **Only ONE of the two FeedbackModule mappings failed, and that asymmetry is the diagnosis**: the export twin also loses #277's `IsKey`/`MaxLength` and #279's `MinOccurs`, which exist on every version, so it stays lossy throughout — if both had failed, the cause would have been something else. Check a suspect property against `gen`'s `version.go` `Introduced` before theorising. The substitution that makes this possible is now **logged** (\"using the BASE PROJECT's copy\"); it was silent, which is what made a one-line cause cost a nightly. To reproduce another version locally: `mxcli setup mxbuild --version 11.6.0` then `MX_BINARY=~/.mxcli/mxbuild/11.6.0/modeler/mx go test -tags integration ./mdl/executor/`. Prove it in both directions — disable the gate and watch the nightly failure reappear on 11.6", "refs": ["#277", "#279"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE LAYOUT` prints a header and no widget structure at all, for a document with 84 elements. Nothing distinguishes it from a genuinely empty layout", "cause": "`getLayoutWidgetsFromRaw` read `rawData[\"Widget\"]`, a key `Forms$Layout` does not have. Its tree hangs off `Content` — a `Forms$WebLayoutContent` (or `Forms$NativeLayoutContent`) whose `Widgets` array holds the root. The type assertion failed and returned nil, silently", "file": "`mdl/executor/cmd_pages_describe.go` (`getLayoutWidgetsFromRaw`), `mdl/executor/cmd_pages_describe_parse.go` (`scrollContainerRegions`)", "insight": "**A `ScrollContainer` holds its regions in five named slots — `Top`, `Right`, `Bottom`, `Left`, `CenterRegion`** (the last spelled unlike its siblings), not in a list. The walk read `CenterRegion` alone, which was survivable for pages and wrong for layouts: the topbar is in `Top` and the navigation in `Left`, so the two things anyone describes a layout to see were the two it skipped. Each occupied slot is now a synthetic region node, the same way `TabControl` preserves tab pages. Controlled by restoring each half separately. ako/mxcli-ledger #136", "refs": ["#136"]}
-{"area": "mdl/executor", "symptom": "A bulk `ALTER PAGES … SET LAYOUT` reports success and the build then fails with **CE1613** \"The selected placeholder … no longer exists\", naming a page rather than the statement", "cause": "The repoint rewrote `Form` and every `Parameter` without checking that the target layout declares the placeholders the page binds to, so a page bound to `HeaderLeft` got `NewLayout.HeaderLeft` pointing at nothing", "file": "`mdl/executor/cmd_pages_repoint.go` (`checkRepointPlaceholdersAgainst`), `mdl/backend/layoutplaceholders.go`, `mdl/backend/pagemutator/mutator.go` (`BoundPlaceholders`)", "insight": "**Check after MAP is applied** — `MAP (Old AS New)` exists precisely to rebind onto a placeholder the new layout does have, so checking before it would refuse the remedy. A target that reports *no* placeholders is one the backend could not read (MCP exposes none), not one that has none, so it skips rather than refusing everything. And **name the remedy in syntax that parses**: the grammar is `MAP (Old AS New)`, while the comment beside the rule had said `MAP (Main -> Main)` since it was written — the arrow reads plausibly and is a parse error", "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "A caption/title/content written from MDL shows as the empty-caption placeholder (`<>`) in Studio Pro, with a \"no translation for this language\" warning, on a project whose language is not en_US. `mxcli`, `mx check` and mxbuild all report success", "cause": "Mendix has no language-neutral text — every `Texts$Translation` carries a `LanguageCode` — and every executor CREATION site hardcoded `\"en_US\"`, ignoring the project's `DefaultLanguageCode`. The read side had already been fixed for the same reason (#702, `describeDefaultLanguage`); the write side was never wired to it", "file": "`mdl/executor/describe_language.go` (`authoringLanguage`), then the ~23 creation sites: `cmd_pages_builder_v3*.go` (`pb.textLang()`), `cmd_microflows_builder_calls.go` (`fb.textLangOrDefault()`), `cmd_entities.go` / `cmd_enumerations.go` / `cmd_validationrules.go` (`authoringLanguage(ctx)`)", "insight": "**Resolve the write language from the project, never a literal.** `DefaultLanguageCode` is by definition enabled, so this cannot produce the unenabled-language case #257 warns about, and DESCRIBE reads the same language CREATE writes so describe→exec round-trips on a non-en_US project. **Two layers, two different seams.** The executor sites build a `model.Text` and can reach `ctx` — fix those first, they are the reported bug. The writer leaves (`sdk/mpr`, `modelsdk`, `widgetobj`, `pagemutator`, `modelsdk/mpr`) build a `Texts$Text` from a **bare Go string** and have no context: a widget `Label`, a pluggable column caption, a navigation item and a menu-document item all land there. **Do not thread a parameter to them** — measured, that is 183 function signatures across five packages (113 in `sdk/mpr` alone), nearly every widget writer, to carry a value constant for the whole run. They read `model.AuthoringLanguage()` instead, published once by `describeDefaultLanguage`. `ALTER PAGE … SET Caption` was never affected: it edits the stored translation in place and keeps its `LanguageCode`. The control that localises it is free: Studio Pro's own pages in the same project store the same word under the right language — and beware counting those as mxcli's, scope the search to the unit. `mx check` reports 0 errors before AND after, so it proves nothing here; assert on the stored `LanguageCode`. mendixlabs/mxcli#970", "refs": ["#257", "#702", "mendixlabs/mxcli#970"]}
-{"area": "mdl/executor", "symptom": "Replaying a `create or replace snippet` silently resets its translated captions to the source language in every language. The run says `Created snippet` (on a document that already exists), `mx check` reports 0 errors, and the app renders in one language", "cause": "The snippet replace path was an unconditional **delete-then-create**. Nothing `canon.Reconcile` does survives that: by the time the create runs there is no stored document left to transplant identities from or to compare against, so translations — and anything else MDL cannot express — go with the deleted unit", "file": "`mdl/executor/cmd_pages_create_v3.go` (`execCreateSnippetV3`); the correct pattern is 40 lines above it in `execCreatePageV3`", "insight": "**A replace must be an UPDATE on the stored unit's ID, never delete+create.** Reuse `snippetsToDelete[0]` as the new document's ID, call `UpdateSnippet` (which already existed and was called nowhere), and delete only the *extra* duplicates. The verb is the tell: a path that prints `Created` on a replace is not going through the write choke point, so it gets neither the identity transplant nor the unchanged-elision. **The control is free and in the same run** — put a page and a snippet with the same shape in one script and replay it: before the fix the page reports `Unchanged` and keeps its Dutch while the snippet reports `Created` and loses it, which is what makes it a snippet defect rather than a fact about replacing documents. Second consequence the page path already documents: delete+add churns git and crashes Studio Pro's RevStatusCache. ako/mxcli-ledger #143", "refs": ["#143"]}
-{"area": "mdl/executor", "symptom": "A mapping names a schema source that does not exist and mxcli writes it through — mxbuild reports it as **CE1613** \"… no longer exists\" at build time, while `mxcli check` and even `check --references` pass; and the same typo silently switches off EVERY member check in that mapping", "cause": "The schema index is empty whenever the structure cannot be loaded FOR ANY REASON, and `resolvable()` reads an empty index as \"there is nothing to validate against\" (its correct meaning for a schema-less mapping). So `with json structure M.NoSuchThing { create M.Loc { LocId = nonsense } }` had two errors and reported neither. Separately `null values` was written as free text, so `null values Banana` reached the stored NullValueOption verbatim — the enum is {LeaveOutElement, SendAsNil}", "file": "`mdl/executor/mapping_customhandler.go` (`resolveJsonStructureSource`, `canonicalNullValueOption`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`", "insight": "**Refuse at the SOURCE, do not make `resolvable()` stricter**: a NAMED but unresolvable source is an error, while NO source at all — XML schema, message definition, schema-less test mappings — must keep working, and conflating the two breaks every one of them. **An empty project and a backend that cannot LIST look identical from here**, so the refusal only fires when the listing succeeds; a listing error takes the name at face value. That distinction has teeth: two pre-existing mock tests named a structure their mock did not provide and started failing, and the right fix was to give the mock the structure rather than weaken the check — a mapping whose named source does not exist is an inconsistent model to assert against. Name what would have worked, the shape #882 established for members. **Still written through**: `with xml schema M.NoSuchThing`. A gen type exists (`modelsdk/gen/xmlschemas`) so it is verifiable, but it needs a new `ListXmlSchemas` across the interface, both engines and the mock; the silent-disabling half does not apply there, since an XML mapping never had member validation at all. Repro `mdl-examples/bug-tests/mapping-259-resolve-schema-sources.mdl`, tests `mdl/executor/mapping_source_resolution_test.go`. Issue ako/mxcli#259", "refs": ["#882", "ako/mxcli#259"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "Pages that were valid start failing **CE6206** \"Attribute paths with multiple steps cannot be used on pages that are accessible through an offline-based navigation\" — and nothing in the script that wrote them changed", "cause": "An offline navigation profile restricts every page it can reach to at most ONE association hop. Adding the PROFILE is what invalidates pages written earlier, so the error appears far from its cause. mxcli writes multi-step paths happily: a datagrid column bound `Req_Asset/Asset_Site/SiteName` stores an `IndirectEntityRef` with two steps and `mx check` reports 0 errors — correctly, until an offline profile exists", "file": "`mdl/executor/validate_offline_paths.go` (`MDL-OFFLINE01`), wired from `validate_program.go`", "insight": "**The threshold is two hops, not one** — pinned by a control inside the reference page, which carried both and had only the 2-step one flagged (`MaintenanceRequest_Asset → AssetName` accepted, `… → Asset_Site → SiteName` rejected). In MDL a hop is a slash, so the count is `strings.Count(path, \"/\")` and no BSON walk is needed. Two traps: an **XPath constraint** is also full of slashes and is NOT an attribute path, so scan attribute bindings only; and a dynamic text binds through **template parameters** rather than `Attribute:`, which is how the second reported error was written. The rule deliberately does NOT decide reachability — Studio Pro walks the whole page graph and `check` does not build the catalog — so it warns naming the profile rather than asserting an error it cannot prove. ako/mxcli-maintenance §6/§7 screenshots", "ce": ["CE6206"]}
-{"area": "mdl/executor", "symptom": "`create or replace navigation Phone` fails with `navigation profile not found: Phone (available: Responsive)`, and no other mxcli command adds one — so a device-specific front end cannot be built from MDL. A layout naming the missing profile then fails **CE1613**", "cause": "`CREATE OR REPLACE NAVIGATION` only ever REPLACED a stored profile. Mendix routes a phone to a Phone **profile** on the User-Agent, not on viewport width, so the profile is the thing that makes phone pages reachable", "file": "`mdl/executor/cmd_navigation.go` (creates when the name is a known kind), `mdl/backend/modelsdk/navigation_profile_add.go` (`newWebProfileBson`), `mdl/types/navigation_profile_kind.go` (the closed set)", "insight": "**Measure what Studio Pro CREATES, not what the reference project HAS.** All six web profiles store the same 14 keys and differ only in Kind and Name — offline profiles included, so there is one builder, not two. The trap is `ProgressiveWebAppSettings`: the reference app's Phone and TabletOffline profiles both carry `{Precaching: true, InstallPrompt: true}`, and a first draft copied that. Those are the USER'S settings — the schema defaults `Precaching` to false, makes the element optional, and a profile added through Studio Pro's own model API stores **null** for every kind. `mx check` reports 0 errors either way, so the only way to tell is to ADD a profile over PED (`ped_update_document`, add to `/profiles`) and read back what it materialised — reading an existing profile measures the user, not the platform. The kind set is **closed**: creating `Phone` adds what the platform routes to, creating `Mobile` would add one that never can, so an unknown name stays an error; Hybrid and native kinds are excluded for want of a reference. The kind table lives in `mdl/types` because both the executor and the backend need it and the executor must not import a backend implementation (ADR-0002). ako/mxcli-maintenance §7", "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "`grant <Role> on System.User (...)` fails with `load domain model 00000000-0000-0000-0000-000000000002: open …/mprcontents/00/00/….mxunit: no such file or directory`, which reads like a corrupt project", "cause": "The System module's domain model is **not a stored unit** in any Mendix project — mxcli synthesises it from a built-in table so System entities can be REFERENCED. The write reached storage, missed the unit, and surfaced as a filesystem error", "file": "`mdl/executor/cmd_security_write.go` (`refuseSystemEntityGrant`, called right after `findModule`)", "insight": "**Refuse by name up front, not by letting the write fail.** A late failure also leaves half-applied state — the roles have already been validated by then. Say in the message that this is true of every Mendix project, or the reader goes hunting for corruption that is not there. Worth stating the consequence too: an XPath constraint that TRAVERSES System is equally unusable, so filtering `Administration.Account` by `[System.UserRoles/System.UserRole/Name = ...]` returns nothing — target a user ROLE and record who acted, which is what the maintenance app did. The guard must be case-insensitive on the module name and must not catch a module merely CONTAINING \"System\"; there is a control test. ako/mxcli-maintenance §4"}
-{"area": "mdl/executor", "symptom": "An import mapping with `find` / `find or create` is accepted by `mxcli check` AND by `exec` (\"Created import mapping\"), and the project is then unbuildable: **CE0250** \"Object element must have a key defined if object handling is set to 'Search for an object'\" and/or **CE0251** \"Searching for an object is not allowed for the entity 'X', because it is not persistable\"", "cause": "Neither requirement was checked anywhere. `def.ObjectHandling` was carried to `elem.ObjectHandling` unconditionally, `elem.IsKey` was set nearby but never cross-checked against the handling, and the entity's persistability was not consulted at all. The failure lands a build later, so an agent generating MDL gets no signal at the point it can still fix the statement", "file": "`mdl/executor/validate_import_mapping_find.go` (`MDL-MAP02` key, `MDL-MAP03` persistable), wired from `validate_program.go` so BOTH `check` and `exec` run it", "insight": "**mxbuild reports ONE AT A TIME** — a keyless `find` over a non-persistent entity is CE0250 *only*, and CE0251 appears only once a key exists, so fixing the key half looks like it fixed everything until someone adds a key. **Persistability follows the GENERALIZATION CHAIN, not the entity's own flag**: `create entity Sub extends NpBase` stores `Persistable: true` (mxcli's own catalog reads it as PERSISTENT) and mxbuild still says CE0251 — a rule reading the flag misses exactly that case, and the control (`Sub extends Keeper`, persistable parent) must stay silent. Both errors are raised **per object element**, not only at the root (\"at Object mapping element 'Pet'\"). A **custom handler is exempt from both** — the executor stores ObjectHandling \"Custom\" whatever keyword was written, and 70 of the demo corpus's 88 `find` elements are that shape, so missing the exemption flags most real mappings. Resolve fail-OPEN: an entity that is in neither the script nor the project is *unknown*, never assumed non-persistable. Sweep control: describing all 151 corpus import mappings and re-checking gives 0 flags, and stripping the `key` markers from that same output gives 18 — a sweep that only shows zero proves nothing (an earlier run's \"0\" was a concatenated file that never parsed). ako/mxcli#253", "refs": ["ako/mxcli#253"], "ce": ["CE0250", "CE0251"], "rules": ["MDL-MAP02", "MDL-MAP03"]}
-{"area": "mdl/executor", "symptom": "`create entity X extends <parent>` passes `mxcli check --references` with \"All references valid\" whatever the parent is, then the build reports **CE1613** \"The selected entity 'X' no longer exists\" — or, if the parent was written unqualified, `mx check` dies with **System.AggregateException … 'Generalization' property** and validates nothing at all", "cause": "An entity's EXTENDS target was never collected as a reference. The generalization is stored BY NAME and written verbatim, so mxcli had no opinion about whether it resolved", "file": "`mdl/executor/validate_generalization.go` (`validateEntityGeneralization`, `checkGeneralizationQualified`, MDL069), wired from `validate.go` (`CreateEntityStmt` case), `cmd_enumerations.go` (`ValidateEntity`) and `cmd_entities.go` (`execCreateEntity`)", "insight": "**The two failures are different sizes and want different gates.** A qualified-but-missing name is recoverable (the project loads, the build reports it) and needs the project to detect, so it belongs in the reference check. An UNQUALIFIED name makes the .mpr unopenable — same shape as #973's bare attribute name — and is a static property of the statement, so it is also MDL069 (fires with no project, which is what makes a `.fail.mdl` catchable by `make check-mdl`) and an executor guard at the TOP of `execCreateEntity`, before the module is auto-created, so `exec --no-check` cannot write it and a statement that can never be valid leaves nothing behind. **Resolve against the whole script, not the statements before it**: a generalization is resolved lazily and `create entity A extends B; create entity B;` is correct — `eagerDefRefs` says so explicitly, and a per-statement executor guard would break it, which is why only the syntactic half runs there. Controls worth keeping: a forward reference, `System.Image`, and an entity from a marketplace module must all still pass.", "refs": ["#973"], "ce": ["CE1613"], "rules": ["MDL069"]}
-{"area": "mdl/executor", "symptom": "`DROP ENUMERATION Mod.Name` reports \"enumeration not found\" for one that `SHOW ENUMERATIONS`, `DESCRIBE ENUMERATION` and `ALTER ENUMERATION` all resolve in the same session", "cause": "The enumeration is inside a FOLDER, so its `ContainerID` is the folder's ID rather than the module's. DROP resolved the owning module with `findModuleByID`, which matches module IDs only, and the failed lookup `continue`d — dropping the candidate silently, so the match list came out empty", "file": "`mdl/executor/cmd_enumerations.go` (`execDropEnumeration`); the trap was `mdl/executor/helpers.go` (`findModuleByID`, now removed — DROP was its only caller)", "insight": "Resolve a container through `getHierarchy(ctx)` + `h.FindModuleID` + `h.GetModuleName`, which is what the other three commands already did — **never compare a `ContainerID` against the module list**, because it is only a module ID for an element at the module root. The helper that invited the mistake is gone rather than left for the next caller. Two controls belong in the fixture: an identical enumeration at the module ROOT (it passed before the fix, so it proves this is container resolution rather than \"drop is broken\") and one whose container walks to no module at all (must still be skipped, not dropped under a guessed name). Test-fixture trap met while writing it: an element created with the folder as its container has `ContainerID == folderID`, so registering `withContainer(h, enum.ContainerID, folderID)` writes folder → folder and hides the module behind a self-loop; register the FOLDER's parent only."}
-{"area": "mdl/executor", "symptom": "A `validation feedback $Var/Attr` on an INHERITED attribute builds as **CE1613** \"The selected attribute 'Mod.Child.Attr' no longer exists\", while `mxcli check --references` passes and DESCRIBE renders the statement back unchanged", "cause": "Mendix qualifies a member reference against the entity that DECLARES it, so an inherited attribute carries the ancestor's name. The builder used `fb.varTypes[variable]` — the variable's declared type — with no generalization walk. Both engines", "file": "`mdl/executor/cmd_microflows_builder_calls.go` (`addValidationFeedbackAction`, `declaringMemberRef`), walking via `mdl/executor/entity_hierarchy.go` (`DeclaringMemberRef`)", "insight": "Same rule as #758 (access rules) and #703 (mappings), unlearned one layer over — when a member reference is built anywhere, ask whether it needs the DECLARING entity. **Do not reuse `ResolveMemberRef` for this**: its walk stops at `System.User` because a user entity's platform members must not appear in an ACCESS RULE (CE0066), which says nothing about referring to one from a microflow — reusing it falls back to the child's name, the exact bug being fixed. `DeclaringMemberRef` is the full-chain walk; the two stops are different questions and are kept apart deliberately. Controls that must be in the fixture: an attribute the entity declares ITSELF (a walk returning an ancestor for everything passes the inherited cases and is just as wrong), and the no-backend path, which keeps the naive spelling rather than emptying the reference.", "refs": ["#703", "#758"], "ce": ["CE0066", "CE1613"]}
-{"area": "mdl/executor", "symptom": "A list widget over `$currentObject/Mod.Assoc` builds as **CE1613** \"The selected attribute 'Mod.<WrongEnd>.Attr' no longer exists\" — the rows are typed as the association's other end — when the page's context object is a SPECIALIZATION of one end. `mxcli check --references` passes", "cause": "`resolveAssociationDestination` picks the end opposite the context by comparing qualified names with `==`. A specialization equals neither end, both ends resolve so neither empty-end fallback applies, and control reaches `return childEntity` under the comment \"default to the child (TO) side, which matches the common FROM=context pattern\"", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`resolveAssociationDestination`, `isSpecializationOf`, `generalizationOf`)", "insight": "**A comment saying \"the common pattern\" is a guess, and a guess that is silent when wrong is the bug.** Walk the generalization chain before falling through — over the domain models `pb` has ALREADY loaded, the same list the ends are resolved against, so the two cannot disagree about what an entity is (going through the backend would be a second source of truth for the same question). Apply it only when BOTH ends resolved: when one is empty the existing fallbacks are load-bearing (issuetracker #14) and a destination of \"\" makes the .mpr unloadable. The cross-association branch has the same `==` and needs the same treatment. Controls, ideally on one page: the context being the end ITSELF (reverse) and forward navigation from the other end — both passed before the fix, which is what makes this \"the context is a specialization\" rather than \"reverse navigation is broken\".", "refs": ["#14"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "symptom": "A microflow's `create` / `retrieve` / `create list of` naming an entity WITHOUT a module prefix passes `mxcli check --references` with \"All references valid\", then `mx check` fails to LOAD the project — `The text 'Name' is not a valid AttributeIdentifier` — so nothing else is reported either", "cause": "The reference collector skipped any entity reference whose `Module` was empty, and the builder writes the property only when both Module and Name are set. So an unqualified name was neither validated nor written: `create` stores no `Entity` key at all (its member assignments then reach disk as bare words) and `retrieve` stores the equally invalid `\".Thing\"`", "file": "`mdl/executor/validate_microflow.go` (`checkQualifiedEntityRef`, MDL008 — the rule that already covered PARAMETERS), plus the guards in `validate.go` (`refs.entities`) and `cmd_microflows_builder_actions.go` that let it through", "insight": "**This is upstream #973 and the reported trigger is not the cause** — omitting `$X =` reproduces nothing on either engine; the entity is stored correctly. Chase the *reported symptom* (\"Entity reference remains empty\") rather than the reported *cause*. Control that separates the two: a QUALIFIED name that resolves to nothing was always caught (`entity not found: … (referenced by create)`), so it is the absent prefix, not the absent entity, that opened the hole. Prefer a project-less lint rule over a reference-check entry for this class: it is a static property of the statement, so it also fires with no `-p`, gates `exec`, and makes a `.fail.mdl` that CI can actually run. Related trap found alongside: DESCRIBE prints `$NewObject = create …` for an activity whose output variable is empty — a name invented at format time (`cmd_microflows_format_action.go`), so reading a document back through describe cannot tell you whether the variable is set.", "refs": ["#973"], "rules": ["MDL008"]}
-{"area": "mdl/executor", "symptom": "A task-page button \"does nothing\": the microflow runs, no error is shown, and the runtime log has `Client: You can't complete this user task, it is not assigned to you`. `mxcli check`, `mx check` and the build are all clean", "cause": "`SET TASK OUTCOME` was called on a user task nobody had claimed. `TARGETING XPATH` / `TARGETING MICROFLOW` decides who may SEE a task — it does NOT assign it, and there is no `ASSIGN TASK` statement", "file": "`mdl/executor/validate_task_claim.go` (`ValidateTaskClaims`, MDL-WORKFLOW10), wired from `validate_program.go`; the platform rule is in `.claude/skills/mendix/write-workflows/SKILL.md`", "insight": "Claiming is a plain write to the Assignees association and must come BEFORE the outcome: `change $Task (System.WorkflowUserTask_Assignees = [%CurrentUser%]); commit $Task; set task outcome …`. Two things the rule needs: walk the body **in order** (a claim written after the outcome does not help, so collecting all claims first would pass it), and match the association on its **member name** — it parses qualified, bare and quoted, and matching one spelling would warn about correct code. A WARNING, never an error: the task may be claimed in a microflow this one calls, so accept a claim inside a branch rather than trying to evaluate the condition. Related trap: `WorkflowUserTask.Name` holds the task CAPTION, not the activity name, so an inbox routed on the activity name silently never matches. ako/mxcli-maintenance-2"}
-{"area": "mdl/executor", "symptom": "A `CALL WORKFLOW` whose parameter mapping is written across two lines builds to **CE0109** `\"Undefined variable 'Request\\n  '\"`. The identical call on ONE line is fine, and `CALL MICROFLOW` is fine at any width", "cause": "The workflow context is stored as a variable NAME, but it is filled from an expression SOURCE — and the visitor deliberately preserves an expression's trailing whitespace so a multi-line expression round-trips byte-for-byte (`appendExpressionListTrailingWhitespace`)", "file": "`mdl/executor/cmd_microflows_builder_workflow.go` (`addCallWorkflowAction`)", "insight": "**Trim the NAME, not the expression.** The obvious fix — a `TrimSpace` in the visitor — breaks the round-trip the whitespace exists for, and there are tests pinning it (`TestRetrieveRangeExpressionsPreserveTrailingWhitespace` and friends). The asymmetry between CALL WORKFLOW and CALL MICROFLOW **is the diagnosis**: microflow arguments stay expressions, where trailing whitespace is harmless, so anywhere an expression source is used as a NAME is the place to look. Trim BEFORE stripping the leading `$`. The control must assert the exact string — the name looks correct in most output until printed with `%q`. ako/mxcli-maintenance-2", "ce": ["CE0109"]}
-{"area": "mdl/executor", "symptom": "A page builds to **CE1571** \"No argument has been selected for parameter 'X' and no default is available\" while `mxcli check --references` passes — the microflow data source was written as `datasource: microflow M.F` with no arguments", "cause": "Nothing compared the flow's SIGNATURE against the data source's arguments. The microflow itself resolves, so the reference check was satisfied and the fault only surfaced at the far end of an `mx check`", "file": "`mdl/executor/validate_datasource_args.go` (`validateDataSourceArguments`, `dataSourceArgErrors`, `buildFlowParameterNames`), wired from `mdl/executor/validate.go` for both pages and snippets; `scriptContext.flowParams`", "insight": "**An ERROR, not a warning, and the measurement is what licenses that**: a page with NO parameters and a page WITH a `$Task` parameter of the microflow parameter's exact entity type BOTH get CE1571, so Studio Pro does not auto-map an object in scope and a missing argument is never filled in. Mendix's own wording (\"no default is available\") suggests otherwise — measure before trusting it. Three controls the rule needs or it is worse than nothing: a **parameterless** microflow with no parens must stay clean (the common case — flagging it would get the rule turned off), an **unresolvable** flow must be left to `validateWidgetReferences` (else a typo'd flow NAME is reported as a missing ARGUMENT, pointing at the wrong line), and the **correct** form must pass. Record script-defined flow signatures in `scriptContext.flowParams` the way `javaActions` already does, or the check only ever fires on a flow that already existed — one script creating a data source microflow and the page that binds it is the common shape. Verified both ways against mxbuild: the flagged widget is exactly the one CE1571 names, and the corrected example builds at 0 errors. ako/mxcli-maintenance-2", "ce": ["CE1571"]}
-{"area": "mdl/executor", "symptom": "`create user role Administrator (...)` fails with `user role already exists`, and since `exec` halts on the first error every later statement in the security script is skipped — leading to the conclusion that `CREATE OR MODIFY USER ROLE` does not exist", "cause": "It does exist and is re-runnable; it requires the parenthesised module-role list, so `create or modify user role Administrator;` fails with `mismatched input ';' expecting '('` — which reads as \"unsupported verb\" rather than \"missing argument\"", "file": "`mdl/executor/cmd_security_write.go` (the `NewAlreadyExists` site)", "insight": "**Name the re-runnable form in the error.** A blank Mendix app already ships an `Administrator` user role, so this fires on the first realistic security script. Before adding \"missing\" MDL surface from a field report, run the statement — this one was filed as a missing feature and was a discoverability failure. ako/mxcli-maintenance-2"}
-{"area": "mdl/executor", "symptom": "`ContentParams: [{1} = $PageVar]` comes back from DESCRIBE as `<unbound>`", "cause": "TWO different faults wearing one symptom. On the DEFAULT engine the write is CORRECT — the stored parameter carries `SourceVariable { LocalVariable: \"Name\" }` — and the READER looked only at `SourceVariable.PageParameter`, found no `AttributeRef` beside it, and fell through to `<unbound>`. On the LEGACY engine the write really was wrong: it put every binding in `PageParameter`, ignoring the kind", "file": "`mdl/executor/cmd_pages_describe_pluggable.go` (`sourceVariableBinding`, now shared), `mdl/executor/cmd_pages_describe_output.go`, `sdk/mpr/writer_widgets.go` (the legacy three-way branch)", "insight": "**Read the stored bytes before believing \"silently dropped\"** — half of this report was the tool disagreeing with itself, not with Mendix, and re-executing the describe output is what would have made it true. Studio Pro populates exactly one of `LocalVariable` / `PageParameter` / `SnippetParameter` on the same `Forms$PageVariable`; a local variable renders bare (`$Name`), the other two carry an `AttributeRef` and render `$Name.Attr`. **Two describers for one stored shape is the actual defect** — the pluggable one already read all three and the other did not, so they now share one resolver rather than being fixed twice."}
-{"area": "mdl/executor", "symptom": "A page variable declared `Enumeration(Mod.Enum)` is stored and described as `String`; a variable typed `Unknown` reverts to `String` on the next page rewrite", "cause": "Two silent defaults, stacked. `mdlTypeToBsonType` had no enumeration case and returned `DataTypes$ObjectType` for anything unrecognised; `localVarTypeToGen` then had no ObjectType case and returned a `StringType`. A type nobody had mapped came out as \"String\", twice, without a word", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`pageVariableType`, `pageVariableMDLType`), `mdl/backend/modelsdk/page_write.go` (`localVarTypeToGen`), `sdk/mpr/writer_pages.go` (`serializeLocalVariables`), `mdl/executor/cmd_pages_describe.go`", "insight": "The qualified name was in the AST all along — the visitor keeps the data type's raw SOURCE TEXT, so `Enumeration(Mod.Status)` arrives complete and only needed parsing; look there before adding a field. A `DataTypes$EnumerationType` needs its `Enumeration` by-name key or Mendix resolves it to null, so an enumeration with no qualified name is deliberately NOT written as one. Fix all four corners together — builder, both writers, and DESCRIBE — or the round trip loses the type at whichever end was missed; `Unchanged page …` on a describe → exec is the proof that reader and writer agree. Stacked defaults are the pattern to look for here: each one is individually defensible and together they erase information."}
-{"area": "mdl/executor", "symptom": "`describe page` emits MDL that mxcli's OWN `check --references` rejects — `duplicate widget name 'row1' … (CE0495)` — on stock pages nobody edited", "cause": "The names are DERIVED at describe time and Mendix stores none of them: `Forms$LayoutGridRow` and `Forms$LayoutGridColumn` carry no `Name` key, and a DataGrid2 column's name is derived from its bound attribute (mxcli says so itself in MDL-WIDGET16). Rows and columns restart numbering per grid, and two columns over one attribute derive one name — so the check was citing a Mendix error for something Mendix does not check", "file": "`mdl/executor/validate_page_context.go` (`checkDuplicateWidgetNames`, `widgetKindsWithoutStoredNames`)", "insight": "**Ask whether the model even HAS the name before enforcing uniqueness on it** — dump the stored widget and look for the `Name` key. A name mxcli invented cannot be a duplicate of anything. This one is also worth remembering for how the triage was WRONG: the first read predicted describe should renumber and called exempting them \"the weaker choice\"; measuring reversed it twice, because there is no stored name to make unique AND `ALTER PAGE` already handles a repeated derived column name (\"column %q is ambiguous … qualify the reference as `ON gridName.%s`\"), so renaming would have broken documented addressing to fix a non-collision. The control is mandatory here: two widgets Mendix DOES name, sharing a name, must still be reported, or the change reads as \"stop checking for duplicates\".", "ce": ["CE0495"]}
-{"area": "mdl/executor", "raw": "| A literal tab typed into an MDL string reaches the model as the two characters `\\t`, so a tab-delimited export becomes one cell per row and the failure looks like a Java bug. A literal NEWLINE in the same string survives, which makes the asymmetry easy to miss | `quoteExpressionLiteral` escaped `\\n`/`\\r`/`\\t` before writing the **Mendix expression**, applying MDL's escaping rules to a different grammar. Mendix's expression engine has exactly one escape — an apostrophe is doubled — and no backslash escapes at all, so the stored `'a\\tb'` IS a backslash and a `t`. The newline survived for an unrelated reason: a multi-line expression is kept as raw SOURCE text (`ast.SourceExpr`) and never reaches the escaping | `mdl/executor/cmd_microflows_helpers.go` (`quoteExpressionLiteral`, `expressionToString`) | **Measure the value where it lands, not where it is written.** Proven end to end against a running 11.13 runtime, straight out of Postgres: before, `length 4, 61 5c 74 62` (`a \\ t b`); after, `length 3, 61 09 62` (a real tab). The escaping had a *documented rationale* that was simply false — \"STRING_LITERAL does not accept them raw\" — when the rule is `'\\'' ( ~['\\\\] \\| '\\\\' . \\| '\\'\\'' )* '\\''` and `~['\\\\]` admits every byte but an apostrophe and a backslash. **Read the grammar rather than the comment about it.** Round-trip is the thing to control: assert describe → exec reproduces the same stored bytes, and use the real parser (`visitor.Build`) rather than a hand-mirrored decoder — the old test asserted \"output contains no control bytes\", which was asserting the bug. A backslash followed by n/r/t is still doubled and still wrong for the same reason (3 stored chars where 2 were meant); it is load-bearing because describe emits the stored expression verbatim, so removing it needs describe to escape on output. Measured blast radius: 0 backslash escapes in any string value across 33,645 units in 90 projects. ako/mxcli-captrack #5 |", "refs": ["#5"]}
-{"area": "mdl/executor", "symptom": "An attribute or entity named `Month` / `Year` / `Quarter` / `Day` passes `check --references`, then a view entity added weeks later fails **CE0174** (\"The 'Month' part is incomplete or incorrect\")", "cause": "An **OQL** reserved word, used **unquoted**. Three grammars stack and each treats quoting differently: MDL parser keywords (quoting works), Mendix platform reserved words (MDL021/CE7247, quoting does *not* — the check strips them), and Mendix **OQL** keywords (quoting **does** work — double quotes, as in SQL)", "file": "`mdl/executor/validate_oql_reserved_names.go` (MDL071, at CREATE/ALTER ADD/RENAME); `mdl/executor/oql_type_inference.go` (MDL032, inside a view's OQL)", "insight": "**Read the CE0174 text before concluding a name is unusable — it lists `OPEN_QUOTE` among what the parser expects.** Measured on 11.13.0: `select s.\"Month\" as MonthNo` and `from Module.\"Year\" as s` both build at **0 errors**, and mxcli passes the quotes through unchanged, so the fix is normally a quote in the view, not a rename. The one place quoting is unavailable is an **alias**, and that limit is **OQL's own**: it takes a bare identifier there for *any* name (`as \"Total\"`, reserved nowhere, is CE0174 too — reported as MDL072), so a view entity's own attribute (whose name IS its select alias) must be renamed. Hence MDL071 is a warning at the point the name is chosen, not an error. **This entry has corrected itself twice, both times by finally reading the error text.** First it asserted OQL had no quoted-identifier form (disproved by `OPEN_QUOTE` in the CE0174 message, and by the source report's own narrative: `SELECT \"Year\" FROM …` works). Then it asserted the alias limit was MDL's grammar rather than OQL's (disproved by `as \"Total\"` — reserved nowhere — also failing CE0174). The two CE0174 texts differ precisely in whether `OPEN_QUOTE` is listed; that difference is the whole answer and was present in the output from the first measurement onwards. Also: adding a warning to `ValidateEntity` surfaced a pre-existing trap — the exec guard was `if len(vs) > 0 { fail(vs[0]) }`, so every warning blocked the write and MDL022 had been doing so since it shipped. Use `firstBlockingViolation`, never the count; control that an MDL021 error still blocks and is not shadowed. ako/mxcli-captrack #1", "refs": ["#1"], "ce": ["CE0174", "CE7247"], "rules": ["MDL021", "MDL022", "MDL032", "MDL071", "MDL072"]}
-{"area": "mdl/executor", "symptom": "`mxcli check` passes and `exec` prints `Created association`, then the project no longer OPENS — `KeyNotFoundException … at StreamingBsonUnitReader.ResolvePostponedProperties()`, a stack trace naming no document", "cause": "An association whose FROM entity lives in ANOTHER module. Mendix stores an association in the module of its FROM entity, so a remote FROM writes a `ParentPointer` aimed at an element in a different unit. Not a build error — a LOAD error, so Studio Pro cannot open it either", "file": "`mdl/executor/validate_association_module.go` (`ValidateAssociationModules`, MDL070), wired in `mdl/executor/validate_program.go`", "insight": "**Refuse; there is nothing to write instead.** Neither stored form can express it: `DomainModels$Association` holds two element IDs both local to the unit, and `DomainModels$CrossAssociation` holds a local `ParentPointer` plus a BY_NAME `ChildRef` — there is no by-name PARENT. Check the storage shape before treating a direction as a writer bug. The reported case was `from System.User`, but it is **not System-specific** — `from Administration.Account` fails identically, and a guard keyed on System would pass the general case through; the rule is the module boundary. Control both ways: the supported direction (`from MyModule.X to System.User`) and a plain same-module association must stay at 0 errors, and stubbing the guard must bring the KeyNotFoundException back. To locate a dangling GUID at all, scan every `.mxunit` for the raw 16 bytes in BOTH endiannesses (`uuid.bytes` and `uuid.bytes_le` — little-endian is the one that hits). **Run `make check-mdl` before pushing any new `mdl-examples/` file**: CI runs every example as a POSITIVE test unless it is named `*.fail.mdl`, so a fixture demonstrating a refusal fails the build. Split it — refused statements in the `.fail.mdl`, working forms in a sibling `.mdl`, each pointing at the other — so both halves are actually gated rather than only the negative one. ako/mxcli-captrack", "rules": ["MDL070"]}
-{"area": "mdl/executor", "raw": "| `mxcli check --references` refuses a page mxbuild builds, with \"microflow data source M.F has no argument for parameter 'P' … does not fill it in, even when an object of the right type is in scope\" (CE1571) | `mdl/executor/validate_datasource_args.go` | The rule was generalised from a sound measurement to a false one. A page **parameter** of the parameter's type does not auto-map (measured, still true); an enclosing **data context** of a compatible type **does**. The two are different things and the message asserted the wrong one as fact. Re-measured on mxbuild 11.13.0, five widgets in one `mx check`: nested in a dataview of the parameter's type → **no error**; matching context two levels up with a mismatched dataview between → **no error**; mismatched context → CE1571; no context → CE1571; page parameter of the exact type → CE1571. The walk now carries a `dataContext` (the entity types of the enclosing data containers), resolved from the container's data source — a flow's **return** type, a `database` source's entity, a `parameter` source's page-parameter type. An **association** or **selection** source marks the context *unresolved*, which **suppresses** the report: guessing wrong in that direction is exactly what rejected the working page. A **primitive** parameter is always reported (a data context can never supply a String), which is what keeps the rule sharp. The three rejected shapes are the controls — without them the fix is indistinguishable from deleting the rule. Generalisation is delegated to `entityCompatibility`, which accepts a relation in **either** direction: a missed CE1571 costs a build error mxbuild still catches, a wrong refusal costs a working page. |", "ce": ["CE1571"]}
-{"area": "mdl/executor", "raw": "| `mxcli check` warns MDL071 \"attribute 'Year' is an OQL reserved word — … a view entity referencing it unquoted fails to build with CE0174\" on a **non-persistent** entity | `mdl/executor/validate_oql_reserved_names.go`, `mdl/executor/cmd_enumerations.go` | The warning's premise cannot arise: an NPE has no table. Measured rather than reasoned about, by pointing a view entity at one — mxbuild 11.13.0 refuses the **reference**, not the name: `CE0174 \"Entity 'X' cannot be used in OQL, because it is a non-persistable entity\"`. `oqlUnreachable` skips a **known** non-persistent entity, for both the attribute name and the entity's own name. Persistence had to become **three-valued** (`entityPersistence`): `ALTER ENTITY … ADD ATTRIBUTE` carries no kind, and the two rules keyed on it want opposite defaults for \"unknown\" — MDL020 stays silent unless known persistent, MDL071 stays loud unless known non-persistent. The old boolean passed `false` for ALTER meaning *unknown*, so a naive gate on it would have silently dropped MDL071 from the path where a name lands on an entity that already has references. VIEW and EXTERNAL entities count as reachable — a view entity's own attribute name **is** its select alias, the one MDL071 case that genuinely needs a rename. |", "ce": ["CE0174"], "rules": ["MDL020", "MDL071"]}
-{"area": "mdl/executor", "raw": "| `mxcli check … --references` reports \"nanoflow not found: Mod.Flow\" for a nanoflow created **earlier in the same script**, printed directly under the line \"(Note: References to objects created within the script are skipped)\". `exec` runs the same file without complaint and `mx check` is 0 errors | `mdl/executor/helpers.go` (`validateWidgetReferences`) | One omission in a list of five. The function consults `sc.<kind>` — the same-script exemption — for microflows, pages, snippets and entities, and for **nanoflows alone** it did not, so every widget reference kind was exempt except that one. Fix is `&& !sc.nanoflows[ref]`, matching its four siblings. Note this is the **inverse** of MDL-ORDER01, which exists to catch a reference to something created *later*; a rule pair like that is worth checking in both directions when one half is added. The test asserts all the kinds in one table so the omission cannot reappear on a different line, and the control is a nanoflow in neither the project nor the script, which must still be reported. Reported as ledger #138; example `mdl-examples/bug-tests/ledger-138-snippet-nanoflow-same-script.mdl` |", "refs": ["#138"]}
-{"area": "mdl/executor", "symptom": "`mxcli check --references` and `exec` both pass, then the native `mx check` fails **CE6681** \"It is not possible to jump to end activities or jump-to activities\" on a workflow `jump to`", "cause": "`buildJumpTo` set the jump activity's **`Name` to its target's name**. Mendix resolves `TargetActivity` **by name**, so the jump could resolve to itself — and CE6681 then describes a different fault than the real one (an unresolved target, or a stolen name)", "file": "`mdl/executor/cmd_workflows_write.go` (`buildJumpTo`, `deduplicateActivityNames`), `mdl/executor/validate_workflow_jump.go` (MDL-WF05)", "insight": "**A jump target is the only INTRA-document reference a workflow has, and nothing resolved it** — `validateWorkflowStatementRefs` covers external refs (microflows, pages, entities) and returns before looking at activity names. Two defects, and the second is not in the report: naming the jump after its target also breaks a **forward** jump to a *valid* activity, because deduplication renames the SECOND activity carrying a name — measured, `jump ... then StepB` gives the jump `StepB` and the real target `StepB2`. The reported \"works\" row of the trigger table holds only for a backward jump, which is why loops looked fine. So fixing only the unresolved case would have left the other half. Fix both ends: give the jump its own name (`JumpTo`, deduped) so it can never collide, **and** run deduplication in two passes with jumps LAST so a jump never claims a name a real activity wanted. Wire the rule into `ValidateWorkflow` **and** call the same function from `execCreateWorkflow` (the #833 lesson — exec is reachable without check). Compute the valid-target set by running the real builders over the AST rather than re-deriving names: a `call microflow M.SUB_X` activity is named `SUB_X`, and a second copy of that rule would drift into false refusals. List the valid names in the suggestion — they are not visible in the script, which is most of why the wrong one is easy to reach. Exclude jumps from the target set (CE6681 again). Two traps hit while doing it: a nested `if jumpPass { if !jumpPass {` from a careless bulk edit silently disabled all jump renaming (caught only by a two-jump uniqueness test — CE0495 would have been the next report), and `Inner` is an MDL keyword, so a test fixture using it fails to parse for reasons unrelated to the fix. mendixlabs/mxcli#1005", "refs": ["#833", "mendixlabs/mxcli#1005"], "ce": ["CE0495", "CE6681"], "rules": ["MDL-WF05"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE WORKFLOW` output fails `mxcli check` — `mismatched input '[%UserRole_Banker%]' expecting ';'` on a `targeting users xpath` line, and every later statement cascades", "cause": "The emitter wrote `fmt.Sprintf(\"… '%s'\", v)` — quotes in the format string, escaping (if any) at the call site. **6 of 23 emit sites did not escape**: both xpath variants, the user-task caption, the workflow-level due date, and both outcome values", "file": "`mdl/executor/cmd_workflows.go` (all 23 sites), `mdl/executor/identifier_quoting.go` (`mdlQuoted`)", "insight": "**Return the quotes WITH the escaping** — `mdlQuoted(s)` yields `'…''…'` complete, so an unescaped emit cannot be written by omission. Escaping at the call site is one thing to remember per site, and the count of sites only grows. Assert the emitted MDL **parses** (wrap the fragment in a minimal `create workflow … end workflow;` and run `visitor.Build`), never that it contains a particular escape — a substring assertion encodes the very escape under test, so it passes for the wrong reason. Route the harness through `formatWorkflowActivities`, not the per-activity formatter: the statement terminator is appended by the caller, so calling the formatter directly produces unparseable output for reasons unrelated to the bug. Emit tests only cover positions the test constructs, so add a **source scan** for a literal `'%s'` in the describers — the real failure mode is a *new* site added later, and `mdlQuoted` carrying its own quotes is what makes that scan sound. The reported symptom was the XPath (its payload is full of quoted constraints, so *every* XPath-targeted user task hits it); the caption one needs only an apostrophe — `Manager's review`. mendixlabs/mxcli#1006", "refs": ["mendixlabs/mxcli#1006"]}
-{"area": "mdl/executor", "symptom": "`DESCRIBE WORKFLOW` output is refused by `mxcli check` with **MDL-WF04** — \"a standalone `annotation` … produces a model Mendix cannot load\"; 13 errors from one unmodified describe of a 23-activity workflow", "cause": "The describer emitted `annotation '<text>';` — the exact construct MDL-WF04 exists to refuse, and that `execCreateWorkflow` refuses again. Two parts of the tree disagreed **in comments**: the emitter said \"emitted as a parseable MDL statement so it survives round-trips\", the validator said it cannot be loaded. The emitter's comment was the stale one", "file": "`mdl/executor/cmd_workflows.go` (`formatAnnotation` + the `WorkflowAnnotationActivity` branch), refusals in `mdl/executor/validate_workflow.go` and `cmd_workflows_write.go`", "insight": "**When a describer and a validator disagree, one of them has a stale comment — read both before choosing a side.** The reporter framed these as canvas annotations; they are not. `formatAnnotation` is called at 10 sites, always with an activity's **attached** `Annotation`, and describe converted attached → standalone, which is the refused form. That distinction changes the fix: the issue's \"support writing annotations\" needs a grammar change, because `MDLWorkflow.g4` has only the standalone `workflowAnnotationStmt` — **no MDL input can express an attached annotation today**, even though the write path stores one. So a comment loses nothing that was reachable. Note the asymmetry that caused this: the **microflow** domain has `@annotation 'text'` as an activity prefix and round-trips it properly; giving workflow activities the same prefix is the non-lossy fix, and is a feature, not this bug. Two traps: a `--` comment runs to end of line, so a multi-line annotation must be prefixed **per line** or the tail becomes stray tokens (the same failure the statement form had), and the standalone branch must set `isComment` or the terminator logic appends `;` to a comment. Assert the emitted MDL **parses AND passes ValidateWorkflow AND still contains the text** — checking only that the keyword is gone also passes for an emit that dropped the annotation entirely. mendixlabs/mxcli#1007", "refs": ["mendixlabs/mxcli#1007"], "rules": ["MDL-WF04"]}
-{"area": "mdl/executor", "raw": "| Every `IMAGE` widget mxcli authors on Mendix 11.13 fails `mx check` with **CE0463** \"the definition of this widget has changed\", including the exact `pluggablewidget` form an existing bug-test documents as fixed. `mxcli fix widgets` clears it | `mdl/executor/widget_engine.go` (`hiddenUnnamedProperties`, the mapping loop) | **Case B**, established before any hypothesis (diagnose-ce0463 Step 0): the baseline blank project ships **10 Studio Pro-authored widgets of the same widget id** and reports **0** CE0463; one mxcli-authored Image makes it 1. So the tool is the variable — and those 10 are a known-good reference in the same project, better than a template extraction. The exhaustive path diff came back with **every path present on both sides** and four differing values, two of them content; the `Type` (PropertyTypes schema) subtree and the `TypePointer`→`PropertyKey` mapping were identical. **Two hypotheses tested and falsified, which is why they are recorded**: (a) *key order* — mxcli's node is not in the reference's alphabetical order, a documented CE0463 cause, but the same page's mxcli-authored Datagrid and Badge share that order and pass; (b) *the width value* — authoring `Width: 48` explicitly passes, so 48 is not rejected. The cause is the interaction: the widget **hides `width` when `widthUnit` is \"auto\"**, and a hidden property must hold its DECLARED default. The engine *skipped* the mapping for a hidden property, which leaves the widget **template's captured value** — image.json holds 48 while its own `ValueType.DefaultValue` says 100. mxcli's own **MDL-WIDGET10** already said so verbatim (\"a non-default value there fails the build with CE0463 (the default is \\\"100\\\")\"), so `check` refused what `exec` emitted: the fix makes the writer read `widgetPropertyDefaults`, the checker's own source, so the two cannot disagree again. The engine's comment already stated the invariant correctly — \"the hidden ones **at their default**, so hidden means default-valued, not absent\" — and skipping only coincides with that when the template happens to be at the default. Where no default can be looked up (a datasource has none) it still skips, so #956's File Uploader pruning is unchanged. **Control**: stub the `SetPrimitive` and CE0463 returns end-to-end. Follow-on the fix *revealed* (CE0463 was masking it): the default `ImageType: image` needs an image-collection entry MDL cannot name, so the bare form builds to Mendix's own \"No image selected.\" — now **MDL-WIDGET22** at check time, and it found the same breakage in four of the repo's own examples. Reported as mxcli-formula1 FINDINGS §69/§142 |", "refs": ["#956"], "ce": ["CE0463"]}
-{"area": "mdl/executor", "raw": "| An `image` widget mxcli wrote shows nothing, and `mx check` fails with **\"No image selected.\"**; and a `describe` → rename → `exec` copy of an Atlas layout (or any page with a brand image) comes out with the image gone, describe having emitted `image staticImage1 (Responsive: false)` with no reference at all | `mdl/executor/widget_engine.go` (the `image` operation), `mdl/executor/widget_defs.go` + `mdl/executor/widget_registry.go` (`operationForType`, `defaultKnownOperations`), `mdl/backend/widgetobj/builder.go` (`SetImage`, `setImageValue`), `mdl/backend/mutation.go` + `mdl/backend/mcp/widget.go`, `{modelsdk,sdk}/widgets/definitions/image.def.json` (`imageObject` → `Image`), `mdl/executor/cmd_pages_describe_pluggable.go` (`extractCustomWidgetPropertyImage`) + `cmd_pages_describe_output.go` (`describeImageWidgetProps`) | MDL had no spelling for **which** image an image widget shows, so its default source (`ImageType: image`, an image collection entry) could never be satisfied and describe had nothing to emit — mxcli-formula1 FINDINGS §142. The name is three parts like an icon reference, `Module.Collection.Image`, stored as a plain string on the `WidgetValue`'s `Image` key. Both halves are needed: with only the write, a round trip still loses it. `setImageValue` **replaces** the existing `Image` key and never adds one — adding a key the widget definition does not declare is the CE0463 shape. Controls: stub `setImageValue` → `TestSetImageValue_SetsTheQualifiedName` fails; stub the describe emission → `TestDescribeImageWidget_EmitsTheImageReference` fails |", "ce": ["CE0463"]}
-{"area": "mdl/executor", "raw": "| `image imgTypo (Image: 'MyFirstModule.Images.NoSuchImage')` passes `mxcli check --references` (\"Check passed!\") and the build then fails **CE1613** \"The selected image '…' no longer exists.\" | `mdl/executor/validate_widget_image_ref.go` (new, `imageRefErrors`, `buildImageQualifiedNames`), `mdl/executor/helpers.go` (`widgetRefCollector.images`, `validateWidgetReferences`) | Wiring `Image:` created a new qualified name and nothing resolved it — every other name a widget carries (microflow, nanoflow, page, snippet, entity) already was. This one has **three** parts, so the two mistakes get two messages: a missing collection sends the reader to `show image collections`, a missing image to that collection's contents (which the diagnostic lists). A **nil** name set means the collections could not be read and nothing is reported; an empty non-nil one is a real answer. No same-script exemption — MDL cannot create an image collection entry, so the reference can only resolve against the project. Control: `TestImageRefErrors_KnownImageIsClean`, and `TestImageRefErrors_NoCollectionsMeansNoOpinion` for the failed-read direction |", "ce": ["CE1613"]}
-{"area":"mdl/executor","symptom":"`main` goes red on a test that passed in **both** PRs that touched it — here `TestDescribeWorkflow_NoAnnotationEmitsNoComment`: `unexpected violations [MDL-WF05] for a plain jump`","cause":"Two PRs merged in sequence. One added a validator rule (MDL-WF05, dangling `jump to` target); the other's control test asserted `len(violations) == 0` over a fixture that was **not a valid workflow** — a lone jump whose target did not exist. Each CI run was green because neither saw the other's change","file":"`mdl/executor/issue1007_annotation_emit_test.go` (the fixture), `mdl/executor/validate_workflow_jump.go` (the rule, which is right)","insight":"**A test fixture that is not a valid instance of the thing under test is a landmine for the next rule.** \"No violations at all\" is only meaningful over input that *should* have none; over an invalid fixture it silently asserts \"no rule has been written yet that notices this\". Fix the **fixture**, not the rule. Generalise: when a test asserts the ABSENCE of diagnostics, make the input something you would be happy to ship. Two green PRs can still merge to red and **neither PR's CI can detect it** — the only protection is a fixture that does not depend on which rules exist today. Found by running `make test` on an unrelated docs branch cut from the merged main, which is an argument for doing that on any branch cut after a batch merge.","refs":["#350","#351"],"rules":["MDL-WF04","MDL-WF05"]}
-{"area": "mdl/executor", "symptom": "`filter($L, Amount > 0)` — or any FILTER/FIND predicate with a bare attribute and an operator other than `=` — fails the build with CE0117 \"Error(s) in expression.\", while the same attribute with `=` builds fine. `mxcli check` and `check --references` both pass. Reported as a Mendix 11.13 regression.", "cause": "The unfinished half of bug #343. Mendix has two filter operations: `Microflows$Filter` takes a member NAME (filter by attribute) and `Microflows$FilterByExpression` takes an expression evaluated per item with the item bound to `$currentObject`. #343 rerouted only `attr = value` to the by-attribute form; every other predicate still fell through to the expression form, where mxcli stored the authored text verbatim — and a bare attribute is not a valid Mendix expression. So the split was on the OPERATOR and invisible to the author: `Status = 'x'` built, `Status != 'x'` did not.", "file": "`mdl/executor/cmd_microflows_builder_actions.go` (`qualifyIteratorAttributes`, `listElementEntity`, `iteratorMemberPath`, `qualifyNamesInSource`); `mdl/executor/validate_microflow_listop_iterator.go` (MDL-LISTOP01); syntax topic `cmd/mxcli/syntax/features_microflow.go`; repros `mdl-examples/bug-tests/1002-filter-find-bare-attribute.mdl` and `1002-filter-bad-iterator.fail.mdl`.", "insight": "Rewrite a bare name that PROVABLY resolves to a member of the list's element entity into `$currentObject/<member>`; refuse one that does not resolve (it used to surface as CE0117 at build time); pass through untouched when the element entity cannot be determined, which proves nothing either way. An association takes its module qualifier in the path, an attribute does not. The predicate is a frozen `SourceExpr` (`buildSourceExpression` in the visitor), so the rewrite has to patch the source TEXT, skipping single-quoted literals — `filter($L, Qty > 0 and Status != 'Amount')` must not rewrite the `'Amount'` inside the literal. Do not blame the Mendix version without running both: the issue reported \"reproduces on 11.13.0, not 11.11.0\" and the identical 7-error probe on mxbuild 11.11.0 and 11.13.0 disproves it — the fork is in mxcli, and nothing in it depends on the version. `mx check -j <file>` is the attribution tool: the console output names only the activity (\"List operation activity 'Filter by expression'\"), so two errors on one line read as one microflow; the JSON carries `document-name` per location. MDL-LISTOP01 keys on scope, not on the name — `$item` is valid in a predicate when it is the enclosing loop's iterator, which is exactly how CLAUDE.md's O(N) `find` idiom is written, so flagging the name would break the documented pattern. Control for the whole fix: stub `qualifyIteratorAttributes` to return the condition unchanged and the repro goes 0 → 7 x CE0117 with the two `=` cases staying green, which is also the #343 regression guard.", "refs": ["#1002", "#343"], "ce": ["CE0117", "CE0109"], "rules": ["MDL-LISTOP01"]}
-{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A copied Atlas layout (or any page mxcli authors) fails `mx check` with **CE0463** on its Image widget, and a full field-level diff against Studio Pro's own widget differs in exactly **one line of 1480** \u2014 `maxHeight`, mxcli's `0` against the installed package's declared default", "cause": "Same class as the \u00a769 width/height fix, which did not cover it \u2014 and why is the point. The reset was applied in a loop over the definition's **property mappings**, and a mapping is what gives a property an MDL keyword: `width`/`height` have one, `maxHeight` has none, so it was never visited and the widget TEMPLATE's captured value stood. Two further halves, each independently load-bearing (stub either and the test fails): a rule whose CONDITION is an unmapped property (`maxHeight` is hidden when `maxHeightUnit` = \"none\") was always indeterminable so never fired \u2014 the declared default is the right fallback there, because nothing can have moved an unnamable property off it; and `def.PropertyVisibility` is **empty** for every widget whose rules are lifted live from the `.mpk`, which is most of them, so a lookup keyed on that field silently finds nothing (both consumers now share `visibilityRules()`).", "file": "`mdl/executor/widget_engine.go` (`unmappedHiddenResets`, `visibilityRules`, the condition fallback in `hiddenUnnamedProperties`)", "insight": "The general rule: **the set of properties that must be default-valued is the widget's editorConfig to decide, not mxcli's** \u2014 making it a subset of what MDL has words for was the mistake. The third trap was found only end-to-end; the unit test passed while the command still wrote the wrong value. Control, end-to-end on a real 11.13 project with the Image `.mpk` patched to declare `maxHeight` 250 (the 1.6.0 value the finding measured, since that version was not obtainable): pre-fix binary writes 0 and all four mxcli-authored Images fail CE0463; fixed binary writes 250 and all four are clean, while `minHeight` stays at its own declared 0 \u2014 per-property from the package, not a blanket value. The project's ~60 Studio Pro-authored Images stay stale under both, which is the package change itself and not mxcli: the Step 0 discrimination diagnose-ce0463.md asks for. Reported as mxcli-ledger FINDINGS \u00a7142."}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A generated loop box is drawn far wider than the activities inside it (e.g. 880px around 440px of content), leaving a large empty area — \"the visualization is poor\"", "cause": "`measureStatements` sums each element's full width **and** adds `HorizontalSpacing` between them, but `HorizontalSpacing` is a centre-to-centre *pitch*: the builder centres each activity on `posX` and advances by exactly that. Counting it on top of each width over-measures a run of n simple activities by `(n-1)*ActivityWidth`", "file": "`mdl/executor/layout.go` (`measureStatementsSpan`), used by `addLoopStatement`/`addWhileStatement` in `cmd_microflows_builder_control.go`", "insight": "For a run of only simple activities the true span is `(n-1)*HorizontalSpacing + ActivityWidth`. **Do not guess the advance for a compound element** (IF/split, nested loop) — its `posX` advance comes from merge geometry (`mergeX + MergeSize + HorizontalSpacing/2`), and guessing under-sizes the box so activities land *outside* it, which is worse than a box that is too wide; those runs fall back to the conservative measure. Verify with a containment check: every child of a LoopedActivity must lie within `[0, width] × [0, height]`. Issue #790", "refs": ["#790"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create or modify external entities` silently resets a per-entity setting the user had changed (e.g. allow-create-change-locally)", "cause": "`applyExternalEntityFields` stamps every field on both the create and the update path, so anything not derivable from the OData contract was overwritten with a default", "file": "`mdl/executor/cmd_contract.go` (`applyExternalEntityFields`)", "insight": "Separate contract-derived fields (Countable/Creatable/Deletable/Skip/Top — refresh from metadata) from local modelling choices (CreateChangeLocally — leave alone; a new entity arrives zero-valued, which is Mendix's default). Issue #782", "refs": ["#782"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`describe page` reports the wrong context entity under a data container bound to a microflow/nanoflow — `-- Context: $currentObject (Module.GetOrders)` names the *flow* instead of the entity it returns", "cause": "`widget.EntityContext = widget.DataSource.Reference` is correct for a database source (reference *is* the entity) and wrong for a flow source (reference is the flow's qualified name)", "file": "`mdl/executor/cmd_pages_describe_flowcontext.go` (`dataSourceEntityContext`, `flowReturnEntity`) + the five assignment sites in `cmd_pages_describe_parse.go`", "insight": "Resolve the flow's return type via `ListMicroflows`/`ListNanoflows` + `getHierarchy().GetQualifiedName`, taking the entity from an Object/List return type; fall back to the reference when the flow is unresolvable or returns a scalar, so the result is never worse than before. Note `GetRawUnitByName` is unimplemented on the modelsdk engine — the list+hierarchy path is the one that works"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`describe page` omits a **pluggable** widget's `DataSource` when it is bound to a microflow (`datagrid g1 {` with no DataSource), while a `database from` source describes fine — re-applying the output recreates the grid unbound", "cause": "A `Forms$MicroflowSource` stores the name in the nested `Forms$MicroflowSettings` (`MicroflowSettings` → `Microflow`), which is what the write path and Studio Pro emit; the reader looked up a top-level `Microflow` key, got `\"\"`, and returned no datasource. The describe *formatter* was correct all along — read bug only", "file": "`mdl/executor/cmd_pages_describe_pluggable.go` (`microflowSourceRef`, `nanoflowSourceRef`, `extractDataGrid2DataSource`, `extractGalleryDataSource`, `parseCustomWidgetDataSource`)", "insight": "Read the nested settings with a top-level fallback, via one shared helper — there were four divergent copies of this lookup and two were wrong. `Forms$NanoflowSource` was missing entirely from the DataGrid2/Gallery switches; add it alongside. Do **not** touch `CustomWidgets$CustomWidgetNanoflowSource` (a different metamodel type whose `Nanoflow` really is top-level) or the `Forms$MicroflowAction` reads (actions, not datasources). Repro `mdl-examples/bug-tests/795-datagrid-microflow-datasource-describe.mdl`. Issue #795", "refs": ["#795"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`ALTER SETTINGS` / `CREATE CONFIGURATION` prints \"Updated …\" but `DESCRIBE SETTINGS` shows the old value — an Integer property was given a non-numeric value, or a Boolean anything other than `true`", "cause": "`strconv.Atoi`'s error was discarded (`if v, err := …; err == nil`) so the assignment was skipped while the caller still printed success; the boolean form compared against `\"true\"`, silently mapping every other spelling to false", "file": "`mdl/executor/cmd_settings.go` (`settingsInt`, `settingsBool`) + `mdl/executor/validate_settings.go` (`typedSettingsKeys`, MDL-SET01/MDL-SET02)", "insight": "Parse through a helper that returns a validation error naming the setting and the offending value, and register the property in `typedSettingsKeys` so `mxcli check` and the LSP flag it before the project is opened for writing. `TestTypedSettingsKeys_MatchExecutor` guards the table against drifting from the executor's switch. Repro `mdl-examples/bug-tests/805-alter-settings-typed-values.fail.mdl`. Issue #805", "refs": ["#805"], "rules": ["MDL-SET01", "MDL-SET02"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Retrieve/datasource XPath with a `[%…%]` token (e.g. `[System.owner = '[%CurrentUser%]']` or `[Title = '[%CurrentUser%]']`) fails `mx check` CE0161, but `[Title='abc']` is clean", "cause": "NOT a token-storage bug — tokens store intact and a type-valid token (`[DueDate < '[%CurrentDateTime%]']`) passes. The failures are semantically-invalid XPath: (1) String/scalar attr compared to a User token = type mismatch; (2) `System.owner`/`changedBy`/… referenced on an entity that doesn't store it (needs `alter entity X add attribute owner: autoowner`)", "file": "`mdl/executor/validate.go` (`validateRetrieveConstraints`, `baseSystemMemberRe`) — diagnose with `mxcli bson dump --type microflow` + `mx check`; verify the token alone works", "insight": "Don't \"fix\" storage — it's correct. Add a `--references` check: collect retrieve `(entity, constraint)` in `flowRefCollector`, look up the entity via `buildEntityIndex` (`ListDomainModels`), and flag a base-entity `System.<member>` ref (regex excludes `/`-traversed refs) when the entity flag (`HasOwner` etc.) is off, with the `alter entity … add attribute …: auto…` hint. Same-script-created entities aren't in the project index, so the check only fires against existing project entities. **Also fixed**: a bare `[%token%]` *inside* a bracketed constraint (`[DueDate < [%CurrentDateTime%]]`) stored unquoted (the inline path keeps the raw source) → CE0161. `normalizeXPathTokens` (`mdl/visitor/visitor_page_v3.go`) requotes bare tokens; wired into `buildXPathSourceExpression`, the multi-predicate `predicateSources`, `buildXPathString`, and `bracketedXPathFromExpr` (already-quoted tokens untouched). Issue #641", "refs": ["#641"], "ce": ["CE0161"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`describe` shows `$var = action ...;`", "cause": "Missing formatter case", "file": "`mdl/executor/cmd_microflows_format_action.go` → `formatActionStatement()`", "insight": "Add `case *microflows.XxxAction:` with `fmt.Sprintf` output"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`describe` shows `$var = list operation %T;` (with type name)", "cause": "Missing formatter case", "file": "`mdl/executor/cmd_microflows_format_action.go` → `formatListOperation()`", "insight": "Add `case *microflows.XxxOperation:` before the `default`"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `create page` reported success but the built page is EMPTY — every widget gone — and `mx check` fails with CE1613 \"The selected layout 'dummyModule.dummyName' no longer exists\"", "cause": "The page had no `Layout:` clause, so `buildPageV3` created no `LayoutCall`; the widget tree is built into the LayoutCall's placeholder arguments, so with no LayoutCall the widgets have nowhere to attach and are silently dropped. `dummyModule.dummyName` is *Mendix's* placeholder for a missing layout, not something mxcli writes", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`buildPageV3`, the `if page.LayoutCall != nil` block)", "insight": "Reject a page that has body widgets (or placeholder blocks) but no LayoutCall — distinguish \"no Layout: clause\" from \"layout not found\" in the message. A Mendix page always needs a layout; snippets (buildSnippetV3) are layout-less and unaffected. Repro `mdl-examples/bug-tests/266-page-without-layout-drops-widgets.mdl`", "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mx check` fails to LOAD the project — `StorageLoadException: ... 'Module.Name' is not a valid AttributeIdentifier` after a `create`/`change` with a `Module.Assoc = …` member, yet `mxcli exec` reported success", "cause": "A one-qualifier member (`Module.Name`) that isn't a known association was written as an *attribute* ref, but a one-qualifier name can't be a valid attribute (attributes are bare or `Module.Entity.Attribute`) → unloadable .mpr. Usually the association's `create` failed earlier (non-idempotent) leaving it absent", "file": "`mdl/executor/cmd_microflows_builder_actions.go` (`resolveMemberChange`, the \"Not an association in the authored module\" branch)", "insight": "When the domain model is available and the one-dot member isn't in `dm.Associations`/`dm.CrossAssociations`, `fb.addError` with an actionable \"create the association first\" message instead of writing an Attribute. Same-script associations are visible via `GetDomainModel`, so no false positive. Repro `mdl-examples/bug-tests/264-create-member-unknown-association.mdl`. FINDINGS #51", "refs": ["#51"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check` rejects a **valid** microflow: **MDL048** on `retrieve … where [id = '[%CurrentUser%]']` (the standard signed-in-user idiom) — but `mx check` → 0 errors", "cause": "MDL048 targets constraining `id` against a STORED value (String/Long var or plain literal), which Mendix XPath can't do; it also matched the `'[%CurrentUser%]'` **server token**, which Mendix DOES resolve to a GUID", "file": "`mdl/executor/validate_microflow.go` (`checkXPathIdConstraint`)", "insight": "Skip an operand of the form `'[%…%]'` (a resolved token) before flagging. Case still fires for real stored-id values. Test `TestValidateMicroflow_XPathIdConstraint` (CurrentUser case); repro `mdl-examples/bug-tests/52-53-microflow-check-false-positives.mdl`. FINDINGS #53", "refs": ["#53"], "rules": ["MDL048"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check` rejects a **valid** microflow: **MDL045** (\"`/` is division\") on `round($a div $obj/Attr * 100)` — division whose divisor is an association-attribute path — but `mx check` → 0 errors", "cause": "The MDL grammar parses `div`/`*`/`/` at one precedence level, so `$a div $obj/Attr` mis-nests as `($a div $obj) / Attr`; MDL045 saw the `/ Attr` as division. But `Attr` is a bare member name — Mendix has no `/` division operator and re-parses the raw `$obj/Attr` as a path (serialized output preserves the `/`, so the build is clean)", "file": "`mdl/executor/validate_microflow.go` (`exprHasSlashDivision`)", "insight": "Don't flag a `/` BinaryExpr whose RIGHT operand is a bare `IdentifierExpr` (member navigation); real division has a numeric/paren/variable divisor. Test `TestValidateMicroflow_SlashDivision` (div-by-assoc cases); repro `mdl-examples/bug-tests/52-53-microflow-check-false-positives.mdl`. FINDINGS #52", "refs": ["#52"], "rules": ["MDL045"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create association X …` errors \"association already exists\" on re-run and aborts the script", "cause": "Correct SQL-shaped semantics (like `CREATE TABLE`) — `create` is not idempotent. The idempotent form is `create or modify association`, but it was undiscoverable from the bare error", "file": "`mdl/executor/cmd_associations.go` (the `NewAlreadyExists(\"association\", …)` sites)", "insight": "Not a code bug in the write path — improve the error to name `create or modify association …` and `drop association …`. Repro `mdl-examples/bug-tests/51-create-or-modify-association.mdl`. FINDINGS #51", "refs": ["#51"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`dynamictext x (Content: '')` builds with **CE0720** \"Place holder index 1 is greater than 0\" — `mxcli check` ✓, describe shows `Content: '{1}'` with no params", "cause": "The builder unconditionally defaulted empty content to the template `{1}`, creating a placeholder with no matching parameter (orphaned)", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildDynamicTextV3`, final `content == \"\"` guard)", "insight": "Only default to `{1}` when there IS a parameter (`autoGeneratedParams`/`explicitParams`); empty content with no params is a literal empty template. Test `TestBuildDynamicTextV3_EmptyContent`; repro `mdl-examples/bug-tests/traceops-9-10-17-dynamictext-listview.mdl`. traceops #9", "refs": ["#9"], "ce": ["CE0720"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`dynamictext s (Content: '$318')` builds with **CE0402/CE1613** (\"attribute '$318' no longer exists\") — the literal was turned into an unbound `{1}` param", "cause": "The auto-bind check treated ANY `$`-prefixed content as a variable; `$318` (dollar + digits) is not a valid Mendix variable", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`isDynamicTextVariableRef` / `dynamicTextVariableRe`)", "insight": "Treat `$` as a variable ONLY when followed by a letter/underscore (`^\\$[A-Za-z_]`); `$318` stays literal content. Tests `TestBuildDynamicTextV3_DollarDigitLiteral`, `TestIsDynamicTextVariableRef`. traceops #10", "refs": ["#10"], "ce": ["CE0402", "CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`listview lv (… PageSize: 200)` always pages at 20 — `mxcli check` ✓, `mx check` ✓, describe shows no PageSize", "cause": "The property parsed into the AST but three layers ignored it: `buildListViewV3` hardcoded `PageSize: 20`, the describe parse never read it, and the listview describe formatter never emitted it", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildListViewV3`) + `cmd_pages_describe_parse.go` (Forms$ListView case) + `cmd_pages_describe_output.go` (listview case)", "insight": "Read `w.GetIntProp(\"PageSize\")` on write; read `w[\"PageSize\"]` on describe; emit a non-default PageSize in the listview formatter. Test `TestBuildListViewV3_PageSize`. traceops #17", "refs": ["#17"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`combobox (Association: Mod.Ref, …)` drops the binding — `mxcli check` ✓ but MxBuild fails **CE0642** \"Property 'Attribute' is required\"", "cause": "The widget engine's `Association` source read the reference only from the `attribute:` keyword (`w.GetAttribute()`), so an explicit `Association:` keyword was ignored and the widget fell back to enumeration mode", "file": "`mdl/executor/widget_engine.go` (`case \"Association\"`) + `mdl/executor/validate_widgets.go` (`validateComboBoxAssociation`)", "insight": "Read the reference from `Association:` OR `attribute:`; and add MDL-WIDGET16 flagging an association combobox that lacks the required `datasource:` (option list). A complete association combobox needs reference + `datasource:` + `CaptionAttribute:`. Tests `TestValidateComboBoxAssociation`; repro `mdl-examples/bug-tests/traceops-23-combobox-association.mdl`. traceops #23", "refs": ["#23"], "ce": ["CE0642"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| `grant view on page` / `grant execute on microflow\\|nanoflow` / `grant access on odata\\|published rest service` to a role from **another module** passes `mxcli check`/`exec` but fails the Mendix build with **CE0148 \"reselect roles\"** — the own-module role works | Document access (page/microflow/nanoflow/service `AllowedModuleRoles`) may only reference the document's **own** module roles; Studio Pro's picker only offers those. The grant path wrote `role.Module + \".\" + role.Name` verbatim with no same-module check (only `validateModuleRole` = role-exists-in-its-module), so a cross-module reference reached the model. The MOVE path already guarded this (`remapDocumentAccessRoles`) — GRANT didn't | `mdl/executor/cmd_security_defaults.go` (`checkDocumentAccessRolesSameModule`) + the 5 grant handlers in `mdl/executor/cmd_security_write.go` | Pre-check each grant: reject when any `role.Module != docModule` with an actionable message (name the doc's module + suggest the own-module role). Reject (don't silently remap) — a GRANT is explicit, so a wrong role/doc shouldn't be substituted. Wired into page/microflow/nanoflow/OData/published-REST grants. Repro `mdl-examples/bug-tests/ce0148-cross-module-grant.mdl` |", "ce": ["CE0148"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "CE7054 \"parameters updated\" / CE7067 \"does not support body entity\" after `send rest request`", "cause": "`addSendRestRequestAction` emitted wrong BSON: all params as query params, BodyVariable set for JSON bodies", "file": "`mdl/executor/cmd_microflows_builder_calls.go` → `addSendRestRequestAction`", "insight": "Look up operation via `fb.restServices`; route path/query params with `buildRestParameterMappings`; suppress BodyVariable for JSON/TEMPLATE/FILE via `shouldSetBodyVariable`", "ce": ["CE7054", "CE7067"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`CREATE X` returns \"already exists — use create or replace to overwrite\" but OR REPLACE is not valid for that type", "cause": "Error message in executor points to wrong keyword", "file": "`mdl/executor/cmd_<type>_*.go` — find the `NewAlreadyExistsMsg` call", "insight": "Change hint from `or replace` to `or modify`; verify the AST stmt uses `CreateOrModify` not `CreateOrReplace`"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mx check` CE0126 \"Missing value for parameter X\" on `call java action ... ($Param = empty)` for typed (non-entity, non-microflow) parameters", "cause": "Builder emitted `BasicCodeActionParameterValue.Argument: \"\"` instead of the literal `\"empty\"` keyword", "file": "`mdl/executor/cmd_microflows_builder_calls.go` → `addCallJavaActionAction`", "insight": "Capture all resolved BasicParameterType params into `resolvedBasicParams`; when bound to MDL `empty`, emit `Argument: \"empty\"` so Studio Pro recognises an explicit empty literal rather than treating the slot as missing", "ce": ["CE0126"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE microflow` puts shared activities inside an `if … then` block — they should appear after `end if;`", "cause": "Nested guard split inside `traverseFlowUntilMerge` crosses the outer merge boundary", "file": "`mdl/executor/cmd_microflows_show_helpers.go` — guard path in `traverseFlowUntilMerge` (~line 854)", "insight": "Add `if contID != mergeID` guard before the `isMerge` skip-through so the guard continuation never crosses the outer merge"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Published OData service: `mx check` reports **CE5016** \"Attribute X has type String(50), but is published as .\" (empty published type) for every exposed attribute — modelsdk engine only (legacy slides by)", "cause": "mxcli never wrote `ODataPublish$PublishedAttribute.EdmType`, the OData EDM type Studio Pro stores on every published attribute. Both engines omitted it, but legacy's `$Type` field order let Studio Pro recompute; modelsdk's order tripped the check. **The legacy output was non-canonical too — don't treat \"legacy passes mx check\" as \"legacy is correct.\"** Found by diffing mxcli BSON vs a Studio-Pro-duplicated-and-fixed copy (the definitive method for these \"empty field\" checks)", "file": "`mdl/executor/cmd_odata.go` (`mendixAttrTypeToEdm`, `lookupEntityMembers`, `astEntityDefToModel`) + both writers (`publishedMemberToGen`, `serializePublishedMember`) + both reads", "insight": "Add `EdmType` to `model.PublishedMember`; derive it from the attribute's Mendix type (inverse of `edmToDomainModelAttrType`: String→Edm.String, Integer→Edm.Int32, Long/AutoNumber→Edm.Int64, Decimal→Edm.Decimal, Boolean→Edm.Boolean, DateTime→Edm.DateTimeOffset, Binary→Edm.Binary); emit + read in both engines", "ce": ["CE5016"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Published OData service: `mx check` reports **CE5022** \"Published association X has changed multiplicity\" for every exposed association — modelsdk engine only", "cause": "Same shape as CE5016 but for `ODataPublish$PublishedAssociationEnd.IsMany` (the exposed navigation's multiplicity), which mxcli never wrote. Confirmed via the same Studio-Pro-duplicate-and-diff method", "file": "`mdl/executor/cmd_odata.go` (`assocMembership.Type`, `astEntityDefToModel`) + both writers/reads", "insight": "Add `IsMany` to `model.PublishedMember`; compute from the association type + exposed side (ReferenceSet ⇒ to-many either end; Reference ⇒ to-many only from the TO/Child side, to-one from the FROM/Parent side); emit + read in both engines", "ce": ["CE5016", "CE5022"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "MDL widget property `mxcli check`s clean but Studio Pro renders the default (e.g. `dataview ... (FormOrientation: Vertical)` always Horizontal)", "cause": "V3 grammar generic-property branch parks the value in `w.Properties`, but the V3 builder never reads it and the writer never emits it; the widget struct has no field for it", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildXxxV3`) + `sdk/mpr/writer_widgets_*.go` (`serializeXxx`) + `sdk/pages/pages_widgets_*.go`", "insight": "Add field to `pages.Xxx`; read via `w.GetStringProp` / `w.GetIntProp`; write in `serializeXxx`. If the Studio Pro UI label differs from the BSON storage name (e.g. DataView \"Form Orientation\" → `LabelWidth: 0/N`), confirm by diffing a Studio Pro-saved page against the reflection-data defaults"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Pluggable widget datasource property (`optionsSourceAssociationDataSource: Module.Entity`) passes `check` + `exec` but `mx check` reports CE0642 \"Property 'Entity' is required\"", "cause": "A `datasource`-operation property was authored by name; the engine reads the widget's `datasource:` clause (`Properties[\"DataSource\"]`), not the named key, so the value is silently dropped (and `hasDataSource` mode-selection also misfires)", "file": "`mdl/executor/validate_widgets.go` (`datasourceTypedKeys`) — and author via the `datasource:` clause", "insight": "`check` now rejects named datasource-typed props (MDL-WIDGET05); the fix for the user is `datasource: database Module.Entity`. Persisting a *named* datasource property (multi-datasource widgets) needs a Studio-Pro-verified mapping — deferred. Real-but-unmapped props get MDL-WIDGET06 warning via def.json `knownProperties` (not a false MDL-WIDGET01)", "ce": ["CE0642"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "CE7247 \"The name 'X' is a reserved word.\" on non-persistent entity attributes (Owner/Type/Context/Id/CreatedDate/ChangedDate/ChangedBy) — mxcli accepts the MDL silently, Studio Pro rejects the project", "cause": "`ValidateEntity` early-returned for NPEs; reserved-word check was not wired into the executor", "file": "`mdl/executor/cmd_enumerations.go` (`ValidateEntity`) and `mdl/executor/cmd_entities.go` (`execCreateEntity`)", "insight": "Drop the `EntityPersistent` early-return; gate only `mendixSystemAttributeNames` (MDL020) to persistent; run `mendixReservedWords` (MDL021) for all kinds; call `ValidateEntity` from `execCreateEntity` before any backend write. Issue #552", "refs": ["#552"], "ce": ["CE7247"], "rules": ["MDL020", "MDL021"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE MICROFLOW` (mdl/json) times out at 300s on a high-McCabe flow, but `--format mermaid` renders in ~1s — extraction is fast, the serializer hangs", "cause": "Exponential path enumeration: `duplicateOutputVariableWarnings` (run during `formatMicroflowActivities`) walked EVERY execution path, cloning the visited map at each branch (`cloneIDBoolMap`), to find output vars assigned twice on one path — O(2^branches). ~20 sequential `if/end if` diamonds already took ~10s. Diagnose with `DBGPROF=… ` CPU profile / add a pprof block to `describeMicroflow`; top-cum names the offender (not the describe traversal, which is linear)", "file": "`mdl/executor/cmd_microflows_show.go` (`duplicateOutputVariableWarnings`)", "insight": "Replace the all-paths walk with **reachability**: a name is a duplicate iff two of its assignments are path-ordered (one reaches the other); exclusive-branch assignments never reach each other. Memoized `reachableFrom` is O(V·E). Loop bodies inherit names assigned by activities that reach the loop node. Went 9.5s→0.1s at 20 diamonds; 120 diamonds completes instantly. Issue #710", "refs": ["#710"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE` of an entity/module emits `grant ... (read (Module.Entity.Attr))` that fails to re-parse with `mismatched input '.'` — breaks the DESCRIBE roundtrip", "cause": "Member emitter used the fully-qualified BY_NAME reference; grant grammar accepts a bare `IDENTIFIER` only", "file": "`mdl/executor/cmd_entities_access.go` → `resolveEntityMemberAccess`", "insight": "Strip `memberName` to the last `.`-segment before appending (bare names have no dot, so it's a no-op for them). Issue #633", "refs": ["#633"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`style:` on a `dynamictext` crashes MxBuild with a NullReferenceException (fails at build, not check)", "cause": "The generic appearance applier wrote an inline Style into the DynamicText's `Forms$Appearance`; Mendix's metamodel can't handle it", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`applyWidgetAppearance`) + `mdl/executor/validate_widgets.go` (`validateStaticWidget`)", "insight": "Reject an inline `style` on a dynamictext as MDL-WIDGET03 (check + executor); the workaround is to wrap it in a container and style the container. Issue #673", "refs": ["#673"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DYNAMICTEXT (Attribute: X)` (e.g. inside a LISTVIEW) is silently dropped — `describe`/BSON shows `Content: '{1}'` with no parameter binding; Studio Pro throws `System.NullReferenceException` (ClientTemplateFormPart.CollectControls) and MxBuild fails CE0720 \"Place holder index 1 is greater than 0\"", "cause": "`buildDynamicTextV3` read `Content`/`ContentParams` but never read the `Attribute:` property, so the binding was discarded and the template defaulted to the orphaned \"{1}\". `mxcli check` had no orphan detection", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildDynamicTextV3`) + `mdl/executor/validate_widgets.go` (`validateStaticWidget`/`validateDynamicTextPlaceholders`)", "insight": "Treat `Attribute: X` as a single auto-generated template param (route through `resolveTemplateAttributePathFull`, same as `ContentParams: [{1} = X]`; non-String attrs get `toString()`). Add **MDL-WIDGET04**: flag a dynamictext whose `Content` template references `{N}` with fewer than N bound params (counting ContentParams or a single Attribute). Issue #650", "refs": ["#650"], "ce": ["CE0720"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A widget `show_page` whose target page is created later in the same script passes `mxcli check --references` but the executor fails with \"page not found … defined later in this script\"", "cause": "The whole-script scriptContext used by reference validation tolerates forward refs (the page exists *somewhere*); the executor resolves page refs in statement order", "file": "`mdl/executor/validate.go` (`validateForwardPageRefs`)", "insight": "An ordered pass flags a widget page ref that is neither in the project nor created earlier in the script, with the same \"move the create statement earlier\" hint the executor gives — keeping check consistent with execution. Issue #674", "refs": ["#674"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Workflow constructs pass `mxcli check` but MxBuild rejects them: user task without a page (CE1834); a single-outcome user task whose one outcome has a nested activity flow (CE1876); a decision outcome that isn't a valid enum value identifier, e.g. `'Confirmed closed'`", "cause": "`CreateWorkflowStmt` had **no** case in `validateWithContext` and no `ValidateWorkflow` at all — workflows received zero semantic validation", "file": "`mdl/executor/validate_workflow.go` (`ValidateWorkflow`, wired from `cmd/mxcli/cmd_check.go`)", "insight": "Recursively walk `stmt.Activities`: **MDL-WF01** flag a `WorkflowUserTaskNode` with empty `Page`; **MDL-WF02** flag `len(Outcomes)==1 && len(Outcomes[0].Activities)>0`; **MDL-WF03** flag a decision/call-microflow outcome `Value` that isn't `True`/`False`/`Default` and fails the identifier regex (space/punctuation). Syntax-only (no project). The page-context-entity check (CE7412) and enum-membership form of WF03 are `--references` follow-ups. See `PROPOSAL_check_mxbuild_gap_heuristics.md`", "ce": ["CE1834", "CE1876", "CE7412"], "rules": ["MDL-WF01", "MDL-WF02", "MDL-WF03"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A DataGrid **control-bar** button passing `$currentObject` (e.g. `Action: show_page P (Order: $currentObject)`) passes `mxcli check` but MxBuild fails CE1571 \"No argument has been selected for parameter …\"", "cause": "A control bar sits above the grid and is not row-scoped, so `$currentObject` is unbound there; no check distinguished control-bar buttons from row-scoped (column) buttons", "file": "`mdl/executor/validate_page_button_context.go` (`ValidatePageButtonContext`, wired from `cmd/mxcli/cmd_check.go`)", "insight": "**MDL-BUTTON01**: walk the widget tree tracking an `underControlBar` flag (any `controlbar`-typed ancestor, mirroring `checkLayoutGridTree`'s `underGrid`); flag any button action (and its `ThenAction` chain) whose args contain the string `$currentObject`. Row-scoped column buttons are unaffected. Syntax-only", "ce": ["CE1571"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE` of a page/snippet emits `action: call_microflow X` / `call_nanoflow X` (button/widget actions) that fails to re-parse — breaks the DESCRIBE roundtrip", "cause": "Action emitters prefixed `call_`; the page-action grammar (`actionExprV3`) accepts `MICROFLOW`/`NANOFLOW` only", "file": "`mdl/executor/cmd_pages_describe_output.go` (`extractButtonAction`) + `cmd_pages_describe_pluggable.go` (`extractCustomWidgetPropertyAction`)", "insight": "Emit `microflow `/`nanoflow ` without the `call_` prefix. Issue #634", "refs": ["#634"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE` of a Java action (or `describe module … with all`) emits a body-less `create java action …;` that fails with `no viable alternative` and cascades into following statements — happens for add-on/Marketplace actions whose `.java` source isn't on disk", "cause": "Body emitted only when `readJavaActionUserCode` returns non-empty, but the grammar requires `AS DOLLAR_STRING` (body is mandatory)", "file": "`mdl/executor/cmd_javaactions.go` → `describeJavaAction`", "insight": "Always emit the `as $$ … $$;` block; when source can't be read, write a placeholder comment body. Issue #637", "refs": ["#637"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE` of a page emits `column Title (...)` / `column Description (...)` (datagrid columns named after a reserved keyword) that fails with `missing {IDENTIFIER, QUOTED_IDENTIFIER}` — breaks the DESCRIBE roundtrip", "cause": "#619 added `mdlIdent` (quote-if-reserved) for general widget names but missed datagrid column names", "file": "`mdl/executor/cmd_pages_describe_output.go` (`column %s` header, ~line 837)", "insight": "Wrap the column name: `fmt.Sprintf(\"column %s\", mdlIdent(colName))`. Issue #638", "refs": ["#619", "#638"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE` of a page/snippet emits widget-action microflow args as `Param = $value` that fails with `mismatched input '=' expecting ':'` — breaks the DESCRIBE roundtrip", "cause": "Arg emitters used `=`, but `microflowArgV3` accepts `IDENTIFIER COLON expr` (`Param: $value`) or `VARIABLE EQUALS expr` (`$Param = …`) — not `IDENTIFIER EQUALS`", "file": "`mdl/executor/cmd_pages_describe_output.go` → `extractMicroflowParameters` / `extractNanoflowParameters`", "insight": "Emit the canonical colon form: `paramName+\": \"+value`. Issue #640", "refs": ["#640"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "DESCRIBE drops `DataSource: selection X` for a DataView bound to a gallery/listview selection (master-detail pages)", "cause": "`extractDataViewDataSource` only handled `Forms$MicroflowSource` / `Forms$NanoflowSource` / `Forms$DataViewSource` / `Forms$DatabaseSource`; `Forms$ListenTargetSource` fell through to `return nil`", "file": "`mdl/executor/cmd_pages_describe_parse.go` (`extractDataViewDataSource`) + `mdl/executor/cmd_pages_describe_output.go` (DataView case) + `mdl/executor/cmd_pages_describe.go` (rawDataSource doc-comment)", "insight": "Add `case \"Forms$ListenTargetSource\":` returning `{Type: \"selection\", Reference: ds[\"ListenTarget\"]}`; add `case \"selection\":` in the DataView output switch emitting `DataSource: selection <ref>`"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "CE0463 on a pluggable widget whose TextTemplate property is *conditionally hidden* by an enum/boolean toggle (VideoPlayer `videoUrl`/`posterUrl` when `type=expression`; Timeline `title`/`description`/`timeIndication` when `customVisualization=true`) — engine clones the template's populated `ClientTemplate` for a property Studio Pro hides and nulls", "cause": "Engine has no per-property visibility metadata; the hide rules live in the widget's compiled `editorConfig.js` (`hidePropertyIn`/`hidePropertiesIn`), not `widget.xml`", "file": "`mdl/executor/widget_defs.go` `widgetVisibilityRules` table + `mdl/backend/mpr/widget_builder.go` `ApplyPropertyVisibility`", "insight": "Extract the widget's `.mpk` `*.editorConfig.js` (`unzip` + grep `hidePropertiesIn`), transcribe the rule into `widgetVisibilityRules[widgetID]` as `{propertyKey, hiddenWhen:{propertyKey, operator eq/ne/truthy/falsy, value}}`; the engine nulls hidden TextTemplate-typed props at build time. Bump `WidgetDefGeneratorVersion` so stale project `.def.json` auto-refresh. Issue #574", "refs": ["#574"], "ce": ["CE0463"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "CE0463 on a `datagrid` whose column uses `ColumnWidth: manual` + `Size: N` — Studio Pro resets the column `size` to `1`", "cause": "The MDL `ColumnWidth:` keyword isn't mapped to the schema `width` enum, so `width` stays at its `autoFill` default; `size` only applies when `width=manual`, so the value is inconsistent. Regression from the Stream B keyword-path consolidation (the deleted `datagrid_builder.go` did `colPropString(col.Properties, \"ColumnWidth\", \"autoFill\")`)", "file": "`mdl/executor/widget_defs.go` `itemPropertyAliases`", "insight": "Add the MDL→schema alias under `[datagrid][\"columns\"]`: `\"width\": {\"ColumnWidth\"}`. Bump `WidgetDefGeneratorVersion` so stale `.def.json` regenerate. General rule when a column/object-list property's MDL keyword differs from the `.mpk` schema key (not just case), add it to `itemPropertyAliases`; cross-check against the pre-B3 `datagrid_builder.go` `colProp*` calls for any other dropped mappings", "ce": ["CE0463"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`describe page` shows a widget's default placeholder text (e.g. the Dutch `'Tekst'` for a DynamicText) instead of the configured content; round-tripping describe→create then overwrites the real caption", "cause": "Text extraction was language-blind: `extractTextContent`/`extractTextCaption`/`extractTextFromTemplate` returned the **first** `Texts$Text` `Items[]` entry, and the page title hardcoded `GetTranslation(\"en_US\")`. In a multi-language project the first Items entry is often a non-default-language placeholder, so the wrong translation is shown. (The MDL surface is single-language regardless — this is display-only; note the real text isn't lost on disk, only mis-displayed)", "file": "`mdl/executor/describe_language.go` (new) + the three extractors in `cmd_pages_describe_output.go`/`cmd_pages_describe_parse.go` + title in `cmd_pages_describe.go`", "insight": "Select the translation by **project default language → en_US → first non-empty** via `selectTranslationText` / `pickTextTranslation`; get the default language from `ctx.Backend.GetProjectSettings().Language.DefaultLanguageCode`, cached on `executorCache` and pre-warmed in `preWarmCache` (race-free for parallel describe). No MDL bug-test possible (MDL can't author >1 translation) — covered by unit tests in `describe_language_test.go`. Issue #702", "refs": ["#702"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Mendix can't resolve the microflow named in `CREATE ODATA CLIENT (ConfigurationMicroflow: microflow X.Y)` / `ErrorHandlingMicroflow:` — error names the literal string `\"MICROFLOW X.Y\"` as the missing microflow", "cause": "Case-mismatched prefix strip: visitor emits uppercase `\"MICROFLOW \"` from `odataValueText`, but `extractMicroflowRef` only trimmed lowercase `\"microflow \"`, so the keyword survived into BSON", "file": "`mdl/executor/cmd_odata.go` → `extractMicroflowRef`", "insight": "Use a case-insensitive strip: `if strings.EqualFold(ref[:10], \"microflow \") { return ref[10:] }`. Whenever a value goes from a visitor that emits a keyword-prefixed form to an executor that strips it, the strip must match the case the visitor produces — grep visitor files for `\"MICROFLOW \" +`/`\"ENTITY \" +`/etc. when adding a new property. Issue #573", "refs": ["#573"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create [or modify] association ... to System.X` passes `mxcli check --references` and `mxcli diff` but fails at `mxcli exec` with `child entity not found: System.X`", "cause": "Two divergent entity resolvers: the write path's `findEntity` resolved the owning module via `h.FindModuleID(dm.ID)`, but the virtual System domain model is not a real unit, so the hierarchy walk yielded an empty module name and System entities never matched. The validation path (`buildEntityQualifiedNames`) keyed on `dm.ContainerID` and worked, hence the check-passes/exec-fails split", "file": "`mdl/executor/oql_type_inference.go` → `findEntity`", "insight": "Resolve the module from `dm.ContainerID` (the module ID `BuildSystemDomainModel` sets), not by walking up from the DM's own unit ID. When a symptom is \"passes check/diff but fails exec,\" suspect two resolvers and make the write-path one match the validation-path one; add an `exec`-level test, not just a `check` test. Issue #610", "refs": ["#610"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`ALTER STYLING ON PAGE/SNIPPET ... SET ...` fails with `unsupported container type: PAGE` (and `DESCRIBE STYLING` silently shows \"No widgets found\"); even past that, design-property writes never reached builder-created pages", "cause": "Two layered bugs: (1) the visitor emits uppercase `ContainerType` `\"PAGE\"`/`\"SNIPPET\"` but `execAlterStyling`/`execDescribeStyling` compared lowercase, so it fell through to the unsupported-container error; (2) ALTER STYLING used the reflection walker `walkPageWidgets` (legacy `ListPages`/`UpdatePage`), which can't locate widgets in MDL-builder pages and violates the mutator-pattern rule", "file": "`mdl/executor/cmd_styling.go` (`execAlterStyling`, `execDescribeStyling`) + `mdl/backend/mpr/page_mutator.go`", "insight": "Normalise container type with `strings.ToLower`. Route ALTER STYLING through `ctx.Backend.OpenPageForMutation(unitID)` like ALTER PAGE; check `mutator.FindWidget`. Add `SetDesignProperty`/`RemoveDesignProperty`/`ClearDesignProperties` to the `PageMutator` interface, writing the widget's `Appearance.DesignProperties` BSON array (`Forms$DesignPropertyValue` → `Toggle`/`Option`/`Custom` value), preserving an existing custom kind on option updates. When an ALTER uses a container-type discriminator, mirror the casing fix already done for ALTER PAGE (#402). Issue #631", "refs": ["#402", "#631"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`declare $x list of T = empty;` (or any list-typed `declare`) passes `mxcli check` but Studio Pro rejects with CE0053 (\"type not allowed\") + CE0038 (\"value required\")", "cause": "`declare` maps to a Create Variable activity, which Mendix forbids from producing a list — but the validator only flagged an empty list *used as a loop source* (MDL002), never the declaration itself", "file": "`mdl/executor/validate_microflow.go` → `walkBody` `*ast.DeclareStmt` case", "insight": "Emit `MDL040` (SeverityError) for any `stmt.Type.Kind == ast.TypeListOf`, regardless of initializer. Lists must come from a microflow parameter, a `retrieve`, or `$x = create list of T;`. Also fix the synced skills that present declare-list as valid (`write-microflows.md`, `cheatsheet-variables.md`, `check-syntax.md`, `patterns-*`). Issue #607", "refs": ["#607"], "ce": ["CE0038", "CE0053"], "rules": ["MDL002", "MDL040"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| `DESCRIBE` of a navigationlist item (`item List`), a fragment widget (`container List`), or a workflow `user task Value` / `jump to Value` emits the name BARE and the output fails `mxcli check` (`mismatched input … expecting IDENTIFIER`) — same root cause as #619 but four further emitter positions the widget-name slice didn't reach | These four output sites interpolated the name directly instead of via `mdlIdent`. Unlike the strict-`IDENTIFIER` cases, the receiving grammar rules already accept `(IDENTIFIER \\| QUOTED_IDENTIFIER)` (`widgetV3` ITEM, `widgetV3`, `workflowUserTaskStmt`, `workflowJumpToStmt`), so **no grammar change is needed** — wrapping the emitted name is sufficient | `mdl/executor/cmd_pages_describe_output.go` (`item %s`, ~line 633), `mdl/executor/cmd_fragments.go` (`outputASTWidgetMDL`, ~line 169), `mdl/executor/cmd_workflows.go` (`jump to %s` ~line 321 + `formatUserTask` ~line 418) | Wrap each name in `executor.mdlIdent(...)`. Regression tests in `mdl/executor/issue619_emitter_quoting_test.go`; roundtrip fixture `mdl-examples/bug-tests/619-quoted-reserved-emitter-names.mdl`. The *other* class of #619 gaps (page-domain `microflowArgV3` show_page/microflow arg param names, `dataSourceExprV3` SELECTION ref, `sortSpec` list-sort attr) also needed a grammar widen — now done: each rule widened to `(IDENTIFIER \\| QUOTED_IDENTIFIER)` (`make grammar`), the visitor unquotes (`buildMicroflowArgV3`, `buildDataSourceV3` SELECTION, both `sortSpec` consumers), and the emitters quote via `mdlIdent` (`extractMicroflowParameters`/`extractNanoflowParameters`/`extractPageParameters`, `DataSource: selection`, list `sort(...)`, plus the fragment `selection` builder). Tests: `mdl/visitor/visitor_page_quoted_test.go` (`TestQuotedReservedSelectionAndArgNames`), `mdl/visitor/visitor_microflow_sort_quoted_test.go`, `cmd_microflows_format_listop_test.go`; fixture `mdl-examples/bug-tests/619-quoted-reserved-grammar-positions.mdl`. NOTE a reserved attribute like `Date` in a list `sort(...)` was *already* emitted bare and broken before this — the fix quotes it. Issue #619 |", "refs": ["#619"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE PAGE` / `DESCRIBE STYLING` silently drops a **compound** (nested) design property — e.g. Atlas `Spacing` → margin-top/bottom — even though it was written to BSON correctly and shows in Studio Pro; only flat toggle/option props survive the read-back", "cause": "The describe-side parser `extractDesignProperties` had no `Forms$CompoundDesignPropertyValue` case (dropped it entirely), and the emitters had no `compound` branch — the write half of #668 was done but the read/roundtrip half wasn't", "file": "`mdl/executor/cmd_pages_describe_parse.go` (`extractDesignProperties` → `parseDesignProperty`) + `cmd_pages_describe_output.go` (`formatDesignPropertiesMDL` → `joinDesignPropertyEntries`) + `cmd_styling.go` (DESCRIBE STYLING emitter)", "insight": "Parse `Forms$CompoundDesignPropertyValue` by recursing over its `Properties` list (each child is again a `Forms$DesignPropertyValue`) into `rawDesignProp.Nested`; emit recursively as `'Key': ['sub': 'v', …]`. Share one formatter (`joinDesignPropertyEntries`) across both describe paths so toggle/option/compound render identically. Verify with a write→`describe`→re-`check` roundtrip (the describe output must re-parse). When a feature writes a construct, always confirm the **describe read-back** too — write-only completeness is the recurring half-shell trap. Issue #668", "refs": ["#668"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`check --references` on a view entity reports `could not parse select clause from OQL query` for a valid OQL query (any `select … from …`), AND MDL031 OQL type-mismatch checks never fire (misses real errors)", "cause": "`extractSelectClause` searched an **uppercased** query (`upperOql`) for the **lowercase** needle `\"select\"`, and compared `strings.ToUpper(oql[i:i+4])` against lowercase `\"from\"`/`\"union\"` — case mismatches that never match, so it returned `\"\"` for *every* query. That single `\"\"` both triggers the false-positive warning (`inferOQLTypes`) and short-circuits `ValidateOQLTypes` (early `return` on empty select clause) so no type checking runs", "file": "`mdl/executor/oql_type_inference.go` → `extractSelectClause`", "insight": "Compare case-consistently: `strings.Index(upperOql, \"SELECT\")` and slice keyword comparisons from `upperOql` (`word := upperOql[i:i+4]; word == \"FROM\"`). The static inferrer stays conservative (division / attribute refs → `TypeUnknown` → skipped), so re-enabling it doesn't over-fire on case/division aggregates. Tests: `TestExtractSelectClause`, `TestValidateOQLTypesNoFalsePositive` in `oql_type_inference_test.go`. Bug 9b", "rules": ["MDL031"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli widget docs` omits all but the first widget of a bundled multi-widget `.mpk` (e.g. Charts.mpk emits only `areachart.md`; ColumnChart/BarChart/PieChart/LineChart/BubbleChart missing)", "cause": "Same class as #679 in an unfixed code path: `RegenerateWidgetDocs` used `mpk.ParseMPK` (returns `WidgetFiles[0]` only), while the def-generation loop (`RefreshWidgetDefinitions`) already used `ParseMPKAll`. Charts.mpk bundles 10 widgetFiles", "file": "`mdl/executor/widget_defs.go` → `RegenerateWidgetDocs`", "insight": "Swap the per-`.mpk` `ParseMPK` for `ParseMPKAll` and loop over every returned `mpkDef` (mirror the def-gen loop). Test `TestRegenerateWidgetDocsMultiWidgetMPK` (uses the `testdata/expr-checker/widgets/Charts.mpk` fixture). Bug 9a", "refs": ["#679"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check --references` flags `attribute 'Type' is a reserved word (CE7247) [MDL021]` even though the attribute is **quoted** (`\"Type\": String`), and the skills say \"always quote to avoid reserved-word conflicts\" — tester assumed quoting should exempt it", "cause": "NOT a bug — the check is correct. Quoting only escapes **MDL parser** keywords (`unquoteString` strips the quotes and the *bare* name is validated). `Type`, `ID`, `GUID`, `CurrentUser`, and the audit names `CreatedDate`/`ChangedDate`/`Owner`/`ChangedBy` are reserved by the Mendix **platform**, so they fail regardless of quoting. The gap was documentation: several skills claimed quoting is \"always safe\" without the platform-name carve-out", "file": "`mdl/executor/cmd_enumerations.go` (`mendixReservedWords`, `mendixSystemAttributeNames`) — no code change needed; docs only", "insight": "Add the carve-out to the \"always quote\" guidance (`check-syntax.md`, `generate-domain-model.md`, `demo-data.md`, docs-site `lexical-structure.md`) and a CLAUDE.md note: quoting is *parser*-safe, not *platform*-safe. Rename `Type`→`ResourceType`; use `AutoCreatedDate`/… pseudo-types for audit fields. Adjacent Mendix rule documented alongside: the after-startup microflow must return `Boolean` (CE0142) — a void seed microflow fails the build", "ce": ["CE0142", "CE7247"], "rules": ["MDL021"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`linkbutton` (a documented CREATE PAGE / ALTER PAGE INSERT widget) fails `exec` with \"unsupported widget type: linkbutton — refresh widget definitions\", even though `actionbutton` works in the same spot", "cause": "`linkbutton` had a grammar token, a `pages.LinkButton` stub, and docs, but **no builder and no serializer** — `buildWidgetV3`'s switch only had `button`/`actionbutton`, so it fell to `default`. Trap: the `Forms$LinkButton` metamodel type requires an `address` (a legacy static hyperlink); the documented `linkbutton (caption, action)` is really a `Forms$ActionButton` with **RenderType \"Link\"** (the toolbox \"link button\"). The `RenderMode` field already existed on `pages.ActionButton` but the serializer hardcoded `RenderType: \"Button\"`", "file": "`mdl/executor/cmd_pages_builder_v3.go` (switch) + `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildButtonV3`) + `sdk/mpr/writer_widgets_display.go` (`serializeActionButton`) + `mdl/backend/modelsdk/widget_write.go` (ActionButton case) + `mdl/executor/cmd_pages_describe_parse.go`/`cmd_pages_describe_output.go`", "insight": "Route `linkbutton` → `buildButtonV3` with `RenderMode = Link`; serialize `RenderType` from `ab.RenderMode` (default \"Button\") on both engines; DESCRIBE reads `RenderType` back and emits the `linkbutton` keyword when it is \"Link\". Reuses the proven `Forms$ActionButton` BSON (only the enum differs), so no CE0463 risk. Tests: `mdl/executor/cmd_pages_linkbutton_test.go`, `sdk/mpr/writer_widgets_linkbutton_test.go`; example in `mdl-examples/doctype-tests/03-page-examples.mdl`", "ce": ["CE0463"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "In an interactive REPL running scripts back-to-back, a script that completes fine (e.g. `11-navigation-examples.mdl`, which contains `REFRESH CATALOG FULL`) leaves the session **silently disconnected** — the *next* `execute script` (or any statement) fails with `not connected to a project`. Only reproduces when a `.mxcli/catalog.db` already exists on disk (from a prior session/script) AND the project has since been written to; a from-scratch piped run never hits it", "cause": "`REFRESH CATALOG FULL` finds the on-disk cache stale (`Cache invalid: project file modified`) and calls `reconnect(ctx)`, which swaps `e.backend` for a fresh connection and syncs it back. When that reconnect fires **inside `execute script`**, the *outer* script statement's `ExecContext` was snapshotted before the reconnect, so it still holds the pre-reconnect (now-closed) backend. `executeInner`'s `syncBack` after the script then clobbers `e.backend` with that stale, closed connection → `IsConnected()` false → next statement reports not-connected. Any handler that runs nested statements via `ExecuteFn`/`ExecuteProgramFn` (EXECUTE SCRIPT, SQL connector-gen) is exposed", "file": "`mdl/executor/executor_dispatch.go` → `executeInner`/`syncBack`", "insight": "Before `syncBack`, snapshot `e.backend` prior to dispatch; if the handler didn't change its own `ectx.Backend` (`ectx.Backend == before`) but a nested call swapped `e.backend` (`e.backend != before`), adopt the live connection and its project-scoped caches (`Backend`, `MprPath`, `Cache`, `Catalog`) into `ectx` so `syncBack` preserves the reconnect instead of reverting it. **Diagnosis pattern**: \"works in a from-scratch/piped run, disconnects only in a long interactive session\" + the only state that nils the modelsdk reader is `Disconnect()` → suspect a stale outer `ExecContext` clobbering executor-global state changed by a *nested* statement; the trigger for the reconnect is a pre-existing `.mxcli/catalog.db` + a modified project. Regression: `TestReconnectInsideScript_KeepsConnection` (`reconnect_in_script_test.go`, integration-tagged)"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "An unrecognized property on a **built-in** (non-pluggable) widget — a typo like `Contnet`, or a genuinely unsupported key — passes `mxcli check`+`exec` with no error and is silently dropped on write (pluggable widgets already got MDL-WIDGET01)", "cause": "`validateStaticWidget` had no unknown-property check; core widgets have no single property registry — builders read keys imperatively, and `describe` even emits keys (`WidthUnit`) the native builder doesn't consume — so a hard reject would false-positive on valid MDL and break the describe→create roundtrip", "file": "`mdl/executor/validate_widgets.go` (`staticWidgetKnownProps`, `validateStaticWidgetUnknownProps`, wired in `validateWidgetTree` gated on `lookupWidgetDef==nil`)", "insight": "Add **MDL-WIDGET07** as a **WARNING** (never an error — the core-widget vocabulary can't be proven complete): flag any `Properties` key not in `staticWidgetKnownProps` (the union of grammar keyword props + builder-consumed keys + the full `describe`-emit vocabulary, harvested by grep), with a `nearestKey` \"did you mean\" hint. Runs only for non-pluggable widgets. Guard the allow-list against describe-vocabulary drift with `TestStaticWidgetKnownPropsCoverDescribe`, and sweep `mdl-examples/**` for zero false positives after any change. Bug-test `mdl-examples/bug-tests/widget-unknown-property.mdl`."}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Pluggable-widget datasource `sort by <attr> desc` (DataGrid2, Gallery; quoted or unquoted attr) round-trips as `asc` — `describe page` shows the direction flipped, runtime renders oldest-first, no error (silent wrong-order). Reproduces on the **default (modelsdk)** engine", "cause": "A Pages/`Forms$GridSortItem` stores its direction under the BSON key **`SortDirection`** (authoritative: the reflection-generated codec type `modelsdk/gen/pages` GridSortItem writes/reads `SortDirection`). The default engine wrote it correctly, but the DESCRIBE readers looked up the wrong key `SortOrder` (that key is only correct for `Microflows$SortItem` / `DocumentTemplates$GridSortItem`) → always fell back to `asc`. The legacy `sdk/mpr` writer *also* emitted the wrong `SortOrder` key, so under `--engine legacy` Studio Pro ignored it and reverted to ascending at runtime too", "file": "`mdl/executor/cmd_pages_describe_pluggable.go` (`gridSortDirection` helper + 3 call sites) & `cmd_pages_describe_parse.go` (1 call site); writer `sdk/mpr/writer_widgets.go` (`SerializeCustomWidgetDataSource`)", "insight": "Add `gridSortDirection(sortItem)` reading `SortDirection` with a `SortOrder` fallback (keeps pre-fix files readable); route all four grid-sort readers through it. Fix the legacy writer to emit `SortDirection`. When a sort/direction field seems misnamed, check the element's gen type in `modelsdk/gen/*/types.go` — different metamodel types genuinely use different keys (`SortDirection` for Forms/Pages grids, `SortOrder` for microflow/document-template sorts). Tests: `mdl/executor/cmd_pages_describe_sortdir_test.go`; bug-test `mdl-examples/bug-tests/bug8-datagrid-gallery-sort-desc.mdl`. Bug 8"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `use fragment` / `use building block` (or a content `slot`) nested **inside a container/layout/dataview** — not at the page-body top level — fails `exec` with `unsupported widget type: USE_FRAGMENT` (or `USE_BUILDING_BLOCK`). The same ref at the top level of the page body works. So a reusable card/panel can't be placed inside a layout column — the natural usage", "cause": "`expandFragments` (the sentinel-expansion pass) only ran on the **top-level** widget list (the two call sites in `execCreatePage`/`execCreateSnippet`); the layout/container builders build children via `buildWidgetV3` directly, which has no case for the `USE_FRAGMENT`/`USE_BUILDING_BLOCK`/`SLOT` sentinel types → falls to `default` \"unsupported widget type\"", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`expandFragments`)", "insight": "Make `expandFragments` **recurse into each widget's children** after expanding the top sentinel: `for _, e := range expanded { if len(e.Children) > 0 { e.Children, _ = pb.expandFragments(e.Children) }; result = append(result, e) }`. The tree is fully expanded to concrete widgets *before* `buildWidgetV3` runs, so no builder needs a sentinel case. Expansion is idempotent on concrete widgets, so the extra traversal of an already-expanded slot payload is harmless. Verified: nested cards inside a layoutgrid column exec + `mx check` = 0 on 11.12.1. Test `TestExpandFragments_NestedInsideContainer`; bug-test `mdl-examples/bug-tests/nested-fragment-expansion.mdl`. **Diagnosis pattern**: \"works at top level, `unsupported widget type` when nested\" = an AST pre-pass (expansion/normalization) that only walks the root list; make it recurse into `.Children`"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "An `autonumber` attribute with **no seed** passes `mxcli check` but fails the build with **CE7247 \"Value cannot be empty\"** (`alter entity … add attribute X: autonumber` or in a `create`). Docs showed seedless `autonumber`", "cause": "`ValidateEntity` had no autonumber-seed rule; the writer emits no `AttributeValue` when `!attr.HasDefault`, so Studio Pro has no start value. Sudoku findings #6", "file": "`mdl/executor/cmd_enumerations.go` (`ValidateEntity`)", "insight": "Add **MDL023** (error): `attr.Type.Kind == ast.TypeAutoNumber && !attr.HasDefault` → \"autonumber requires a seed (`default N`)\". Also fixed the skill docs (`mdl-entities.md`, `generate-domain-model.md`) to show `autonumber default 1`. Test `TestValidateEntityAutonumberNeedsSeed`; negative bug-test `f6-autonumber-seed.fail.mdl`", "refs": ["#6"], "ce": ["CE7247"], "rules": ["MDL023"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "An AutoX audit pseudo-type declared under a non-matching name — `StartedAt: autocreateddate` — silently becomes the fixed system member `CreatedDate` (declared name discarded), and binding that member in a widget then fails the build with **CE1613 \"attribute … no longer exists\"** (it's a system member, not a bindable attribute)", "cause": "The write path discards the identifier for AutoX types and `ValidateEntity` skipped them with no name check, so the rename + unbindable-member trap was silent. Sudoku findings #7", "file": "`mdl/executor/cmd_enumerations.go` (`ValidateEntity`, `autoMemberNames`)", "insight": "Add **MDL022** (warning): when an AutoX attr's name (case-insensitive) ≠ its canonical member (`owner`/`ChangedBy`/`CreatedDate`/`ChangedDate`), warn that the name is discarded and the member isn't widget-bindable — use a plain attribute you set yourself if a widget must show it. Test `TestValidateEntityAutoMemberRename`", "refs": ["#7"], "ce": ["CE1613"], "rules": ["MDL022"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A **DataGrid2 column bound to an associated attribute** (`column c (attribute: Order_Customer/Name)`) passes `mxcli check` but fails MxBuild **CE1613** \"The selected attribute 'Module.Entity.Order_Customer/Name' no longer exists.\" — an own-entity `attribute: Name` works. (Feature gap: no way to show an associated attribute in a column.)", "cause": "The grammar `attributePathV3` already accepts a bare `Assoc/Attr` path (module-qualified `M.Assoc/Attr` does not — bare only), but the reader flattened it (`resolveAttributePath` just prefixes the entity, leaving the `/` embedded → `Module.Entity.Assoc/Attr`) and both column serializers hardcoded `EntityRef: nil`. So the column stored a flat, unresolvable attribute path with no association step", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`resolveAssociationAttributePath`, extracted from `resolveTemplateAssociationPath`) + `mdl/executor/widget_engine.go` (full-page column `attribute` case) + `cmd_pages_builder_v3_widgets.go` (`buildColumnSpecFromAST`, ALTER) + `mdl/backend/mutation.go` (`ObjectListItemProperty`/`DataGridColumnSpec` gain `AttributeRefSteps`) + `mdl/backend/widgetobj/builder.go` (`setAttributeRefField`+`attributeEntityRefBSON`) + `datagrid_column.go` (`buildColumnAttributeProperty`) + `mdl/executor/cmd_pages_describe_pluggable.go` (`columnAttributeFromRef`)", "insight": "Reuse the DynamicText contentparam machinery: resolve the `/`-path to a final attribute QN + `[]pages.AttributeRefStep` (hop → destination entity via `associationEndpoints`), carry the steps on the column spec, and emit `AttributeRef.EntityRef = IndirectEntityRef` of `EntityRefStep{Association, DestinationEntity}` (raw-BSON `attributeEntityRefBSON`, mirroring the codec-form `attributeRefWithStepsToGen`). DESCRIBE reconstructs the **short** `Assoc/Attr` (short association names — `attributePathV3` rejects module-qualified associations). mxbuild-validated (`mxcli docker check --no-update-widgets` = 0 errors) + describe round-trip. Tests: `mdl/backend/widgetobj/widget_builder_attribute_ref_test.go`, `mdl/executor/cmd_pages_describe_column_assoc_test.go`; bug-test `mdl-examples/bug-tests/datagrid2-associated-attribute-column.mdl`. Bug 7", "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A DataGrid2 column's `DynamicCellClass: '<expr>'` (per-cell dynamic CSS class) parses, passes `check` + `mxbuild`, but is **silently dropped** — `describe` shows no `DynamicCellClass`, the `columnClass` slot is written as an **empty** expression, runtime cell is unstyled. Both engines", "cause": "The DataGrid `columns` object-list mapping (`itemPropertyAliases`) had aliases for `header←Caption`, `dynamicText←Content`, `width←ColumnWidth` but **none** for `columnClass`. `buildObjectListItem` looks up the schema key + its MDL aliases in the AST property bag (case-insensitive via `lookupProperty`), so `DynamicCellClass` never matched → the property fell through to the template's empty default. Cached `.mxcli/widgets/datagrid.def.json` files also had to regenerate to carry the new alias", "file": "`mdl/executor/widget_defs.go` (`itemPropertyAliases`, `columns.columnClass`) + `mdl/executor/widget_engine.go` (`WidgetDefGeneratorVersion` bump)", "insight": "Add `\"columnClass\": {\"DynamicCellClass\"}` to the datagrid `columns` aliases (schema property is `type: \"expression\"` → `operationForType` → written via the expression branch). **Bump `WidgetDefGeneratorVersion`** (5→6) so existing projects' cached def.json auto-regenerate via `RefreshStaleWidgetDefinitions` and pick up the alias — a code-only alias add is invisible until the stamped def is refreshed. DESCRIBE already reads `columnClass`→`DynamicCellClass` (`cmd_pages_describe_pluggable.go`). Test: `TestObjectListItemAliases`; bug-test `mdl-examples/bug-tests/bug10-dynamic-css-classes.mdl`. Bug 10a"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `dynamictext` contentparam over an association fails mxbuild (\"No value specified\") — **re-reported as still-broken after the modelsdk fix**. Investigation: the contentparam is actually **already correct on the default (modelsdk) engine** in every *valid* container (datagrid custom-content column, `listview + database`, `dataview` over a page parameter — all mx check 0 errors). The only failing repro is a `dataview (datasource: database …)`, which is an **invalid Mendix construct** — a data view shows one object, so Mendix offers only Context/Microflow/Nanoflow/Listen sources, never Database (that's for list widgets). mxcli wrongly accepted it: modelsdk errored \"not yet supported — rerun with legacy\", and legacy silently wrote a `Forms$DataViewSource` that mxbuild rejects with **CE7007** \"Selected value is not valid for entity\"", "cause": "mxcli had no check for a DataView database source (only the association case, MDL-WIDGET08). So the invalid construct routed users to the deprecated legacy engine, which produced a broken page. **Do not \"fix\" legacy** (`LEGACY_ENGINE_KNOWN_ISSUES.md`: legacy is being removed, not patched) and **do not implement dataview+database in modelsdk** (Mendix doesn't allow it) — reject it at check, sibling to MDL-WIDGET08", "file": "`mdl/executor/validate_widgets.go` (`validateStaticWidget`, MDL-WIDGET09) + `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildDataViewV3` exec refusal)", "insight": "Add **MDL-WIDGET09**: `dataview` + `database` source → error steering to a microflow/nanoflow source (or page parameter), or a list widget. Refuse it in `buildDataViewV3` too (both engines) so a bare `exec` can't create a broken page. When a construct fails only on legacy, first check whether it's valid on modelsdk in a *valid* container — the fix is usually a check-time rejection of the invalid form, not a legacy patch. Tests: `TestValidateStaticWidget_DataViewDatabaseSource`; bug-test `mdl-examples/bug-tests/dataview-database-source-rejected.fail.mdl` (negative). Bug 3 (re-report)", "ce": ["CE7007"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `dynamictext` contentparam (or DataGrid2 column) navigating an association still fails mxbuild **CE0402 \"No value specified\"** — the *actually unsolved* Bug 3 case. Reproduces only when the widget's entity context is a **specialization** of the entity that declares the association: a grid over `SpecialExpense extends Expense` with `contentparams: [{1} = Expense_Employee/Name]` (the `Expense_Employee` association is on the base `Expense`). An exact-endpoint context (grid over `Expense`) works. `describe` shows `[{1} = <unbound>]`; the binding is dropped. **Very common in real apps** (entities inherit from a base, associations on the base) — which is why the earlier fixes looked incomplete", "cause": "`resolveAssociationAttributePath` → `associationDestination` matched the context against the association's FROM/TO **by exact string equality**. A subclass context equalled neither endpoint, so it returned `ok=false` and the caller fell back to the flat, unresolvable `Assoc/Attr` path → no valid AttributeRef → CE0402. Affects both engines (shared builder) and both the contentparam and Bug 7 column-attribute paths", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`associationDestination`, new `entityIsOrDescendsFrom` + `entityGeneralizations`)", "insight": "Match the endpoint the context **is or descends from**: walk the generalization chain (`Entity.GeneralizationRef`, qualified parent name) so an association declared on a base entity resolves from a subclass context. Diagnose association-binding drops by checking whether the widget's entity context exactly equals the association endpoint — inheritance is the usual culprit. mxbuild-verified 0 errors across grid-over-base, listview, and grid-over-subclass. Tests: `TestResolveAssociationAttributePath_InheritedContext`; bug-test `mdl-examples/bug-tests/bug3-contentparam-inherited-association.mdl`. Bug 3 (inheritance)", "ce": ["CE0402"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE` of a generic pluggable widget (chart) omits its object-list child blocks — `series`/`line`/`scalecolor` items are dropped, so describe→exec loses the chart's data. (Pre-existing; SERIES always had it.) DataGrid2/Gallery were unaffected — they have specialized column output", "cause": "The generic `pluggablewidget` DESCRIBE branch only emitted scalar `ExplicitProperties`; nothing walked the widget's `WidgetObject` lists. (The DataGrid2 column reconstruction, `extractDataGrid2Columns`, was the only object-list reader and is hard-coded to `columns`.)", "file": "`mdl/executor/cmd_pages_describe_objectlist.go` (`extractObjectLists`, `buildObjectListNestedKeyMap`, `extractObjectListItem`, `objectListMDLKey`) + wired into `cmd_pages_describe_parse.go` (generic-pluggable branch) + `cmd_pages_describe_output.go` (emit child blocks)", "insight": "Generalize the column-reconstruction pattern: `buildObjectListNestedKeyMap` (like `buildColumnPropertyKeyMap` but for any list key) resolves the item's `TypePointer→sub-key` map from `Type.ObjectType.PropertyTypes[listKey].ValueType.ObjectType.PropertyTypes`; per item, read datasource / AttributeRef / Expression / TextTemplate / PrimitiveValue and map the schema key to PascalCase MDL (`staticXAttribute`→`StaticXAttribute`). Keyword via `deriveObjectListKeyword` (lowercased). Only runs for the generic branch (`!isKnownCustomWidgetType`), so DataGrid2/Gallery keep their specialized output — no double-emission. Verified: describe→exec→describe is byte-identical on bar/line/heatmap. Tests: `TestExtractObjectListItem_ChartSeries`, `TestObjectListMDLKey`."}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A HeatMap `scalecolor` entry's `ColorValue: '#rrggbb'` parses and passes `check` but the colour is **silently dropped on write** — describe shows only `ValuePercentage`, and the runtime scale has no colour. `valuePercentage` persists fine", "cause": "The schema property is spelled **`colour`** (British), and `scaleColors` had no `ColorValue` MDL alias, so the engine looked up `colour`, didn't find `ColorValue`, and wrote the template default (empty). Identical mechanism to Bug 10a (`columnClass`←`DynamicCellClass`) — a missing `itemPropertyAliases` entry", "file": "`mdl/executor/widget_defs.go` (`itemPropertyAliases`, `heatmap.scaleColors.colour`) + `mdl/executor/widget_engine.go` (`WidgetDefGeneratorVersion` bump)", "insight": "Add `\"colour\": {\"ColorValue\"}` to the HeatMap `scaleColors` aliases and **bump `WidgetDefGeneratorVersion`** so cached `.mxcli/widgets/heatmap.def.json` regenerate. DESCRIBE reconstructs it as `Colour:` (the PascalCase schema key — round-trips case-insensitively). Verified: `#rrggbb` now in BSON; describe→exec byte-stable. Test: `TestObjectListItemAliases_HeatMapColour`. Bug 10a class"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A **PieChart/HeatMap** (charts that bind data at the WIDGET level, no series object-list) fails MxBuild **after `mx update-widgets`** with **CE0642** \"Value attribute is required\" and (PieChart) **CE4899** \"Series name is required\" — even though `mxcli check` + `exec` are clean. The datasource persists; the value attribute + series name don't. Only surfaces once CE0463 version-drift is cleared by update-widgets", "cause": "These widgets expose several attribute-typed top-level properties (`seriesValueAttribute`, `seriesSortAttribute`) plus a required `seriesName` texttemplate. The engine's `resolveMapping` `\"Attribute\"` case read a single generic `w.GetAttribute()` — ambiguous across multiple attribute props and blind to the friendly MDL names — so `ValueAttribute:` never reached `seriesValueAttribute`; and `GenerateDefJSON` **skips all top-level texttemplate props**, so `seriesName` had no mapping. Item 1b", "file": "`mdl/executor/widget_defs.go` (`propertyAliases`, `GenerateDefJSON` attribute-alias + gated texttemplate case) + `mdl/executor/widget_engine.go` (`PropertyMapping.MdlAliases`, `namedPropValue`, `resolveMapping` `\"Attribute\"`/`\"TextTemplate\"`, version bump)", "insight": "Add `PropertyMapping.MdlAliases` (top-level analog of `ItemPropertyMapping.MdlAliases`) + a `propertyAliases` map (piechart/heatmap `seriesValueAttribute`←`ValueAttribute`, piechart `seriesName`←`SeriesName`). `resolveMapping` `\"Attribute\"` now reads via `namedPropValue` (property key + aliases) and resolves against the widget datasource entity (the DataSource mapping is ordered first), falling back to `w.GetAttribute()` for single-attribute widgets. Emit a top-level texttemplate mapping **only** when an alias is registered (keeps the broad skip). Bump `WidgetDefGeneratorVersion`; the example must supply the required `SeriesName:`. mxbuild-verified: whole chart file = 0 errors after update-widgets. **Diagnose \"required property\" CE0642/CE4899 by running `mx update-widgets` first (clears CE0463), then check which schema key is missing from the BSON.** Tests: `TestResolveMapping_NamedAttribute`, `TestGenerateDefJSON_PieChartNamedProperties`. Widget-level DESCRIBE of `seriesName`/datasource is a separate gap. Item 1b", "ce": ["CE0463", "CE0642", "CE4899"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A view entity whose attribute is named after a Mendix OQL keyword — most often a date-part word like `Quarter`/`Month`/`Year` — passes `mxcli check`/`exec` but fails **MxBuild CE0174** \"The 'Quarter' part is incomplete or incorrect. You could use here: … OPEN_QUOTE, or IDENTIFIER\". A `Region`/`Period` column is fine", "cause": "OQL reads the bare word as the keyword, not the attribute. **This row previously said mxcli cannot escape it and that `s.\"Quarter\"` is a parse error — both are wrong**, and the error text quoted in the row disproves the first (it lists `OPEN_QUOTE` among what is valid there)", "file": "`mdl/executor/oql_type_inference.go` (`ValidateOQLSyntax`, `oqlReservedWords`, **MDL032**, **MDL072**); `mdl/executor/validate_oql_reserved_names.go` (**MDL071**)", "insight": "**Quote it in a SOURCE position** — `select s.\"Quarter\" …`, `from Module.\"Year\" as s` — measured at 0 errors on 11.13.0, with the quotes passed through verbatim (`RawQuery` via `extractOriginalText`). The **alias** is the one position OQL will not take a quote in, for any name at all, so a view entity's own attribute — whose name IS its alias — has to be renamed; that is the only case that does. Read the two CE0174 texts side by side before concluding anything about quoting: the source position lists `ASTERISK, AT_SIGN, OPEN_QUOTE, or IDENTIFIER` and the alias position lists only `IDENTIFIER`. MDL071 warns at CREATE (where a rename is still cheap), MDL032 inside a view's OQL, MDL072 on the quoted-alias spelling.", "ce": ["CE0174"], "rules": ["MDL032", "MDL071", "MDL072"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A view entity with a **derived string column** — `cast(x as string)`, a string-returning `CASE`, or a string expression — passes `mxcli check`/`exec` but fails **MxBuild CE6770** \"View Entity is out of sync with the OQL Query\" whenever the declared attribute length is anything other than **200** (e.g. `string(30)`, `string(50)`, unlimited). The OQL itself runs fine, so it looks like a serialization gap but is a **platform rule**: Mendix normalizes a derived string column to the default length String(200); a plain pass-through column (`c.Name as Name`) instead inherits its source length", "cause": "Two parts. (1) The rule: only *derived* string columns are forced to 200 — a bare attribute ref infers `TypeUnknown` and is skipped, so any concretely-typed String the static inferrer sees is derived → 200. (2) The checker was **dead**: `inferTypeStatic`/`inferTypeFromExpression`/`inferCaseType` uppercased the expr (`upper := ToUpper(...)`) then compared against **lowercase** literals (`HasPrefix(upper, \"cast(\")`, `\"count(\"`, `\"case\"`, `== \"true\"` …), so every prefix check failed and only `DATEPART(` (uppercase literal) ever matched — CAST/CASE/COUNT/SUM/AVG/MIN/MAX/LENGTH inference all returned Unknown. Sibling of Bug 9b's `extractSelectClause` case bug", "file": "`mdl/executor/oql_type_inference.go` (`inferTypeStatic` CAST/CASE + case-fixed prefixes, `castTargetType`, `derivedStringLength=200`, `ValidateOQLTypes` string-length normalize, `typesStrictlyCompatible` length compare, `inferCaseType`, `inferTypeFromExpression`) — **MDL031**", "insight": "Infer `cast(expr AS string)` and string CASE as `String(200)`; in `ValidateOQLTypes` normalize any inferred `TypeString` length to 200 (derived); `typesStrictlyCompatible` compares String **length** (not just kind), so `string(30)` vs `String(200)` is flagged with `Fix: change to 'X: String(200)'`. **Fix the case-comparison bug** (lowercase→UPPERCASE literals) so the checker actually runs. **Guard against false positives**: `SUM(` over an un-inferable inner (a bare attribute ref → Unknown) returns **Unknown**, not a guessed Decimal — otherwise `sum(s.Units)` declared `integer` false-fires (caught on `34-chart-widget-examples.mdl`). mxbuild-confirmed on 11.6.6: `string(30)`→CE6770, `string(200)`→0 errors. Tests: `TestValidateOQLTypesDerivedString`, `TestValidateOQLTypesNoFalsePositive`; bug-test `mdl-examples/bug-tests/view-entity-derived-string-length.mdl`", "ce": ["CE6770"], "rules": ["MDL031"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A view entity with a **pass-through string column** — a bare source-attribute reference like `select c.Name as CategoryName` — declared with a length **different from the source attribute** (most often an unbounded `string` against a `string(100)` source) passes `mxcli check` but fails **MxBuild CE6770** \"View Entity out of sync\". This is the counterpart of the *derived*-column rule (which forces 200): a pass-through column inherits the source length **exactly**", "cause": "The references-mode validator (`validateViewEntityTypes`) compared with `typesCompatible`, whose String rule only guards **truncation** (`declared.Length >= inferred.Length`), so an unbounded `string` (Length 0) or a wider `string(200)` against a `string(100)` source slipped through. Only *derived* columns (via `ValidateOQLTypes`/`typesStrictlyCompatible`, syntax mode) were length-exact", "file": "`mdl/executor/oql_type_inference.go` (`passthroughStringLengthMismatch`, called in `validateViewEntityTypes` before the generic `typesCompatible`)", "insight": "For a pass-through column (`col.SourceAttr != \"\"`, set only for a bare `alias.attr` ref — aggregates use a throwaway col so it stays empty) require **exact** String length match; emit the source entity/attr + inherited length in the message. **References-mode only** (needs the domain model to resolve the source attribute's length), so the repro is not a `.fail.mdl` (the syntax-only `make check-mdl` harness can't see it). Test `TestPassthroughStringLengthMismatch`; example `mdl-examples/bug-tests/ledger-36-view-passthrough-length.mdl`; mxbuild-confirmed on 11.12.1 (`string`→CE6770, `string(100)`→clean). Ledger finding #36", "refs": ["#36"], "ce": ["CE6770"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| A microflow `declare $x Module.Entity [= $obj];` (object/entity-typed local variable) passes `mxcli check` but mxbuild rejects it with **CE0053** \"Selected type is not allowed\" (+ CE0038 \"Value required\", + CE7247 on a following `set`) — a silent trap. The declare-entity attribute qualifier is a red herring: the whole construct is invalid, bare or initialized | Mendix's Create Variable activity (what `declare` maps to) only holds **primitive** types; there is no object/list Create Variable form (same restriction as MDL040 for lists). Objects must come from a parameter, a `retrieve … limit 1`, a `create` object, or a loop iterator. The check was missing; the microflow parser records a bare `Module.X` declare type as the ambiguous `TypeEnumeration` (`EnumRef`, `ExplicitEnum=false`), an explicit `Enumeration(Module.X)` sets `ExplicitEnum=true` | `mdl/executor/validate_microflow.go` (`walkBody` `*ast.DeclareStmt` case, next to the MDL040 list check) | Add **MDL043**: flag `Type.Kind == TypeEntity \\|\\| (TypeEnumeration && EnumRef != nil && !ExplicitEnum)`; error points to parameter/retrieve/create/loop and notes \"if it's an enum, write `Enumeration(...)`\". Reliable connection-free (no backend) because bare object names resolve to a distinct AST shape from explicit enums. Also fix the skills that wrongly taught `declare $x Module.Entity;` / `declare $x as …` as valid (`write-microflows.md`, `cheatsheet-variables.md`, `cheatsheet-errors.md`, `check-syntax.md`, `patterns-crud.md`, `patterns-data-processing.md`, `business-events.md`, `resolve-forward-references.md`, `migrate-k2-nintex.md`, `README.md`). Test: `TestValidateMicroflow_DeclareObjectIsRejected`; bug-test `mdl-examples/bug-tests/declare-object-variable-rejected.fail.mdl`. mxbuild-confirmed (11.12.0) |", "ce": ["CE0038", "CE0053", "CE7247"], "rules": ["MDL040", "MDL043"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`alter entity M.E add attribute X: autonumber;` (no seed) or `... add attribute Created: AutoCreatedDate;` (renamed AutoX) passes `mxcli check` \"Check passed!\" but fails the build (CE7247) / silently discards the name — while the SAME attribute in `create entity` is correctly flagged (MDL023 / MDL022)", "cause": "The per-attribute checks (MDL021/022/023) only ran on `CreateEntityStmt`; the ALTER ENTITY ADD ATTRIBUTE path had no validation at all, so an attribute added later escaped every rule", "file": "`mdl/executor/cmd_enumerations.go` (`ValidateAlterEntity`, `validateEntityAttribute`) wired from `cmd/mxcli/cmd_check.go` + `cmd/mxcli/lsp_diagnostics.go`", "insight": "Extract the CREATE loop body into `validateEntityAttribute(attr, persistent, entityName)`; add `ValidateAlterEntity(stmt)` that runs it on `AlterEntityAddAttribute`. The entity kind isn't known from ALTER, so the persistent-only MDL020 is skipped; the kind-independent MDL021/022/023 all run. Bug-test `mdl-examples/bug-tests/f6-autonumber-seed-alter.fail.mdl`. Findings #6 (alter path)", "refs": ["#6"], "ce": ["CE7247"], "rules": ["MDL020", "MDL021", "MDL022", "MDL023"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create or modify entity M.E ( <subset> )` on an entity that already has more attributes **silently drops** every attribute not re-listed (36→2 attrs seen in practice), then widgets/microflows still bound to them fail the build with CE1613 — and the \"already exists\" error that leads users here recommends the destructive `create or modify` for a partial edit", "cause": "`create or modify` rebuilds the entity from the statement alone and REPLACEs the stored one, so any omitted attribute is deleted with no warning; the `NewAlreadyExistsMsg` hint pointed at `create or modify` without distinguishing \"replace whole\" from \"add one\"", "file": "`mdl/executor/cmd_entities.go` (`droppedEntityMembers`, the warn block before `UpdateEntity`, and the `execCreateEntity` already-exists message)", "insight": "Warn-only (non-blocking, the user asked to modify): before `UpdateEntity`, diff existing vs replacement members (`droppedEntityMembers` — named attrs case-insensitive + the four audit flags) and print what's dropped + point at `alter entity … add attribute` for incremental edits. Fix the already-exists message to recommend `alter entity` for a member change and reserve `create or modify` for a full replace. Bug-test `mdl-examples/bug-tests/f24-create-or-modify-dataloss.mdl`. Findings #24", "refs": ["#24"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Design properties are written free-form: a `ColorPicker`/`ToggleButtonGroup` value serializes as a plain option (wrong `$Type` for Studio Pro's Appearance tab), and a typo'd key/value (they're case-sensitive) passes `mxcli check`. Also `show design properties <widget>` reports \"No design properties found for widget type container\" for a valid widget", "cause": "Root bug: `resolveDesignPropsKey` upper-cased the MDL keyword but the lookup map is **lowercase-keyed**, so `container`→`DivContainer` never resolved — leaving `resolveDesignPropertyValueType` dead code and the theme registry unused on the write/validate paths", "file": "`mdl/executor/theme_reader.go` (`resolveDesignPropsKey` case fix) + `mdl/executor/cmd_pages_builder_v3.go` (`astDesignPropToValue` takes theme props) + `mdl/executor/validate_design_properties.go` (new, MDL-WIDGET11/12) wired from `cmd/mxcli/cmd_check.go` + `cmd/mxcli/lsp_diagnostics.go` (cached `themeRegistry`)", "insight": "Fix `resolveDesignPropsKey` to lower-case the lookup. On write, resolve each flat value's type from the registry **by matching the value against the property's declared options** (see the CE6084 correction below — the control type alone does NOT decide it). On check (`-p` only, when themesource defines properties), walk page/snippet/alter-page widget trees and warn: **MDL-WIDGET11** unknown key (case-sensitivity hint / valid-key list), **MDL-WIDGET12** invalid value (lists allowed values). Warnings, not errors — a newer theme may add keys/values (forward-compat, per `page-styling-support.md:402`). Skip compound (registry doesn't model sub-props) and widgets with no type-specific metadata (pluggable). Bug-test `mdl-examples/bug-tests/typed-design-properties.mdl`", "ce": ["CE6084"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Follow-up regression from the row above: after typed design properties merged, `mx check` fails **CE6084** \"Expected design property _Flex container_ / _Column gap_ / _Align items Y_ … to be of type **Toggle button group**, but found **Custom**\" on any page using a flat `ToggleButtonGroup` value (Atlas flex/spacing/typography, e.g. `'Column gap': 'Medium'`). Broke `TestMxCheck_DoctypeScripts` on `12-styling`, `15c-fragment-bindings`, `31-pluggable-datagrid-gallery-v010` (both engines) — green on unit tests, red only in `make test-integration`", "cause": "`resolveDesignPropertyValueType` mapped `ToggleButtonGroup`→`custom` by control type. But a ToggleButtonGroup selection picks one of a **fixed option set**, so Studio Pro stores it as an **Option** — a `Custom` value type mismatches the declaration. Only a ColorPicker's **off-list** value (a free-form hex) is genuinely Custom. The value type is decided by the **value**, not the control", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`resolveDesignPropertyValueType`, now takes the value and reuses `themeOptionAllowed`)", "insight": "Make it value-aware: value ∈ declared options → `option` (Dropdown, ToggleButtonGroup, predefined ColorPicker swatch alike); off-list **and** `ColorPicker` → `custom`; else `option`; no metadata → `option`. Verified: the three doctype examples pass `mx check` = 0 errors on both engines. Test `TestAstDesignPropToValue_Typed` extended with the `Column gap: Medium` + ColorPicker swatch/hex cases. **Diagnosis pattern**: a value-type/BSON-`$Type` mapping keyed on a *declared control type* is a trap — verify it against `mx check`, never assert it from the type name alone (this is exactly how the original bug slipped in). **Process lesson**: this shipped red because `make test-integration` (mx-check doctype roundtrips) was not run before merge — run it, not just unit tests, for any page/widget-serialization change", "ce": ["CE6084"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create or modify persistent entity` (even a byte-for-byte identical re-run) NULLs every column value on the next runtime DB sync — rows survive, values gone. Reports success (`Modified entity`), `mx check` = 0 errors; the loss only surfaces when something reads the data. Diagnose via the DB-sync count in `runtime.log` (\"Executing N database synchronization command(s)\") on an unchanged model", "cause": "`execCreateEntity` minted a FRESH attribute ID for EVERY attribute each run, even unchanged ones. Mendix's DB synchronizer keys off attribute identity — a new ID reads as \"attribute departed + new attribute added\", so it drops and re-adds the column. Only the entity's own ID was preserved; ALTER ENTITY (the safe path) mutates loaded attributes in place, keeping IDs", "file": "`mdl/executor/cmd_entities.go` (`execCreateEntity`)", "insight": "On CREATE OR MODIFY of an existing entity, build a name→ID map from `existingEntity.Attributes` and reuse the existing ID for retained attributes (only new attributes get a fresh ID); `attrNameToID` propagates the reused ID into validation rules + indexes. Also steer the \"already exists in project\" hint (`validate_duplicates.go`) toward `alter entity … add attribute` for entities. Test `TestCreateOrModifyEntity_PreservesAttributeIDs`; repro `mdl-examples/bug-tests/create-or-modify-preserves-attribute-ids.mdl`. Findings #13", "refs": ["#13"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A widget EXPRESSION property (`dynamicclasses`/`visibleif`/`editableif`) that walks an association passes `mxcli check --references` but fails `mx check` with CE0117 \"Error(s) in expression.\" Easy to trip: a data binding (`contentparams`) on the SAME widget can traverse the same association legitimately", "cause": "No check inspected expression-typed widget property values for association steps (MDL-WIDGET04/07/etc. check placeholders/keys, not expression contents). Mendix client-side expressions cannot follow associations — only data bindings can", "file": "`mdl/executor/validate_widgets.go` (`validateWidgetExpressionAssociations`, called from `validateStaticWidget`)", "insight": "New MDL-WIDGET13: for `DynamicClasses`/`VisibleIf`/`EditableIf`, regex `exprAssociationStepRe` (`/Ident.Ident/`) flags a module-qualified step between slashes; a plain attribute (`$obj/Slug`) or enum literal (`Mod.Enum.Val`, no leading slash) doesn't match. Fix for the user: denormalise the attribute onto the bound entity (calculated attribute) or use a data binding. Test `TestValidateWidgetExpressionAssociations`. Findings #4", "refs": ["#4"], "ce": ["CE0117"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Checker HINTS send the author the wrong way: MDL001 (nested loop) recommends `retrieve $Match from $List where … limit 1` (a parse error — can't filter a list variable); MDL044 flags `count()` in an expression with \"Did you mean 'round()'?\" (count is an aggregate, not a typo); MDL044's hint cites `mxcli syntax expressions` (no such topic)", "cause": "Message-only defects in the linter", "file": "`mdl/executor/validate_microflow.go` (MDL001 message ~216; `checkExprFunctions` ~283; `mendixAggregateFuncs`)", "insight": "MDL001 → recommend `$Match = FIND($List, <cond>)` (in-memory O(N); also fix CLAUDE.md idiom #2); MDL044 → for `count/sum/average/minimum/maximum` emit \"aggregate activity, not an expression function — assign to a variable first: `$n = count($List);`\" instead of a did-you-mean; point the generic hint at `mxcli syntax microflow`. Findings #7/#8/#14c", "refs": ["#14", "#2", "#7", "#8"], "rules": ["MDL001", "MDL044"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A microflow-CALL output variable reused across a fallback chain (`$S = call M.Inner(...); if … then $S = call M.Inner(...) end if;`) — the natural \"try A else try B\" — fails the build CE0111 \"Duplicate variable name\"", "cause": "Each `$Var = call microflow/create/retrieve …` is a *fresh* variable creation; reusing the name (even inside an if) is a duplicate. `check --references` runs the flowBuilder validation (`validateOutputVariable`) which catches it — bare `check` (no project) does not", "file": "`mdl/executor/cmd_microflows_builder_validate.go` (`validateOutputVariable`, `validateScopedStatements`)", "insight": "Already caught by the shared create-output-var check (same fix as the retrieve/create case); locked in by `TestValidateDuplicateMicroflowCallOutputVar` (same-scope + nested-in-if). Fix for the user: one variable per call, then a plain `set` picks the winner (documented in write-microflows.md). Finding #5 (2nd trigger)", "refs": ["#5"], "ce": ["CE0111"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`call javascript action` / `call java action` with a wrong-cased or misspelled PARAMETER name passes `check --references` (the action itself resolves) but writes a dangling reference that fails the build with CE1613 \"The selected … parameter … no longer exists\". E.g. `NanoflowCommons.OpenURL(url = …)` when the parameter is `Url`", "cause": "The reference checker resolved only the action NAME (`buildJava*ActionQualifiedNames` returns names, discarding params); the call's `CallArgument` names were never compared to the action's declared parameters", "file": "`mdl/executor/validate.go` (`flowRefCollector` → `codeActionCallRef`, `validateCodeActionParams`)", "insight": "Carry the call's `argNames` on the collector; after the name-exists check, `ReadJavaScriptActionByName`/`ReadJavaActionByName` → `.Parameters[].Name`, diff case-sensitively; casing-only mismatch → did-you-mean. Skip `System.*` (runtime-provided) and degrade to no-error when the backend reports no params. References-mode only (needs `-p`). Tests `TestValidateCodeActionParams`. RSS-reader follow-up finding", "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE PAGE` omits a textbox's `placeholder`/`onchange` even though they are written correctly (present in the .mxunit, live app works) — so a DESCRIBE round-trip is not a reliable way to confirm the write landed", "cause": "The describe read path (`parseRawWidget`) only read `LabelTemplate` + `AttributeRef` for a textbox; `PlaceholderTemplate` and `OnChangeAction` were never read back into `rawWidget`", "file": "`mdl/executor/cmd_pages_describe_parse.go` (`extractPlaceholderText`), `cmd_pages_describe.go` (`rawWidget` fields), `cmd_pages_describe_output.go` (`renderClientActionMDL`/`extractOnChangeAction` + TextBox emit)", "insight": "Add `Placeholder`/`OnChange` to `rawWidget`; read `PlaceholderTemplate` via `extractTextFromTemplate` (same as label) and `OnChangeAction` via a key-agnostic `renderClientActionMDL` (refactored out of `extractButtonAction`, since OnChangeAction is the same client-action type under a different key); emit `Placeholder:`/`OnChange:` in the TextBox case. Single describe path serves both engines (reads raw BSON via `GetRawUnit`). Test `TestParseRawWidget_TextBoxPlaceholderAndOnChange`. RSS-reader follow-up (verification note on #9)", "refs": ["#9"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE PAGE` of a `dynamictext` bound to a NON-STRING attribute (Integer/DateTime/…) emits `ContentParams: [{1} = toString($currentObject/Attr)]`; re-applying that output fails the build with CE1613 \"attribute '…toString($currentObject/Attr)' no longer exists\" — the rendered expression is treated as an attribute NAME. A string binding round-trips fine (bare attribute name)", "cause": "The write side converts a non-String attribute binding to `toString($currentObject/Attr)` (`resolveTemplateAttributePathFull`), stored as a ClientTemplateParameter `Expression`; the describe reader emitted the Expression verbatim instead of reversing the transform", "file": "`mdl/executor/cmd_pages_describe_output.go` (`unwrapToStringAttrParam` in `extractClientTemplateParameters`)", "insight": "When a ContentParam Expression is exactly `toString($currentObject/<path>)` or `toString($param/<attr>)` (the auto-generated forms), emit the bare `<path>` / `$param.attr`; the write side re-derives the toString on the next apply, so it round-trips. Any other expression (extra text, hand-written toString) is left untouched. Tests `TestUnwrapToStringAttrParam`, `TestParseRawWidget_DynamicTextNonStringAttribute`. RSS-reader follow-up finding", "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| A `contentparams`/`captionparams` value bound to a client EXPRESSION (`[{1} = formatDateTime($obj/LastImport, 'd MMM yyyy')]`) passes `mxcli check` but Studio Pro rejects the page with CE1613 \"attribute … no longer exists\" — the whole expression is stored as a bogus attribute name. A plain attribute path (`$obj/Attr`) or quoted literal (`'text'`) works | **mxcli** treats a template-parameter slot as a data binding: `buildClientTemplateParams` stores any unquoted value as an attribute path (`resolveTemplateAttributePathFull`), so an expression becomes a bogus attribute name. No check inspected the value for expression syntax. NOTE the original row said a template parameter *is* a data binding \"not an expression\" — that is a claim about MENDIX and it is **false**: Studio Pro's Edit Template Parameter dialog offers `Parameter type: Value | Expression`, with its own editor, variable list and wizard, and `Pages$ClientTemplateParameter` carries `Expression` beside `AttributeRef` and `SourceVariable`. The limit is mxcli's | `mdl/executor/validate_widgets.go` (`validateTemplateParamExpressions`, called from `validateStaticWidget`) | New **MDL-WIDGET14**: for each `ContentParams`/`CaptionParams` value, skip quoted string literals, then regex `templateParamExprRe` (`Ident(` function call or an arithmetic/comparison operator) flags an expression; an attribute path never matches. Fix for the user: set the parameter's type to Expression in Studio Pro, or bind an attribute path / quoted literal in MDL — do NOT send them to build a calculated attribute for something the platform already offers (the message used to, which is unnecessary modelling). Test `TestValidateTemplateParamExpressions`; bug-test `mdl-examples/bug-tests/contentparam-expression-rejected.fail.mdl`. Ledger finding #26 |", "refs": ["#26"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A microflow expression using `dateTime(2026, $Month, $Day)` (a variable/computed arg) passes `mxcli check` but fails the build with CE0117 — Mendix builds `dateTime()`/`dateTimeUTC()` from hardcoded numeric constants only", "cause": "No check inspected date-construction arguments; the function name resolves so the unknown-function check (MDL044) is silent", "file": "`mdl/executor/validate_microflow.go` (`checkDateTimeLiterals`/`exprHasNonLiteralDateTime`, MDL046)", "insight": "New **MDL046**: walk the expression for a `FunctionCallExpr` named `dateTime`/`dateTimeUTC` with any non-`LiteralExpr` argument. Fix for the user: step off a literal anchor date — `addDays(addMonths(dateTime(2026,1,1), $Month-1), $Day-1)` (addDays/addMonths take variables). Test `TestValidateMicroflow_DateTimeLiterals`; repro `mdl-examples/bug-tests/ledger-21-datetime-literals.fail.mdl`. Ledger finding #21", "refs": ["#21"], "ce": ["CE0117"], "rules": ["MDL044", "MDL046"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A retrieve constraint `where [Ledger.Transaction_Category = empty]` (an ASSOCIATION `= empty`) passes `mxcli check` but fails the build with CE0161 \"Error(s) in XPath constraint\" — XPath `= empty` tests attribute nullability, not association nullability", "cause": "No check inspected constraint strings for an association compared to `empty`; a bare attribute `= empty` IS valid, so a blanket ban would false-positive", "file": "`mdl/executor/validate_microflow.go` (`checkXPathAssociationEmpty`/`xpathAssocEmptyRe`, MDL047)", "insight": "New **MDL047**: on a `RetrieveStmt.Where` (via `expressionToXPath`), regex a **module-qualified** name (one dot) directly `= empty`, with a leading boundary class that excludes `/` (so `Assoc/Attr = empty` — a valid attribute-over-association test — is NOT flagged) and `.`/word (so a 3-part enum literal tail isn't grabbed). Fix for the user: `[not(Assoc/Module.Target)]`. **Also covers page/widget datasource where-clauses** (`validateDatasourceXPathAssociationEmpty` on `DataSourceV3.Where`, shared regex via `xpathAssociationEmptyMatches`) — the ledger project hit it there first. Tests `TestValidateMicroflow_XPathAssociationEmpty`, `TestValidateDatasourceXPathAssociationEmpty`; repros `ledger-25-xpath-assoc-empty.fail.mdl` (retrieve) + `ledger-25-page-datasource-assoc-empty.fail.mdl` (datagrid). Ledger finding #25", "refs": ["#25"], "ce": ["CE0161"], "rules": ["MDL047"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Two sibling `dynamictext` widgets in a container render as `€ 310Last import: 7/24/2026` — concatenated with no separator, regardless of each one's RenderMode", "cause": "A Mendix DynamicText is always an inline `<span>`; RenderMode does not make it block-level. Not a build error — a silent layout surprise, so a non-fatal advisory fits", "file": "`mdl/executor/validate_widgets.go` (`validateConsecutiveDynamicText`, called from `validateWidgetTreeIn`)", "insight": "New **MDL-WIDGET15** (info): scan each sibling list; emit once when a run of ≥2 adjacent **inline** dynamictexts occurs. **Only H1–H6 are block-level** (`headingRenderModeRe`) — `Text`/unset AND `Paragraph` both render as an inline `<span>` (verified on Mendix 11.12.1 + Atlas), so `inlineDynamicText` excludes only headings. A heading+subtitle pair is NOT flagged; a Paragraph+Paragraph pair IS (it fuses). Fix for the user: merge into one dynamictext, wrap each in a container, or use a **heading** RenderMode — NOT Paragraph. Info severity so it never fails the build. Test `TestValidateConsecutiveDynamicText`; repro `mdl-examples/bug-tests/ledger-27-consecutive-dynamictext.mdl`. **Lesson: verify Mendix render behavior empirically — `Paragraph` sounds block-level but isn't; don't infer `display` from a name.** Ledger findings #27/#29", "refs": ["#27", "#29"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create association … from/to <ViewEntity>` passes `mxcli check --references` and `mxcli exec` creates it, but `mx check` rejects it with **CE6771** \"It is not possible to create associations to/from View Entities.\" Both directions are invalid", "cause": "Associations to/from a view entity are statically impossible, but the reference checker only validated that the endpoint modules exist — it never inspected whether an endpoint was a view entity", "file": "`mdl/executor/validate.go` (CreateAssociationStmt case) + `mdl/executor/cmd_entities.go` (`isViewEntity`)", "insight": "Resolve both endpoints via `findEntity`; if either `isViewEntity` (Source `DomainModels$OqlViewEntitySource`, or OqlQuery/SourceDocumentRef set), reject with CE6771 and point at a non-persistent entity carrying a real reference. Same-script endpoints are skipped (validated on their own statement). **References-mode only** (needs the domain model). Tests `TestIsViewEntity`; example `mdl-examples/bug-tests/ledger-41-view-entity-association.mdl`. Verified on Mendix 11.12.1. Ledger finding #41", "refs": ["#41"], "ce": ["CE6771"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `create or modify entity` that omits (drops) an INDEXED attribute leaves the entity's index orphaned — its column references a GUID that no longer exists. `mxcli` prints only the attribute-drop warning; `mx check` then **CRASHES loading the project** with `System.AggregateException` \"The given key '<guid>' was not present in the dictionary\" (DESCRIBE shows a dangling `index ()`)", "cause": "Two parts. (1) The executor rebuilt the entity from the statement (no index clause → empty `entity.Indexes`), so the existing index wasn't reconciled against the surviving attributes. (2) The write path: `entityToGen` produced an **empty, untouched** Indexes PartList, which the codec treats as \"clean\" and passes the raw (orphaned) index through — an empty typed list does NOT override raw bytes for an existing element", "file": "`mdl/executor/cmd_entities.go` (`reconcileDroppedIndexes`, before `UpdateEntity`) + `mdl/backend/modelsdk/domainmodel_alter.go` (`UpdateEntity` empty-index dirtying)", "insight": "(1) When the statement lists no indexes, carry existing indexes forward, pruning columns for dropped attributes (attr IDs survive by name via #13) and dropping empty indexes — a **partial** drop (`index (A,B)` → drop B → `index (A)`) works via this non-empty list. (2) For the **all-removed** case, force the empty Indexes list dirty (`AddIndexes(NewIndex())` + `RemoveIndexes(0)` — `PartList.Remove` calls `markDirty`) so the codec re-emits it as empty, clearing the raw orphan. **Codec insight: an untouched empty PartList is `clean` → raw passthrough; only a *dirtied* list (even if empty) overrides raw for an existing element.** Tests `TestReconcileDroppedIndexes`; example `mdl-examples/bug-tests/ledger-39-drop-indexed-attribute.mdl`. **Verified end-to-end: `mx check` → 0 errors on Mendix 11.12.1** (previously crashed). Ledger finding #39", "refs": ["#13", "#39"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`retrieve … where [id = $Var]` (constraining on the object id) passes `mxcli check` but fails the build with **CE0161** \"Error(s) in XPath constraint\" — whether `$Var` is String or Long. Mendix XPath has no id operator reachable from a microflow expression", "cause": "No check inspected retrieve constraints for an id comparison; `id` is a reserved member so it resolves loosely", "file": "`mdl/executor/validate_microflow.go` (`checkXPathIdConstraint`/`xpathIdConstraintRe`, MDL048)", "insight": "New **MDL048**: on `RetrieveStmt.Where`, regex a bare `id` (word-boundaried, case-insensitive) before a comparison, **capturing the operand**, and flag only when the operand is a VALUE — a `$`-var whose kind is a primitive (in `varKinds`; objects aren't) or a string/number literal. **Comparing `id` to an OBJECT variable (`[id != $obj]`, the valid \"exclude self\" pattern) is NOT flagged** — verified valid on mx check; an over-broad `\\bid\\b\\s*[=…]` regex false-positived `16-xpath-examples.mdl`'s exclude-self example. Fix for the user: a marketplace GUID action (GetObjectByGuid), **or** expose the id as a String on a view entity (`cast(id as string) as ObjectId`) and constrain on that String column. Test `TestValidateMicroflow_XPathIdConstraint`; repro `mdl-examples/bug-tests/ledger-42-retrieve-by-id.fail.mdl`. **Lesson: `[id = $x]` splits on the operand type — value → CE0161, object → valid; a checker that ignores the operand mislabels the valid case.** Ledger finding #42", "refs": ["#42"], "ce": ["CE0161"], "rules": ["MDL048"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A call argument bound to an association-object path (`call M.Consume(B = $Edit/M.Edit_Budget)` — the object reached over an association) passes `mxcli check` but fails the build with **CE0117** \"Error(s) in expression.\" An attribute value over the same association (`$Edit/M.Edit_Budget/Name`) is fine", "cause": "Mendix does not treat an association path as a value — it must be materialized (`retrieve`) first. No check inspected call arguments for an association-object path", "file": "`mdl/executor/validate_microflow.go` (`checkAssociationObjectArgs`/`exprIsAssociationObjectPath`, MDL049; wired for CallMicroflowStmt + CallNanoflowStmt)", "insight": "New **MDL049**: an argument whose value is an `AttributePathExpr` whose FINAL segment is module-qualified (a `.` → an association, yielding an object) is flagged; a final bare segment (an attribute) is not. Fix for the user: `retrieve $x from $Edit/M.Edit_Budget;` then pass `$x`. Test `TestValidateMicroflow_AssociationObjectArg`; repro `mdl-examples/bug-tests/ledger-44-assoc-path-as-value.fail.mdl`. Ledger findings #43/#44", "refs": ["#43", "#44"], "ce": ["CE0117"], "rules": ["MDL049"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "~~MDL050 \"format function + association navigation\"~~ **REMOVED — it was a false positive.** MDL050 flagged `formatDateTime($obj/Mod.Assoc/Date, …)` and `formatDecimal(…) + $obj/Mod.Assoc/Attr` as CE0117. Re-verification against `mx check` on 11.12.1 (once the real #48 root cause — the dropped association target-entity step — was fixed) showed the premise was wrong on BOTH cases", "cause": "The earlier \"format-function + association\" correlation was an artifact of TWO unrelated bugs, neither of which is about format functions: (1) **association navigation dropped its target-entity step** → CE0117 for ANY `$obj/Assoc/Attr` in an expression (see the \"#48 root cause\" row above), which happened to include the formatDateTime example; (2) **`formatDecimal($x, 2)` fails CE0117 on a PLAIN local decimal** with no association at all — a `formatDecimal`-signature bug, not an association issue. With (1) fixed, `formatDateTime($obj/Assoc/Date, …)` builds clean → MDL050 rejected valid code", "file": "`mdl/executor/validate_microflow.go` (removed `checkFormatWithAssociation`/`exprHasRenderFunc`/`exprHasAssociationNav`/`renderFuncsIncompatibleWithAssoc`)", "insight": "Deleted the check, its call sites, its test (`TestValidateMicroflow_FormatWithAssociation`), and its bug-test. **Lesson (reinforced): even after \"reproducing the failing neighbours\", a rule can still be mis-premised if the neighbours share a DIFFERENT hidden bug — here the missing entity step. Verify a check is still valid after every related write-path fix; a correlation-based rule is fragile.** The remaining real issue — `formatDecimal($x, precision)` failing CE0117 regardless of associations — is a **separate open finding** (likely a wrong function signature/arity; investigate against `mx` and fix in the executor or flag via the function checker). Ledger finding #48 (root cause corrected; MDL050 retired)", "refs": ["#48"], "ce": ["CE0117"], "rules": ["MDL050"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "An action property on a pluggable widget — e.g. `onClick: microflow …` on a DataGrid2 — passes `mxcli check --references` AND `mx check`, builds and runs, but is **silently discarded**: `DESCRIBE PAGE` omits it and the model round-trips minus the action, with no error or warning", "cause": "The .def.json **generator** never emitted an `action` operation for `type=\"action\"` properties (across 42 generated defs, no action operation existed at all). The writer reads only `propertyMappings` from the def, so with no action mapping it had nothing to write. The `.mpk` correctly declares the action slot; the gap is purely in generation", "file": "`mdl/executor/widget_defs.go` (`GenerateDefJSON` `case \"action\"` + `actionSourceForKey`); `mdl/executor/widget_engine.go` (`resolveMapping` `case \"OnChange\"`; `WidgetDefGeneratorVersion` bump 12→13)", "insight": "Emit an `action` `PropertyMapping` for the action slots MDL can author: `onClick`→source `OnClick` (reads the widget's `Action` property, i.e. the `onClick:`/`Action:` alias) and `onChange`→source `OnChange`. The engine's **existing** `applyOperation \"action\"` → `builder.SetAction` path (nil-guarded) then serializes the `ClientAction` with its parameter mapping. Non-authorable action slots (DataGrid2 `onSelectionChange`/`onConfigurationChange`) return `\"\"` from `actionSourceForKey` → no mapping (no MDL surface yet). Bump the generator version so existing projects regenerate. Tests `TestGenerateDefJSON_ActionMapping`; example `mdl-examples/bug-tests/ledger-67-pluggable-widget-action.mdl`. **Verified end-to-end: `mx check` → 0 errors on 11.12.1**, and the DataGrid2 persists the onClick microflow action with its `Thing: $currentObject` mapping (the raw page unit carries `L67.OnClick` + `L67.OnClick.Thing`). Ledger finding #67 (write path)", "refs": ["#67"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "**General guard for the #67 class:** a real widget property that the generator doesn't map to a write path could be silently dropped (or, via an alias, slip through) with no diagnostic — the same failure mode as #67 for any unmapped property type (`expression`, `icon`, a future type, an action slot with no MDL surface)", "cause": "The `WidgetDefinition.KnownProperties` field + the `MDL-WIDGET06` \"recognized but not persisted\" path already existed, but the **generator never populated `KnownProperties`**, so the warning never fired: an unmapped property either false-errored as MDL-WIDGET01 \"no such property\" or (via an alias like `Action`) passed silently", "file": "`mdl/executor/widget_defs.go` (`GenerateDefJSON` — populate `KnownProperties`); `WidgetDefGeneratorVersion` bump 13→14", "insight": "Compute `KnownProperties` purely from the two artifacts mxcli already has — **every `.mpk`-declared property key with no mapping in the generated def** (subtract PropertyMappings + aliases + ChildSlots + ObjectLists + mode mappings from the full key set). No per-widget knowledge. The existing `knownUnmappedProperties`/MDL-WIDGET06 check then WARNS \"recognized but not persisted — the value will be dropped.\" **Three-way discrimination verified on DataGrid2 (11.12.1): a mapped property (`onClick`) is silent, a real-but-unmapped one (`rowClass`) warns MDL-WIDGET06, a truly-unknown one (`totallyBogusProp`) still errors MDL-WIDGET01.** Test `TestGenerateDefJSON_KnownPropertiesUnmapped`. **This is the tester's suggested general check — it catches the whole class without guessing which widgets support what; the `action` mapping remains the specific fix for onClick.** Ledger finding #67 (general guard)", "refs": ["#67"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "**DESCRIBE read gap (follow-up to #67):** after the write fix, `DESCRIBE PAGE` still omitted a DataGrid2's `onClick` action — a describe round-trip silently lost it", "cause": "The datagrid2 describe parse/output paths read datasource + columns + paging but never read the widget-level action; the param-aware `renderClientActionMDL` reader (used for button/onchange) was never called for a pluggable widget's action", "file": "`mdl/executor/cmd_pages_describe_pluggable.go` (`customWidgetPropertyActionMap`), `cmd_pages_describe.go` (`rawWidget.OnClick`), `cmd_pages_describe_parse.go` (datagrid2 branch), `cmd_pages_describe_output.go` (datagrid2 emit)", "insight": "New `customWidgetPropertyActionMap` returns the raw `Forms$*ClientAction` map for a CustomWidget property (NoAction → nil); the read is wired in **two** describe paths — the `datagrid2` branch AND the **generic `pluggablewidget '…'` branch** (`!isKnownCustomWidgetType`, where **CustomChart — the finding's actual widget — is described**). Each renders it via `renderClientActionMDL` (param-aware) into `rawWidget.OnClick`; the output emits `onClick: <action>` (the generic branch's guard also fires on `w.OnClick != \"\"` so an action-only widget still gets its `pluggablewidget` header). **Verified end-to-end on BOTH DataGrid2 and CustomChart: describe → re-exec → `mx check` 0 errors, round-trip preserves the full `onClick: microflow …(param: $currentObject)` including the parameter mapping** (CustomChart quotes the param name, `\"Data\":`, which re-parses fine). Test `TestCustomWidgetPropertyActionMap`. Ledger finding #67 (DESCRIBE read gap closed for datagrid2 + generic pluggable/CustomChart)", "refs": ["#67"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Two loops in the same microflow reusing the same iterator name (`loop $R in … end loop; loop $R in … end loop`) pass `mxcli check` but `mx check` fails with **CE0111** \"Duplicate variable name 'R'.\" at Loop", "cause": "A Mendix loop iterator is scoped to the **whole microflow**, not to its loop — so the second loop re-creates an existing variable. No check tracked loop iterator names across a microflow", "file": "`mdl/executor/validate_microflow.go` (`checkDuplicateLoopVariables`, MDL052)", "insight": "New **MDL052**: walk the microflow body (recursing through if/case/while/loop bodies) collecting `LoopStmt.LoopVariable` names; flag any name used by a second loop. Catches sequential AND nested reuse (a nested loop reusing an outer iterator is also CE0111). Distinct iterators, a single loop, and the same name across DIFFERENT microflows are fine. Fix for the user: give each loop a distinct iterator (`$R`, `$C`, `$M`). Test `TestValidateMicroflow_DuplicateLoopVariable`; repro `mdl-examples/bug-tests/ledger-64-duplicate-loop-variable.fail.mdl`. Ledger finding #64", "refs": ["#64"], "ce": ["CE0111"], "rules": ["MDL052"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `break` nested inside an `if`/`case` within a loop passes `mxcli check` but serializes a **dangling sequence-flow reference** — `mx check` then **CRASHES loading the project** with an unhandled `System.AggregateException` (\"key … not present in the dictionary\"), an unrecoverable failure. A break placed **directly** in the loop body serializes fine", "cause": "The flow builder (`addBreakEvent`) creates the Break event but the sequence flow connecting it from inside a conditional dangles — a write-path (flow-graph serialization) bug, still open. `break` directly in the loop body wires correctly", "file": "`mdl/executor/validate_microflow.go` (`loopBodyHasConditionalBreak`/`stmtsContainBreak`, MDL051) — **interim check**, pending the serialization fix", "insight": "New **MDL051**: on a `LoopStmt`, scan its body for a `break` inside an if/case/inheritance-split (not descending into nested loops — a nested loop traps its own break); a direct-child break is not flagged. Since the pattern currently produces a *crash*, a check-time rejection is a strict improvement. Fix for the user: a guard variable (`declare $Done Boolean = false; … if not($Done) then … set $Done = true`) — **verified clean on mx check**. Test `TestValidateMicroflow_ConditionalBreak`; repro `mdl-examples/bug-tests/ledger-52-break-in-conditional.fail.mdl`. Verified on 11.12.1: conditional break → KeyNotFound crash, direct break + guard-var workaround → 0 errors. **The real fix is the break-in-conditional flow serialization (write path) — MDL051 is the interim guard.** Ledger finding #52", "refs": ["#52"], "rules": ["MDL051"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A datagrid **column** with an explicit empty caption (`Caption: ''`) passes `mxcli check` but `mx check` rejects the page with **CE0463** \"The definition of this widget has changed\" on the Data grid 2 (error points at the widget version, not the caption). Omitting the caption, or a non-empty string, both build clean", "cause": "The pluggable widget engine's column-header fallback treated a **present-but-empty** header property as \"has header\" and skipped the attribute-name default — so `Caption: ''` emitted an empty header (which Studio Pro rejects) while an **absent** caption got the fallback. The keyword datagrid path already handled it (`if caption == \"\" { caption = col.Attribute }` in `datagrid_column.go`)", "file": "`mdl/executor/widget_engine.go` (`applyColumnHeaderFallback`)", "insight": "**Write-path fix.** Detect an empty header (a `texttemplate` op with empty `TextTemplate` and no `Parameters`) and treat it like an absent one: fill it **in place** with the bound attribute's leaf name (not appended — that would duplicate the `header` prop). A header WITH params (`Caption: '{1}'`) is left untouched. Result: `Caption: ''` now behaves like omitting it. **Round 2 (custom-content columns):** the first fix left a column with **no bound attribute** (an action/custom-content column) untouched — it had nothing to derive a header from, so an empty OR absent caption still tripped CE0463 (a custom-content column requires a non-empty header). Fixed by falling back to the **column's own name** when there's no attribute, and **gating the whole fallback on the item template having a `header` slot** (`mapping.ItemProperties`) so header-less object-list items (chart series, accordion groups) are never given a spurious header. `applyColumnHeaderFallback(spec, columnName, hasHeaderSlot)`. Test `TestApplyColumnHeaderFallback` (cases 1–8); examples `ledger-54-empty-column-caption.mdl` + custom-content verified via exec. **Verified: `mx check` → 0 errors on 11.12.1 for attribute columns AND custom-content columns (empty + absent caption)** (previously CE0463). Ledger finding #54 (custom-content columns)", "refs": ["#54"], "ce": ["CE0463"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`CREATE CONFIGURATION` (or any `ALTER SETTINGS`) reports success and `mx check` passes, but Studio Pro throws `System.InvalidOperationException: Sequence contains no matching element` at `MprProperty.cs:25` when the changed unit is opened (e.g. from the version-control status grid). Silently, the same write also resets **HttpPortNumber/ServerPortNumber to 0** on every *existing* configuration", "cause": "Three storage-name/enum defects in the settings write, all invisible to mxbuild (its deserializer tolerates unknown properties; Studio Pro resolves each stored property against the type's property list and throws when there is no match). (1) `createConfiguration` hardcoded `DatabaseType: \"HSQLDB\"` — the enum member is `Hsqldb`. (2) The gen `Configuration` binds the ports as `RuntimePortNumber`/`AdminPortNumber` (SDK names) while Studio Pro stores `HttpPortNumber`/`ServerPortNumber`, so the read returned 0 and the overlay wrote that 0 back. (3) Mendix renamed the runtime Java version property between 11.6 (`JavaVersion` = `\"Java21\"`) and 11.12 (`JavaMajorVersion` = `\"21\"`); mxcli wrote the 11.6 name unconditionally, leaving `JavaMajorVersion` stale and adding a property 11.12 does not define", "file": "`mdl/executor/cmd_settings.go` (`settingsDatabaseType`, `createConfiguration` defaults), `mdl/backend/modelsdk/settings_read.go` (`rawInt`, `javaVersionOf`), `mdl/settingsoverlay/settingsoverlay.go` (`JavaVersionKey`/`SetJavaVersion`, `newServerConfiguration`), `sdk/mpr/parser_settings.go` + `writer_settings.go`", "insight": "Canonicalise enum-valued settings against `generated/metamodel` and reject the rest (executor **and** `mxcli check`, via a `settingsKind*` entry so the drift guard covers it). Read version-renamed properties off the stored document and write them back to the key they came from — **never invent a key the document does not already have** (the same reasoning removed the hardcoded `Tracing: nil` from the no-sibling fallback: 11.12 spells it `OpenTelemetry`). **Diagnose without Studio Pro**: dump the `Settings$ProjectSettings` unit before and after the command and diff key-by-key against the project `mx create-project` produced — the write must be purely additive. A \"no matching element\" *property* lookup means a key Mendix does not know; an enum member mismatch is a different exception. Repro: `create configuration 'X'` on an 11.12 project. Issue #759", "refs": ["#759"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check … --references` reports **\"All references valid\" / \"Check passed!\"** for a script whose GRANT names a module role from a different module than the document; `exec` then fails with **CE0148** — after the preceding statements have already been applied, leaving the project half-modified", "cause": "The guard (`checkDocumentAccessRolesSameModule`) existed and was wired into all five exec paths, but **no validate path ever called it**. mxcli does not run a script in a single transaction, so a failure that only surfaces at exec time is exactly what a pre-flight check exists to prevent", "file": "`mdl/executor/validate_grant_roles.go` (`ValidateGrantRoles`, MDL-GRANT01), `mdl/executor/cmd_security_defaults.go` (`validateCrossModuleGrant`), wired in `cmd/mxcli/cmd_check.go`", "insight": "Reuse the existing exec-time guard from the **no-project** violations pass, covering all five document-access grants (microflow, nanoflow, page, OData service, published REST service). Take the document's module from the **statement's own qualified name**, not the resolved document — same comparison, and it works before the document exists (it is often created earlier in the same script). **Put it in the no-project pass, not under `--references`**: the check compares two names already in the script, so requiring `-p` withholds an answer mxcli can always give, and a plain `mxcli check` now catches it. **Generalisable — the shape to look for**: when exec rejects something a checker accepts, the bug is usually not a missing rule but a rule wired into only one of the two paths — grep the guard's callers before writing a new one. Repro `mdl-examples/bug-tests/836-check-cross-module-grant.fail.mdl`; verified end-to-end (check exits 1 naming the statement and CE0148, project left untouched; same-module variant still passes and gives 0 errors under mx check). Issue #836", "refs": ["#836"], "ce": ["CE0148"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE MICROFLOW` emits **`on error rollback`** on activities authored with no error-handling clause at all, growing the diff on every round-trip. No checker flags it — `\"Rollback\"` is structurally valid, so `mx check` and every mxcli validator pass", "cause": "`Rollback` is what `convertErrorHandlingType(nil)` stores for an activity with no clause **and** what the parser falls back to when `ErrorHandlingType` is absent from the BSON. The stored value therefore cannot distinguish an authored clause from the default, and read-back guessed \"authored\"", "file": "`mdl/executor/cmd_microflows_show_helpers.go` (`formatErrorHandlingSuffix`)", "insight": "Drop the `Rollback` case so it falls through to no suffix. **The asymmetry is the whole argument**: omitting it is lossless (re-executing stores `Rollback` again, so the model is unchanged), while emitting it is lossy in the direction that matters — it puts a clause in the user's script that they never wrote. `Continue` / `Custom` / `CustomWithoutRollback` are never defaults, so they still round-trip. **Generalisable — the shape to look for**: when a formatter renders an enum whose zero/fallback value is also a legal authored value, read-back cannot invert the write; render only the values that are *never* defaults. Ask \"what does the parser fall back to?\" before trusting a stored enum to mean the author chose it. Repro `mdl-examples/bug-tests/840-describe-invents-on-error-rollback.mdl`; verified end-to-end (describe → exec → describe byte-identical, `mx check` 11.13.0 0 errors). Issue #840", "refs": ["#840"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `create rest client` operation reports success, but `describe rest client` omits `Query:`, `Parameters:` and `Headers:` and always prints `Response: none`. BSON shows the query parameters/headers stored **correctly** while `ResponseHandling` is `Rest$NoResponseHandling` — the response mapping is gone. `mx check` passes (0 errors), so nothing anywhere complains", "cause": "**Two unrelated defects with one symptom.** *Write*: `model.RestClientOperation` documents `BodyType`/`ResponseType` as UPPER-case tokens and every consumer compares against that spelling, but the MDL executor stored the visitor's lower-case source text — so `op.ResponseType == \"MAPPING\"` never matched and the mapping fell through to the else-branch, which legitimately writes `NoResponseHandling`. *Read*: `restOperationFromGen` populated only Name/HttpMethod/Path/Timeout and type-asserted `*genRest.RestParameter` for **both** parameter lists, while the writer emits `Rest$OperationParameter` and `Rest$QueryParameter` — two different gen types, so both assertions failed silently", "file": "`mdl/executor/cmd_rest_clients.go` (`buildRestClientOperation` normalization + `checkInlineMappingBody`), `mdl/backend/modelsdk/integration_read.go` (`restOperationFromGen` + response/body/mapping-tree readers), `mdl/backend/modelsdk/consumed_rest_write.go` and `modelsdk/mpr/serialize_web_services.go` (`EqualFold`), `mdl/executor/validate_rest_mapping.go` (MDL-REST01)", "insight": "Normalize with `strings.ToUpper` at the one place the AST becomes the semantic model, and make the two serializer comparisons `EqualFold` so the landmine is not left armed for the next producer. **Generalisable — the shape to look for**: a case-sensitive comparison against a *documented-but-unenforced* string constant, where the non-matching branch is a **legitimate** outcome. Nothing errors, because \"no response handling\" is a real thing an operation can have — the else-branch launders a producer/consumer mismatch into a plausible-looking model. Grep every comparison against the constant, expect one per engine, and check whether the false branch is silent. **Second shape**: a reader that type-asserts one concrete type for two lists the writer builds from two *different* types; the assertion fails to `ok=false` and `continue`s, so a stub reader is indistinguishable from an empty document. The pre-existing round-trip test even created a query parameter — but only asserted the operation *count*, never that the parameter survived. **Third, separate half (#843's headline)**: `Response: mapping Mod.IMM_X` names an import mapping **document**, which Mendix cannot reference — `Rest$RestOperationResponseHandling` has exactly two implementations, inline and none. The clause parsed, contributed no entries, and was written as \"none\". Now refused at exec *and* `mxcli check` (MDL-REST01, no project needed). **Note** `Rest$QueryParameter` stores no DataType at all, so the MDL type is decorative and `describe` re-emits every query parameter as `String` — do not \"fix\" that by inventing the authored type back (see the #840 row). Repros `mdl-examples/bug-tests/843-rest-response-mapping.mdl` + `843-rest-response-mapping-no-body.fail.mdl`; verified end-to-end (`mx check` 11.13.0 0 errors, BSON now `Rest$ImplicitMappingResponseHandling` with a full `ImportMappings$ObjectMappingElement` tree, describe → exec → describe byte-identical). Issue #843", "refs": ["#840", "#843"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`loop { if <cond> then break; }` where the `if` is the **last** statement builds a Decision with only its `true` outgoing flow (→ break). `mxcli check` passes but `mx check` reports **CE0079** \"the 'false' condition value should be configured in properties for an outgoing sequence flow\", and the microflow won't deploy. (Distinct from the earlier #791 crash — that was a dropped Break/Continue *event*; this is a missing *flow*.) `continue` and break-not-last behaved likewise", "cause": "The loop-body flow builder (`addLoopStatement`) is a simplified copy of `buildFlowGraph` that connected body statements with a plain `newHorizontalFlow` and **never honoured the deferred `nextFlowCase`** a merge-less split leaves for its FALSE branch. So the split's false case was dropped: mid-body it wired the next statement with no case; as the last statement it wired nothing at all", "file": "`mdl/executor/cmd_microflows_builder_control.go` (`addLoopStatement` body loop)", "insight": "Mirror `buildFlowGraph`: track `pendingCase` between body statements and apply it to the connecting flow; then, for a leftover `pendingCase` at the end of the loop body (a decision whose non-terminal branch falls off the end), synthesize a **ContinueEvent** and wire the split's false flow to it — the valid Mendix representation of \"didn't break/return → next iteration\". **Trap**: the check-time acceptance test (`TestValidateMicroflow_ConditionalBreakAccepted`) only asserted MDL051 doesn't fire — it never ran `mx check` on the *output*, so the CE0079 microflow shipped green. Assert the produced BSON, not just that check accepts the source. Repro `mdl-examples/bug-tests/ledger-52-break-in-conditional.mdl`; verified raw `mx check` 0 errors (was 1× CE0079) and the split now carries both a true→Break and a false→Continue flow. Ledger #52", "refs": ["#52", "#791"], "ce": ["CE0079"], "rules": ["MDL051"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A workflow containing a standalone `annotation '...'` writes a project Mendix **cannot load**: `System.InvalidOperationException: Type ...Workflows.Model.Annotation does not contain a constructor with a parameter of type ...Workflows.Model.Flow`. Not a build error — Studio Pro will not open the project and `mx check` dies before validating anything. `mxcli check` passed and `exec` succeeded", "cause": "mxcli writes the annotation into the workflow's **activity flow**. Mendix loads that list by constructing every child with a `Flow` parent, and no annotation type takes one: `Workflows$Annotation` carries only `Description` (it attaches to a Flow) and `Workflows$FloatingAnnotation` (the canvas sticky note, which has exactly the `RelativeMiddlePoint`/`Size` fields mxcli was already writing) is not a flow element either. **Placement is the defect, not the storage name** — swapping the `$Type` to FloatingAnnotation reproduces the identical error with the new type name", "file": "`mdl/executor/validate_workflow.go` (new `MDL-WF04`), `mdl/executor/cmd_workflows_write.go` (`execCreateWorkflow` guard + `hasStandaloneWorkflowAnnotation`), skill `.claude/skills/mendix/write-workflows.md` (which had documented the construct)", "insight": "**Refuse rather than emit an unopenable unit** — at check time *and* at exec time, because a user who skips `check` otherwise still loses the whole project. The correct container is not determinable from the gen model (no struct owns a `FloatingAnnotation` list) and CLAUDE.md's rule applies: when the BSON shape is unknown, get a Studio Pro reference rather than guess. **Generalisable**: verify a storage-name hypothesis by *swapping only the name* — if the error is byte-identical with the new type, the bug is where the element is attached, not what it is called. Repro `mdl-examples/bug-tests/it-15-workflow-annotation-refused.fail.mdl`; A/B: pre-fix binary writes it and `mx check` cannot load the project, fixed binary refuses and the project checks 0 errors. issuetracker #15 **Follow-up (CI):** three `-tags integration` round-trip tests asserted this construct *works* and went red on the guard. They exercised mxcli's own write → read → describe → re-execute loop, which a structurally invalid document survives — the loop never loaded the project in Mendix, so it proved nothing about validity. Re-settled by stubbing the guard and running real `mx check`: the project fails at \"Loading the mpr file\". The tests were pinning the defect, and now assert the refusal (`TestCreateWorkflow_StandaloneAnnotationRefused`). **Second instance in one PR** of a green test codifying a bug (see the `jump to` row) — when a pre-existing test contradicts a new guard, re-derive the ground truth from the layer the symptom lives in before believing either.", "refs": ["#15"], "rules": ["MDL-WF04"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A page datasource navigating an association writes `DestinationEntity: \"\"`, and the project becomes **unloadable**: `An error occurred when trying to set the 'DestinationEntity' property of a Entity ref step ... ---> System.ArgumentNullException` at `EntityRefStep.set_DestinationEntityId`. Studio Pro will not open it and `mx check` dies before validating anything. `mxcli check` and `exec` both succeed", "cause": "`resolveAssociationDestination` resolves both ends via `entityQNByID`, which only sees the **project's own** domain models — an association ending in a **System** entity (`from W.Issue to System.Workflow`) yields `\"\"` for that side. The context then matched neither end, and the fallback `return childEntity` returned the empty one. An empty by-name reference is not \"absent\", it is a reference Mendix resolves to null", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`resolveAssociationDestination` fallbacks + a hard guard in the `association` case of `buildDataSourceV3`)", "insight": "Prefer whichever end actually resolved and is not the context; then **refuse** an unresolved destination rather than write it, pointing at the explicit `Assoc/Module.Entity` form (verified to build 0 errors — it is the construct the reporter had abandoned). **Narrower than reported**: the finding blamed *nesting*, but a one-step probe with the same association reproduces it identically — nesting was incidental. Always re-derive the trigger with the smallest case before fixing the reported shape. **Generalisable**: a resolver that returns `\"\"` on failure will silently produce a null by-name reference; make the write path refuse empty rather than trusting the resolver. Repro `mdl-examples/bug-tests/it-14-assoc-destination-entity.mdl`; A/B: pre-fix binary leaves the project unopenable, fixed binary refuses and the project checks 0 errors. issuetracker #14", "refs": ["#14"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`describe workflow` renders a plain `jump to Review;` as `jump to Review comment 'Review';` — a comment clause the author never wrote, which then round-trips back into the model as a real caption", "cause": "`buildJumpTo` defaults the activity's `Caption` to the **target name**, and the DESCRIBE emitter echoed `Caption` unconditionally (falling back to the activity `Name` when empty). Both are derived values carrying no authored information", "file": "`mdl/executor/cmd_workflows.go` (`JumpToActivity` case in `formatWorkflowActivities`)", "insight": "Emit `comment '...'` only when the caption is genuinely authored — non-empty **and** different from both the target name and the activity name. **Watch for tests that codify the bug**: `TestFormatJumpTo_CaptionCommentFormat` had a \"name fallback when caption empty\" case asserting the phantom comment, and two issue-619 quoting tests were incidentally coupled to it; a green suite was pinning the defect in place. Tests `mdl/executor/cmd_workflows_describe_test.go`, `mdl/executor/issue619_emitter_quoting_test.go`. issuetracker #16", "refs": ["#16"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A workflow `decision '<expr>'` referencing the context passes `mxcli check`, executes, then the build fails `[error] [CE0117] \"Error(s) in expression.\" at Decision 'Decision'`. `$WorkflowContext/X` (exact casing) works; `$workflowContext/X` — the spelling this repo's own skill documented — and `$Ctx/X` from the author's `parameter $Ctx:` header both fail", "cause": "mxcli always stores the context parameter as `WorkflowContext` and Mendix expressions are **case-sensitive**. `normalizeWorkflowContextExpr` already existed but was wired into `autoBindCallMicroflow` only, so `with (...)` mappings were normalized while a decision's condition was written through verbatim. Separately, the header's declared variable name was parsed into `ast.CreateWorkflowStmt.ParameterVar` and then **never consumed** — a field populated but read nowhere, so `$Ctx` resolved to nothing", "file": "`mdl/executor/cmd_workflows_write.go` (`contextExprNormalizer` + threading it through `autoBindActivitiesInFlow`), `mdl/executor/cmd_alter_workflow.go`, skill `.claude/skills/mendix/write-workflows.md` (whose examples were the failing spelling)", "insight": "One normalizer applied to **every** expression an author can write in a workflow — decision conditions, user task due dates and XPath targeting, wait-for-timer delays, call-microflow mappings — rather than a second point fix. The declared name is aliased onto the stored one (whole-word, so `$CtxItem` is not mangled) instead of documenting it as meaningless. **Generalisable**: grep for an AST field that is written by the visitor and read nowhere — that is a silently-discarded user intent, not dead code. Repro `mdl-examples/bug-tests/it-17-workflow-context-expression.mdl`; A/B: pre-fix binary writes it and `mx check` reports CE0117, fixed binary checks 0 errors. issuetracker #17", "refs": ["#17"], "ce": ["CE0117"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A page widget bound through an association — `Attribute: Issue_Assignee/Name` — passes `mxcli check`, executes, then fails `[error] [CE1613] \"The selected attribute 'IT.Issue.Issue_Assignee/Name' no longer exists.\"`. The error text is the raw MDL path glued onto the context entity. Same-module paths (`Issue_Project/Code`) work", "cause": "A domain model keeps associations in **two** lists. `Associations` holds intra-module ones (both ends BY_ID); an association targeting another module is a `DomainModels$CrossAssociation` in **`CrossAssociations`**, where only the local end is BY_ID and the remote end is the BY_NAME `ChildRef`. `associationEndpoints` searched only the first list, so every cross-module hop returned ok=false and the writer fell back to a flat attribute path instead of an `AttributeRef` with an `IndirectEntityRef` of steps", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`associationEndpoints`, `resolveAssociationDestination`), `mdl/executor/widget_engine.go` + `cmd_pages_builder_input.go` (`resolveAssociationPathIn`, `storedSystemMemberName`)", "insight": "**Scope correction — the reported trigger was wrong.** The finding blamed the *System module*; a plain second app module reproduces it identically, so the trigger is cross-module. Fixing \"System\" alone would have left the commoner case broken — always re-derive the trigger with a neutral variant before fixing the reported one. Two sibling defects in the same finding: (a) a ComboBox's `Association:` was qualified with the module of its **own option list**, because the `DataSource:` mapping runs first and moves `pageBuilder.entityContext` — an association belongs to the *containing* entity, so it now resolves against the context saved at `Build` entry (`outerEntityContext`); (b) `CreatedDate: AutoCreatedDate` is the spelling mxcli **requires** when declaring an audit member, but the member is stored as `createdDate`, so binding the name you just declared failed — `storedSystemMemberName` now maps declared→stored. **Generalisable**: when a resolver reads one collection off a model object, check whether the model splits that concept across two (intra- vs cross-module, own vs inherited). Repro `mdl-examples/bug-tests/it-19-cross-module-attribute-path.mdl`; A/B on Mendix 11.12.1: pre-fix binary → 4 × CE1613, fixed binary → 0 errors. issuetracker #19", "refs": ["#19"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "GRANT rejects members Mendix does recognise — `entity M.Label has no member(s) Issue_Label` for the non-owning end of an `OWNER Both` reference set, and `has no member(s) createdDate, changedDate` for audit members — and a `read * / write *` rule that looks complete still fails `[error] [CE0066] \"Entity access is out of date.\"`, so partial coverage is worse than none", "cause": "Two unrelated gaps in \"what counts as a member\". (a) `OWNER Both` makes an association a member of **both** ends, but the writer emitted the MemberAccess only for the FROM entity (`ParentID`) **and** `ReconcileMemberAccesses` independently applied the same FROM-only rule — so it stripped the entry back out on the next write even if the executor had added it. Two places had to agree. (b) Audit members are entity **flags** (`HasCreatedDate`/`HasChangedDate`), not entries in `entity.Attributes`, so the member walk never yielded them", "file": "`mdl/executor/cmd_security_write.go` (`execGrantEntityAccess`, `storedAuditMembers`, `otherModuleBothOwnerAssociations`), `mdl/backend/modelsdk/domainmodel_security_write.go` (`ReconcileMemberAccesses`)", "insight": "**Ask mxbuild what it wants instead of inferring symmetry.** Emitting a MemberAccess for `createdDate` seemed like the obvious fix for (b) — mxbuild **rejects** it with CE0066, and an entity storing audit members checks clean with no entry. So audit members are accepted as names but per-member rights on them are **refused with the reason** rather than silently dropped; only the `OWNER Both` association actually needed a new entry. **When a symptom has two spellings (a rejection and a build error), check whether they are one bug or two** — here they were two, and fixing them the same way would have introduced a new CE0066. **Generalisable**: a writer and a reconciler that both compute \"the expected member set\" are one invariant in two places; changing one alone is silently undone. Repro `mdl-examples/bug-tests/it-20-grant-member-coverage.mdl` (+ `it-20-grant-audit-member-rights.fail.mdl`); A/B on Mendix 11.12.1, same module same project: pre-fix binary → CE0066 + the bogus rejection, fixed binary → 0 errors. Controlled: the identical model with `OWNER Default` checks clean pre-fix, so the owner mode is the trigger. issuetracker #20", "refs": ["#20"], "ce": ["CE0066"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A loop's variable used after `end loop;` passes `mxcli check`, then `mx check` fails `[error] [CE0108] \"Variable 'item' is defined but not in scope at this location.\"` at the referencing activity. Applies to the **iterator** and to anything the body introduces (a `retrieve`, a `$X = create …`, a call output)", "cause": "Nothing tracked loop-variable *visibility*. MDL052 already covered the sibling rule — names are unique across the whole microflow (CE0111) — and the wording of that rule (\"scoped to the WHOLE microflow\") reads as if the variable is readable flow-wide. Uniqueness and visibility are different: the name is reserved everywhere, readable only inside the loop body", "file": "`mdl/executor/validate_microflow_loop_scope.go` (new `MDL053`, wired from `microflowValidator.validate`), skill `.claude/skills/mendix/write-microflows.md`", "insight": "Map each loop-scoped name to the loop whose **own** body introduces it (nested loops keep their own names), then walk the flow with the set of enclosing loops and flag any reference from outside the owner. **A name claimed by two loops is dropped, not reported** — that is the MDL052/CE0111 case, and without the guard the MDL052 negative example started failing for the wrong reason: the first loop's own use of `$R` was blamed on the second loop's claim. **Generalisable**: a rule keyed by variable *name* needs an ambiguity escape hatch whenever another rule exists precisely because names can collide. Both flavours verified against mxbuild 11.12.1 (2 × CE0108 in one probe). Repro `mdl-examples/bug-tests/loop-variable-out-of-scope.fail.mdl`; tests `mdl/executor/validate_microflow_loop_scope_test.go`. Found while working the sudoku findings, but **not** one of them — the numbered finding it was filed under is an app bug in that project, not an mxcli defect", "ce": ["CE0108", "CE0111"], "rules": ["MDL052", "MDL053"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A page bound to an attribute the entity **inherits** (`Person extends Administration.Account`, page binds `FullName`) passes `mxcli check --references` AND `mxcli lint`, then the real MxBuild fails `[error] [CE1613] \"The selected attribute 'TaskBoard.Person.FullName' no longer exists.\"` The message reads as a deletion; it never existed there", "cause": "Mendix stores a page's attribute reference against the entity that **declares** the attribute. `resolveAttributePath` qualified a bare name with `pb.entityContext` unconditionally, so a specialization that merely inherits the attribute got a dangling reference. Two independent resolvers had the same bug: the direct binding, and the final attribute of an association path (`resolveAssociationAttributePath`)", "file": "`mdl/executor/cmd_pages_builder_input.go` (`declaringEntityFor`, `entityAttributeOwners`), `mdl/executor/cmd_pages_builder_v3.go` (final attribute of the association path)", "insight": "Walk the generalization chain and qualify with the first entity that declares the name. **Fix both resolvers** — a probe that only tested the direct case would have shipped half a fix; the reporter's own table already showed the associated case failing, and it did still fail after the first patch. Unknown names keep today's context qualification rather than being re-pointed, and a cyclic chain terminates. **Watch the new dependency**: attribute resolution now consults the domain models, and `getDomainModels` panics on a nil backend — several unit tests build a `pageBuilder` with neither backend nor cache, so the lookup bails out early instead. A/B on Mendix 11.12.1: pre-fix binary → CE1613 for the inherited column and 0 errors for the own column; fixed binary → 0 errors for both shapes. Repro `mdl-examples/bug-tests/todo-12-inherited-attribute-on-page.mdl`; tests `mdl/executor/cmd_pages_builder_inheritance_test.go`. mxcli-todo #12", "refs": ["#12"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A decision written with **uppercase** keywords — `IF $T/Status != M.Status.Done AND $T/CompletedOn != empty` — passes `mxcli check` and then fails the build with `[error] [CE0117] \"Error(s) in expression.\"`, quoting the expression back with `AND` still uppercase. The same condition written with `=` builds fine, which makes it look like `!=` cannot be an operand of `AND`", "cause": "Mendix requires its word operators lowercase. A rebuilt `BinaryExpr` gets `strings.ToLower(e.Operator)`; a condition kept as an `ast.SourceExpr` (original text **plus** the parsed tree) returned `e.Source` verbatim and skipped it. The `=` form parses to a BinaryExpr and the `!=` form to a SourceExpr — hence the operator-shaped illusion", "file": "`mdl/executor/cmd_microflows_helpers.go` (`normalizeMendixOperatorCase`, applied in the `SourceExpr` branch)", "insight": "Lowercase `and/or/not/div/mod` in preserved source, leaving everything else byte-identical: a scanner that tracks single-quoted literals (with `''` escapes) and skips any word preceded by `.`, `/` or `$`, so `'AND'`, `M.Enum.And`, `$Task/Mod` and `$Android` are untouched. **The reporter's own probe table is the cautionary bit** — nine builds established a rule (\"any `!=` inside `AND` fails\") that was real in every observation and wrong about the cause, because every failing probe was uppercase and the control was not. When a table's rule tracks a token, check what ELSE differs between the rows. Reproduced and fixed against mxbuild 11.12.1: stored `AND` → CE0117, stored `and` → 0 errors. Repro `mdl-examples/bug-tests/todo-14b-uppercase-and-operator.mdl`; tests `TestNormalizeMendixOperatorCase`. mxcli-todo #14b", "refs": ["#14"], "ce": ["CE0117"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`CREATE DEMO USER` reports success and `SHOW PROJECT SECURITY` reports `Demo Users Enabled: true`, yet the running app has **zero** accounts — `SELECT Name FROM Administration.Account` returns 0 rows, there is no login page, and none of the row-level XPath rules are enforced", "cause": "A blank mxcli template ships with **Security Level: Off**, and with it off the runtime creates no accounts at all. The demo users are written to the model correctly; nothing connected the two facts, so the model said yes and the app said nothing", "file": "`mdl/executor/cmd_security_write.go` (`warnDemoUsersInert`, called after a successful create)", "insight": "Say it at the moment the user would otherwise believe it worked, and name the one statement that fixes it (`alter project security level prototype`). A *warning*, not a refusal: authoring demo users before raising the level is legitimate ordering. **Generalisable**: when a write succeeds but a project-level setting makes it inert, the write path is the only place with both facts in hand. Tests `TestWarnDemoUsersInert`. mxcli-todo #15", "refs": ["#15"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Wiring a microflow that takes parameters to a **BEFORE CREATE** event handler passes `mxcli check` (and `--references`), and the build then fails `[error] [CE7247] \"Microflow should not have parameters\" at Event handler of entity …`", "cause": "Mendix passes no object to a before-create handler — the object does not exist yet — so the handler is called with no arguments. Nothing compared the handler's moment against the microflow's signature; the pairing is only invalid for this one moment/event combination", "file": "`mdl/executor/cmd_entities.go` (`checkBeforeCreateHandlerHasNoParameters`, called from `buildEventHandlers`)", "insight": "Guard where the two paths converge — `buildEventHandlers` is shared by `CREATE ENTITY`'s inline handlers and `ALTER ENTITY ADD EVENT HANDLER`, so one check covers both. It refuses **before the model is written**, and the message carries the build code plus the way out (AFTER CREATE, which does receive the object). **A microflow created earlier in the same script is not readable back yet, so an unreadable microflow is skipped rather than refused** — mxbuild still catches the real case, and failing on the read would break legitimate scripts. Note this is an exec-time guard: `mxcli check` without a project cannot see the microflow's signature at all. A/B on 11.12.1: pre-fix binary writes it and mxbuild reports CE7247; fixed binary refuses, and both AFTER CREATE and a no-parameter BEFORE CREATE still work. Tests `mdl/executor/cmd_entities_before_create_test.go`. mxcli-todo #14a", "refs": ["#14"], "ce": ["CE7247"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A wrong `icon:` reference passes `mxcli check` (including `--references`) and first surfaces as a **build** error: `[error] [CE1613] \"The selected custom icon 'Atlas_Core.Atlas_Filled.no-such-icon' no longer exists.\" at Action button 'btnBad'`", "cause": "Nothing resolved the reference — the name was written straight through to BSON. Icon-collection lookup existed only for `show`/`describe` (`cmd_iconcollections.go`), never in a validation path", "file": "`mdl/executor/validate_icon_refs.go` (`validateIconRefs`), wired into `validateProgram`", "insight": "Index the project's icon collections once per run and resolve every reference in the program. **Put it in the `--references` pass, not the no-project one** — the collections are documents *in the project* (a blank 11.13 app ships three, ~770 icons), so unlike the #836 grant check there is genuinely nothing to resolve against without `-p`. **Report the two failures differently**: an unknown *icon* in a known collection gets near-match suggestions plus `describe icon collection <name>`; an unknown *collection* gets the list of collections that exist, because that is where the typo usually is. **Generalisable — the shape to look for**: a string property that names a model element but is stored as a plain string is invisible to every reference checker; grep for properties whose value is a qualified name yet whose type is `string`. **Test the silence, not just the noise**: the risk in a new check rule is false positives, so sweep the repo's own examples (all 9 `mdl-examples` scripts using icons) before shipping — a rule that fires on valid input is worse than the gap it closes. **Repro cannot be a `.fail.mdl`**: `make check-mdl` runs `mxcli check` with no `-p`, so a bad-icon script would pass there and be reported as a negative test unexpectedly passing; the repro carries valid icons and the rejection cases live in unit tests. Repro `mdl-examples/bug-tests/icon-reference-validation.mdl`; verified end-to-end (bad reference reported before any write; `mx check` 11.13.0 0 errors on the valid script)", "refs": ["#836"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check` reports `✓ Syntax OK` / `Check passed!`, then `mxcli exec` on the same script fails partway through with `failed to resolve page: page not found: Module.Page` — a button targeting a page the script creates further down. `exec` is not transactional, so the statements before the failure are already written to the .mpr", "cause": "Page references are resolved in statement order at exec time. `check --references` already had an ordered pass (`validateForwardPageRefs`), but it needs `-p`; plain `check` had nothing, and plain `check` is what gets run", "file": "`mdl/executor/validate_page_order.go` (`ValidateScriptPageOrder`, MDL-PAGE01), wired in `cmd/mxcli/cmd_check.go` beside the other project-free validators", "insight": "The soundness argument is what makes this work without a project: a **plain** CREATE later in the script would fail if the page already existed, so the script itself asserts the page does not exist yet and the earlier reference cannot resolve against the project either. `CREATE OR MODIFY`/`OR REPLACE` assert nothing, so they stay with `--references`, which can look. **Generalisable**: an ordering rule that seems to need project state often does not, once you find the statement that already asserts what you were going to look up. Two things the diagnostic must say and does: a cycle cannot be fixed by ordering (create one page without the linking widget, add it with `ALTER PAGE … INSERT`), and commit before executing a large script. Verified against all `mdl-examples/**/*.mdl` for false positives (0). Tests `mdl/executor/validate_page_order_test.go`, example `mdl-examples/bug-tests/todo-9-forward-page-reference.fail.mdl`. mxcli-todo #9", "refs": ["#9"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create non-persistent entity X ( A: String not null error '…' )` (or `unique`) passes `mxcli check` AND `mxcli exec`, then the build fails **CE0070** \"Validations rules are not allowed on entity 'X', because it is not persistable\"", "cause": "`not null` / `unique` ARE validation rules — Studio Pro models \"required\" and \"uniqueness\" as rules on the entity, not as column constraints — so Mendix rejects them on a non-persistable entity. Nothing in mxcli connected the attribute constraint to the entity's persistence kind", "file": "`mdl/executor/cmd_enumerations.go` (`validateNPEValidationRules`, called from `ValidateEntity`)", "insight": "Add **MDL054**, error severity, fired from the CREATE path only. **Establish the construct matrix against mxbuild before writing the rule, not from the issue text** — verified on 11.6.6 that `not null` with a message, `not null` bare, AND `unique` each produce CE0070 while a plain attribute does not, so the bare form (easy to miss, since the reporter only showed the message form) is flagged too. The CREATE path is the only one that can run this: `ALTER ENTITY … ADD ATTRIBUTE` does not carry the persistence kind, the same limitation MDL020 has. Sweep `mdl-examples/` + `scripts/check-skill-mdl.sh` after adding any error-severity rule — a false positive there breaks every user with that shape. Negative test `mdl-examples/bug-tests/832-npe-validation-rules.fail.mdl` (`.fail.mdl` = must fail check, enforced by `make check-mdl`) plus `-ok.mdl` pinning the other edge; tests `TestValidateEntityNPEValidationRules`. Issue #832", "refs": ["#832"], "ce": ["CE0070"], "rules": ["MDL020", "MDL054"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`retrieve $L from Mod.Entity where [Attr = $Var/Mod.Assoc/Attr]` passes `mxcli check` AND `mxcli exec`, then the build fails **CE0161** \"Error(s) in XPath constraint\"", "cause": "Mendix XPath reaches at most ONE hop off a variable, and nothing checked the hop count", "file": "`mdl/executor/validate_microflow.go` (`checkXPathVariableTraversal`, `xpathVarTraversalRe`), called from the `*ast.RetrieveStmt` arm beside MDL047/MDL048", "insight": "Add **MDL055**, error severity, matching a `$var`-rooted path with **2+ segments**. **Establish the boundary against mxbuild first — it is narrower than it looks**: `$Var/Attr` VALID, `$Var/Mod.Assoc` VALID (one hop to the associated object), `$Var/Mod.Assoc/Attr` CE0161. A rule keying on \"a module-qualified segment follows a variable\" would reject the middle form, which is legal; key on hop count instead. Verified on 11.6.6 by building all three and dropping the offender to confirm the other two are clean. **Reject, don't try to serialize** — there is no valid XPath for the two-hop form, so the constraint must be restructured and only the author knows which way. **Verify the suggestion you emit**: both recommended rewrites (`retrieve $Related from $Var/Mod.Assoc;` then constrain on `$Related/Attr`; or invert to `[Mod.Assoc/Mod.Entity = $Var]`) were built and confirmed at 0 errors before the message claimed \"both forms build clean\". Negative test `mdl-examples/bug-tests/831-xpath-variable-traversal.fail.mdl` + `-ok.mdl`; test `TestXPathVariableTraversal`. Issue #831", "refs": ["#831"], "ce": ["CE0161"], "rules": ["MDL047", "MDL048", "MDL055"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check` reports a microflow rule (e.g. MDL048 `[id = $StringVar]`) but `mxcli exec` writes the same script silently — a script that skips `check` produces a project the build rejects", "cause": "Two different validators. The exec path called `ValidateMicroflowBody` (semantic errors); the MDL0xx rule set lives in `ValidateMicroflow`, which was wired only into `cmd/mxcli/cmd_check.go` and the LSP. Same shape as #836, where a guard existed on every exec path but was never reached from validate", "file": "`mdl/executor/validate.go` (`validateMicroflowRules`, `execEnforcedMicroflowRules`) called from `mdl/executor/cmd_microflows_create.go` — the handler, mirroring `ValidateEntity` in `cmd_entities.go` (NOT `validateWithContext`, which would double-report under `check --references`)", "insight": "Promote an **explicit allowlist** of rules verified against a real mxbuild, never the whole set. **Blanket promotion was tried and reverted**: it turns every error-severity rule into a write barrier, and `MDL009` (\"enumeration splits require exactly one value per branch\") was a **false positive** — a multi-value branch covering every enum value builds at 0 errors on 11.6.6, and the shipped `write-microflows` skill documents that very form (since retired, see the MDL056 row). It also broke an existing repo test whose fixture uses `else` on an enum split. `MDL008` by contrast IS correct (mxbuild: CE0079 per uncovered value + CE0773) — so before promoting any rule, build its construct and read the verdict. Warnings are never promoted. Tests `TestValidateMicroflowRules_ReachedFromExec` and `…_UnverifiedRulesNotPromoted` (the latter fails if the allowlist is widened carelessly). Issue #833", "refs": ["#833", "#836"], "ce": ["CE0079", "CE0773"], "rules": ["MDL008", "MDL009", "MDL048", "MDL056"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check` errors **MDL009** \"enumeration splits require exactly one value per branch\" on `when Open, Pending then` — but Mendix accepts it, so check rejects valid MDL and contradicts the shipped `write-microflows` skill", "cause": "The rule asserted the opposite of the platform's behaviour. Nobody had built the construct: a multi-value branch covering every value **plus `(empty)`** builds at 0 errors on 11.6.6", "file": "`mdl/executor/validate_microflow.go` (the `*ast.EnumSplitStmt` arm; `checkEnumSplitEmptyBranch`)", "insight": "Retire the assertion and replace it with what actually fails: an enum split needs an outgoing flow per condition value, so a missing branch is **CE0079**. **MDL056** checks the `(empty)` branch — universal, verified to hold even on a `not null` enum attribute, so it needs no enumeration lookup and works from the statement alone. Full value coverage (the other half of CE0079) is deliberately NOT implemented: it needs the enum's member list, i.e. resolving the split variable's type against script or project, which `ValidateMicroflow` cannot see — guessing would trade one false positive for another. **Use a NEW rule ID rather than repurposing**, so anything citing the old number still means the old, wrong thing. `MDL008` (no `else`) is correct and stays — mxbuild gives CE0079 per uncovered value **plus** CE0773 on the else flow. Fix the skill in the same change: it documented the invalid `else` form. Tests `TestValidateMicroflow_EnumSplitMultipleValuesAllowed` / `…RequiresEmptyBranch`; repro `mdl-examples/bug-tests/mdl009-enum-split-empty-branch.fail.mdl` + `-ok.mdl`", "ce": ["CE0079", "CE0773"], "rules": ["MDL008", "MDL009", "MDL056"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A published OData service created purely from MDL passes `mxcli check` and then fails the build — `[CE0729] \"The service name should not be empty.\"` and `[CE7375] \"Attribute ID for entity 'X' must be published and be the key when associations are exposed as an associated object id.\"` — the second firing even with no associations exposed at all", "cause": "Two defaults `CREATE ODATA SERVICE` never set. (1) `Name` (the document) and `ServiceName` (the name in the OData metadata document) are different properties and only the first was set; the CONSUMED path had defaulted this for CE0339 all along. (2) `PublishAssociations` defaults to false = \"associations as an associated object id\", which Mendix only allows when the system `ID` is published as the key — but MDL's `expose (Attr (KEY))` publishes an ordinary attribute", "file": "`mdl/executor/cmd_odata.go` (`serviceName` fallback + heal on create-or-modify; `publishAssociationsFor`; `nonPersistablePublishedEntities` warning), `mdl/ast/ast_odata.go` + `mdl/visitor/visitor_odata.go` (`PublishAssociationsSet`)", "insight": "**Wider than reported**: the finding framed CE7375 as a non-persistable-entity problem. Measured on 11.12.1, the identical service with a PERSISTENT entity and a unique key builds 0 errors with `true` and CE7375 with `false` — so the default broke *every* published service, and non-persistable was just where it could not be worked around. Defaulting to true does not pick a preference; it picks the only value that can build from the MDL people write. Needs tri-state (`PublishAssociationsSet`) so an explicit `false` is still honoured, and `create or modify` no longer flips a stored value the author did not mention. **Why nothing caught it**: `mdl-examples/doctype-tests/10-odata-examples.mdl` sets both properties explicitly, so the repo's own example worked around both defaults. Tests `cmd_odata_service_name_test.go`, `cmd_odata_publish_associations_test.go`; examples `f1-10.1-…`, `f1-10.4-…`. mxcli-formula1 #10.1/#10.4", "refs": ["#10"], "ce": ["CE0339", "CE0729", "CE7375"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`describe odata service Module.Api` emits MDL that will not parse — `ReadMode: CallMicroflow:Module.Read` matches no value, `expose (Module.Entity.Attr ...)` where the clause takes a bare member name — and quietly renames the entity set, printing the entity TYPE's exposed name in the `as '…'` position where the entity SET's belongs", "cause": "Three independent slips in one emit block. The backend stores a microflow-backed mode as `CallMicroflow:<qn>` and a member fully qualified; DESCRIBE printed the stored forms verbatim. The set/type name confusion is invisible in a single-word case and only shows when the two differ (Studio Pro's convention is singular type, plural set)", "file": "`mdl/executor/cmd_odata.go` (`odataModeToMDL`, `bareMemberName`, entity-set exposed name, `KEY` over `IsPartOfKey`)", "insight": "Storage form ≠ input form: anywhere DESCRIBE prints a value read back from the backend, ask whether the *parser* accepts that spelling — `mx check` and the linter never see DESCRIBE output, so nothing else can catch it. Proved by round trip rather than by eye: describe → check (parses) → drop → exec the output → describe again → **byte-identical**, and the rebuilt model reports 0 errors from mxbuild. Tests `cmd_odata_describe_roundtrip_test.go`. mxcli-formula1 #10.5", "refs": ["#10"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `create database connection … type 'Redshift'` (or `'SQLServer'`) executes, builds **0 errors**, and the connection does not work. The skill's own table listed both, and omitted the one value that matters for an unsupported driver", "cause": "mxcli passes the type string straight to BSON (`addStr(e,\"DatabaseType\",…)`) and **mxbuild does not validate it either** — verified on 11.12.1 — so nothing between the author and the runtime says the type is not real. Studio Pro's picker (read from `modeler/ide-client/database-connector-editor/`, identical on 11.10.0/11.12.1/11.13.0) is MSSQL, MySQL, Oracle, PostgreSQL, Snowflake, **BYOD** (\"Other\") — no Redshift, no SQLServer", "file": "`mdl/executor/validate_database_type.go` (`ValidateDatabaseConnectionType`, MDL-DB01), wired in `cmd/mxcli/cmd_check.go`; `.claude/skills/mendix/database-connections.md`", "insight": "**A warning, not an error**: the value set is version-specific and mxcli cannot prove a string wrong on a Mendix version it has not seen — but silence is worse when the build is green and the connection is dead. **`BYOD` is the discovery worth keeping**: it forces connection-string config and *skips the driver-presence check*, so any JDBC driver Mendix has no entry for (DuckDB, SQLite, ClickHouse) works by dropping the JAR in `userlib/`. **Generalisable**: when a doc lists enum values, the shipped Studio Pro editor bundle is the authority — grep `id:\"…\",label:\"…\"` out of `ide-client/`, and diff across cached versions to see whether the set moved. Tests `validate_database_type_test.go`. mxcli-formula1 #6", "refs": ["#6"], "rules": ["MDL-DB01"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE microflow` prints a bare `else` on a `split type` the author never wrote one for, and each describe→exec pass accumulates another", "cause": "An object-type decision always carries an `(empty)` outgoing flow (the null-object case), emitted by the builder whether or not an `else` was written. DESCRIBE rendered that flow as `else`. Invisible until the `InheritanceCase` writer landed — before that every branch degraded to `NoCase`, so nothing distinguished it from a real case", "file": "`mdl/executor/cmd_microflows_show_helpers.go` (the `elseFlow` block in the inheritance-split traversal)", "insight": "Drop the `else` line when its body renders empty — the same `elseLineIdx`/truncate pattern the if/else emitters already use. Exec re-creates the flow, so the omission is lossless and the roundtrip is stable. **Do NOT 'fix' this in the builder**: removing the empty-entity branch there fails the build with **CE0089** \"The '(empty)' value should be configured for an outgoing flow\" — that flow is load-bearing and is why `else` cannot substitute for the base entity's case (CE0090); `(empty)` and the base type cover different things. That wrong fix was implemented first and caught only because every shape was re-run through mxbuild, not because a unit test failed. Tests `TestBuilder_InheritanceSplitKeepsEmptyCaseFlow` (builder must KEEP it) and `TestTraverseFlow_InheritanceSplitOmitsEmptyElse` (describe must not print it)", "ce": ["CE0089", "CE0090"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A published service will not build: every whole-number attribute is `[CE5016] \"Attribute … has type Integer, but is published as Edm.Int32\"`, and an exposed enumeration adds CE5016 plus `[CE4583] \"Enumeration 'X' is not published in this service.\"`", "cause": "`mendixAttrTypeToEdm` mapped Integer→Int32 (Mendix publishes it as **Int64**, same as Long), and the enum path wrote `Edm.String` while `EnumerationAsString` was hardcoded `false` — the one combination Mendix rejects, since with the flag false it wants the enumeration published as its own EDM enum type. The function's own comment flagged the unverified rows, and the existing unit test *pinned the wrong answer*", "file": "`mdl/executor/cmd_odata.go` (`mendixAttrTypeToEdm`, `enumPublishedAsString`, `publishedAttrType`), `model/types.go` (`PublishedMember.EnumerationAsString`), `mdl/backend/modelsdk/odata_write.go` + `sdk/mpr/writer_odata.go` (stop hardcoding the flag)", "insight": "**Let mxbuild adjudicate the whole table at once**: publish one attribute of every Mendix type in one service and read the CE5016s off the build. That found Integer (reported) *and* Enumeration (only suspected), and confirmed String/Long/Decimal/Boolean/DateTime were already right — five verified rows for one build. Binary turns out to be unpublishable at all (CE5013), whatever type you give it. **A type and a flag that only work as a pair must travel as a pair** — `Edm.String` is ambiguous between String and a flattened enum, so the flag is the only thing distinguishing them and it belongs on the same struct. Watch for an existing test that encodes the bug: this one asserted `Edm.Int32`, so the fix *failed the suite* until the assertion was corrected. Tests `cmd_contract_test.go`, `cmd_odata_edm_type_test.go`. mxcli-formula1 #16", "refs": ["#16"], "ce": ["CE4583", "CE5013", "CE5016"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create odata client` against a service behind `authentication basic` prints `Warning: could not fetch $metadata: … HTTP 401`, creates the client anyway, and the following `create external entities from …` imports nothing — from a script that reports success", "cause": "The statement's `HttpUsername`/`HttpPassword`/`HEADERS` are stored for the runtime, but the design-time fetch was a bare `client.Get`. The fetch failure is only a warning, so the empty client propagates silently", "file": "`mdl/executor/cmd_odata.go` (`metadataFetchAuth`, `metadataAuthFromStmt`, `fetchODataMetadata`), `mdl/ast/ast_odata.go` + `mdl/visitor/visitor_odata.go` (`HttpUsernameIsLiteral` / `HeaderDef.ValueIsLiteral`)", "insight": "**Only a literal is usable at design time.** The visitor strips a quoted literal's quotes, so `'f1api'` and `Module.ApiUser` both arrive as bare strings — the AST has to record which was written, or mxcli sends a *constant's name* as the password. Unresolved names are reported instead, which is also the honest answer: mxcli has no runtime to resolve a constant against. **A warning on a step something else silently depends on needs to say what breaks next** — the message now names the empty client and the import that will do nothing. Verified against a real basic-auth server that 401s without credentials and 403s without the custom header, so both had to arrive. Tests `cmd_odata_metadata_auth_test.go`. mxcli-formula1 #23", "refs": ["#23"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Re-running `create or modify odata service` after editing a `publish entity` block changes nothing — the served `$metadata` is identical, and only `drop odata service` + create picks the edit up", "cause": "The modify branch updated the service's scalar properties and never touched `EntityTypes` / `EntitySets`", "file": "`mdl/executor/cmd_odata.go` (modify branch rebuilds published entities via `astEntityDefToModel`, and carries `AllowedModuleRoles` through)", "insight": "**Replace, don't merge**: a member removed from the script has to leave the service, which merging cannot express — the script is the description of the service. **Carry through what the statement cannot express**: role grants come from a separate `grant access on odata service` and would otherwise be dropped by a modify (reported; *not* reproduced on 11.12.1 — kept as a guard, and the commit says so rather than claiming a fix). Verified: same script yields `Label as 'label'` before and `Label as 'label' (Filterable, Sortable)` after, build stays at 0 errors. Tests `cmd_odata_modify_members_test.go`. mxcli-formula1 #26", "refs": ["#26"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A contract property called `name` is generated as `Stg_Drivername` / `Circuitname` — prefixed with the remote type. A page written against the published `$metadata` then fails with `The selected attribute 'F1Live.Drivers.name' no longer exists`, and the *same* field carries a different name in every module because the remote type names differ", "cause": "`attrNameForOData` disambiguates any name in `reservedEntityAttrNames`, and `name` was on that list with the comment \"Mendix system-managed attribute for the object name\". It is not: Mendix builds an external entity with an attribute literally named `name`", "file": "`mdl/executor/cmd_contract.go` (`reservedEntityAttrNames` loses one entry; the import now reports the renames it does make)", "insight": "**Test the whole list at once, not the reported entry.** One contract with a property per listed name, prefixing disabled, then `mx check`: CE7247 \"The name 'x' is a reserved word\" for `id`/`owner`/`changedBy`/`changedDate`/`createdDate`/`type`/`context`, and silence for `name`. That turns \"is the list wrong?\" into \"which rows are wrong?\" for the cost of a single build, and it *earns* the seven entries that stay rather than leaving them as folklore. Two existing tests pinned the old behaviour and had to be corrected — a hand-maintained list of platform rules will accrete guesses unless each row can point at an error code. **Migration**: a re-import renames the attribute back, so references to the prefixed name must follow. Tests `cmd_contract_reserved_test.go`. mxcli-formula1 #28", "refs": ["#28"], "ce": ["CE7247"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create odata client` with credentials given as constants (`HttpUsername: '@Module.ApiUser'`) still gets HTTP 401 and an empty client, after the fix that made literal credentials work. Sharpened by the same release making a constant `ServiceUrl` mandatory — the shape the tool insists on is the shape whose credentials it will not read", "cause": "`resolveCredential` trusted the visitor's isLiteral flag. `'@Module.ApiUser'` **is** a STRING_LITERAL, so the flag said \"literal\" and the previous code sent the fifteen characters `@Module.ApiUser` as the username — and the unresolved-credential note did not fire either, because as far as the code knew nothing was unresolved", "file": "`mdl/executor/cmd_odata.go` (`resolveCredential`, `constantReference`, `designTimeConstants`)", "insight": "**A syntactic classification is not a semantic one.** The visitor can say \"this was a quoted string\"; only the executor can say \"this quoted string names a constant\". Any flag of the form isLiteral needs the consumer to ask what the literal *contains* before treating it as a value. **The fix is to resolve, not to refuse**: a constant's design-time default is exactly what Studio Pro sends on the same fetch, so reading it is the value rather than a workaround — and mxcli already has the project open. Three spellings must all work (`'v'`, `@M.C`, `'@M.C'`); a dotted literal like a password containing a dot must not be mistaken for a reference. Tests `cmd_odata_metadata_auth_test.go`. mxcli-formula1 #23 follow-up", "refs": ["#23"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `MOVE` cannot be confirmed and a module's layout cannot be reviewed: `SHOW STRUCTURE` groups by document type at every depth and never names a folder, `DESCRIBE` answers for one document at a time, so checking where things ended up means opening the `.mpr` as SQLite", "cause": "The read side of folders was simply never built. `MOVE`/`DROP FOLDER` write containment; nothing read it back", "file": "New `mdl/executor/cmd_list_folders.go` + grammar (`FOLDERS` lexer token, `showOrList FOLDERS (IN …)?` in `MDLCatalog.g4`, `FOLDERS` added to the `keyword` rule so it stays usable as an identifier), `mdl/ast/ast_query.go`, `mdl/visitor/visitor_query.go`, `mdl/executor/executor_query.go`", "insight": "**A layout listing must show what is *not* there**: empty folders (`[0]`) and documents still at the module root, or it cannot be diffed against an intended layout — that is the whole use. Documents are indexed by `ContainerID` across every list call the backend offers, each best-effort, so a backend that cannot answer one kind yields a listing missing that kind rather than no listing. **Do not stub the hierarchy in the test** — `mkHierarchy` populates `moduleNames` but not `folderNames`, so `BuildFolderPath` returns `\"\"` and every folder silently collapses into the module root, which looks exactly like the bug. Build it from the mock's `ListModules`/`ListUnits`/`ListFolders`, as `getHierarchy` does. Tests `cmd_list_folders_test.go`, example in `18-folder-examples.mdl`. mxcli-formula1 issue #2", "refs": ["#2"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE PAGE` reports a drill-down button as `linkbutton b (Caption: 'Weekend', Action: show_page Mod.Page)` — the `(Race: $currentObject)` argument is gone. The model is fine (`mx check` is clean, and an unmapped required page parameter is a consistency error, so it could not have built), but the description reads as a diagnosis mid-hunt and costs cycles fixing a button that was correct", "cause": "mxcli deliberately writes `ParameterMappings` as an empty array for a page action, because Studio Pro infers the row object from the enclosing widget and rejects an explicit `$currentObject` Argument as CE0115 (#296). That decision was right; its other half was missing. `renderClientActionMDL` read only explicit mappings, and the writer's comment *asserted* DESCRIBE recovered the implicit one — it never did", "file": "`mdl/executor/cmd_pages_describe_output.go` (`pageActionParameters`, `targetPageParameterNames`), stale comment corrected in `sdk/mpr/writer_widgets_action.go`", "insight": "**When a writer stores something implicitly, the reader owes it an explicit reconstruction — and a comment claiming the reader already does is worth nothing until a test says so.** Recover from the *target page's* declared parameters, not from the action, since that is where the information actually lives. Guard both ends: an explicit mapping still wins (recovery fills a gap, it does not override Studio Pro), and an unresolvable page yields no arguments rather than invented ones — a description that omits an argument is recoverable, one that names a parameter that does not exist is not. **A lossy DESCRIBE is costliest exactly when it is most used**, because DESCRIBE is what you reach for once you have stopped trusting the model. Tests `cmd_pages_describe_pageparams_test.go`; the control (explicit-only) reproduces the reported output verbatim. mxcli-formula1 §39", "refs": ["#296"], "ce": ["CE0115"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A published OData resource backed by a read microflow silently returns the wrong thing: `?$top=5` yields the whole collection with a 200, and a client re-reading a held row by key gets the collection default and adopts the FIRST row as that object's identity. No error anywhere — well-formed request, valid collection, correct `$count`, 200", "cause": "Two promises the service makes on the microflow's behalf and nothing checked: the `KEY` in `expose (…)`, and the `TopSupported`/`SkipSupported` annotations (which default to **true** when unspecified). Mendix applies no query options to a read-microflow resource — it hands over the request and returns what comes back", "file": "New `mdl/executor/validate_odata_read_contract.go` (MDL-ODATA02 key promise, MDL-ODATA03 capability over-claim), wired in `cmd/mxcli/cmd_check.go`; the response contract documented in `.claude/skills/mendix/odata-data-sharing.md`", "insight": "**A read microflow cannot answer 400** — unlike an OData action or an insert/update/delete microflow, the read capability has no `System.HttpResponse` parameter ([docs](https://docs.mendix.com/refguide/published-odata-entity/#custom-http-response)). Its contract is therefore *declarative*: declaring `TopSupported: No` is the read path's only substitute for the refusal it cannot send. **Pick a trigger you can prove**: both rules fire only when the microflow takes no `System.HttpRequest` parameter, because then it provably cannot see a key or a query option; a microflow that does take it gets the benefit of the doubt, since proving *which* options it parses needs real analysis and a rule that guesses gets switched off. **Verify a check rule against a real parse, never a hand-built AST** — the visitor stores `ReadMode` as `MICROFLOW Module.Name` **upper-cased**, so a case-sensitive prefix match made the whole rule dead while it still looked right; the casing is now pinned by its own test. Tests `validate_odata_read_contract_test.go`, examples in `10-odata-examples.mdl` (both correct shapes: request-aware, and honestly declared). mxcli-formula1 §37/§20, suggested issues 2 and 3"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A published OData entity with no `KEY` fails the build with **CE6585** \"Published entity 'X' must have a key defined.\" — so any advice of the form \"drop the KEY\" is impossible to follow", "cause": "Mendix requires every published entity to have a key. MDL-ODATA02's suggestion offered \"…or drop the KEY\" as the alternative to answering a key lookup, and a doctype example demonstrated that non-existent option", "file": "`mdl/executor/validate_odata_read_contract.go` (suggestion text), `mdl-examples/doctype-tests/10-odata-examples.mdl`, `.claude/skills/mendix/odata-data-sharing.md`", "insight": "**Query options you may decline; the key you may not.** A microflow-backed resource whose rows a client can hold *must* answer the key lookup — there is no opt-out, which makes MDL-ODATA02's real remedy singular rather than a choice. **Verify the remedy a diagnostic recommends, not just the diagnosis** — the rule correctly identified an unanswerable KEY and then proposed something mxbuild rejects, which is worse than saying nothing. This is the second time in one session that a doctype example was validated with `mxcli check` (parse-only) instead of the integration gate; `mxcli check` cannot see CE-codes at all, so **any change to `mdl-examples/doctype-tests/` needs `go test -tags integration -run TestMxCheck_DoctypeScripts/<script>` before it is called done** — the two-minute run that would have caught both. mxcli-formula1 §37 follow-up", "ce": ["CE6585"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| A page written by mxcli will not open in Studio Pro, and `mx check` dies during *load* with `ArgumentNullException` at `EntityRefStep.set_AssociationId` — no page error, no CE code, the whole project is down rather than one document | An association DATASOURCE wrote the association name exactly as authored. Both halves of an `EntityRefStep` are BY_NAME and Mendix resolves either one it cannot find to null, but only `DestinationEntity` was guarded (issuetracker #14) — a bare `Order_Line` reached BSON unqualified. The **explicit-destination** form is the live trap: supplying the destination satisfies that guard, so nothing stood between a bare name and the crash — and `Assoc/Module.Entity` is exactly what the guard's error tells the author to write | `mdl/executor/cmd_pages_builder_v3.go` (`buildDataSourceV3`, `case \"association\"`: qualify via `resolveAssociationPathIn`, then verify an author-supplied destination's association exists via `associationEndpoints`) | **Guard every BY_NAME half of a ref, not the one that was reported.** #854 reported the destination; the association beside it failed identically and was reachable through the fix's own advice. **Diff the two properties in the dump** (`grep -A1 '\"Key\": \"(Association\\|DestinationEntity)\"'`) rather than reading the exception name — the loader reports whichever it touches first. **Hold the input constant across builds**: the pre-fix binary was first run with bare names and post-fix with qualified ones, which \"reproduced\" nothing; re-running the *same qualified* script on both is what isolated cross-module (`\"\"`) from same-module (resolved). `mx check` exits 0 on this failure — assert on the `contains: N errors` line, never `$?`. Tests `cmd_pages_builder_assoc_datasource_test.go`, example `mdl-examples/bug-tests/854-assoc-datasource-qualified-name.mdl`. upstream #854 follow-on |", "refs": ["#14", "#854"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`MDL-ODATA03` (\"advertises TopSupported … so no paging is applied\") is silenced by giving the read microflow a `System.HttpRequest` parameter — even when the parameter was added for the **KEY** and no paging was implemented. The half-fixed resource, which is the one still shipping unpaged 200s, is exactly the one the rule stops warning about", "cause": "MDL-ODATA02 (KEY) and MDL-ODATA03 (paging) shared a single test — `takesHTTPRequest(decl)` — and answering either concern satisfied both. The rule could see whether the microflow *could* read the request, not whether it *did*", "file": "`mdl/executor/validate_odata_read_contract.go` (`capabilityViolations` now takes the declaration; `pagingEvidence`/`walkForPaging` reflect-walk the reachable body), `mdl-examples/doctype-tests/10-odata-examples.mdl`", "insight": "**When one input satisfies two rules, the rules will silence each other.** The tell is a shared precondition that means something different to each check — grep for other validators keyed on the same `takesX()` helper before adding one. **The wire spelling is the evidence.** An OData query option is literally named `$top`, so a microflow implementing it must contain that text; presence of the text is weak evidence of handling, absence is strong evidence against — which is the only direction a rule that reports absences needs. **Reflect-walk, do not type-switch per statement**: MDL gains activity types regularly and a walker that misses one converts a false negative into a false *positive* (\"nothing reads $top\" about a body it never looked at). Reflection also picks up new nesting — loop bodies, if-branches, error handlers — for free. **Exclude `Annotations`/`Documentation`/`Comment` fields from the walk**: an `@annotation '$top is not applied here'` is prose admitting the defect, and counting it as implementation silences the rule on the one resource that documents the bug. **Keep an escape hatch and make it outrank the evidence**: a call into a Java action, a JavaScript action, a nanoflow, or a microflow the script does not define ends the analysis with silence — same stance the rule already took toward out-of-script read microflows. Follow calls into helpers the script *does* define, since real code factors paging out. **Report per option, not per resource** — flagging `SkipSupported` while `$top` is genuinely handled avoids advising an author to withdraw working support. **Shipped examples are part of the blast radius**: the doctype example's variant (a) was written to the old rationale (\"taking `$Request` is enough to earn its silence\") and started warning the moment the rule tightened — a changed rule needs `mxcli check` over `mdl-examples/` and then the integration gate, not just its own unit tests. Each guard has its own revert control (restore benefit-of-the-doubt / drop the annotation skip / drop `opaque` / stop following helpers), and all four reproduce. Tests `mdl/executor/validate_odata_read_contract_test.go`. mxcli-formula1 §42"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create database connection` with literal credentials succeeds, then the project will not open in Studio Pro and `mx check` dies during *load* with `StorageLoadException: ... is not a valid ConstantIdentifier` — no CE code, no document named, the whole project down rather than one unit", "cause": "`connection string` / `username` / `password` are ConstantIdentifier properties (`generated/metamodel` types all three as `model.QualifiedName`; gen binds them as `property.ByNameRef`) — BY_NAME references to a Constant document with **no literal alternative**. The grammar offers a `STRING_LITERAL` alternative anyway, and the executor passed it straight through into the ref", "file": "New `mdl/executor/validate_dbconnection.go` (`ValidateDatabaseConnection`, MDL058), wired into `cmd/mxcli/cmd_check.go` **and** `mdl/executor/cmd_dbconnection.go`", "insight": "**Refuse, do not auto-create.** Minting a Constant from the literal would be a silent side effect, and for `password` it would bake a secret into the model as a design-time default — which is the exact thing the constant indirection exists to prevent. **Wire both paths**: `check` catching it does not help a script that never ran `check` (the #833 lesson), so the exec handler runs the same rule before the write. **Report all three at once, in fixed order** — one literal per exec run is a miserable loop. **A grammar alternative is not proof a form is legal**: the literal spelling parsed, executed, and only died at load. Tests `validate_dbconnection_test.go`, negative example `mdl-examples/bug-tests/dbconn-literal-credentials.fail.mdl`. Found while verifying the #863 ExecuteDatabaseQueryAction fix", "refs": ["#833", "#863"], "rules": ["MDL058"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`alter page … set DataSource = $Param` fails with \"unsupported DataSource type for alter page set: parameter\", while the same retype through `replace` works", "cause": "Two gaps stacked, both silent about the other path: the executor's `convertASTDataSource` had no `parameter` case, and the mutator's `serializeDataSourceBson` had no `*pages.DataViewSource` case. REPLACE works because it rebuilds the widget through the CREATE PAGE builder, which handles every type — so the capability existed all along, just not in SET", "file": "`mdl/executor/cmd_alter_page.go` (`convertASTDataSource`), `mdl/backend/pagemutator/mutator.go` (`serializeDataSourceBson`, `SetWidgetDataSource`, `lookupParameter`)", "insight": "**A parameter source has TWO by-name halves** — `EntityRef` (DirectEntityRef naming the entity) and `SourceVariable` (PageVariable naming the parameter). Mendix nulls either one it cannot find, which is the #854 unopenable-project shape, so an unknown parameter name must be refused, not written unresolved. **Resolve the entity in the mutator, not the executor**: the entity is not in the statement, and the mutator is the only layer holding the document that carries `Parameters`. **Read snippet-vs-page off the stored parameter's `$Type`** (`SnippetParameter` vs `PageParameter` key) rather than the mutator's container kind — same fact, taken from the document that must agree with it. **When a path genuinely cannot do something, name the one that can**: the bare \"unsupported\" message was half the complaint, so the remaining types now point at REPLACE. Tests `mutator_datasource_test.go`, example `mdl-examples/bug-tests/855-alter-page-set-parameter-datasource.mdl`. upstream #855", "refs": ["#854", "#855"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A microflow expression navigating an association builds as `[CE0117] \"Error(s) in expression.\"`, with `exec` and `check --references` both silent, and the same path written fully qualified building clean", "cause": "Two independent defects in the step that inserts the association's target entity. (a) **Cross-module**: `lookupAssociation` walked only `dm.Associations`, so an association whose target is in another module (a `DomainModels$CrossAssociation`, remote end = BY_NAME `ChildRef`) never resolved and nothing was inserted — the author's short form went through unchanged. (b) **Same-module with the entity named bare**: the skip guard only fired when the next segment was already *qualified*, so `Mod.Assoc/Tag/Label` got the resolved step inserted **in addition**, yielding the four-segment `Mod.Assoc/Mod.Tag/Tag/Label`", "file": "`mdl/executor/cmd_microflows_builder_actions.go` (`lookupAssociation` gains the CrossAssociations pass), `mdl/executor/cmd_microflows_builder.go` (`resolvePathSegments` consumes a bare target-entity segment instead of duplicating it)", "insight": "**Third occurrence of the two-list trap** (#854, issuetracker #19): any code reading associations from a domain model must read `CrossAssociations` too, or every cross-module hop silently no-ops. Grep for `range dm.Associations` before assuming a lookup is complete. **Test the shape the author wrote, not just the shape you expect** — the report was only about cross-module, and the same-module-with-bare-entity case was broken in the opposite direction (over-insertion) and would have survived a cross-module-only fix. **Build a control into one project**: two microflows, short and fully-qualified, gives `1 errors` and names which one; dropping the short one and getting `0 errors` proves it. Cross-module `childPersistable` is unknowable from the local document — the remote entity is not in it — so it must not be read as a fact. Tests `cmd_microflows_assoc_path_test.go`, example `mdl-examples/bug-tests/829-cross-module-assoc-expression.mdl`. upstream #829", "refs": ["#19", "#829", "#854"], "ce": ["CE0117"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `SNIPPETCALL` for a snippet with parameters has no working spelling: omitting `Params:` is refused by mxcli (\"requires parameter $X\"), and supplying `params: {X: $currentObject}` is accepted and then fails the build with `[CE0115] \"The arguments that are passed to snippet … do not match the expected parameters and need to be refreshed.\"` — Studio Pro's \"Refresh snippet parameters\" then deletes what mxcli wrote", "cause": "`$currentObject` was translated into `Forms$PageVariable{PageParameter: \"currentObject\"}` — a by-name reference to a page parameter that does not exist. \"Satisfied by the enclosing data context\" is not a variable in Mendix; it is the **absence** of a mapping, which is exactly why Studio Pro emits an empty `ParameterMappings` and why its refresh removes the invented entry", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildSnippetCallParams`, `isContextArgument`)", "insight": "**Test the form the report calls \"working\" too** — passing a REAL page parameter built at 0 errors all along, which narrows the bug from \"SNIPPETCALL params are broken\" to \"`$currentObject` is not a variable\" and changes the fix entirely. **An empty list and a missing key are different models**: the fix is to emit `ParameterMappings: [3]`, not to skip the property. **Keep the refusal where it is still right** — omission is legal only when `pb.entityContext` equals the parameter's entity; a context of a different entity gets the guidance rather than a CE0115 later, so the error survives for the case it was written for. Tests `cmd_pages_snippetcall_params_test.go`, example `mdl-examples/bug-tests/868-snippetcall-context-parameter.mdl`. upstream #868", "refs": ["#868"], "ce": ["CE0115"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`describe Module.Name` reports `no describable document named \"...\"` for a document that plainly exists and that `describe building block Module.Name` / `describe icon collection Module.Name` describes fine when the type is named explicitly", "cause": "Two lists in different packages drifted apart. Bare DESCRIBE resolves the type by looking the qualified name up in the catalog `objects` view and mapping its `ObjectType` through `objectTypeToDescribeKind`. Building blocks were built into `building_blocks_data` but never joined into the `objects` view union, so the lookup returned no row; icon collections had **no catalog table at all**, leaving the `ICON_COLLECTION` entry in the map as dead code that nothing could ever emit. Measured on a stock 7-module marketplace project: 43 of 251 documents (40 building blocks + 3 icon collections) were unreachable this way — auto-detect coverage 81%, explicit-type coverage 98%", "file": "`mdl/executor/describe_auto.go` (`objectTypeToDescribeKind`), `mdl/catalog/tables.go` (the `objects` view union + the `*_data` table), `mdl/catalog/builder.go` (`buildSimpleNamedDocs` call), `mdl/catalog/catalog.go` (the `CATALOG.*` table list)", "insight": "Add the type in **all four** places — a map entry alone does nothing if the view never emits the `ObjectType`, and a view row alone does nothing if the map has no kind. For a document with just name/folder/documentation, the builder is one `buildSimpleNamedDocs(\"<Unit$Type>\", \"<table>\", \"<Label>\")` line; get the unit `$Type` from the MPR itself (`Images$ImageCollection` vs `CustomIcons$CustomIconCollection`), not from the catalog, which only knows types it already models. **Do not measure coverage from the catalog** — the `objects` view indexes only describable types, so it reports 100% by construction; enumerate raw unit `$Type`s instead. Guard is `TestDescribeAutoCoversCatalogObjectTypes` in `mdl/executor/describe_auto_test.go`, which reads the `ObjectType` literals out of the view's own SQL and fails when one has neither a describe kind nor an entry in `notAutoDescribable`. Watch for **new ambiguity**: adding types to a name-keyed index can make a qualified name match two kinds (verified none here). Issue: marketplace-diff DESCRIBE coverage spike"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check` reports `[MDL044] … calls 'currentDeviceType()', which is not a Mendix expression function`, `mxcli exec` writes the microflow anyway, and the build then fails `[error] [CE0117] \"Error(s) in expression.\" at Create variable activity`", "cause": "MDL044 was not in `execEnforcedMicroflowRules`, so it fired only on the `check` path — the #833 shape, one rule at a time. Promoting it was blocked by a false positive of its own: exprcheck's `funcTable` is MDL044's sole allow-list and was missing three REAL built-ins (`isNew`, `isSynced`, `isSyncing`), so a write barrier would have refused valid MDL", "file": "`mdl/executor/validate.go` (`execEnforcedMicroflowRules`), `mdl/exprcheck/func_checker.go` (`funcTable`), `mdl/exprcheck/unknown_funcs.go` (`roundingFuncs`)", "insight": "**Sweep for false positives BEFORE promoting a check-only rule** — a rule that merely reports may be wrong for years without anyone noticing, and promotion converts every one of those into a refusal. Diff the rule's allow-list against the full published function list, then **build each candidate**: `isNew`/`isSynced`/`isSyncing` came back 0 errors (genuine gaps), while `trunc` — which *looked* like a sibling of round/floor/ceil and was even listed in `roundingFuncs` — came back CE0117, so it is correctly flagged. Adding names on resemblance is how a write barrier stops catching anything. **`funcTable` also contains unverified entries** (the `dayOfYear`/`hour`/`minute` extraction family, flagged in its own comment); those are false NEGATIVES and promotion does not worsen them, but do not add more. **Prove the promotion is the cause**: build a control binary with the rule removed from the map, exec the bad script, and confirm mxbuild reports CE0117 — `check` alone rejecting it proves nothing about the exec path. Tests `validate_microflow_rules_exec_test.go`, `validate_microflow_expr_test.go`, examples `mdl-examples/bug-tests/828-unknown-expression-function.fail.mdl` + `828-object-state-functions-ok.mdl`. upstream #828", "refs": ["#828", "#833"], "ce": ["CE0117"], "rules": ["MDL044"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A datagrid column bound to an association — `column c (attribute: Order_Customer)` — reports success from `mxcli exec` and then fails the build with `[error] [CE1613] \"The selected attribute 'Mod.Order.Order_Customer' no longer exists.\" at Columns (1/1) of data grid 2`. Separately, there is no MDL spelling for the drop-down filter's association mode: `mxcli check` says `[MDL-WIDGET01] has no property \\`refEntity\\``", "cause": "Two unrelated defects behind one report. (1) The reference is **not representable**: `CustomWidgets$WidgetValue.AttributeRef` is typed `AttributeRef`, not the polymorphic `MemberRef`, so the association was qualified like an attribute and written as a dangling `AttributeRef`. (2) `dropdownfilter.def.json` mapped only `attrChoice`/`attributes`/`defaultFilter`, so every `baseType: 'ref'` property was unmapped and dropped", "file": "`mdl/executor/cmd_pages_builder_input.go` (`rejectAssociationAsAttribute`, `entityInChain`) wired into `mdl/executor/widget_engine.go` (the objectlist `attribute` case and the `Attribute` source); `sdk/widgets/definitions/dropdownfilter.def.json` (association mode); `mdl/executor/cmd_pages_describe_parse.go` + `_pluggable.go` + `_output.go` (round-trip)", "insight": "**Establish that a shape is unrepresentable before designing a fix for it** — hand-patch the BSON and run `mx check`. A `DomainModels$AssociationRef` in that slot makes the project **UNLOADABLE** (`ArgumentException: Object of type 'AssociationRef' cannot be converted to type 'AttributeRef'`), and the assembly defining the type (`Mendix.Modeler.WebUI.dll`) has no `AssociationRef` member at all — so the only correct outcome is a refusal carrying both working forms. **`<associationTypes>` on an ATTRIBUTE-typed widget property is permission to TRAVERSE a reference, not to bind one** — `attribute: Assoc/Attr` already worked and is what the XML is advertising; the DataGrid column is the only shipped widget where the two are easy to confuse. **A def.json `mode` is the whole feature** for an unauthorable widget mode — the engine already had the `association` operation and the `hasDataSource` condition, so the second half was a data change plus its DESCRIBE reader (without which describe→edit→exec silently reverts the filter to attribute mode). **0 errors from `mx check` does not prove the properties landed** — an unmapped property is silently dropped and the build is just as green; read them back with `mx dump-mpr`. Tests `cmd_pages_builder_assoc_as_attribute_test.go`, `widget_dropdownfilter_assoc_test.go`, example `mdl-examples/bug-tests/830-datagrid-association-filter.mdl`. upstream #830", "refs": ["#830"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A microflow call bound to a task queue in Studio Pro loses that binding on `create or replace microflow` — silently, and `mx check` goes from `[CE1613] \"The selected task queue no longer exists\"` to **0 errors**, because the configuration the error was about has been deleted", "cause": "Two defects behind one report. (1) `Microflows$MicroflowCall` has `QueueSettings` in `NullFields` of `codec.RegisterTypeDefaults` (and the legacy writer hardcodes null too) — correct for a newly authored call, destructive for a stored one, and since a CREATE OR REPLACE rebuilds the whole microflow it fires on every rewrite. (2) MDL had **no queue surface at all**, so a script could not restate the binding even in principle", "file": "`mdl/executor/validate_queued_calls.go` (new: the refusal), `mdl/executor/cmd_microflows_create.go` (call site), `mdl/types/queue.go` + `mdl/backend/infrastructure.go` (`QueueBackend`), `mdl/backend/modelsdk/queue_write.go` + `sdk/mpr/queues.go` (both engines), `mdl/grammar/domains/MDLDomainModel.g4` + `MDLCatalog.g4`, `mdl/executor/cmd_queues.go`", "insight": "**A green build can be the bug**: the fix made `mx check` report MORE errors than before (CE1613 came back), because the binding it complains about now survives. Any \"error count went down\" check would have scored the data loss as a fix. **`describe` showing nothing is not evidence of nothing** — the binding was invisible from every angle (describe omitted it, check went quiet, the write reported success), which is why it needed a stored-BSON probe: inject `Queue`+`QueueSettings` into a stored call, rewrite, and dump. **Isolate which property Mendix acts on before guarding on it**: a call carrying only `Queue` (with `QueueSettings` null) draws NO complaint from `mx check` — `QueueSettings` is the load-bearing one, so a guard keyed on `Queue` alone would have both missed the real case and fired on inert ones. **Get the BSON shape from a Mendix-authored model, not from the metamodel**: `mxcli marketplace download 202649` (Business Events 3.12.1) has four real queues, and all four agree — `Config` is a `Queues$BasicQueueConfig` whose `ParallelismExpression` is a **STRING**, with the sibling int32 `Parallelism` absent in every one. Writing the int (which the metamodel makes look equally valid) is inventing a property Mendix does not write. **Refuse, do not half-author** (ADR-0005): `in queue` on a call is deliberately still unimplemented, because the `Retry` shape has no Studio-Pro-authored sample to diff against, and guessing it would put a second unverified shape into user projects. **Adding a keyword costs an identifier** — `QUEUE`/`QUEUES` had to go into the `keyword` rule or `queue` would have stopped working as an attribute name. Tests `mdl/backend/modelsdk/queue_write_test.go`, `mdl/executor/validate_queued_calls_test.go`, `mdl/executor/cmd_queues_mock_test.go`, `mdl/visitor/visitor_queue_test.go`, example `mdl-examples/bug-tests/queue-authoring-and-rewrite-guard.mdl`", "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`GRANT <role> ON Module.Specialization (READ (…, SomeAssociation))` is refused with \"entity X has no member(s) SomeAssociation; grant only names members of the entity or of an entity it inherits from\" — when the association *is* declared on an entity it inherits from", "cause": "The member walk resolved inherited **attributes** through the generalization chain (#758) but collected associations only from the entity's own domain model where `ParentID == entity.ID`. An association declared on an ancestor was therefore invisible, which made the rule OpenAIConnector ships impossible to express in MDL (`OpenAIDeployedModel extends GenAICommons.DeployedModel`)", "file": "`mdl/executor/cmd_security_write.go` (`inheritedAssociations`, `domainModelHasEntity`)", "insight": "**Find the declaring domain model by looking for the entity, not by matching module names** — the module-name lookup goes through the hierarchy cache and returns \"\" often enough that filtering on it silently collected nothing; the first cut of this fix looked right and did nothing. **Qualify the ref against the module that DECLARES the association**, as the attribute walk does. **Test that an unrelated entity does not get the entry** — a walk collecting every association in the module passes the positive tests and puts entries exactly where Mendix reports CE0066 for having them. Tests `mdl/executor/cmd_security_inherited_assoc_test.go`; the mock needs `GetModuleByNameFunc`, without which even own attributes fail to resolve. Reported in mxcli-chat FINDINGS §26. (The emitted entry then did not reach storage; that half is the FINDINGS §25 row below.)", "refs": ["#758"], "ce": ["CE0066"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check --references` reports \"java action not found: M.X (referenced by call java action)\" for an action the **same script** creates a few statements earlier. Entities, microflows, pages and nanoflows in the same position are accepted", "cause": "`scriptContext` — the set of objects a script defines, consulted so a script can be checked against its own output — had categories for modules, entities, enumerations, microflows, nanoflows, pages and snippets, but not for java or JavaScript actions. The java-action branch of `validateFlowBodyReferences` went straight to the project lookup", "file": "`mdl/executor/validate.go` (`scriptContext.javaActions`/`javaScriptActions`, `collectDefinitions`, `collectSingle`, `allNames`, `has`, `validateFlowBodyReferences`)", "insight": "**Store the declared parameter names, not a bool.** Exempting the action from \"not found\" must not also exempt it from the parameter-name check — the script declares the parameters, so a typo is still catchable, and a bool would have silently dropped that. **`allNames()` and `has()` move together**: `annotateForwardRef` reads both, so adding a category to one and not the other makes a *created* object look \"defined later in this script\" forever. Tests `mdl/executor/validate_script_javaactions_test.go` (including the control that a misspelled parameter still errors). Reported in mxcli-chat FINDINGS §37"}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| `CREATE IMPORT MAPPING` is reported to \"not preserve JSON member names\": `total` becomes `Total`, `camelCase` becomes `CamelCase`, `__Value` becomes `__ValueItem`. The import then fails at runtime with `key not found: Path(QName(None,),None,)` at `MappingCache.storeValueMappingElement` | The capitalisation is **Mendix's own** and not the defect. A `JsonStructures$JsonElement` stores TWO names — `Path` (the raw JSON key, `(Object)\\|uuid`, which the RUNTIME resolves by) and `ExposedName` (derived by capitalising the initial, and suffixing `Item` on an array's item object, which Studio Pro DISPLAYS). The real defect: mxcli's DESCRIBE emits `ExposedName` while its builder resolved only raw keys, so mxcli's own output did not round-trip — re-executing a DESCRIBE FABRICATED a path (`(Object)\\|Total`; for arrays the `\\|(Object)` item marker vanished entirely, leaving `(Object)\\|EntityInstances\\|__ValueItem`) and zeroed MaxOccurs. Export mappings had the identical bug. Separately, mxcli wrote `IsDefaultType` on every `ValueMappingElement` (a property only the OBJECT element types own) and cloned the JSON structure's `OriginalValue` — the SAMPLE value from the snippet — onto every mapping element, where Studio Pro leaves it empty | `mdl/executor/cmd_import_mappings.go` (`jsonSchemaIndex`, `newJSONSchemaIndex`, `resolve`, `memberNames`; `buildImportMappingElementModel` now returns an error), `mdl/executor/cmd_export_mappings.go` (same), `mdl/backend/modelsdk/mapping_write.go` + `sdk/mpr/writer_import_mapping.go` + `sdk/mpr/writer_export_mapping.go` (drop `IsDefaultType` from the value writers); `cmd_import_mappings.go` again for the `OriginalValue` clone | **A blank Mendix app is a free Studio-Pro-authored fixture** — `FeedbackModule.IMM_PostResponse` + `JSON_AppInsightsResponse` settle \"what does Studio Pro actually write?\" with no Studio Pro and no marketplace download: they store `ExposedName \"Uuid\"` against `Path \"(Object)|uuid\"`. Author the SAME mapping over the SAME structure in the SAME module with mxcli and diff the two units — the only variable left is which tool wrote it. **Run the reporter's repro as written before believing the diagnosis**: theirs produced paths byte-identical to the structure's, so their MDL was not the failing input; the corruption needed a DESCRIBE in the middle. **DESCRIBE emitting a different name than the parser accepts is a round-trip bug even when both are \"correct\"** — the fix is to accept BOTH spellings, not to change what DESCRIBE prints, because the exposed name is the one Studio Pro shows. **Never fabricate a path for an unresolved member**: the invented path passed `mxcli check` and surfaced only in mxbuild (CE5015) or at runtime, so the tool that wrote it reported success — refuse, and list the spellings that would have worked. **`generated/metamodel` decides property ownership**: `isDefaultType` is declared on `Import/ExportObjectMappingElement` and on neither `ValueMappingElement`, and per CLAUDE.md's overlay rule an extra property is the shape mxbuild tolerates and Studio Pro will not open — so a green build proves nothing here. **Count the samples before calling a difference a defect**: two Studio-Pro-authored mappings in a blank app (~15 value elements) all write `OriginalValue: \"\"` while their structures carry 17 non-empty samples, which is what makes \"the sample belongs to the structure\" a measurement rather than an opinion. **Running the reporter's repro is how you find out it is not a reproduction**: theirs PASSED at runtime on 11.6.6 and 11.13.0, so the runtime error they see needs something their standalone file does not carry — say so instead of claiming the fix. And **control the harness before believing its failure**: an early runtime run failed until the control (Studio Pro's own mapping, same harness) failed identically, which located the fault in the test's missing module-role grants, not in the mapping. Tests `mdl/executor/cmd_mappings_member_resolution_test.go`, `mdl/backend/modelsdk/mapping_isdefaulttype_test.go`, example `mdl-examples/bug-tests/882-mapping-member-names.mdl`. upstream #882 |", "refs": ["#882"], "ce": ["CE5015"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE PAGE` output will not re-parse for any page carrying a **pluggable widget**: `mxcli check` on it fails with `extraneous input ':'` / `extraneous input '('` from the first widget onward. Separately, a boolean property the author set is missing from the description entirely", "cause": "Two independent defects in the same path. **Emit**: explicit properties were written with a raw `%s`, so every string lost its quotes — a JSON `spec: {\"a\": 1}` then broke the parse at its first brace. **Read**: `extractExplicitProperties` skipped any value of `\"true\"`/`\"false\"` as a \"common default\", so booleans never reached the output", "file": "`mdl/executor/cmd_pages_describe_output.go` (`explicitPropValue`, `isBareLiteral`), `mdl/executor/cmd_pages_describe_pluggable.go` (`buildPropertyValueTypeMap`, `extractExplicitProperties`), `mdl/executor/cmd_pages_describe.go` (`rawExplicitProp.ValueType`)", "insight": "**Fixing one half alone is worse than the bug.** Quote without emitting booleans and the description re-parses cleanly while silently dropping a property — a wrong page that validates. Both halves ship together or neither. **Quote by the DECLARED type, never the value's shape**: `ValueType.Type` sits in the widget's `Type.ObjectType.PropertyTypes`, the same array `buildPropertyTypeKeyMap` already walks for `PropertyKey` and throws away; a String property holding `\"30\"` or `\"true\"` is indistinguishable from a number once it is a string in BSON, and must still come back quoted. Where no type is declared, fall back to the value's shape and quote anything not plainly numeric or boolean — quoting is the safe direction, since an unquoted arbitrary string may not parse at all. **The round trip is the test, not the output**: describe → `check` → `exec` → describe must be byte-identical and leave `mx check` at 0 errors. Tests `mdl/executor/cmd_pages_describe_pluggable_roundtrip_test.go`; example `mdl-examples/bug-tests/pluggable-describe-roundtrip.mdl`, verified end to end on 11.12.1. **Uncovered while verifying, NOT fixed**: giving a property in a conditionally shown group a non-default value writes a widget Mendix rejects with CE0463 — ProgressCircle's `showLabel: true` and `labelType: 'percentage'` both do it with no DESCRIBE involved, while the same widget's General-group properties take non-default values happily. Reported in mxcli-ledger FINDINGS #104", "refs": ["#104"], "ce": ["CE0463"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE PAGE` output will not re-parse for any page carrying a **pluggable widget**: `mxcli check` on it fails with `extraneous input ':'` / `extraneous input '('` from the first widget onward. Separately, a boolean property the author set is missing from the description entirely", "cause": "Two independent defects in the same path. **Emit**: explicit properties were written with a raw `%s`, so every string lost its quotes — a JSON `spec: {\"a\": 1}` then broke the parse at its first brace. **Read**: `extractExplicitProperties` skipped any value of `\"true\"`/`\"false\"` as a \"common default\", so booleans never reached the output", "file": "`mdl/executor/cmd_pages_describe_output.go` (`explicitPropValue`, `isBareLiteral`), `mdl/executor/cmd_pages_describe_pluggable.go` (`buildPropertyValueTypeMap`, `extractExplicitProperties`), `mdl/executor/cmd_pages_describe.go` (`rawExplicitProp.ValueType`)", "insight": "**Fixing one half alone is worse than the bug.** Quote without emitting booleans and the description re-parses cleanly while silently dropping a property — a wrong page that validates. Both halves ship together or neither. **Quote by the DECLARED type, never the value's shape**: `ValueType.Type` sits in the widget's `Type.ObjectType.PropertyTypes`, the same array `buildPropertyTypeKeyMap` already walks for `PropertyKey` and throws away; a String property holding `\"30\"` or `\"true\"` is indistinguishable from a number once it is a string in BSON, and must still come back quoted. Where no type is declared, fall back to the value's shape and quote anything not plainly numeric or boolean — quoting is the safe direction, since an unquoted arbitrary string may not parse at all. **The round trip is the test, not the output**: describe → `check` → `exec` → describe must be byte-identical and leave `mx check` at 0 errors. Tests `mdl/executor/cmd_pages_describe_pluggable_roundtrip_test.go`; example `mdl-examples/bug-tests/pluggable-describe-roundtrip.mdl`, verified end to end on 11.12.1. Reported in mxcli-ledger FINDINGS #104", "refs": ["#104"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DROP FOLDER 'x' IN Module` reports success, then Studio Pro / `mx check` fails **CE1613** \"The selected import mapping 'Module.X' no longer exists\" for documents that are still in the project. `LIST FOLDERS` had shown that folder as `[0]`", "cause": "Two halves of one blind spot. (a) `execDropFolder`'s doc comment claimed \"the folder must be empty\" but **nothing checked** — it called `DeleteFolder` unconditionally, and the children were left pointing at a container that no longer existed. Nothing is *deleted*: every document is **orphaned**, losing its module qualification (`FeedbackModule.IMM_PostResponse` → `.IMM_PostResponse`), so it survives as a unit that nothing can resolve. (b) `documentsByContainer` is a hand-maintained list of twelve document kinds; JSON structures, import/export mappings, regular expressions and image collections were missing, so the folder rendered `[0]` — which is what made the drop look safe", "file": "`mdl/executor/cmd_folders.go` (`execDropFolder`, `folderContentSummary`), `mdl/executor/cmd_list_folders.go` (`documentsByContainer`)", "insight": "Guard on **`ctx.Backend.ListUnits()`**, never on the per-kind lists — `ListUnits` is type-agnostic, so it cannot inherit the blind spot that caused the bug, whereas a guard built on `documentsByContainer` would wave through exactly the kinds it forgets. Folders are units too (`Projects$Folder`), so one containment scan covers documents *and* sub-folders. **Fail closed**: if `ListUnits` errors, refuse — for a destructive op \"I could not check\" must never mean \"go ahead\". Note the mock's `ListUnits` defaults to `nil, nil` rather than an error, so a test that forgets to stub it sees an empty project and the guard silently passes; stub it explicitly. Separately add the missing kinds to `documentsByContainer` so the count stops lying. Repro `mdl-examples/bug-tests/892-drop-folder-not-empty.fail.mdl`. Issue #892", "refs": ["#892"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE PAGE` renders an **Accordion group** (or any pluggable widget's object-list item) **empty** — the group's own properties print, its nested widgets do not — so a describe→exec round-trip silently DELETES whatever was inside", "cause": "An object-list item can carry child widgets in a **Widgets-typed sub-property** (the group's `content` / `headerContent` slot). `extractObjectListItem` handled only scalar sub-properties (datasource, attribute, expression, text template, primitive) and fell through on everything else, so children were never read; and the emitter always closed an item with `\"\\n\"`, so they had nowhere to go even once read. Both halves must change — reading without emitting still prints an empty group", "file": "`mdl/executor/cmd_pages_describe_objectlist.go` (`rawObjectListItem.Children`, `extractObjectListItem`), `mdl/executor/cmd_pages_describe_output.go` (the object-list item loop)", "insight": "Parse a `Widgets` array with `parseRawWidget` — the same recursion the rest of DESCRIBE uses — and emit the item with a `{ … }` body, recursing through `outputWidgetMDLV3` so nesting and indentation stay consistent. Also relax the \"keep this item\" test to include `len(item.Children) > 0`, or a group whose only content is widgets is dropped wholesale. **The Accordion ships in every blank app** (`widgets/com.mendix.widget.web.Accordion.mpk`) — do not conclude it needs a marketplace install because `modelsdk/widgets/definitions/` has no `accordion.def.json`; that is mxcli's *bundled* registry, while project widgets are discovered from the MPK into `.mxcli/widgets/`. Author one with `PLUGGABLEWIDGET 'com.mendix.widget.web.accordion.Accordion'` (`ACCORDION` is the catalog's MdlName but not a parser keyword). Repro `mdl-examples/bug-tests/891-accordion-group-nested-widgets.mdl`. Issue #891", "refs": ["#891"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A DataGrid 2 column named in MDL (`column colLabel (...)`) cannot be addressed by that name: `ALTER PAGE … ON dg1.colLabel` says not found, and `describe page` shows a name the author never wrote", "cause": "Working as designed and undiscoverable. Mendix stores no name on a pluggable DataGrid 2 column — the schema has no name key, and `backend.DataGridColumnSpec` has no field for one — so the MDL name is dropped and everything downstream uses a derived name (bound attribute → sanitized caption → `colN`)", "file": "`mdl/executor/validate_widgets.go` (`validateDataGrid2ColumnName`, `derivedDataGrid2ColumnName`)", "insight": "Warn at authoring time (MDL-WIDGET16) naming the addressable name, instead of leaving the author to discover it from a failed ALTER. **Warn, not reject**: the name reads as documentation in the source and rejecting it would break every existing script — mxcli's own doctype tests name every column. Stay silent when the derivation cannot be known (no attribute, no caption → `colN`, which depends on position), because naming the wrong one is worse than naming none. Note this is specific to the **pluggable** DataGrid 2; legacy `Forms$DataGridColumn` does store a Name"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Four MDL scripts pass `mxcli check` with 0 errors and execute cleanly; `mx check` then reports CE0156 (user role cannot sign in) and CE5601 (page URL missing a parameter segment)", "cause": "Both are decidable from the MDL alone and neither had a rule. A user role built only from application module roles has no System module role, so nobody holding it can sign in or read System entities; a page with parameters and a `Url` needs a `{Name}` segment per parameter or Mendix cannot bind it", "file": "`mdl/executor/validate_role_and_url.go` (new — `ValidateUserRoleSystemModuleRole` MDL-SEC20, `ValidatePageURLParameters` MDL-PAGE20, `urlBindsParameter`), `mdl/executor/validate_program.go` (wiring)", "insight": "Add both as model-free rules so `check` catches them without a project. **The URL matcher is the subtle half**: Mendix binds a parameter by an attribute path, so `url: 'p006/{Customer/Name}'` is the ordinary shape and an exact `{Customer}` match would flag correct pages — match the segment's leading identifier instead. Verified against mxcli's own page examples at 0 false positives, which is the control that matters for a new rule. **MDL-SEC20 shipped too strict and CI caught it**: `make check-mdl` runs `mxcli check` over every example, and an error-severity rule broke two of them. Measured against mxbuild 11.13 rather than argued about — CE0156 fires at security level Prototype and **not at all** at Off, which a blank project ships, so the rule warns by default and is an error only when the script itself enables security. CE5601 fires either way, so MDL-PAGE20 stays an error and the one example it flagged was genuinely broken (fixed). **Generalisable**: `make test` is not the CI gate — `make check-mdl` runs the rules against real scripts, which is exactly where a new rule's false-positive rate shows up. Run it before shipping a rule. A role declared with no module roles at all is left alone: that is a placeholder for ALTER USER ROLE, not a missing System role. mxcli-dbreplication F10", "ce": ["CE0156", "CE5601"], "rules": ["MDL-SEC20"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`MDL-WIDGET16` fires 44 times on one project, once per DataGrid 2 column, all saying the same thing", "cause": "The rule was written per column when the fact — this grid stores no column names — belongs to the grid. Correct but chatty enough to bury the rest of the report", "file": "`mdl/executor/validate_widgets.go` (`validateDataGrid2ColumnNames`, now called per widget rather than per object-list item)", "insight": "Emit one violation per grid listing each `written → addressable` mapping. **Generalisable**: an advisory rule's unit should be the thing the advice is about, not the thing that triggered it — N identical infos train the reader to skip the category. Feedback on a rule shipped days earlier, from the project using it. mxcli-dbreplication F6"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`combobox cb (Association: …, Caption: Name)` passes `mxcli check`, executes, and the caption is **gone** — `describe page` does not show it and the build fails `CE0642 \"Property 'Caption' is required.\"` The reporter concluded the association combo box was unusable and redesigned the UI around it", "cause": "`Caption` is in `isBuiltinPropName`'s universal allow-list, so MDL-WIDGET01 never questions it on a widget the engine has no route for — while `OptionCaption` *is* correctly rejected. The working spelling is `CaptionAttribute:`, which round-trips cleanly, so the feature was never broken: the author was one property name away with nothing to tell them", "file": "`mdl/executor/validate_widgets.go` (`builtinPropertyMisuse`, `misusedBuiltinProperty`, rule MDL-WIDGET17)", "insight": "Flag the builtin names that are wrong on a specific widget and name the one that works. Deliberately an **explicit list**, not inference: whether a builtin is routed lives in the engine's dispatch, not the .def.json (the combobox def declares `optionsSourceAssociationCaption{Type,Expression}` and nothing called `Caption`), so inferring it would mean reimplementing that dispatch and getting it wrong the other way — the universal allow-list exists precisely to stop false positives on `Label:`/`Class:`. **Generalisable**: a permissive allow-list added to prevent false positives converts every unrouted name into a silent drop; the cost is invisible until a build error names a property the author did write. mxcli-owid #38", "refs": ["#38"], "ce": ["CE0642"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "CE7375 \"must be published and be the key when associations are exposed as an associated object id\" on a service publishing no associations", "cause": "`PublishAssociations` is the representation, not a yes/no — `No` selects \"as an associated object id\", which needs the system ID as key", "file": "`mdl/executor/validate_odata_service_shape.go`", "insight": "Set `PublishAssociations: Yes` (\"as a link\", and the default when omitted). MDL-ODATA06 warns at check time", "ce": ["CE7375"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mx check` exits with `System.ArgumentOutOfRangeException: length ('-1')` and no error code", "cause": "an OData service `Path` with no slash in it; mxbuild throws out of its own validator", "file": "`mdl/executor/validate_odata_service_shape.go`", "insight": "Path must not start with `/` and must end with one (CE6550/CE6552). MDL-ODATA05 catches all three", "ce": ["CE6550", "CE6552"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`alter entity Mod.Ent rename attribute Old to New;` reports success, and `mx check` then fails the app with one **CE1613 \"The selected attribute 'Mod.Ent.Old' no longer exists.\"** per create/change activity member, page attribute widget, validation rule and access rule that named it. Studio Pro still opens the project, so nothing looks wrong until a build", "cause": "The handler renamed the attribute inside the domain model and stopped. Everywhere else Mendix stores an attribute reference it stores the **fully qualified name as a string**, so none of them followed. `mxcli rename` already had the project-wide scanner (entity, enumeration, association, module, microflow, page, constant, java action) — attributes were the one kind never wired to it", "file": "`mdl/executor/cmd_entities.go` (`ast.AlterEntityRenameAttribute`), `mdl/executor/alter_entity_rename_attribute_test.go`", "insight": "Call `ctx.Backend.RenameReferences(Mod.Ent.Old → Mod.Ent.New, false)` and report the count. **Order is load-bearing: scan AFTER `UpdateEntity`, never before.** The scan is a raw-BSON pass over every unit *including the domain model*, while `UpdateEntity` re-serializes the whole domain model from the parsed entity — so scanning first hands the model write the last word and silently undoes the scan's edits inside the domain model, which is exactly where a validation rule's `Attribute` string and a `MemberAccess.Attribute` live. `execRenameEntity` gets away with the opposite order only because entity refs *within* the domain model are binary pointers, not strings. Also added the missing collision guard (renaming onto an existing attribute name made two attributes no reference could tell apart). **Scope, stated rather than hidden**: uses inside expressions (`$obj/Attr`) and XPath constraints (`[Attr = ...]`) are free text where a bare name is only resolvable from the type of what precedes it — they are NOT rewritten, mxbuild reports them as CE0117 / CE0161, and the command now says so instead of reading as complete. Controls on Mendix 11.13.0 with `mdl-examples/bug-tests/910-rename-attribute-updates-references.mdl`: pre-fix build 3 errors, post-fix 0. mendixlabs/mxcli#910 (problem 2)", "refs": ["mendixlabs/mxcli#910"], "ce": ["CE0117", "CE0161", "CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`ALTER ENTITY … MODIFY ATTRIBUTE X SET DEFAULT <v>` (or any unrecognised word in the type position, including a typo like `Integr`) silently retypes the attribute to `Enumeration(<word>)`, and the project then **cannot be loaded at all** — `mx check` dies before validating with `System.ArgumentNullException: Value cannot be null. (Parameter 'value') at EnumerationAttributeType.set_EnumerationId`", "cause": "`MODIFY ATTRIBUTE` requires a `dataType`, whose last grammar alternative is a bare `qualifiedName` (entity reference), so any word matches and the visitor maps it to `TypeEnumeration`. The executor wrote it with no enumeration behind it. CREATE ENTITY had guarded this since #552; the guard was **inline in the create handler** and never applied to MODIFY", "file": "`mdl/executor/attribute_type_ref.go` (new), `mdl/executor/cmd_entities.go` (`AlterEntityModifyAttribute` case)", "insight": "Extract the create-path guard to `validateAttributeTypeRef` and call it from the modify path **before** mutating the attribute. Add `DROP DEFAULT ON ATTRIBUTE <name>` so clearing a default has a spelling that does not go through the type slot, and point the refusal at it. Check `mxcli syntax` too: the topic documented `MODIFY ATTRIBUTE AttrName SET DEFAULT val` — the corrupting form — which is how the reporter got there. When a guard is added inline to one handler, grep for sibling handlers that take the same input. mendixlabs/mxcli#910", "refs": ["#552", "mendixlabs/mxcli#910"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "An `OnChange:` on a `checkbox`, `radiobuttons`, `combobox`, `dropdown`, `textarea` or `datepicker` does nothing. The MDL parses, `mxcli check` passes, `exec` reports success, and `describe page` shows the widget with its Label + Attribute and **no OnChange**. In the browser the control changes state and issues **zero `/xas/` requests** — no server round-trip at all. `textbox` and `actionbutton` keep their actions, so it reads as a page problem rather than a per-widget one", "cause": "Three independent drops, any one of which is sufficient: (1) the page builder read `w.GetOnChange()` in `buildTextBoxV3` **only**, so the property died between AST and model for the other five; (2) the legacy writer hardcoded `serializeClientAction(nil)` for TextArea/DatePicker/CheckBox/RadioButtons/DropDown; (3) for pluggable widgets `actionSourceForKey` matched only the bare keys `onClick`/`onChange`, but Mendix's Combobox names its slot **`onChangeEvent`**, so no action mapping was emitted — and the shipped `combobox.def.json`, which **overrides any .mpk-derived def**, had none either", "file": "`mdl/executor/cmd_pages_builder_v3_widgets.go` (`applyOnChangeV3`), `sdk/mpr/writer_widgets_input.go`, `mdl/executor/widget_defs.go` (`actionSourceForKey`), `sdk/widgets/definitions/combobox.def.json` + `modelsdk/widgets/definitions/combobox.def.json`, `mdl/executor/cmd_pages_describe_parse.go` + `_output.go`", "insight": "Route every input widget's OnChange through one helper rather than repeating the block, so the next widget added cannot forget it. Strip **one** `Event`/`Action` suffix before matching an action slot — narrowly: a Combobox also carries `onChangeFilterInputEvent` and `onChangeDatabaseEvent`, which have no MDL surface and must stay unmapped or one `OnChange:` writes three actions. A hand-written built-in `.def.json` beats the generator, so fixing the generator alone changes nothing for COMBOBOX/GALLERY/DATAGRID/filters — patch both, and put the mapping in **every** mode (modes are exclusive). Wire DESCRIBE at the same time: DESCRIBE is how a dropped property gets *found*, and it could only see this one on `textbox`. `dropdown` has no DESCRIBE case at all (separate gap). Repro `mdl-examples/bug-tests/widget-onchange-dropped.mdl`. **Sequel caught by CI:** mapping a slot also makes its storage key pass `allowedWidgetProperties`, so `onChangeEvent: …` became an accepted MDL keyword that `resolveMapping` never reads — the same silent drop one layer up. An `action` mapping is authorable by its **Source** only (`OnChange`/`OnClick`/`Action`), never by its PropertyKey; `addMappingNames` enforces that and `actionStorageKeys` reports the storage key with the spelling that works. FINDINGS #14", "refs": ["#14"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli exec` applies a script that `mxcli check` rejects with an error — e.g. a page written with an invalid widget property, which is then silently dropped, so the widget renders but does nothing", "cause": "`exec` ran no semantic checks at all. Parse errors stopped it; the ~24 `Validate*` checks lived inline in `cmd/mxcli/cmd_check.go` and had exactly one caller. \"Run check before exec\" was a convention nothing enforced, on a tool built for unattended agent use", "file": "`mdl/executor/validate_program.go` (the shared list), `cmd/mxcli/cmd_exec.go` (the gate), `cmd/mxcli/cmd_check.go`", "insight": "`executor.ValidateProgram` is now the single definition of what `check` checks, and `exec` refuses to run when it reports an **error** (warnings print and do not block). `--no-check` opts out. **A check wired into nothing is invisible** — it reports no violations and reads as a clean project — so `TestValidateProgram_WiresEveryWholeProgramValidator` asserts structurally that every exported `Validate*(prog *ast.Program, …)` is called from `ValidateProgram`; per-statement helpers take a statement and are excluded. When adding a check, add it to `ValidateProgram` and both commands get it"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check` reports **MDL003** *\"microflow returns X but not all code paths have a return statement\"* on a microflow that is correct and builds cleanly. Since `exec` began refusing scripts whose checks report an error, the script also will not run without `--no-check` — so a false positive became a hard block. Seven shipped `mdl-examples` scripts were in this state", "cause": "The microflow uses the documented `RETURNS T AS $Var` form and assigns `$Var` instead of writing an explicit `RETURN`. `buildFlowGraph` sets the final EndEvent's `ReturnValue` to `\"$\"+Var` **whenever the AS clause is present** (`cmd_microflows_builder_graph.go`), so the return is synthesized either way — that is what the clause is for. The check demanded a `RETURN` statement in the source on top of it", "file": "`mdl/executor/validate_microflow.go` (Check 5 in `microflowValidator.validate`)", "insight": "Skip MDL003 when `returnType.Variable != \"\"`, mirroring the builder's own condition exactly rather than inventing a second rule. **Verify against mxbuild, not intuition**: the flagged microflow builds with **0 errors** on 11.13.0, `describe microflow` renders the synthesized `return $Found;`, and the stored EndEvent carries a `ReturnValue` — three independent confirmations the check was wrong, not the script. Keep a companion test for the no-AS-clause case, or a fix that simply disables the rule passes. **Sweeping examples as a control**: exclude `*.test.mdl` (those are `mxcli test` files with `@test`/`@expect` blocks, unparseable by `check` by design) and `*.fail.mdl`, and diff failure SETS rather than counts", "rules": ["MDL003"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| A guard that walks a stored BSON document works on the **modelsdk** engine and is a **silent no-op on legacy** (or vice versa) — same project, same document, opposite behaviour. Here `checkNoQueuedCalls` refused a rewrite that would drop a task-queue binding under modelsdk, and let it through under `--engine legacy`, destroying the binding exactly as the guard existed to prevent | The two readers return **different Go shapes for the same BSON**: `modelsdk` yields `[]interface{}` for arrays, the legacy `mpr` reader yields **`bson.A`**. `bson.A` is a NAMED slice type (`type A []interface{}`), so a type switch `case []any:` does **not** match it and the walk never descends into `ObjectCollection.Objects` | `mdl/executor/validate_queued_calls.go` (`queuedCallTargets`, `storedQueueRetries`); the same blind spot exists in `mdl/backend/mcp/page.go`, `mdl/backend/mcp/page_mutator.go`, `mdl/executor/widget_sync_apply.go` | Add `case bson.A:` alongside `case []any:` in every raw-BSON walk. The house pattern already does this (`mdl/backend/bsonnav`, `mdl/catalog/builder_pages.go`, `mdl/xpathrefs/scan.go` and ~7 more) — the ones missing it are the outliers: `for f in $(grep -rln \"case \\[\\]any:\" --include=*.go mdl/); do grep -q \"bson.A\" $f \\|\\| echo $f; done`. **Test both shapes of the same document in one test**, not just the one your engine returns. **A unit test alone is not enough to find this**: it only surfaced by running the same command under `MXCLI_ENGINE=legacy` and diffing against modelsdk — engine parity has to be exercised, not assumed. Reported as FINDINGS #25 |", "refs": ["#25"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A generated loop/while box does not fit its contents: activities sit outside the container, or the box is far wider than what is in it. An explicit `@position` on a loop child moves the child but not the box", "cause": "The container's `Size` came from `measureStatementsSpan`, a pre-pass over the AST run BEFORE the body was built, so it was a function of statement COUNT alone. Varying only the children's positions changed nothing: 2 activities at x=150/310, at x=1500/2000 and at x=160/170 all produced `480;160`, and in the second case both children sat entirely outside their own container. Nothing catches it — the model carries no geometry rules, so `mx check` is silent", "file": "`mdl/executor/layout.go` (`containerBounds`, `fitContainerSize`), called from `addLoopStatement` / `addWhileStatement` in `cmd_microflows_builder_control.go`", "insight": "Size the box AFTER the body is built, from the real child bounding box (`Position ± Size/2`). Nesting needs no extra code — an inner loop is sized when its own `addLoopStatement` returns, so the outer measures a correct inner box. **Do NOT translate the children to fit**, however tempting: their positions round-trip through DESCRIBE as `@position`, so moving them makes a describe→exec cycle store different coordinates than it read, which under ADR-0008 turns a quiet re-run into a write. Grow the box instead. **Two measurement traps hit while verifying this.** A helper that sets an annotation via `ast.StatementAnnotations` is a silent no-op when the field is nil (it returns nil rather than allocating) — the explicit-`@position` test passed while testing nothing until the field was assigned directly. And an idempotence check over `mprcontents` proved blind because the re-run script began with `create module`/`create entity` and aborted at \"already exists\" before reaching the microflow; the `MXCLI_ALWAYS_WRITE=1` control is what exposed it, so never assert \"nothing changed\" without it. Repro `mdl-examples/bug-tests/container-autosize-884.mdl`. Issue #884 problem 1", "refs": ["#884"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `describe microflow` → `exec` round-trip moves the **StartEvent**: a Studio-Pro-authored flow whose start sat at `145;200` comes back at `100;200`, while every other coordinate in the flow survives exactly", "cause": "The start has no MDL statement to annotate and DESCRIBE cannot emit its position, so the builder always derives one — `(first annotated activity X) − spacing`, i.e. `260 − 160 = 100`. Studio Pro's `145` is not derivable from anything in the description", "file": "`mdl/executor/cmd_microflows_create.go` (`storedStartPosition`), `mdl/executor/cmd_microflows_builder.go` (`flowBuilder.startPosition`), `mdl/executor/cmd_microflows_builder_graph.go` (the StartEvent construction)", "insight": "Carry the position over from the microflow being replaced, the way the folder and the allowed module roles already are on CREATE OR MODIFY — read it off the stored document and let it win over the derived value. Nil on a fresh CREATE keeps the existing derivation, so only a rebuild of an existing flow is affected. Best-effort: a backend that cannot read the stored flow yields the derived placement rather than failing the statement. **Verify with the whole coordinate set, not just the start** — dump every `RelativeMiddlePoint` before and after and diff, or a fix that pins the start while shifting something else reads as success. Control: stub the `fb.startPosition` branch and the `100;200` drift returns. Issue #884 follow-up", "refs": ["#884"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create or replace` on a document whose module holds a same-named **excluded** twin edits the WRONG one — the live document keeps its old body and the script looks like a no-op — and the rewrite also clears the twin's `Excluded` flag, so a project that built at 0 errors fails **CE0122** \"Duplicate document name\". Also `describe` returns the excluded document's body", "cause": "Studio Pro's \"Exclude from project\" makes a document name non-unique: Mendix allows the duplicate as long as at most one is active (measured on 11.13.0 — excluded pair = 0 errors, both active = CE0122). Every by-name lookup took the FIRST match, so which document it hit depended on enumeration order; and every rebuild wrote `Excluded` from the AST default (`false`) instead of carrying the stored value. `@excluded` exists and round-trips through DESCRIBE, so absence of the annotation must mean \"the script does not say\", never \"make it active\"", "file": "`mdl/executor/excluded_docs.go` (`pickLive`) + the create paths: `cmd_microflows_create.go`, `cmd_nanoflows_create.go`, `cmd_pages_create_v3.go` (pages **and** snippets), `cmd_enumerations.go`, `cmd_queues.go`, `cmd_workflows_write.go`, `cmd_javaactions.go`, `cmd_javascript_actions_write.go`, `cmd_businessevents.go`, `cmd_published_rest.go`, `cmd_dbconnection.go`, `cmd_datatransformer.go`, `cmd_import_mappings.go`, `cmd_export_mappings.go`, `cmd_jsonstructures.go`, `cmd_imagecollections.go`, `cmd_agenteditor_*.go`, plus `cmd_microflows_show.go` for DESCRIBE", "insight": "Route every by-name lookup through `pickLive` (live match wins; an all-excluded set still resolves to the first, so lookups do not start reporting \"not found\") and carry the stored flag next to the ID/roles each path already preserves. Four types had **no** `Excluded` field to carry — `model.Enumeration`, `types.JavaAction`, `types.ImageCollection`, `pages.Snippet` — so the field had to be added and populated in BOTH engines' readers (`TestFieldCountDrift` catches the `mdl/types` half and requires `convert.go` + the expected counts to be updated). Backends that hardcoded `SetExcluded(false)` (enumeration, snippet, image collection) are the same bug wearing a different hat. **Measure, do not read**: queues looked correct (their reader and writer both carry the flag) and still dropped it, because the executor built a fresh struct — the matrix run is what found it. Pages/snippets additionally collected ALL name matches and DELETED the extras, which destroyed the excluded twin outright. Tests `TestPickLive`, `TestCreateOrModifyMicroflow_PreservesStoredExclusion`, `TestCreateOrModifyMicroflow_TargetsLiveTwin` (both fail with the reported symptoms when the fix is reverted); fixture `mdl-examples/bug-tests/914-excluded-document-preserved.mdl`. Issue #914", "refs": ["#914"], "ce": ["CE0122"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check` reports `✓ Syntax OK`, `exec` writes the microflow, and the defect appears only when a human opens Studio Pro's Errors pane: CE0038 on a value-less `declare`, CE0068 on a `return` inside a loop, CE0111 on `declare $X` followed by `$X = call microflow …`", "cause": "Nothing in the MDL rule set covered them — each is a Mendix consistency rule with no MDL counterpart. CE0111's real scope is far wider than the reported case: a microflow's variable namespace is **flat**, so parameters, loop iterators and every activity output share it, and neither a branch nor a loop body opens a scope (all seven combinations measured on mxbuild 11.6.6)", "file": "`mdl/executor/validate_microflow_ce_gaps.go` (MDL061/062/063), wired from `validate_microflow.go`; fixtures `mdl-examples/bug-tests/893-check-gaps-*.mdl`", "insight": "Error severity alone closes the gap — `exec` pre-flights the whole script and refuses with nothing written; they are deliberately kept OUT of `execEnforcedMicroflowRules` so `--no-check` still works. **Run any new rule over `mdl-examples/` before wiring it up**: this one hit 4 of 374 files and 3 were FALSE positives, because the rule reads the AST while the outcome depends on what the BUILDER emits — `while true` becomes an ExclusiveMerge back-edge and not a loop object (#350), `returns T as $Var` routes the End event elsewhere, `set $x = contains($str,$str)` parses as a ListOperationStmt that the builder rewrites to a Change Variable (ledger #53/#63), and an `@excluded` document is never checked by mxbuild at all. The 4th was a genuine CE0111 in a shipped example. The shared predicate `stringOverloadedListOp` keeps rule and builder from drifting. Issue #893 items 1/2/6", "refs": ["#350", "#53", "#63", "#893"], "ce": ["CE0038", "CE0068", "CE0111"], "rules": ["MDL061"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| `DESCRIBE IMPORT MAPPING` output does not reproduce the script that made it: `Total = total` comes back as `Total = Total`, an array binding as `= ItemItem`, `LineId = id` as `LineId = _id` — and the output cannot be re-run at all, failing with \"import mapping already exists\". Export mappings identically (unreported) | DESCRIBE printed the element's **ExposedName** (Mendix's display name — capitalised initial, `Item` suffix on an array's item object) instead of the raw JSON key from `JsonPath`, and emitted a bare `create` header where every other DESCRIBE emits `create or modify` | `mdl/executor/cmd_import_mappings.go` (`mappingMemberName`, the four print sites, the header) + `cmd_export_mappings.go` (same four + header) | Print the raw key derived from `JsonPath` — strip a trailing `\\|(Object)` first, because an array's mapping element sits at the ITEM object while the script addressed the array (that suffix is what produced `ItemItem`). Fall back to ExposedName when there is no JsonPath (XML-schema / message-definition mappings have none). Safe by construction: the raw path is `jsonSchemaIndex.resolve`'s FIRST lookup, so it cannot regress #882. **Do NOT \"fix\" ExposedName itself** — the capitalisation is Mendix's own, confirmed against a Studio Pro-authored document in the blank app (`ExposedName \"Uuid\"` vs `Path \"(Object)|uuid\"`); rewriting it would diverge from Studio Pro. The `Item` suffix could NOT be confirmed the same way (a blank app has no Studio Pro array structure) and was left alone — with a separate `ExposedItemName` property in the BSON, that is worth checking against a marketplace module before anyone touches storage. Note the issue's framing was half wrong: the mapping DID round-trip semantically (re-executing the old output rebuilt byte-identical JsonPaths), so this was a text/diff defect, not a broken mapping — measure before agreeing with a title. Tests `TestMappingMemberName`, `TestDescribe{Import,Export}Mapping_RoundTripsMemberNames` (fail with the reported symptoms when reverted); two existing header assertions needed updating with the intentional change; fixture `mdl-examples/bug-tests/915-mapping-describe-roundtrip.mdl` is a DESCRIBE fixed point. Issue #915 |", "refs": ["#882", "#915"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A widget property is accepted by `mxcli check`, written by `exec`, and does nothing: a pluggable widget's `imageUrl: '{1}', contentparams: [...]` builds as **CE0720** (\"place holder index greater than parameter count\"), and `editable:` on a button silently leaves it enabled with no warning at all", "cause": "Both allow-lists are widget-type AGNOSTIC. `isBuiltinPropName` (`widget_engine.go`) is ONE flat list holding both `ContentParams` and `Editable`, and it backs both MDL-WIDGET01 (pluggable) and MDL-WIDGET07 (static): it answers \"is this a real MDL property name anywhere\", and both validators read it as \"is this valid on THIS widget\". The engine then only acts on each for the widget kinds that support it", "file": "`mdl/executor/widget_engine.go` (`numericTemplatePlaceholderRe`, the TextTemplate case), `mdl/backend/mutation.go` + `widgetobj/builder.go` + `mcp/widget.go` (`SetTextTemplateWithClientParams`), rules in `validate_widget_editability.go` (MDL-WIDGET20) and `validate_widget_contentparams.go` (MDL-WIDGET21)", "insight": "For the template: the engine took the parameters path only for mxcli's `{AttrName}` spelling, so Mendix's own numeric `{1}` had no route and the template was written with `Parameters=[2]` (empty). A `dynamictext` with identical syntax is the control that localises it. For editability: **check the metamodel before implementing** — `PagesActionButton` has `ConditionalVisibilitySettings` but no `Editability`, and exactly 11 Pages types have editability (10 inputs + DataView) against 14 button types with none, so the request was impossible and the fix is to WARN. Both MDL spellings must be caught: `editable:` lowers to `Editable`, the bracket form `editable: [expr]` to **`EditableIf`** — dump the parsed `w.Properties` rather than assuming the key. Neither rule can be a `.fail.mdl`: they are warnings, `check` exits 0, and the fixture would report \"negative test unexpectedly passed\". Issue #928", "refs": ["#928"], "ce": ["CE0720"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`import from mapping M.IMM($json)` builds cleanly and then throws at runtime: `MicroflowException: key not found: Path(QName(None,),None,)` at `com.mendix.integration.importer.mapping.MappingCache.storeValueMappingElement`. Reported as \"import mapping documents are broken / JSON path resolution is broken in mxcli's serialization\"", "cause": "**Not the mapping document — the ACTIVITY.** The Range and the result variable's cardinality are separate axes (#881), but an **unauthored** range set neither pointer, so `ForceSingleOccurrence` and `ConstantRange.SingleObject` both fell back to `SingleObject` — true for an object-rooted mapping. That is Studio Pro's **First** (\"take one of a list\"), a different activity. Studio Pro writes **both flags false** for a plain single-object import and expresses \"one object\" solely through `VariableType=ObjectType`. `all` and `first` and limit/offset all set the pointers explicitly, so only the **bare** form — the one every doc and example uses — was broken", "file": "`mdl/executor/cmd_microflows_builder_calls.go` (`addImportFromMappingAction`: add the `else` branch writing both pointers false); tests `mdl/executor/cmd_microflows_import_range_test.go`; fixture `mdl-examples/bug-tests/import-mapping-single-object-runtime.mdl`", "insight": "**A valid model that fails only at runtime**: `mxcli check`, `mx check` (0 errors) and mxbuild all pass — the document is well-formed, it just means something else. The repo had **no runtime coverage of import mappings at all**; every existing test stopped at `mx check`, which is exactly the gap `.claude/skills/verify-in-runtime.md` exists for. **Get a Studio Pro-authored app and cross the variables** — `ako/TestApp` settled this in minutes after days of BSON diffing: run the SP microflow and an mxcli one *in the same boot*, then cross them (mxcli microflow → SP mapping, and mxcli mapping → SP structure+entity). The cross-test is what separated the activity from the document; an \"isolation\" where BOTH artifacts are mxcli's isolates nothing, and I asserted the wrong culprit twice before running it. **A control is only evidence if its harness is known good** — an earlier run had Studio Pro's own mapping failing too, which \"exonerated\" mxcli, but the probe app was independently broken. **Diff the ENCODING, not just the values**: `bson.M` loses key order and non-canonical extended JSON hides `int32` vs `int64`; dump with `MarshalExtJSONIndent(doc, true, …)` and compare raw key order via file order. Four differences found that way were all real and none causal (int32-vs-int64 on 14 numerics, root `MinOccurs` 0 vs 1, missing `MessageDefinition2`, blanked `OriginalValue`) — chasing document differences was the wrong tree entirely. Also: #882's \"Studio Pro leaves `OriginalValue` empty\" is contradicted by a second app, so it was generalised from too small a sample", "refs": ["#881", "#882"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`Body: file from $Doc` on a consumed REST operation sends the literal text `$Doc` instead of the file. `mxcli check` passes, `mx check` reports 0 errors, the request returns **HTTP 200** — and the payload is 4 bytes where the document held 8090", "cause": "Mendix has **no binary request body**. `generated/metamodel` has exactly three: `Rest$JsonBody`, `Rest$StringBody`, `Rest$ImplicitMappingBody`. Both engines folded `FILE` into the `TEMPLATE` branch and wrote a `Rest$StringBody` whose `ValueTemplate` is the **expression text** — `mdl/backend/modelsdk/consumed_rest_write.go:218` (default engine) and `sdk/mpr/writer_rest.go:250` (legacy). `describe` shows it straight back as `Body: template '$Doc'`, so the round trip looks consistent", "file": "`mdl/executor/cmd_rest_clients.go` (`checkFileRequestBody`, called from `buildRestClientOperation`); `mdl/executor/validate_rest_mapping.go` (MDL-REST02); tests `mdl/executor/cmd_rest_clients_file_body_test.go`; fixture `mdl-examples/bug-tests/rest-file-request-body.fail.mdl`", "insight": "**Refuse; do not write a different type** — there is no correct type for a CONSUMED OPERATION body. Binary POST is expressible, on the microflow REST CALL activity (`Microflows$BinaryRequestHandling`), which is where the refusal now points. A silent downgrade that returns 200 is the worst outcome available: every signal a user or an agent checks says success. Same shape as MDL-REST01, and one function is called from **both** the check pass and exec so `mxcli check` and `mxcli exec` cannot disagree. **Fix both engines, not just the one the reporter cited** — the report named only `sdk/mpr`, but the default engine is `modelsdk` and had the identical branch; a legacy-only fix would have left the default path broken. Keep the refusal **narrow**: `Response: file as $Doc` downloads correctly and is untouched (its own defect is a `CHANGE` on the result, which is separate). Judge an upload by what the server **echoes** (httpbingo `/post` returns `Content-Length` and the body), never by \"the call did not throw\" — a 200 proved nothing here"}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| A pluggable widget authored by MDL passes `mxcli check` and then fails **CE0463** \"the definition of this widget has changed\" on `mx check`, so `mx create-module-package` refuses the whole module. mxcli's own MDL-WIDGET10 warns about several properties — all of them harmless — and says nothing about the one that breaks the build | mxbuild evaluates the widget's compiled `editorConfig.js#getProperties()`, and a property that function **hides** must hold its **default** value. mxcli lifted only the top-level `hidePropertyIn`/`hidePropertiesIn` calls: `hideNestedPropertiesIn` and the 5-argument nested form were skipped by design (#574 Phase 1), which is exactly where the Accordion hides its group's `initialCollapsedState`/`initiallyCollapsed`. Two further gaps in the same extractor: a comparison guard read from a `\\|\\|` connector or a ternary's ELSE branch was recorded with the WRONG polarity (`eq` where the code means `ne`), and the shipped compilation is `forEach((function(n,o){…}))` — a double paren the callback-parameter regex read as the parameter name, so every nested condition was scoped to the widget instead of the item | `mdl/executor/editorconfig_extract.go` (`hideTargetKeys`, `parseGuard`, `enclosingForEachParam`); `mdl/executor/validate_widget_hidden.go` (`validateWidgetItemVisibility`, `hiddenPropertySeverity`); `mdl/types/widget_visibility.go` (`ListPropertyKey`, `Scope`); bump `WidgetDefGeneratorVersion` in `mdl/executor/widget_engine.go`; tests `mdl/executor/editorconfig_nested_test.go`, `mdl/executor/validate_widget_hidden_test.go`; fixture `mdl-examples/bug-tests/931-accordion-hidden-property.mdl` | **Split the severity on the VALUE, not the property** — the same hidden property is harmless at its default (Studio Pro ignores it) and a build failure otherwise, which is why four warnings fired on defaults while the two real failures were silent. **Measure the rule instead of reading the JS**: a matrix of eight one-property variants through `mx check` (`collapsible` on/off × default/non-default) pinned it in minutes and became the test oracle — mxcli's verdict now matches mxbuild on all nine measured cases. Note `\"web\" !== platform` evaluates TRUE under mxbuild, so guards behind it never fire; the conjunct rule below is what makes the Accordion's compound guard liftable anyway. **`X && Y \\|\\| hide(…)` soundly implies \"hide when Y falsy\"** whatever X is, so a compound guard with one unresolvable operand is still liftable — but `X && Y && hide(…)` is not (hiding needs both), and lifting it would over-fire. **Widget defs are cached per project** in `.mxcli/widgets/*.def.json`; a rules change is invisible until `WidgetDefGeneratorVersion` is bumped, and the refresh happens during `exec`, so the run that regenerates them still validates against the old set. Issue mendixlabs/mxcli#931 |", "refs": ["#574", "mendixlabs/mxcli#931"], "ce": ["CE0463"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "An `else` branch on a `split type` \"never fires\" — the author expects it to catch object types with no `case`, and it only runs when the object is **null**. Often surfaces as CE0090 \"The '<Entity>' value should be configured for an outgoing flow\" on a split that visibly has an `else`", "cause": "Not a bug: `else` on an inheritance split IS the `(empty)` flow (a null object), not a default. Mendix requires a separate outgoing flow for **every** concrete subtype and the base entity; an `else` contributes nothing to that coverage. The keyword is misleading, which is the defect", "file": "`mdl/executor/cmd_microflows_builder_actions.go` (the `addBranch(\"\", s.ElseBody)` call and its CE0089/CE0090 comment)", "insight": "Add a `case` for every subtype **and** the base entity, keeping the `else`. Do NOT drop the `else` to \"fix\" CE0090 — that flow is load-bearing and its absence is CE0089. Measured on mxbuild 11.13.0: `case Dog` + `else` → CE0090 for `Cat` and `Animal`; every type cased, `else` kept → 0 errors. The branch is now spelled `when (empty) then`, which says what it does; `else` still parses and warns **MDL065**. Background in [the #913 report](../../docs/12-bug-reports/2026-08-20-issue-913-split-statement-syntax.md)", "refs": ["#913"], "ce": ["CE0089", "CE0090"], "rules": ["MDL065"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE microflow` output for a split cannot be read: a branch body sits at the SAME column as its `when`/`case` keyword, so a nested `if`'s `else` lands exactly where a case branch would — in output where `else` on a `case` is an MDL008 error. The enum split and the type split are wrong in OPPOSITE directions (enum indents the branch but not the body; type indents the body but not the branch), and `if/else` is right", "cause": "Both emitters wrote the branch keyword at `indentStr+\"  \"` and then traversed the body at `indent+1` — the same column. No test caught it because `assertLineContains` matches substrings and never sees leading whitespace", "file": "`mdl/executor/cmd_microflows_show_helpers.go` (`emitEnumSplitStatement`, `emitInheritanceSplitStatement`) **and** `mdl/executor/cmd_diff_mdl.go` (`microflowStatementToMDL`)", "insight": "Traverse branch bodies at `indent+2`. **There are two MDL emitters, not one** — the diff renderer had the identical bug and is only found by grepping for the pattern rather than fixing the file the report names. Prove it with the control: revert one `indent+2` and the test must fail with `branch body indent = 4, want 6`; a test written only against fixed code detects nothing. Test `TestSplitBranchBodiesIndentFromTheirBranchKeyword` (includes an `if is the reference` sub-test, so the splits follow `if` rather than a hardcoded number)", "rules": ["MDL008"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`CREATE OR MODIFY … FOLDER 'x'` on a document that already exists reports success (\"Modified json structure: …\") and the document does not move. The folder itself *does* appear, empty, which makes it look like a partial write rather than a no-op. Reported for JSON structures and mappings", "cause": "Not doctype-specific — **every** doctype with a FOLDER clause did this. A document's folder is its unit's `ContainerID`, a column in the `Unit` row, and every `Update*` on both engines rewrites only the unit's *contents*. So the handlers resolved the folder, stored it on the model object, and had it dropped one layer down. `resolveFolder` creates missing folders as a side effect, which is where the empty folder comes from. The typed `Move*` methods that do reparent were only ever called from `cmd_move.go` / `cmd_folders.go`; `MoveImportMapping` and `MoveExportMapping` existed on the interface, both engines and the mock, and **nothing called them**", "file": "`mdl/executor/document_placement.go` (new: `resolveRequestedFolder` + `applyDocumentFolder`), wired into every CREATE OR MODIFY handler that resolves a folder (`cmd_jsonstructures.go`, `cmd_microflows_create.go`, `cmd_nanoflows_create.go`, `cmd_enumerations.go`, `cmd_constants.go`, `cmd_pages_create_v3.go`, `cmd_odata.go` ×2, `cmd_published_rest.go`, `cmd_businessevents.go`, `cmd_rest_clients.go` ×2); primitive in `modelsdk/mpr/writer_core.go` (`MoveUnit`) + `sdk/mpr/writer_domainmodel.go` (`moveUnitByID`); interface `mdl/backend/placement.go`", "insight": "Fix the **class**, with one type-agnostic `MoveDocument(unitID, containerID)` on the backend, not a `Move<Doctype>` each — placement is the same row update whatever the document is, and a per-doctype method means the next document type inherits the bug by not having one written for it. **The counting is half the fix**: a move changes no byte of the document, so it is invisible to content-based no-op elision (ADR-0008) — without `writesOffered`/`writesLanded` on the row update, `ReportMutation` calls a real move \"Unchanged\", and without the equality check re-running an in-sync script dirties the `.mpr`. Both directions have controls (strip either and `TestMoveDocumentPersistsAndIsIdempotent` fails). **The control that decides fix-vs-new-bug**: an omitted FOLDER must leave placement alone. `resolveFolder(\"\")` answers with the *module root*, so a handler that passes it through unfiles every foldered document on the next `CREATE OR MODIFY` — far worse than the no-op. `resolveRequestedFolder` returns `\"\"` for \"not asked\" and `applyDocumentFolder` ignores `\"\"`, so the distinction cannot be forgotten per-site. Doctypes rewritten as **delete+create** (snippets, rest clients) had the *inverse* bug already live — they really do re-apply the container, so a silent statement filed them into the module root; they need `existingContainerID` carried forward, not a move. **Diagnose against storage, not mxcli's own reads** (cf. #722/Bug 12b, where the same symptom was a read illusion): diff `Documents in Modules` / `Documents in Folders` counts from the raw `Unit` table, with an explicit `MOVE` of a supported doctype as the positive control. Repro `mdl-examples/bug-tests/932-folder-on-modify.mdl`; tests `mdl/executor/document_placement_test.go`, `mdl/backend/modelsdk/placement_test.go`. Issue #932", "refs": ["#722", "#932"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE PAGE` renders a List View as though it had one plain body, and re-executing that output **destroys** the page's specialization templates — measured on ako/TestApp: 4 templates before a describe → exec round trip, 0 after, with `mx check` reporting **0 errors both times**", "cause": "`Forms$ListViewTemplate` was write-only and entity-less across the whole stack. `parseListViewContent` read only `w[\"Widgets\"]`, so DESCRIBE never saw the sibling `Templates` array; the typed parser never populated `ListView.Templates` either, so a rebuild wrote zero; `sdk/pages.ListViewTemplate` had no entity field at all; and `modelsdk/gen` bound the entity under the SDK name `Specialization` where every Studio Pro document stores `Entity`", "file": "`mdl/executor/cmd_pages_describe_parse.go` (`parseListViewTemplates`), `cmd_pages_describe_output.go`, `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildListViewTemplateV3`), `sdk/pages/pages_widgets_data.go`, `sdk/mpr/writer_widgets_display.go`, `modelsdk/gen/pages/types.go`", "insight": "Add the MDL surface (`template for Module.Entity { … }`) and read the array on the way back out. Four traps. (1) **`modelsdk/gen` is wrong about the key** — `Entity`, not `Specialization`; patch `init<Type>` AND `InitFromRaw`, per the STORAGE-NAME OVERRIDE rule. (2) **Order is authored, not derived** — TestApp's is Bus, Truck, Car, SUV, so a DESCRIBE that sorted would not round-trip. (3) **Inside a template the context object is the specialization**, not the list view's entity, or an attribute only the specialization has fails to resolve. (4) **`FOR` is in the parser's `keyword` rule**, so the new alternative must come FIRST in `widgetV3` or it collides with Gallery's pre-existing `template <name>` content slot — which is a different construct and must keep working. **Generalisable**: `mx check` is no signal for a dropped container — the document stays valid, it just holds less. Control on a **round trip through the real project** with the previous binary (`4 → 0`), not on the validator. mendixlabs/mxcli#940", "refs": ["mendixlabs/mxcli#940"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`describe page` emits MDL that will not re-execute for any non-database datasource. Three shapes: a chart series bound to a microflow comes back as `DataSource: database from Module.TheMicroflow` (→ `entity not found: Module.TheMicroflow`); a pluggable list whose source carries no entity comes back as `DataSource: database from ` with an empty slot (→ `entity not found: from`, the parser reading `from` as the entity); and a **gallery** bound over an association loses its datasource **entirely** while a **listview** bound the same way keeps it", "cause": "One cause, three faces: the datasource switch was copied per widget family — five copies on the read side (`extractDataViewDataSource`, `extractListViewDataSource`, `extractDataGrid2DataSource`, `extractGalleryDataSource`, `parseCustomWidgetDataSource`) and six on the write side — and they drifted apart. The pluggable read copy, which every Gallery/DataGrid2/chart goes through, knew `Forms$MicroflowSource` and `Forms$NanoflowSource` but **not** `Forms$AssociationSource`, `Forms$ListenTargetSource` or the context forms, so those were dropped; its `CustomWidgets$CustomWidgetXPathSource` case returned `{database, \"\"}` unconditionally where its own near-twin guarded on a non-empty reference; and the object-list item emitter had **no type switch at all**", "file": "new `mdl/executor/cmd_pages_describe_datasource.go` (`parseDataSource`, `dataSourceExpr`, `appendDataSourceProp`); the five readers in `cmd_pages_describe_parse.go` / `cmd_pages_describe_pluggable.go` now delegate; all six emit sites in `cmd_pages_describe_output.go` go through one renderer", "insight": "**One reader and one renderer, because a datasource means the same thing wherever it sits.** The per-widget copies were the defect, not the individual missing cases — patching the pluggable switch alone would have left five copies to drift again. Take the `$Type` set from `generated/metamodel`'s `DataSource` interface rather than from the copies. **Read sorting from whichever shape is present** (`SortBar.SortItems` for grid-like sources, `Sort.Paths` for list views) so the reader stays container-agnostic. **Distinguish \"unknown type\" from \"known type, empty payload\"**: the first is mxcli's gap and is reported as a `-- DataSource (…) has no MDL spelling` comment (never dropped, never guessed into a `database from` that cannot re-execute); the second is the model's own incompleteness and yields nil, which an existing test deliberately pinned (`TestExtractDataViewDataSource_ListenTargetSourceEmptyTarget`) — collapsing the two broke it. **Verify with a whole-project describe diff, not a unit test alone**: running `describe page` over every page before and after showed the four intended changes and nothing else — and it surfaced two WHERE/SORT clauses the combobox emitter had been silently dropping, which no unit test would have found. Controls: stub `dataSourceExpr`'s switch to `\"database\"` and the tests report the issue's own string, `got \"database from Mod.DS_GetItems\"`; drop the association/selection cases and they report `datasource was dropped`. **Note what the fix does NOT fix**: 10 of 21 pages in the probe project still fail `describe`→`check`, identically before and after — unquoted XPath containing `[`, duplicate generated widget names, context errors. Those are separate round-trip gaps; counting the failures on both sides is what tells them apart from a regression. **Generalisable measurement trap, and it invalidated this fix's first control**: copying a project for an `mx check` baseline with `cp rp.mpr mprcontents/` is NOT a copy of the project. The theme lives in `theme/`, so a copy without it reports **924 CE6083** \"Design property … is not supported by your theme\" plus CE0535 for the missing `widgets/` — a baseline of ~950 errors where the real project has **0**. Before/after still compares equal, so the check looks like it passed, but it has no power: a genuine new error is one line in a thousand and the theme-dependent checks never ran at all. Copy the whole directory (`cp -r project/. dest/`) and expect the baseline to be 0 — a non-zero baseline on a healthy project means the copy is incomplete, not that the project is broken. Repro `mdl-examples/bug-tests/941-describe-page-datasources.mdl`; tests `mdl/executor/cmd_pages_describe_datasource_test.go`. Issue #941", "refs": ["#941"], "ce": ["CE0535", "CE6083"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE PAGE` output that **used to parse stops parsing** after a fix that restores a WHERE clause — reported against stock `Administration.Account_New`, which every project from the Mendix template carries", "cause": "Two older gaps the restored clause collided with. The constraint was emitted **raw** (`expr += \" where \" + xpath`), so a stored XPath carrying an inner predicate — `System.grantableRoles[reversed()]/…` — ended the MDL `expression` parse at the `[`. The grammar takes either a bare expression or a bracketed `xpathConstraint`, and only the second is safe for arbitrary XPath. The same six lines also stripped the outer brackets by testing the first and last byte, turning `[a][b]` into `a][b`, and guarded on `strings.Trim(s, \"\")` — an empty cutset trims nothing, so a whitespace-only constraint emitted a bare `where`", "file": "`mdl/executor/cmd_pages_describe_datasource.go` (`xpathConstraintClause`)", "insight": "**Emit the bracketed production always, and stop deciding.** The bare form reads better but parses only for simple comparisons, and \"is this XPath also a valid MDL expression\" is not a question an emitter can answer — a bracketed group is accepted for every constraint. Reuse `visitor.SplitXPathPredicateGroups` (the quote- and nesting-aware splitter written for #772) rather than keeping a second, simpler copy: the naive strip is exactly the bug that helper exists to prevent. **Measure the round trip as a SET, not a count.** The claim this regression contradicted came from counting failing pages before and after, seeing 10 both times, and concluding nothing had changed — but an equal count hides a page flipping each way, and here a template page flipped from parse to fail while the total held. `join` the pass-sets: `join <(grep PASS before) <(grep FAIL after)` names the regressions directly. Control: revert the bracketing and `Account_New` stops parsing again. Reported in mxcli-formula1 §57.1/§57.3", "refs": ["#772"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A widget datasource bound to a microflow **loses its arguments** through `describe`: `microflow Mod.DS(Race: $Race)` describes as `microflow Mod.DS`, and replaying that description fails the build with **CE1571** \"No argument has been selected for parameter 'Race' and no default is available\" — the very error #835 fixed on the write side. `check --references` calls the argument-less form valid, so nothing catches it before mxbuild", "cause": "The write side stores the mappings correctly; **no describe path ever read them**. Not confined to pluggable widgets — a plain `dataview` loses them too. Older than #941, which merely printed the whole line wrong so the loss hid behind a larger bug", "file": "`mdl/executor/cmd_pages_describe_datasource.go` (`flowSourceArgs`, and the `case \"microflow\", \"nanoflow\"` renderer)", "insight": "Storage puts the bindings in `<Flow>Settings.ParameterMappings`, each `{Parameter, Expression}` behind typed-array marker 3, with **Parameter qualified by the flow** (`Mod.DS_Filtered.Term`) while MDL names the parameter alone — the flow is already left of the parentheses. **Strip that prefix by matching the flow's own qualified name, not by cutting at the last dot**: a document storing the name bare would otherwise lose its first segment. The value is in `Expression` for both a variable ref and a literal; `Variable` is the older spelling and is honoured when present. A parameterless flow must render **without** parentheses — the grammar makes the list optional and empty parens would churn every existing description. **Get the BSON shape from a real unit, not from the writers**: the two serializers here disagree in spelling (gen's `SetParameterQualifiedName` vs legacy's `Parameter`), and only a dump settles which key is on disk. Verify by replaying a description and counting CE1571 (4 → 0 on a two-widget page), not by eyeballing the text. Reported in mxcli-formula1 §57.2; same family as §39, where `SHOW_PAGE` drops `(Race: $currentObject)`", "refs": ["#835", "#941"], "ce": ["CE1571"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`use building block X (datasource: …)` starts failing with \"datasource override supplied, but the block has no datasource widget to rebind\" — on both engines, for a stock Atlas block, immediately after a fix that made DESCRIBE stop emitting malformed datasources", "cause": "The rebind expands the block by **re-rendering it to MDL through the describe emitter and re-parsing that text**, then looked for a widget already carrying a `DataSource` property. A reusable block is a *template*: its datasource is unbound. That used to render as the malformed `DataSource: database from ,` — the exact output #941 fixed — and the re-parse turned it into a `DataSource` property, so the rebind found its target. Emitting nothing for an empty datasource, which is correct, left it with nothing to match", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`isDataSourceWidget`, and the `DataSourceOverride` branch)", "insight": "Match the target by **widget type — what can carry a datasource, not what does**. The sibling `ActionOverride` branch already did exactly this, and its comment says why: Atlas blocks \"ship placeholder buttons with no action\". Same fact about the same blocks; the datasource branch just hadn't learned it. **The generalisable shape**: a consumer that re-parses another component's *rendered output* silently depends on that output's bugs, so fixing a renderer can break something that never reads the model. Grep for callers of the emitter (`outputWidgetMDLV3` here) before changing what it emits — unit tests on the emitter cannot see this, and the failure surfaced only in the integration suite. Control: restore the property-based predicate and the stock-block rebind fails again. Tests `mdl/executor/cmd_pages_builder_bb_rebind_test.go`; CI repro `mdl-examples/doctype-tests/15c-fragment-bindings-examples.mdl`", "refs": ["#941"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `SHOW_PAGE` widget action **silently ignores an argument that is not the context object**: `action: show_page Mod.Detail(Car: $Other)` inside a data view bound to `$Car` opens the page with **`$Car`**. Nothing reports it — `mx check` is **0 errors**, the build is green, and `describe page` prints `(Car: $currentObject)`, so the description looks like a *diagnosis* of a lost mapping rather than an accurate report of a model that never held one", "cause": "mxcli stores a widget show-page action with an **empty** `ParameterMappings` array and lets Mendix infer the argument from the enclosing widget's context object. That part is deliberate and twice-confirmed — an explicit `Forms$PageParameterMapping` whose `Argument` is `$currentObject` is rejected as **CE0115** \"parameters do not match\" (#296, re-confirmed on mxbuild 11.12.1 for §56). The missing half was the case where the author names something *else*: the builder built `PageClientParameterMapping` objects and both engines dropped them on the floor (`formSettingsToGen` takes only the page name; the legacy writer hardcodes `bson.A{int32(2)}`)", "file": "`mdl/executor/cmd_pages_showpage_args.go` (new: `pageArgumentBindsContextObject`, `contextVarFor`, `validateShowPageArguments`); the guard in `cmd_pages_builder_v3.go`'s `case \"showPage\"`; `contextVarName` threaded through `cmd_pages_builder.go`, `cmd_pages_builder_v3_widgets.go`, `widget_engine.go`, `validate_widgets.go`", "insight": "**Refuse, don't author.** The instinct is to write the mapping the user asked for, but #296 already established that Mendix rejects an explicit one — so the only honest options are \"bind the context object\" or \"say no\", and silently doing the first while the author wrote the second is what caused the bug. **To refuse without false positives you need the context *variable*, not its entity.** `pb.entityContext` carries only `Module.Entity`, and both `$Car` and `$Other` have it — a type check cannot tell them apart. Track the name the data source gives the context object (`contextVarFor`: a `parameter` source names it, a database/association/microflow source leaves it `$currentObject`-only) and allow the argument when it matches either spelling. That keeps the **documented** form working — `create-page.md`'s `show_page Mod.EditPage(Product: $Product)` inside a data view on `$Product` is the arg-equals-context case — while catching only arguments that are provably discarded. **`mx check` is worthless as a control here** and that is the whole point of the bug: an inferred mapping is a *valid* mapping, so mxbuild reports 0 errors on the corrupted page. The control is the guard itself — stub `pageArgumentBindsContextObject` to `return true` and the probe writes silently again, describing as `$currentObject`. Mirrored at check time as **MDL-PAGEARG01** so the LSP and `mxcli check` catch it with no project, the same pairing as MDL-WIDGET09. **\"No context variable\" and \"context unknown\" are different states, and conflating them is a false positive that bites immediately**: `ALTER PAGE … SET Action = SHOW_PAGE P(Car: $Car) ON btnGo` builds the action against a *stored* page the pass never traverses, so `contextVarName` is empty for a reason that has nothing to do with the argument — the first cut refused that statement, which is correct code. A separate `contextKnown` flag, set only on entering a data-bound widget, keeps the guard to what it can prove; ALTER PAGE behaves exactly as it did before. Caught by trying the ALTER form by hand, not by any test in the suite. Found while verifying §39, whose *reported* half (DESCRIBE omitting the inferred mapping entirely) was already fixed by `4551a4e`", "refs": ["#296"], "ce": ["CE0115"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DROP ATTRIBUTE` succeeds, but Studio Pro / `mx check` reports **CE1613** \"The selected attribute 'Mod.Ent.Attr' no longer exists.\" at *Validation rule of entity 'Mod.Ent'*. The executor even prints `Removed 1 validation rule(s)`", "cause": "**Two independent bugs on the same statement, and each hides the other.** (1) The executor's cleanup compared `vr.AttributeID` against the dropped attribute's **element ID**, but a validation rule and a MemberAccess reference their attribute by **BY_NAME qualified name** (`Mod.Ent.Attr`) — both arrive in the same `model.ID` field, so the comparison matched nothing and every rule was kept. Both engines feed the qualified name (`sdk/mpr/parser_domainmodel.go` stores the string verbatim; `mdl/backend/modelsdk/domainmodel.go` says so in a comment). (2) With (1) fixed the rule was removed in memory and **still not written**: `entityToGen` only appends to a child list when it is non-empty, so a list emptied by the update stays *clean* and the codec passes the **stored raw bytes** through — the removal silently does not happen", "file": "`mdl/executor/cmd_entities.go` (`AlterEntityDropAttribute` cleanup) and `mdl/backend/modelsdk/domainmodel_alter.go` (`UpdateEntity`, the emptied-child-list loop)", "insight": "Match **both reference forms** (element ID *or* qualified name built as `Module.Entity.Attr`, exactly what `serializeValidationRule` writes), and dirty **every** emptied child list, not one at a time. The list bug already had a precedent — Indexes, ledger #39 — so `ValidationRules`, `Attributes`, `AccessRules` and `EventHandlers` are all covered in one loop rather than rediscovered one error code at a time. **The trap is that it only bites on the LAST member**: removing one of two rules dirties the list and works fine, so any two-member fixture passes against the broken writer — the `Attributes` case is worse than a dangling reference (dropping an entity's *only* attribute reported success and wrote nothing at all) and had gone unnoticed for the same reason. Index references really are element IDs (`AttributePointer`), which is why that one path always worked and makes the positive control. Verify with `mx check`, not the executor's own output: it reported `Removed 1 validation rule(s)` while CE1613 persisted. Repro `mdl-examples/bug-tests/drop-attribute-orphaned-validation-rule.mdl`. Reported in the banking-app feedback", "refs": ["#39"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A workflow that calls a microflow existing nowhere passes `mxcli check --references` with \"All references valid\" and is written by `exec` with exit 0; only native `mx check` catches it (**CE1613** \"The selected microflow ... no longer exists\"). The identical mistake inside a plain microflow body IS caught", "cause": "`validateWithContext`'s `CreateWorkflowStmt` case called only `validateWorkflowParameterMappings`, whose own comment defers a target that is not in the project to \"the missing-reference check\" — **which was never written**. `validateFlowBodyReferences` (which does catch it) is wired only to `CreateMicroflowStmt`/`CreateNanoflowStmt`. `AlterWorkflowStmt` had **no case at all** and fell to `default: skip validation`", "file": "`mdl/executor/validate_workflow_refs.go` (`validateWorkflowReferences`, `validateWorkflowStatementRefs`, `validateAlterWorkflowRefs`); `mdl/executor/validate.go` (both switch cases, `scriptContext.workflows`, `collectDefinitions`/`collectSingle`/`allNames`); `mdl/executor/helpers.go` (`buildWorkflowQualifiedNames`); exec-side guards in `cmd_workflows_write.go` + `cmd_alter_workflow.go`", "insight": "**The gap is never one reference kind** — probe them all before fixing. Here *every* reference in a workflow was unvalidated: call microflow, call workflow, user task page, targeting microflow, context entity, and the workflow's own module (checked for a microflow, not for a workflow — and `exec` auto-creates a module, so `check` was the only guard against a typo silently making one). **`check` and `exec` run different passes**: `check --references` runs `validateProgram`, `exec` does not, so a validator wired only into the switch leaves exec writing the broken model — the guard must ALSO be called from the statement handler, before `findOrCreateModule` (same shape as #833). Pass `nil` for the scriptContext there: exec applies statements one at a time, so an earlier statement's output is already in the project. **The real risk is false positives** — verify by diffing error counts against a baseline binary over every workflow script in `mdl-examples/`, with the referenced modules actually present, and exempt `System.*` (`isBuiltinModuleEntity`) or every built-in target is reported missing. Issue #943", "refs": ["#833", "#943"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`CREATE OR MODIFY ODATA CLIENT` reports `Unchanged OData client` after the contract file was refreshed from the running backend — `SHOW CONTRACT ENTITIES` keeps listing the old entity types, and the `CREATE OR MODIFY EXTERNAL ENTITIES` that follows imports the old shape with no warning. `DROP ODATA CLIENT` + recreate is the only way out, and it invalidates the client ID the existing external entities point at", "cause": "The modify branch updated every property **except the cached contract**. Only the create path fetched `$metadata`; `svc.Metadata` / `svc.MetadataHash` kept the snapshot taken when the client was first created. The same branch also stored `stmt.MetadataUrl` raw, skipping the `NormalizeURL` the create path applies, so a relative `./contracts/x.xml` ended up as a URL neither Studio Pro nor `fetchODataMetadata` can open", "file": "`mdl/executor/cmd_odata.go` (`refreshCachedMetadata`, `normalizeMetadataURL`, `contractSummary`, called from the `stmt.CreateOrModify` branch of `createODataClient`); test `mdl/executor/cmd_odata_metadata_refresh_test.go`; repro `mdl-examples/bug-tests/odata-client-stale-contract-on-modify.mdl`", "insight": "**Refresh from the *effective* URL, not the statement's** — a `CREATE OR MODIFY` that omits `MetadataUrl` still has to converge the cache, or the idiomatic re-run silently keeps the stale contract. **A failed fetch must keep what is cached** (warning, not error): losing a contract that was merely unreachable is worse than serving a stale one, and there is nothing to fall back on. **Leave `svc` untouched when the hash matches**, or ADR-0008 elision breaks and every re-run churns the document — the unchanged-contract control is what proves this, and it passes both before and after the fix, so it is the half of the test that keeps the other half honest. `ALTER ODATA CLIENT SET MetadataUrl` has the same staleness and is deliberately **not** fixed here: it carries no design-time credentials, so a blind re-fetch of an authenticated URL would warn where it used to be silent. `mx check` is no oracle for any of this — the stale project builds with 0 errors, because a client caching an old contract is perfectly valid"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A microflow rewritten by `CREATE OR MODIFY MICROFLOW` is drawn with its **StartEvent stranded** — every activity where the script asked, the start left behind, joined to its own first activity by a long mostly-empty line across the canvas. Reproduces on every rewrite, and copying a working script's `@position` pattern does not help", "cause": "The fix for the OPPOSITE report. #884 was a describe→exec round-trip MOVING a hand-placed start (145;200 → 100;200), fixed by carrying the stored position over on every rewrite; that then **pinned** the start of every rewritten flow, so it no longer followed activities the same script had just moved. Both reports are real and neither is answerable without asking where the stored value came from", "file": "`mdl/executor/cmd_microflows_start_position.go` (`authoredStartPosition`, `derivedStartPosition`, `startAnnotationLines`), `mdl/executor/cmd_microflows_create.go` (`storedStartPosition`), `mdl/executor/cmd_microflows_builder_graph.go` (StartEvent construction)", "insight": "Carry the stored position over **only when it is not where the layout would have put it** — a start at `first.X − spacing` on `first.Y` is mxcli's own arithmetic handed back and carries no intent, so re-derive it; anywhere else, a person put it there, so keep it. Add `@start(x, y)` on the first statement (the `@merge` precedent — it positions the other node with no statement of its own) so the position can be *stated* rather than inferred, and have DESCRIBE emit it **only for a non-derived start**, which is what makes the round-trip exact without pinning every described flow. **`mx check` is not the oracle, and neither is a green build**: the Mendix model carries no geometry rules, so a stranded start is a valid document — 0 errors on mxbuild 11.13.0 before and after. Verify by reading the coordinates back off the stored document. **Emit from BOTH describers**: `formatMicroflowActivities` and `formatMicroflowActivitiesWithSourceMap` are near-duplicates, and the first cut of this fix patched only the second, so `describe microflow` silently dropped the line. Controls: reverting the narrowing reproduces the stranded start, reverting the builder arm reproduces \"@start does nothing\", reverting either describer reproduces the lossy round-trip. Repro `mdl-examples/bug-tests/951-microflow-start-event-position.mdl`. Issue #951", "refs": ["#884", "#951"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`SPLIT TYPE … END SPLIT` followed by any statement draws that statement **on top of the merge** in Studio Pro, joined by a zero-length sequence flow, and the merge itself sits far to the right of the branches it joins (branches at x=720, merge at x=1480). `CASE` and `IF/ELSE` with the same graph shape lay out correctly. `mx check` reports 0 errors either way", "cause": "Two defects in `addStructuredInheritanceSplit`. (1) It ended with `fb.posX = mergeX` — the merge's own centre — where `addEnumSplit` steps to `mergeX + HorizontalSpacing/2` and `addIfStatement` to `mergeX + MergeSize + HorizontalSpacing/2`; three builders, three conventions, and the type split's was zero. (2) Branch width came from `measureStatements(appendInheritanceBodies(s))`, which concatenated every branch body into ONE list and measured it as a single left-to-right run — so the merge slid right by an activity-plus-spacing per **extra branch**, not per branch *width*. `layout.go`'s own `measureInheritanceSplitStatement` always took the max, so the builder disagreed with its measurer", "file": "`mdl/executor/cmd_microflows_builder_actions.go` (`addStructuredInheritanceSplit`; `appendInheritanceBodies` → `inheritanceBranchBodies`); tests `mdl/executor/cmd_microflows_builder_split_geometry_test.go`; repro `mdl-examples/bug-tests/953-split-type-merge-overlap.mdl`", "insight": "**Geometry is invisible to every automatic check below Studio Pro** — the model is valid, so `mx check` passes, the build passes, and `describe` output looks right until you read the coordinates. `describe` printing `@position`/`@merge` IS the headless oracle: diff those, don't open the modeler. **The split builders had zero positional coverage** before this (grep `Position` in the enum-split and inheritance-split tests: nothing), which is the same gap behind the loop-box sizing bugs #790 and #884. **Pick the IF convention, not the CASE one**: the constants are centre-to-centre for a 40px edge gap, and `CASE`'s `+HorizontalSpacing/2` leaves a following activity's left edge exactly touching the merge (measured: merge 890, activity 970, both edges at 910) — a lesser pre-existing nit deliberately left alone, because changing it re-lays-out every enum split ever written. **`@merge(x,y)` was not a workaround**: `fb.posX = mergeX` read the overridden value, so moving the merge by hand moved the stacked element with it. A fix needs a control that the neighbouring construct did NOT move — `TestEnumSplitGeometryIsUnchanged` — or \"the type split matches CASE now\" can be achieved by breaking CASE. Issue #953", "refs": ["#790", "#884", "#953"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check --references` prints \"Check passed!\" (exit 0) and `mxcli exec` then fails (exit 1) on the same script, over the order things are created *in the script* — with earlier statements already written, because exec is not transactional. exec's own message is already right (\"… is defined later in this script — move its create statement before this one\")", "cause": "`validateProgram` calls `sc.collectDefinitions(prog)` over the **whole program up front**, so every name in the script is \"defined\" for every statement and a forward reference is indistinguishable from a backward one. `annotateForwardRef` computes the diagnosis, but only in `ExecuteProgram`, *after* a statement has failed. `exec`'s pre-flight runs the package-level `ValidateProgram` (the no-project tier) and not the reference tier, so it was no safety net either", "file": "`mdl/executor/validate_definition_order.go` (`ValidateScriptDefinitionOrder`, MDL-ORDER01), wired into `mdl/executor/validate_program.go` beside `ValidateScriptPageOrder`; tests `mdl/executor/validate_definition_order_test.go`; repros `mdl-examples/bug-tests/955-forward-definition-order{,.fail,-tolerated,-or-modify-not-flagged}.mdl`", "insight": "Put it in the **no-project tier**, not under `--references`: that is what makes `exec`'s pre-flight refuse the script too, which turns a half-applied project into \"Nothing was written\" — the actual harm, and the part a `check`-only fix leaves in place. **Do not flag every forward reference**: measure which ones the executor resolves eagerly, because several do not fail — an entity's `EXTENDS`, `CALL JAVA ACTION`, `RETRIEVE … FROM`, and `CREATE <entity>` in a body all execute correctly with the definition after them (measured on 11.6.6), and a blanket rule rejects working scripts. **Only a plain CREATE later is sound with no project** (the MDL-PAGE01 argument: a plain CREATE asserts the document is absent, so the earlier reference could not have resolved against the project either); a later `CREATE OR MODIFY` fails exec just the same but cannot be judged without `-p`, and is deliberately left as known residue. Key by **kind as well as name** — Mendix namespaces documents by type — and skip `at == i` or a recursive microflow call reports itself. A bare `Module.Name` written as a type lands in `EnumRef` whether it means an entity or an enumeration (the TypeEnumeration/TypeEntity ambiguity), so accept both kinds unless `ExplicitEnum`. **`exec` exit 0 is not proof a forward reference is safe** — describe the result and check the reference actually got wired before adding it to the tolerated list. Regression probe that matters: run `check` over all of `mdl-examples/` and expect **zero** new findings (it found exactly one, a fixture whose GRANT genuinely preceded its entity). Issue #955", "refs": ["#955"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A pluggable widget's `onClick:` / `OnChange:` is a **one-way write**: the action lands in the `.mxunit` and builds at 0 errors, but `describe page` omits it, so describe→exec deletes the wiring. Or `OnChange:` is refused outright by **MDL-WIDGET01** with the self-contradicting *\"property `OnChange` is the widget's internal storage name … use `OnChange:` instead\"*", "cause": "A widget's **storage key is not MDL's name** for the slot, and only the writer knew. Mendix's own widgets suffix theirs — BadgeButton stores `onClickEvent`, HeatMap `onClickAction`, Combobox `onChangeEvent` — while Slider/RangeSlider/StarRating store the bare `onChange`. `actionSourceForKey` strips one `Event`/`Action` suffix (ledger #14); the reader looked up the literal string `\"onClick\"`, the generic describe path read no OnChange at all, and `OnChange` was missing from `isBuiltinPropName` (where `Action` was present) so MDL's own spelling collided with the storage-name check", "file": "`mdl/executor/cmd_pages_describe_pluggable.go` (`customWidgetActionForSource`), `mdl/executor/cmd_pages_describe_parse.go` (both custom-widget branches), `mdl/executor/cmd_pages_describe_output.go` (the generic pluggable branch condition + emission), `mdl/executor/widget_engine.go` (`isBuiltinPropName`)", "insight": "Resolve the stored key **through `actionSourceForKey`** rather than a second copy of the rule, so the reader cannot drift from the writer again; read **both** sources, not just OnClick; add `OnChange` beside `Action` in `isBuiltinPropName`. **`mx check` is not the oracle** — a page that lost its action is a valid document, 0 errors before and after; verify by describing the page back and by `strings`-ing the `.mxunit`. **Controls**: restore the literal `\"onClick\"` lookup → only the suffixed widgets fail; drop `OnChange` from `isBuiltinPropName` → only the same-spelling widgets fail. **Idempotence trap**: re-running the whole repro aborts at `module role already exists` before reaching a page, so an \"Unchanged\" check passes vacuously — re-run only the page statements, with `MXCLI_ALWAYS_WRITE=1` as the control. **Slider is not a usable fixture**: it raises CE0463 when mxcli writes it at all (measured with an action-free control), unrelated to action slots — use StarRating, which stores the same bare `onChange` and builds clean. Repro `mdl-examples/bug-tests/956-pluggable-widget-action-slot-names.mdl`. Issue #956", "refs": ["#14", "#956"], "ce": ["CE0463"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A pluggable widget's action slot has **no MDL surface** — `mxcli check` says *\"property `X` is recognized but not yet persisted by mxcli — a non-default value will be dropped; set it in Studio Pro if needed\"* (**MDL-WIDGET06**), so a widget can be placed but not wired. File Uploader's six slots, DataGrid2's `onSelectionChange`, Switch's `action`", "cause": "`actionSourceForKey` recognises only `onclick`/`onchange` (after stripping one `Event`/`Action` suffix) and `GenerateDefJSON` emitted a mapping **only** when it returned non-empty, so every other action-typed property got none and the engine had nothing to write", "file": "`mdl/executor/widget_defs.go` (`GenerateDefJSON` `case \"action\"`), `mdl/executor/widget_named_action_slot.go`, `mdl/executor/widget_engine.go` (`resolveMapping`'s no-Source branch), `mdl/grammar/domains/MDLPage.g4` (`widgetPropertyV3`), `mdl/visitor/visitor_page_v3.go`, `mdl/executor/validate_widgets.go` (`readsFixedASTSlot`)", "insight": "Emit a mapping for **every** action-typed property; one with no MDL alias carries **no `Source`** and is addressed by its own `PropertyKey` — the shape object-list item mappings already use, so it adds no concept. `microflow`/`nanoflow` on such a slot parse as a **DataSourceV3**: `dataSourceExprV3` and `actionExprV3` overlap and the datasource alternative must keep winning (else a chart series' `staticDataSource: microflow M.X` becomes an action), so the executor converts it — the same split `fragmentArgValue` resolves. Add the grammar alternative AFTER the datasource one for the unambiguous forms. **A `readsFixedASTSlot` that takes only the operation is wrong now**: an action mapping reads a fixed AST slot only when it HAS a Source. **Test the engine wiring separately from the AST reader** — stubbing out `resolveMapping`'s call left every reader test green. **Watch for conditional slots**: DataGrid2's `onSelectionChange` is `hidden when itemSelection = None` and writing into a pruned slot is CE0463 — control is the same page with the slot unset, which builds clean; `mxcli widget describe <name>` lists the conditions. Repro `mdl-examples/bug-tests/956-named-action-slots.mdl`. Issue #956", "refs": ["#956"], "ce": ["CE0463"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A pluggable widget mxcli writes fails **CE0463** even with no action and nothing but `Attribute:` set, while the SAME widget placed by hand in Studio Pro in the same project is clean. Slider and RangeSlider both", "cause": "**Two causes, and neither alone is enough.** (A) The bare `Attribute:` keyword filled EVERY attribute-typed mapping — a Slider declares four (`valueAttribute`, `min/max/stepAttribute`), so one keyword wrote the same AttributeRef into all of them, and Studio Pro leaves min/max/step unset unless the matching `*ValueType` is \"attribute\". (B) `tooltip` got a populated `Forms$ClientTemplate` where Studio Pro stores `TextTemplate: nil` — the #574 class — because the visibility extractor lifted only the ELSE branch of `showTooltip ? \"value\"===tooltipType && hide(\"tooltip\") : hide([\"tooltip\",…])`, so a tooltip hidden by the widget's own DEFAULTS read as visible and `ApplyVisibilityRules` took its *visible* branch and FILLED an empty template", "file": "`mdl/executor/widget_engine.go` (`isPrimaryAttributeMapping`, `currentDef`), `mdl/executor/editorconfig_extract.go` (`ternaryThenCandidate`, `splitTernaryThenGuard`, `negate`, `?` boundary case in `parseGuard`); tests `mdl/executor/editorconfig_ternary_then_test.go`, `mdl/executor/widget_primary_attribute_test.go`", "insight": "**Diff the two widgets in ONE project file, and diff the `Type` first to eliminate it**: here the whole `Type` — 27 PropertyTypes, their order, their nested ValueType maps, the metadata — was **byte-equivalent** once random `$ID`s were normalised, which rules out schema/order/template-version and leaves only the stored `Object`. **A conjunction is not expressible** as one `WidgetVisibilityCondition`, so the then-branch's inner condition is emitted ONLY when another rule hides the same property under the negation of the outer one — the else branch — making the pair a correct disjunction (`hidden ⟺ ¬showTooltip ∨ tooltipType==\"value\"`); without that cover, skipping is safe (degrades to \"not hidden\") and guessing is CE0463's mirror image. **Why Slider and not ProgressCircle**, whose shape looks identical: ProgressCircle parenthesises the branch, which the existing grouping-paren strip removes; Slider does not, so the guard arrived as `e.showTooltip?\"value\"===e.tooltipType` and `lastGuardExpr` handed back a `?` boundary nothing handled. **A hidden list can be COMPUTED and then nothing is liftable** — Slider's min/max/step hides are `[].concat(n(v[e.minValueType]), …)`, table lookups with no string literal — so the hidden-property guard cannot cover cause A at all; not writing the property is the only fix that does not depend on that data. Issue #238", "refs": ["#238", "#574"], "ce": ["CE0463"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A pluggable widget's property-visibility rule is **wrong rather than missing**: `.def.json` gains a rule for a key that is not a property at all, and two mutually-exclusive properties are both recorded under the same guard. Downstream, `MDL-WIDGET10` stays silent and the widget serializes a value into a slot Studio Pro prunes → **CE0463**", "cause": "`hideTargetKeys` scanned a `hidePropertiesIn([...])` array with `stringLitRE.FindAll`, harvesting **every** string literal in it. For `[\"files\"===e.uploadMode?\"associatedImages\":\"associatedFiles\", …]` that yields three keys — `files` (the *comparison value*), plus BOTH branches — all attributed to the enclosing guard, with the ternary's own condition lost. The extractor already handled a ternary wrapped **around** a hide call, which is why sibling properties in the same file (`onUploadSuccessImage`) were gated correctly and these were not", "file": "`mdl/executor/editorconfig_extract.go` (`ternaryKey`, `ternaryElement`, the conditional-element branch in `hideTargetKeys`, and per-branch emission in `extractVisibilityRulesFromJS`); test `mdl/executor/editorconfig_ternary_test.go`", "insight": "**A wrong rule is worse than no rule** — `SkippedComplex` degrades to \"not hidden\", which is safe; a mis-attributed rule prunes the wrong property in the wrong configuration. Reuse `guardToCondition` with its `falsy` flag rather than writing a second comparison parser: then-branch is `eq`, else-branch is `ne`, and the polarity logic already exists for the ternary-around-a-call case. **Verify against a regenerated `.def.json`, not just the unit test** — `mxcli widget init` then read `propertyVisibility` back; the observable effect is that the bogus key disappears and the two branches carry opposite conditions. Visibility is applied at **serialization** time (`widget_engine.go` → `ApplyPropertyVisibility`), not only in validation, so a wrong rule reaches the stored BSON. Measured on File Uploader 2.5.0 (marketplace 235351): before, `associatedImages` carried only `readOnlyMode truthy`; after, `uploadMode eq files` — and MDL-WIDGET10 fires where it was silent. Issue #956", "refs": ["#956"], "ce": ["CE0463"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "An action written on an object-list **item** — a chart series' `StaticOnClickAction:`, a popupmenu item's `action:`, a maps marker's `onClick:`, an accordion group's `onToggleCollapsed:` — is accepted by `mxcli check`, the page is written, `mx check` reports 0 errors, and the slot is **empty**. `DESCRIBE` does not mention it either, so nothing reveals the loss", "cause": "The executor's item-property switch had no `action` case and fell to `default: continue`, carrying `TODO(#538 follow-up)`. Everything under it was already in place — the `.def.json` carries the mapping (`operationForType` returns `\"action\"`), `backend.ObjectListItemProperty` has an `Action` field, and `widgetobj/builder.go` writes `Value.Action` — so the action reached the AST, matched a mapping, and fell off the end of a switch. `mdl/backend/mcp/widget.go`'s item switch had no `action` case either", "file": "`mdl/executor/widget_engine.go` (item switch → `namedActionSlotValue` + `buildClientActionV3`), `mdl/executor/cmd_pages_describe_objectlist.go` (the `Action` branch in `extractObjectListItem`), `mdl/backend/mcp/widget.go` (`SetObjectList` → `customWidgetClientAction`); tests `mdl/executor/widget_item_action_slot_test.go`, `mdl/backend/mcp/widget_item_action_test.go`; example `mdl-examples/bug-tests/956-object-list-item-action-slots.mdl`", "insight": "**Read the slot through `namedActionSlotValue`, not off the AST's `Action` field.** `microflow M.X` in a property position parses as a **`*DataSourceV3`** — `dataSourceExprV3` wins in `widgetPropertyV3`, deliberately, or a series' `DataSource: microflow M.X` would become an action — so a direct read misses the form people actually write **and** takes the `datasource` branch of the same switch on the way past. Only the widget definition knows the slot is an action. **Three switches, not one**: executor write, DESCRIBE read, MCP builder — patching the first alone gives a page that holds the action and describes as though it does not, which is the lossy round trip wearing the right answer. **A NoAction is the unset default** and must be skipped on read and never written on an unset slot, or every untouched item grows a line and re-exec clears what the widget had. `mx check` is no oracle in either direction — a series with no click action is a normal series, 0 errors before and after; verify by describing back and reading the `.mxunit`. When faking stored BSON in a test, the `$Type` is the **storage** name: `Forms$MicroflowAction`, not `Forms$MicroflowClientAction` (`sdk/mpr/writer_widgets_action.go` is the arbiter) — a wrong one makes the reader silently skip and reads as the fix not working. Issue #956", "refs": ["#538", "#956"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "An MDL keyword that several widget properties share writes into **all** of them, including one the widget's configuration hides — **CE0463**. Naming the keyword once is then also reported by `MDL-WIDGET10` as having set a property the script never mentions, so the statement is refused even though it is correct", "cause": "Two causes, one in each direction. `widgetValueMap` marked a property `explicit` whenever it was reached through `m.Source`, so a keyword routed to several properties counted as naming each of them. And the write path had nothing that skipped a hidden property: `ApplyVisibilityRules` is scoped to **TextTemplate**-typed properties (it was built for #574), so a hidden DataSource or primitive was written normally", "file": "`mdl/executor/validate_widgets.go` (`sharedSource` in `widgetValueMap`), `mdl/executor/widget_engine.go` (`hiddenUnnamedProperties`, consulted in the mapping loop); test `mdl/executor/widget_hidden_shared_source_test.go`", "insight": "**Skip the mapping; do not clear the property afterwards.** Measured on a Studio Pro-authored File Uploader 2.5.0: **34 of 34** declared properties are stored, the hidden ones at their DEFAULT — so \"hidden\" means default-valued, not absent, and letting the widget template's default survive reproduces Studio Pro exactly while post-hoc nulling would not. **Only skip a property the script did not name** — naming a hidden property outright stays an MDL-WIDGET10 error, which is the DataGrid2 `onSelectionChange` case and must keep firing; the discriminator is whether the source is shared by more than one mapping, not whether the property is hidden. `mx check` is the only oracle: the wrong write is a valid document until Studio Pro loads it, and the MDL-WIDGET10 false positive looks like a correct refusal. Issue #956", "refs": ["#574", "#956"], "ce": ["CE0463"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE PAGE` omits a pluggable widget's own **datasource**, so `describe → exec` drops it. Measured: a Studio Pro-authored File Uploader at **0 errors** comes back as **CE0642** \"Property 'Associated files' is required\" plus **2× CE1571** \"no argument has been selected for parameter\" — and the DESCRIBE text is **byte-identical** before and after, so the round trip looks lossless", "cause": "The generic pluggable-widget renderer emitted `Label`, explicit properties, `onClick`, `OnChange`, named actions and appearance — and never `w.DataSource`. The parse side had been populating a field nothing printed. Only the per-widget branches (ComboBox, DataGrid2, Gallery, drop-down filter) emitted one, via their own extractors", "file": "`mdl/executor/cmd_pages_describe_output.go` (`appendDataSourceProp` in the generic pluggable branch), `mdl/executor/cmd_pages_describe_parse.go` (generic fallback), `mdl/executor/cmd_pages_describe_pluggable.go` (`anyCustomWidgetDataSource`)", "insight": "**The CE1571s are a consequence, not a second bug** — an action's parameter loses its default once the datasource providing the object is gone, so all three errors clear together; chasing the parameter mappings separately is wasted work. **`firstObjectPropertyDataSource` is not a substitute**: it returns as soon as a property's DataSource parses to a non-nil value, even one carrying no reference, and a File Uploader has such a property AHEAD of its real one — so the caller got an empty datasource, discarded it, and described the widget as having none. Keep scanning until one names something. **Verify with `mx check`, never with a describe diff**: the text matched exactly while the model lost data, and an exec that fails to parse re-describes identically too — so confirm the exec actually ran (`Replaced …`) before believing a round-trip test. Issue #956", "refs": ["#956"], "ce": ["CE0642", "CE1571"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| A `describe → exec` round trip on a page whose object-list item carries a **text template with a placeholder** turns a building page into **CE0720** \"Place holder index 1 is greater than 0, the number of parameter(s)\". The DESCRIBE text is identical before and after | Two bugs, one on each side. DESCRIBE emitted the template's TEXT and discarded its parameters — `extractTextTemplateText` already returns the template map and `extractObjectListItem` threw it away. And the engine read the companion with a **case-sensitive map index**, `child.Properties[matchedAlias+\"Params\"]`, where `matchedAlias` is the SCHEMA key (`buttonCaption`) while the script and DESCRIBE write the widget's own casing (`ButtonCaptionParams`) | `mdl/executor/cmd_pages_describe_objectlist.go` (emit `<Key>Params`), `mdl/executor/widget_engine.go` (`lookupProperty` for the companion), `mdl/grammar/domains/MDLPage.g4` + `mdl/visitor/visitor_page_v3.go` (a generic `<Name>Params` form); tests `mdl/executor/widget_item_template_params_test.go` | **Fix both sides or neither shows**: emitting the params without the lookup fix still drops them, and the lookup fix alone has nothing to read — each half has its own control. **The grammar had no generic form**: only `ContentParams`/`CaptionParams` have tokens, so emitting `ButtonCaptionParams` first requires `(IDENTIFIER | keyword) COLON paramListV3`, placed BEFORE the generic `propertyValueV3` alternatives — which also admit `[...]`, and `{N} = expr` inside is what separates them. Render through `formatParametersV3`: `extractClientTemplateParameters` returns bare expressions and `paramListV3` needs `{N} = expr`, so a raw join produces `['abc']`, which parses as an ARRAY and silently sets the wrong thing. **The case-sensitivity agreed by luck for a DataGrid column** (`Caption` → `CaptionParams` matches what MDL writes), which is why the defect survived — any test using a column passes. Issue #956 |", "refs": ["#956"], "ce": ["CE0720"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`rest call … returns mapping M.IMM as Module.Entity` builds cleanly — `mxcli check`, `mx check` 0 errors, mxbuild fine — and throws the moment the activity runs, over a valid response body: `MicroflowException: key not found: Path(QName(None,),None,)` at `MappingCache.storeValueMappingElement`. `as list of` instead fails the BUILD with CE0243, so an object-rooted mapping has no working `returns mapping` form at all", "cause": "The REST branch mirrored BOTH of the ImportMappingCall's flags onto the result variable's cardinality. They are three axes, not one: `SingleObject` types the VARIABLE, `ForceSingleOccurrence` means \"the mapping yields many, bind one\", `Range.SingleObject` is Studio Pro's First/All. `as Entity` set all three true, so an OBJECT-rooted mapping was told to force an occurrence it does not have. #192 fixed the identical conflation in the sibling `import from mapping` branch and never reached this one", "file": "`mdl/executor/cmd_microflows_builder_calls.go` (`addRestCallAction`'s `ast.RestResultMapping` case + the shared `mappingRootIsList` helper); tests `mdl/executor/cmd_microflows_rest_mapping_occurrence_test.go`; example `mdl-examples/bug-tests/242-rest-mapping-single-object-runtime.mdl`", "insight": "**Measure the flags one at a time before fixing.** All four combinations were run in one boot over the same mapping and JSON: `FSO=true/Range=true` FAIL, `FSO=true/Range=false` FAIL, `FSO=false/Range=false` PASS, `FSO=false/Range=true` PASS — so `ForceSingleOccurrence` alone drives the exception and `Range` is innocent, which is NOT what reading the code suggests. **Do not write `ForceSingleOccurrence=false` unconditionally**: that fixes the object-rooted case and silently strips the flag from `PrivateCloudData.REST_GetEnvironmentByUUID`, a Studio Pro document that binds one object out of a LIST-rooted mapping and stores it true (recorded in `mdl-examples/bug-tests/519-rest-mapping-as-list-of.mdl`). Infer it from the MAPPING's root instead — true only when the mapping yields many AND the call site binds one. An unresolvable mapping must read as object-rooted: guessing \"list\" fails at RUN time, guessing \"object\" is caught by mxbuild as CE0243 at BUILD time. **A unit test on the flags is not enough** — every static check passes on the broken document, so the regression example has to be driven through `mxcli test --local` with a real JSON endpoint (`python3 -m http.server`), and the generated test wrapper swallows the exception text: call `MxTest.Test_*` directly through `/mxtest/run` with the token from `<project>/.mxcli/test-endpoint.json` to read it. Issue #242", "refs": ["#192", "#242"], "ce": ["CE0243"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Someone translates the whole app into a language with `create translations`, every run reports success, `mx check` is clean — and the app shows not one translated string", "cause": "The project had not ENABLED that language. Enabled languages (`Settings$LanguageSettings.Languages`) decide what the build emits; a translation for any other language is stored in the model, survives every check, and is discarded at build time. Measured on mxbuild 11.13.0: a caption translated into de_DE on a blank app (which enables en_US only) builds at 0 errors and the German string appears NOWHERE under `deployment/` — no `translations_de_DE.properties`, and \"de_DE\" does not occur in the built model at all; the English control appears in three files. A stock app invites the mistake: it enables ONE language while its marketplace modules ship translations in NINE, so \"other languages already have translations here\" is true and misleading", "file": "`mdl/executor/language_enablement.go` (`languageIsEnabled`, `unenabledLanguageWarning`), wired into `mdl/executor/cmd_translations.go` and surfaced by `mdl/executor/cmd_settings.go` (both `show` and `describe`)", "insight": "Warn, do not refuse: Mendix tolerates the state at **both** layers — measured live over PED, Studio Pro loads the unenabled language's translation and keeps it beside the enabled one (`{\"languageCode\":\"sv_SE\",\"text\":\"Etikett\"}` next to the en_US entry on a caption in an en_US-only project), reporting no error; only the BUILD drops it — and refusing would break the legitimate order of \"translate now, enable when the review lands\". **Unknown must not read as disabled** — with no settings, or a settings part carrying no `Languages`, a warning would be a guess, and a false warning about a language that IS enabled trains people to ignore the true one. DESCRIBE lists the enabled languages as a **comment**, because MDL cannot author the list (`alter settings LANGUAGE` carries `DefaultLanguageCode` only) and a statement that does not re-execute is worse than a comment that does not. The measurement that settles any doubt is `mxbuild --target=deploy` plus a same-page control string in the default language — `mx check` says nothing either way. Repro `mdl-examples/bug-tests/translations-unenabled-language.mdl`"}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| `describe settings` output does not replay onto another project: it stops at `Error: configuration not found: <name>`, and before that it silently lost every enabled language | DESCRIBE emitted the verbs that read best rather than the ones that re-execute — `alter settings configuration` for a configuration the target may not have, and a COMMENT for the language list. Round-trip was never asserted, so both were invisible: the output looks correct and cannot be run | `mdl/executor/cmd_settings.go` (`describeSettings`, `writeSettingsConfiguration`), `mdl/executor/cmd_settings_languages.go`, plus the upserts that make replay possible: `alterSettingsLanguageUpsert` and `CreateConfigurationStmt.CreateOrModify` (`mdl/ast/ast_settings.go`, `mdl/visitor/visitor_settings.go`, `createConfiguration`) | Emit **upsert** verbs — `create or modify configuration`, `alter settings LANGUAGE add or modify` — because the plain CREATE/ADD forms refuse what is already there, which is right for a hand-written script and wrong for a described project replayed onto itself. Note `CREATE (OR (MODIFY\\|REPLACE))?` was **already** in the grammar generically, so `create or modify configuration` parsed and silently behaved as a plain CREATE: a documented upsert that answered \"already exists\". Order matters — `DefaultLanguageCode` is validated against the enabled list, so it must come AFTER the languages — and every option must be named, because MODIFY touches only what it names. **Test both directions**: replay onto the SAME project (unit byte-identical, and the run reports `Unchanged`, not `Updated`) and onto a BLANK one (settings document identical field for field). The same-project replay is what exposes verb dishonesty; the blank-project replay is what exposes a missing upsert. Known boundary: settings that REFERENCE module documents (`AfterStartupMicroflow`, a constant override) legitimately dangle on a project without them — mxbuild says CE1613 — and mxcli neither warns nor validates those references, which is tracked separately. Example `mdl-examples/doctype-tests/languages.mdl` |", "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A Java action, JavaScript action or microflow **silently loses its Studio Pro toolbox entry** on an unrelated rewrite. Two shapes: with `exposed as …` kept, the icon and image PNGs come back as empty binaries; with the clause omitted, the whole entry disappears — caption, category, icon and image — and the action vanishes from the palette. `mx check` reports **0 errors** in both cases", "cause": "`CodeActions$MicroflowActionInfo` has six fields (Caption, Category, IconData, IconDataDark, ImageData, ImageDataDark) and MDL's clause names two, so the write path *constructed* the sub-document from the clause instead of merging onto the stored one. Compounded on the default engine by a read that never loaded the bitmaps: `modelsdk/gen` declares all four as `string` while Mendix stores BSON **binary**, so `DecodeString` returned `\"\"` for every real icon — the same gen/storage mismatch class as scheduled events and regular expressions", "file": "`mdl/executor/expose_action_info.go` (`mergeMicroflowActionInfo`, `applyExposeClauses`, `applyExposeBitmaps`), `mdl/executor/cmd_javaactions.go`, `mdl/executor/cmd_javascript_actions_write.go`, `mdl/executor/cmd_microflows_create.go`, `mdl/backend/modelsdk/java_read.go` (`readActionInfoBitmaps`, `actionInfoFromGen`), `mdl/backend/modelsdk/microflow_write.go` (`patchMicroflowToolboxEntries`); tests `mdl/executor/cmd_javaactions_expose_preserve_test.go`, `mdl/executor/expose_action_bitmaps_test.go`; example `mdl-examples/doctype-tests/39-expose-as-toolbox-action.mdl`", "insight": "**Silence is preservation, not removal** — an absent clause must carry the stored value, so removing needs its own syntax (`NOT EXPOSED`, `DROP ICON`). Rebuilding a sub-document from the subset MDL can express is the general shape of this bug (ADR-0005); look for `X = &T{...}` where `X` is a stored polymorphic child. **Check the READ before blaming the write**: a merge cannot carry what the reader never loaded, and a gen accessor typed `string` over a BSON binary fails silently to `\"\"`. **Two microflow renderers exist** in `cmd_microflows_show.go` (`describeMicroflow` and `renderMicroflowMDL`) — patching one leaves DESCRIBE unchanged on the path the CLI actually takes. A test fixture generating two same-sized PNGs produces **identical bytes**, so an \"each target is routed separately\" assertion passes vacuously unless the fixtures differ"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`alter settings` writes a microflow, entity or constant name that does not exist, reports success, and `mxcli check --references` calls the script valid — the build then fails with **CE1613** *\"The selected microflow/constant no longer exists\"*. A misspelled constant is worse than a dangling pointer: the override is **created** for a constant that does not exist, leaving dead configuration data", "cause": "Settings were the ONLY statement family that resolved nothing. `--references` walks `validateWithContext`, whose switch had no `*ast.AlterSettingsStmt` case at all, so the qualified names in `AfterStartupMicroflow` / `BeforeShutdownMicroflow` / `HealthCheckMicroflow`, workflow `UserEntity` and the constant override went straight to the writer", "file": "`mdl/executor/validate_settings_refs.go` (`validateSettingsReferences`, `validateSettingsConstantRef`), wired into `mdl/executor/validate.go` (the `AlterSettingsStmt` case + `scriptContext.constants`) and into `alterSettings` itself; index helper `buildConstantQualifiedNames` in `mdl/executor/helpers.go`", "insight": "Put the guard in the **handler**, and have check call the same functions — that is what makes `exec` refuse exactly what `check` reports, including under `--no-check`, and it is why the exec-time call passes a **nil script context**: by then the earlier statements have run, so anything the script created is really in the project. Three cases a naive resolver gets wrong, each with a test: an **empty value clears** the setting (Studio Pro's \"(none)\") and must not be resolved; a document **created earlier in the same script** is not missing (the escape hatch every other family has, which is why the fixture pair is a `.fail.mdl` AND a passing control); and **dropping** a constant override must stay legal even when the constant is gone, or there is no way to tidy up after deleting one. Note the two `ValidateProgram`s are different passes — the package-level one (which `exec` runs) has only a project PATH, while the reference pass has a connected backend, so a check needing project reads cannot live in the first. Repro `mdl-examples/bug-tests/274-settings-reference-validation.fail.mdl` + `274-settings-reference-valid.mdl`. Issue #274", "refs": ["#274"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`alter settings` writes a microflow, entity or constant name that does not exist, reports success, and `mxcli check --references` calls the script valid — the build then fails with **CE1613** *\"The selected microflow/constant no longer exists\"*. A misspelled constant is worse than a dangling pointer: the override is **created** for a constant that does not exist, leaving dead configuration data", "cause": "Settings were the ONLY statement family that resolved nothing. `--references` walks `validateWithContext`, whose switch had no `*ast.AlterSettingsStmt` case at all, so the qualified names in `AfterStartupMicroflow` / `BeforeShutdownMicroflow` / `HealthCheckMicroflow`, workflow `UserEntity` and the constant override went straight to the writer", "file": "`mdl/executor/validate_settings_refs.go` (`validateSettingsReferences`, `validateSettingsConstantRef`), wired into `mdl/executor/validate.go` (the `AlterSettingsStmt` case + `scriptContext.constants`) and into `alterSettings` itself; index helper `buildConstantQualifiedNames` in `mdl/executor/helpers.go`", "insight": "Put the guard in the **handler**, and have check call the same functions — that is what makes `exec` refuse exactly what `check` reports, including under `--no-check`, and it is why the exec-time call passes a **nil script context**: by then the earlier statements have run, so anything the script created is really in the project. Three cases a naive resolver gets wrong, each with a test: an **empty value clears** the setting (Studio Pro's \"(none)\") and must not be resolved; a document **created earlier in the same script** is not missing (the escape hatch every other family has, which is why the fixture pair is a `.fail.mdl` AND a passing control); and **dropping** a constant override must stay legal even when the constant is gone, or there is no way to tidy up after deleting one. Note the two `ValidateProgram`s are different passes — the package-level one (which `exec` runs) has only a project PATH, while the reference pass has a connected backend, so a check needing project reads cannot live in the first. Repro `mdl-examples/bug-tests/274-settings-reference-validation.mdl` + `274-settings-reference-valid.mdl` — a plain `.mdl`, NOT `.fail.mdl`: `make check-mdl` runs `mxcli check` without a project, and a rule that resolves names against the model cannot decide anything there, so the file checks clean and `.fail.mdl` would report \"negative test unexpectedly passed\" — a working rule made to look regressed. The Makefile documents this above `check-mdl` (#891/#892); CI caught it here. Issue #274", "refs": ["#274", "#891", "#892"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A decision inside `while` is written with only its **true** flow — Studio Pro reports **CE0079** *\"the 'false' condition value should be configured on an outgoing sequence flow\"*. `mxcli check` reports \"Syntax OK\" and exit 0, so the broken microflow is written by `exec` and surfaces only in the Errors pane. The same body inside `loop` is correct", "cause": "A merge-less split (`if X then break` / `then continue`) defers its FALSE case to the next flow. `addLoopStatement` tracks that deferred case through the body and wires whatever is left over to a synthesized `ContinueEvent` (ledger #52); `addWhileStatement` had **neither** the `pendingCase` variable nor the trailing block, so the case was dropped. Four shapes affected: break-last, continue-last, either with a trailing statement, either after a leading statement", "file": "`mdl/executor/cmd_microflows_builder_control.go` (`addWhileStatement`, the `pendingCase` loop + trailing `addContinueEvent` block)", "insight": "Mirror `addLoopStatement` **verbatim** — a WHILE body is a loop body, and the divergence was the whole defect. The durable guard is the **parity test**: assert LOOP and WHILE agree on the same body, which is what would have caught the ledger #52 fix landing in only one of two builders. Grep for the sibling before fixing any loop-body defect. Note `return`-in-a-loop is refused by MDL062, so `break` and `continue` are the only live shapes. Not expressible as a `.fail.mdl`: the MDL is **valid** and `check` is right to accept it (this is a writer defect, not a check gap), so the guards are unit tests in `mdl/executor/cmd_microflows_while_break_test.go`. Repro `mdl-examples/bug-tests/893-while-break-false-edge.mdl`. Issue #893 case 3 — note the reported shape (`IF` first in a WHILE body) did **not** reproduce; this was found by probing its neighbourhood, and cases 1/2/6 were already fixed by MDL061/062/063", "refs": ["#52", "#893"], "ce": ["CE0079"], "rules": ["MDL061", "MDL062"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`describe microflow` renders a loop with an **empty body** — `loop $X in $L begin end loop;` — when the body carries an `@annotation`. Silent, exit 0, and the truncated script passes `check`, so the documented describe → exec round trip **deletes the loop body**. `bson dump` and `--format mermaid` both still show the activity", "cause": "`emitLoopBody` picks the body's start as \"no incoming sequence flow, leftmost then topmost\" (`preferLoopBodyStart`). A `*microflows.Annotation` **is** an object in `ObjectCollection.Objects` but connects via `AnnotationFlows`, never `Flows`, so its incoming count is permanently 0 and it was always a start candidate. When it won, traversal began at a node with no outgoing sequence flow and emitted nothing. Only loops: the top level starts from its `StartEvent`, and mermaid iterates objects directly rather than traversing", "file": "`mdl/executor/cmd_microflows_show_helpers.go` (`isFlowNode`, and the `incomingCount` candidate loop in `emitLoopBody`)", "insight": "**The defect is positional, and that is the trap**: annotation LEFT / ABOVE-same-X / ABOVE-LEFT lose the body, annotation RIGHT renders correctly *including* the annotation — so a fixture that puts it on the right passes against broken code. Cover all four. **Not Studio Pro-only**, which was the first wrong reading: mxcli's own builder emits the annotation at the same X and above (measured activity (150,80), annotation (150,-20)), the losing shape, so mxcli destroyed loop bodies it authored itself. **Why #330 missed it**: that fixture covers the same construct, but its Go regression tests the AST→BSON *build* path and its describe assertion is a manual procedure in a comment — `make check-mdl` runs without a project, so CI only syntax-checked it. Nothing had ever *described* an annotated loop body. The durable guard is a **build → describe round trip** using the builder's real positions, asserting its own premise so it fails loudly if layout changes stop it exercising the defect. Not expressible as `.fail.mdl` (the MDL is valid; the bug was in describe). Repro `mdl-examples/bug-tests/965-loop-body-lost-to-annotation.mdl`, guards `mdl/executor/cmd_microflows_describe_loop_annotation_test.go`. Issue #965", "refs": ["#330", "#965"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create association … comment 'text'` reports success and stores **no documentation**, and a `/** … */` doc comment before the statement is dropped too — so an association is the one domain-model element with no working way to document it on create. `mx check` passes (an undocumented association is valid), and `describe association` simply shows nothing", "cause": "Both halves sit upstream of the writer, which has emitted `Documentation` all along. (1) `mdl/visitor/visitor_association.go` never called `findDocCommentText(ctx)`, the way the entity and enumeration visitors do, so `stmt.Documentation` was always empty. (2) The **plain-CREATE** branches of `execCreateAssociation` built the `Association` / `CrossModuleAssociation` literal without a `Documentation` field at all — while the `OR MODIFY` branches a few lines above them *do* set it, which is what makes the field look wired when the file is read casually", "file": "`mdl/executor/cmd_associations.go` (`associationDocumentation`, both plain-CREATE literals, both OR MODIFY branches), `mdl/visitor/visitor_association.go`; tests `mdl/executor/cmd_associations_documentation_test.go`", "insight": "**A field set on the OR MODIFY path is not evidence it is set on the CREATE path** — the two construct the element separately and sit next to each other. Grep for the struct literal, not for the field name. This is also why `comment` was *kept* on `create association` when it was removed from entity/enumeration/module/microflow/nanoflow/rule: there the doc comment already worked so the dead option was redundant, but here **neither** spelling worked, and removing the option would have left nothing at all. Check both spellings before deciding whether an option is dead or load-bearing"}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| Every member of an **array-rooted** import/export mapping is rejected: `\"id\" is not a member of the JSON structure at (Object), which has no members there` — while the identical body over an object-rooted structure works | Both executors hardcoded the root lookup to `\"(Object)\"`, and an array-rooted structure is built at `\"(Array)\"` with its item at `\"(Array)|(Object)\"` (`buildElementFromRawRootArray`). The root resolved to nothing, so the child lookup reported members \"at (Object)\" — a node that structure never had, which reads as \"your key is wrong\" rather than \"the root was looked up in the wrong place\". 122 of the 327 mapping documents in the demo apps are array-rooted, the single largest gap in the mapping surface | `mdl/executor/cmd_import_mappings.go` (`buildImportMappingElementModel`, `jsonSchemaIndex.root`), `mdl/executor/cmd_export_mappings.go` (`buildExportMappingElementModel`, `buildExportRootArrayElement`, `exportRootToPrint`) | Take the root FROM the structure instead of assuming it. No new syntax: the structure decides, and Studio Pro does not ask either. The import side then needs nothing more — the array branch was already stepping `\"(Array)\"` → `\"(Array)|(Object)\"` for NESTED arrays. **The two sides store different shapes and the difference is not guessable**: an array-rooted IMPORT mapping is ONE element at `(Array)|(Object)` (the container collapses), an array-rooted EXPORT mapping is a bare `Array` container at `(Array)` whose single child carries the entity with `ObjectHandling=Parameter`. Pin both against Studio Pro documents before writing either (`Teamcenter.IMM_ItemRevision`, `FactoryManagement.IMM_ScenarioList`, `SnowflakeIntegration.EXM_SensorData` — Evora demo app, 11.13). A second export shape exists (`DigitalTwin.EMM_EntityQuery`: entity on the container, `Find` on the item, for a parameter that OWNS the list) and MDL cannot say which is meant, so it stays unauthorable — #262. **Adding an authorable shape means teaching DESCRIBE about it in the same change**, or the newly writable mapping joins the 112 silent-loss cases of #260: the export container is not `Kind==\"Object\"`, so it fell into the value branch and printed `Root = ` with its whole subtree dropped. Discriminate the container on its stored **JsonPath**, not on `Kind` — the two engines' readers label it differently (\"Array\" vs \"Object\") and only the path is in the document. Controls: revert the root lookup and the repro returns verbatim, while the object-rooted control still passes; `mdl-examples/bug-tests/519-rest-mapping-as-list-of.mdl` goes from dying on its own mapping statement to executing. `mx check` needs the base project's own error count as the control (a blank app carries a pre-existing CE0495). Repro `mdl-examples/bug-tests/248-array-rooted-mappings.mdl`, tests `TestImportMappingArrayRoot` / `TestExportMappingArrayRoot`. Issue #248 |", "refs": ["#248", "#260", "#262"], "ce": ["CE0495"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| A mapping sourced from a **message definition** cannot be authored at all — MDL has `with json structure` and `with xml schema` and no third form — and `describe` of an existing one silently omits the source clause while still producing output that PARSES, so `describe` → `exec` rebuilds the mapping bound to nothing | 74 of the 327 mapping documents in the demo apps use one (the second-largest gap after the array root), 70 of them in the silent-loss class. The document is `MessageDefinitions$MessageDefinitionCollection` — a COLLECTION, which is why the reference is three parts (`Module.Collection.Definition`) — and it is derived from the **domain model**, not a payload sample: every node names an entity or an attribute and carries two names, its own (`Emails`) and the singular one its items take (`Email`) | `mdl/executor/mapping_messagedefinition.go` (`findMessageDefinition`, `messageDefPaths`, the two builders), `mdl/backend/modelsdk/messagedefinition_read.go`, `model/types.go` (`MessageDefinitionCollection`, and `XmlPath` on both mapping element types) | **A message-definition mapping stores BOTH path families** — that is the whole reason it needs its own builder rather than a branch of the JSON one: `json=(Array)\\|(Object)\\|From` beside `xml=Emails\\|Email\\|From`. The rules, measured on AgentCore.MesDef_Email / .MesDef_WorkflowDetails and Email_Connector.MD_EmailTemplate: an unbounded node contributes `ExposedName\\|ExposedItemName` to the XML path and `ExposedName\\|(Object)` to the JSON one, a single node contributes `ExposedName` to both, and the ROOT is the asymmetry — its own name is in the XML path but the JSON one is just `(Array)\\|(Object)`. `model.ImportMappingElement`/`ExportMappingElement` had **no XmlPath field** and every writer hardcoded `\"\"`, so that had to be added and carried on both engines' read and write paths first. **Do not \"helpfully\" drop the body**: the definition fixes entity, attributes and names, so a bodyless \"map everything\" form is tempting — measured, six of the ten real message-definition mappings map every exposed node and four map a strict subset (58 of 96, 27 of 30, 28 of 30, 26 of 27), so it would be lossy for 40% of them. `modelsdk/gen/messagedefinitions` already models the whole tree and decodes real documents unchanged (zero entries in `keyaudit_test.go`), so the read is one `mprread.ListUnitsWithContainer` call; the legacy engine has no parser and **refuses rather than returning an empty list**, because empty reads as \"this project has no message definitions\" and turns a real reference into a bogus \"not found\". The oracle is a Studio Pro mapping over the SAME definition: authoring `AgentCore.MesDef_Email.Email` from MDL reproduces `AgentCore.Email_Import` element for element. Repro `mdl-examples/bug-tests/263-message-definition-source.mdl`, tests `mdl/executor/mapping_messagedefinition_test.go`. Issue #263 |", "refs": ["#263"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A value **converter microflow** — `Attr = Module.MF(jsonField)` — is accepted, the mapping is created, and the transform is silently absent; DESCRIBE prints the element as a plain `Attr = jsonField`", "cause": "The grammar and the AST already carried it (`Converter`, `ConverterParam` in `ast_import_export_mapping.go`) and nothing downstream read either: the model element had no `Converter` field and every writer hardcoded the BSON key to `\"\"`. The visitor also never set `JsonName` for that alternative, so even with a model field the member had no name to resolve against. 39 of the 327 demo-app mapping documents use one, including the two a blank app ships (`FeedbackModule.IMM_PostResponse`, `.EXM_PostFeedback`)", "file": "`mdl/executor/mapping_messagedefinition.go` (`setMappingConverter`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go` (build + describe), `mdl/visitor/visitor_import_export_mapping.go`, `model/types.go`, and the four writers + four readers", "insight": "**A half-wired feature is worse than a missing one** — the syntax parsed, so scripts using it looked correct and produced mappings without the transform. When the grammar already has a form, check the whole chain (AST → model → both writers → both readers → describe) before assuming it works. The stored element carries **one** property, `Converter`, and no separate parameter path: the microflow's input IS the member the element binds, which is why the member belongs inside the call and there is nothing to cross-validate. The export side had **no spelling at all** (22 export value elements use one), so the mirrored `jsonKey = Module.MF(Attr)` was added — note the argument is the ATTRIBUTE there, since the direction is reversed. An unresolvable microflow is refused, same rule as an unresolvable schema source (#259). Control that matters: assert the sibling element WITHOUT a converter carries an empty one, or the test passes against a writer that stamps every element. Repro `mdl-examples/bug-tests/266-converter-microflow.mdl`, tests `mdl/executor/mapping_converter_test.go`. Issue #266", "refs": ["#259", "#266"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A mapping element whose object handling is **Custom** — a microflow resolves the object instead of Create/Find — cannot be authored, and `describe` of one drops the handler while still producing output that executes, so the rebuilt mapping CREATES objects where the original called a microflow", "cause": "56 of the 327 demo-app mapping documents use it. Both writers hardcoded `CustomHandlerCall` to nil, and gen models the call but not the property: `Import/ExportObjectMappingElement` has no `CustomHandlerCall` accessor at all", "file": "`mdl/executor/mapping_customhandler.go`, `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`, `mdl/backend/modelsdk/mapping_write.go` (`customHandlerToGen`, list marker + TypeDefaults) and `mapping_read.go` (`customHandlerFromRaw`), `modelsdk/gen/mappings/types.go` (STORAGE-NAME OVERRIDE), `mdl/backend/mpr/backend.go` (legacy refusal)", "insight": "**Three shapes `mx check` caught that reading the document did not**, in the order they appeared: (1) `CE0281 \"Unknown value element 'idx' selected for parameter\"` — a value-path parameter needs the value to EXIST as an attribute-less value mapping element under the object being resolved; Studio Pro adds it when you pick the value, so mxcli must too. (2) `CE5015 \"Attribute type 'String' does not match schema type 'Integer'\"` — that added element's type must mirror the schema element, since there is no attribute to derive it from. (3) the element then has to be **hidden from DESCRIBE**, because it is derived from the `by (Param: member)` clause and printing it emits ` = idx` with no attribute, which does not parse. Also: the parameter element's stored `$Type` is `Mappings$MicroflowCallParameterMappingImpl` where gen says `MappingMicroflowParameter` (161 of 161 documents) — a STORAGE-NAME OVERRIDE, patched on both the encode and decode halves; `ParameterMappings` is written even when the microflow takes **no** parameters, as the bare `[2]` (a MandatoryLists entry, like a rule's `Flows`); and `ObjectHandlingBackup` must NOT inherit \"Custom\", which is not in the `{Create, Error, Ignore}` enum — import documents store Create, export ones Error. gen declares a `ValueElementPath` that Studio Pro writes in 0 of 161 documents, so the writer builds the sub-document with the generic element helpers rather than gen. Read back from **raw BSON**, since gen has no accessor. Legacy **refuses** rather than dropping the microflow. Repro `mdl-examples/bug-tests/264-custom-object-handling.mdl`, tests `mdl/executor/mapping_customhandler_test.go`. Issue #264", "refs": ["#264"], "ce": ["CE0281", "CE5015"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| An export mapping's **array container** is written with an entity and association, so the MDL makes the author declare `Assoc/Entity` twice and the result matches no Studio Pro document | Studio Pro leaves the container BARE — 93 of the 93 entity-less object elements in the demo apps are array containers of the shape `et=Array entity=- assoc=- oh=Find` over `et=Object entity=… assoc=… oh=Find` at the `\\|(Object)` step (AgentCommons.EM_Agent, MxGenAIConnector.EM_ConverseRequest, SnowflakeIntegration.Export_AnyChart_Heatmap) | `mdl/executor/cmd_export_mappings.go` (the array branch of `buildExportMappingElementModel`, `exportArrayItemToPrint`) | Declare an array like a plain nested object — `Assoc/Entity as items { values }` — and GENERATE the container, the same rule #248 applied to a root array; only the object handling differs (Parameter on the root's item, Find on a nested one). **Keep honouring the old two-level spelling as written**: `Assoc/Entity as items { ItemAssoc/ItemEntity as ItemsItem { … } }` names TWO entities, one per level, which the bare-container shape cannot express — rewriting it produced **CE0295** \"Association … is not allowed\" because the item's association no longer reached its parent. It is also what DESCRIBE emitted before the change, so the doctype suite and any script in the wild use it; the integration run caught this, a unit test would not have. DESCRIBE unwraps only the BARE container (discriminate on the stored paths — the item's is the container's plus `\\|(Object)` — never on `Kind`, which the two engines' readers label differently), so an old-form mapping still round-trips to its own shape. **An entity-less PLAIN object element is a different thing**, written `group as toolConfig { … }`, and it may hold **object elements only** — a value under one is **CE0061 \"No entity selected.\"**, because a value has no entity to bind its attribute to. That constraint cost a detour worth copying: the first attempt put a value there, mxbuild refused it, and the syntax was withdrawn on the assumption that the SHAPE was unsupported. Transplanting the shipped document (`MxGenAIConnector.EM_ConverseRequest`) into an 11.13 project and checking it — **0 errors** — showed the shape was fine and the reproduction was not. **When a build error contradicts a shipped marketplace module, check the module itself before believing the construct is unsupported**; the demo corpus is a ready-made oracle for exactly that. Two traps in setting that check up: a base project another session has **upgraded** (local-test-app moved to 11.14) makes mxbuild refuse the whole file, and renaming a v2 `.mpr` needs `mprcontents/mprname` updated or the loader throws `StorageMprNameDiscrepancyException`. Repro `mdl-examples/bug-tests/262-export-array-container.mdl`, test `TestExportNestedArrayContainerIsBare`. Issue #262 |", "refs": ["#248", "#262"], "ce": ["CE0061", "CE0295"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| A mapping rooted at a **nested schema element** cannot be authored, and `describe` prints it as if it were rooted at the document root — output that PARSES and executes, producing a mapping whose members do not exist at that level | Studio Pro lets the author start a mapping at any element and stores that as the root element's `JsonPath`; 13 of the 327 demo-app documents do (`OpenAI_API.IM_OpenAI` at `(Object)\\|choices\\|(Object)\\|message`, `Teamcenter.Import_ChildrenParent`, `MxGenAIConnector.IM_Collection_RetrieveNearestNeighbors`). Both executors resolved the root from the structure and had nowhere to put a selection | `mdl/executor/mapping_customhandler.go` (`resolveSchemaRoot`, `schemaRootClause`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`, `mdl/grammar/MDLLexer.g4` (`ROOT`), `mdl/grammar/domains/MDLDomainModel.g4` | `root a/b/c` on the source clause, in member names. **The path may pass through an array where a value reference may not**: the mapping is then rooted at the array's ITEM (`root choices/message` → `(Object)\\|choices\\|(Object)\\|message`), which is why this walks the index itself instead of reusing `resolvePath` — that one refuses an intermediate array because many items cannot collapse into one value (CE0256). Thread the selection through as the root's `parentPath` rather than adding a parameter: the isRoot branch already takes its lookup from there, so `\"\"` keeps meaning \"the structure's own root\" and #248's fix is untouched. DESCRIBE **derives** the clause from the stored path rather than remembering it — drop the leading segment and every `(Object)`/`(Array)` marker, the inverse of how it resolves — so a Studio-Pro-authored mapping prints one too. The round-trip proof to aim for is `Unchanged import mapping …`: the rebuild is semantically equal and ADR-0008 elides the write entirely. Repro `mdl-examples/bug-tests/267-nested-schema-root.mdl`, tests `mdl/executor/mapping_schema_root_test.go`. Issue #267 |", "refs": ["#248", "#267"], "ce": ["CE0256"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| Every member of an **array-rooted** import/export mapping is rejected: `\"id\" is not a member of the JSON structure at (Object), which has no members there` — while the identical body over an object-rooted structure works | Both executors hardcoded the root lookup to `\"(Object)\"`, and an array-rooted structure is built at `\"(Array)\"` with its item at `\"(Array)|(Object)\"` (`buildElementFromRawRootArray`). The root resolved to nothing, so the child lookup reported members \"at (Object)\" — a node that structure never had, which reads as \"your key is wrong\" rather than \"the root was looked up in the wrong place\". 122 of the 327 mapping documents in the demo apps are array-rooted, the single largest gap in the mapping surface | `mdl/executor/cmd_import_mappings.go` (`buildImportMappingElementModel`, `jsonSchemaIndex.root`), `mdl/executor/cmd_export_mappings.go` (`buildExportMappingElementModel`, `buildExportRootArrayElement`, `exportRootToPrint`) | Take the root FROM the structure instead of assuming it. No new syntax: the structure decides, and Studio Pro does not ask either. The import side then needs nothing more — the array branch was already stepping `\"(Array)\"` → `\"(Array)|(Object)\"` for NESTED arrays. **The two sides store different shapes and the difference is not guessable**: an array-rooted IMPORT mapping is ONE element at `(Array)|(Object)` (the container collapses), an array-rooted EXPORT mapping is a bare `Array` container at `(Array)` whose single child carries the entity with `ObjectHandling=Parameter`. Pin both against Studio Pro documents before writing either (`Teamcenter.IMM_ItemRevision`, `FactoryManagement.IMM_ScenarioList`, `SnowflakeIntegration.EXM_SensorData` — Evora demo app, 11.13). A second export shape exists (`DigitalTwin.EMM_EntityQuery`: entity on the container, `Find` on the item, for a parameter that OWNS the list) and MDL cannot say which is meant, so it stays unauthorable — #262. **Adding an authorable shape means teaching DESCRIBE about it in the same change**, or the newly writable mapping joins the 112 silent-loss cases of #260: the export container is not `Kind==\"Object\"`, so it fell into the value branch and printed `Root = ` with its whole subtree dropped. Discriminate the container on its stored **JsonPath**, not on `Kind` — the two engines' readers label it differently (\"Array\" vs \"Object\") and only the path is in the document. Controls: revert the root lookup and the repro returns verbatim, while the object-rooted control still passes; `mdl-examples/bug-tests/519-rest-mapping-as-list-of.mdl` goes from dying on its own mapping statement to executing. `mx check` needs the base project's own error count as the control (a blank app carries a pre-existing CE0495). Repro `mdl-examples/bug-tests/mapping-248-array-rooted-mappings.mdl`, tests `TestImportMappingArrayRoot` / `TestExportMappingArrayRoot`. Issue ako/mxcli#248 |", "refs": ["#260", "#262", "ako/mxcli#248"], "ce": ["CE0495"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| A mapping sourced from a **message definition** cannot be authored at all — MDL has `with json structure` and `with xml schema` and no third form — and `describe` of an existing one silently omits the source clause while still producing output that PARSES, so `describe` → `exec` rebuilds the mapping bound to nothing | 74 of the 327 mapping documents in the demo apps use one (the second-largest gap after the array root), 70 of them in the silent-loss class. The document is `MessageDefinitions$MessageDefinitionCollection` — a COLLECTION, which is why the reference is three parts (`Module.Collection.Definition`) — and it is derived from the **domain model**, not a payload sample: every node names an entity or an attribute and carries two names, its own (`Emails`) and the singular one its items take (`Email`) | `mdl/executor/mapping_messagedefinition.go` (`findMessageDefinition`, `messageDefPaths`, the two builders), `mdl/backend/modelsdk/messagedefinition_read.go`, `model/types.go` (`MessageDefinitionCollection`, and `XmlPath` on both mapping element types) | **A message-definition mapping stores BOTH path families** — that is the whole reason it needs its own builder rather than a branch of the JSON one: `json=(Array)\\|(Object)\\|From` beside `xml=Emails\\|Email\\|From`. The rules, measured on AgentCore.MesDef_Email / .MesDef_WorkflowDetails and Email_Connector.MD_EmailTemplate: an unbounded node contributes `ExposedName\\|ExposedItemName` to the XML path and `ExposedName\\|(Object)` to the JSON one, a single node contributes `ExposedName` to both, and the ROOT is the asymmetry — its own name is in the XML path but the JSON one is just `(Array)\\|(Object)`. `model.ImportMappingElement`/`ExportMappingElement` had **no XmlPath field** and every writer hardcoded `\"\"`, so that had to be added and carried on both engines' read and write paths first. **Do not \"helpfully\" drop the body**: the definition fixes entity, attributes and names, so a bodyless \"map everything\" form is tempting — measured, six of the ten real message-definition mappings map every exposed node and four map a strict subset (58 of 96, 27 of 30, 28 of 30, 26 of 27), so it would be lossy for 40% of them. `modelsdk/gen/messagedefinitions` already models the whole tree and decodes real documents unchanged (zero entries in `keyaudit_test.go`), so the read is one `mprread.ListUnitsWithContainer` call; the legacy engine has no parser and **refuses rather than returning an empty list**, because empty reads as \"this project has no message definitions\" and turns a real reference into a bogus \"not found\". The oracle is a Studio Pro mapping over the SAME definition: authoring `AgentCore.MesDef_Email.Email` from MDL reproduces `AgentCore.Email_Import` element for element. Repro `mdl-examples/bug-tests/mapping-263-message-definition-source.mdl`, tests `mdl/executor/mapping_messagedefinition_test.go`. Issue ako/mxcli#263 |", "refs": ["ako/mxcli#263"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A value **converter microflow** — `Attr = Module.MF(jsonField)` — is accepted, the mapping is created, and the transform is silently absent; DESCRIBE prints the element as a plain `Attr = jsonField`", "cause": "The grammar and the AST already carried it (`Converter`, `ConverterParam` in `ast_import_export_mapping.go`) and nothing downstream read either: the model element had no `Converter` field and every writer hardcoded the BSON key to `\"\"`. The visitor also never set `JsonName` for that alternative, so even with a model field the member had no name to resolve against. 39 of the 327 demo-app mapping documents use one, including the two a blank app ships (`FeedbackModule.IMM_PostResponse`, `.EXM_PostFeedback`)", "file": "`mdl/executor/mapping_messagedefinition.go` (`setMappingConverter`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go` (build + describe), `mdl/visitor/visitor_import_export_mapping.go`, `model/types.go`, and the four writers + four readers", "insight": "**A half-wired feature is worse than a missing one** — the syntax parsed, so scripts using it looked correct and produced mappings without the transform. When the grammar already has a form, check the whole chain (AST → model → both writers → both readers → describe) before assuming it works. The stored element carries **one** property, `Converter`, and no separate parameter path: the microflow's input IS the member the element binds, which is why the member belongs inside the call and there is nothing to cross-validate. The export side had **no spelling at all** (22 export value elements use one), so the mirrored `jsonKey = Module.MF(Attr)` was added — note the argument is the ATTRIBUTE there, since the direction is reversed. An unresolvable microflow is refused, same rule as an unresolvable schema source (#259). Control that matters: assert the sibling element WITHOUT a converter carries an empty one, or the test passes against a writer that stamps every element. Repro `mdl-examples/bug-tests/mapping-266-converter-microflow.mdl`, tests `mdl/executor/mapping_converter_test.go`. Issue ako/mxcli#266", "refs": ["#259", "ako/mxcli#266"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A mapping element whose object handling is **Custom** — a microflow resolves the object instead of Create/Find — cannot be authored, and `describe` of one drops the handler while still producing output that executes, so the rebuilt mapping CREATES objects where the original called a microflow", "cause": "56 of the 327 demo-app mapping documents use it. Both writers hardcoded `CustomHandlerCall` to nil, and gen models the call but not the property: `Import/ExportObjectMappingElement` has no `CustomHandlerCall` accessor at all", "file": "`mdl/executor/mapping_customhandler.go`, `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`, `mdl/backend/modelsdk/mapping_write.go` (`customHandlerToGen`, list marker + TypeDefaults) and `mapping_read.go` (`customHandlerFromRaw`), `modelsdk/gen/mappings/types.go` (STORAGE-NAME OVERRIDE), `mdl/backend/mpr/backend.go` (legacy refusal)", "insight": "**Three shapes `mx check` caught that reading the document did not**, in the order they appeared: (1) `CE0281 \"Unknown value element 'idx' selected for parameter\"` — a value-path parameter needs the value to EXIST as an attribute-less value mapping element under the object being resolved; Studio Pro adds it when you pick the value, so mxcli must too. (2) `CE5015 \"Attribute type 'String' does not match schema type 'Integer'\"` — that added element's type must mirror the schema element, since there is no attribute to derive it from. (3) the element then has to be **hidden from DESCRIBE**, because it is derived from the `by (Param: member)` clause and printing it emits ` = idx` with no attribute, which does not parse. Also: the parameter element's stored `$Type` is `Mappings$MicroflowCallParameterMappingImpl` where gen says `MappingMicroflowParameter` (161 of 161 documents) — a STORAGE-NAME OVERRIDE, patched on both the encode and decode halves; `ParameterMappings` is written even when the microflow takes **no** parameters, as the bare `[2]` (a MandatoryLists entry, like a rule's `Flows`); and `ObjectHandlingBackup` must NOT inherit \"Custom\", which is not in the `{Create, Error, Ignore}` enum — import documents store Create, export ones Error. gen declares a `ValueElementPath` that Studio Pro writes in 0 of 161 documents, so the writer builds the sub-document with the generic element helpers rather than gen. Read back from **raw BSON**, since gen has no accessor. Legacy **refuses** rather than dropping the microflow. Repro `mdl-examples/bug-tests/mapping-264-custom-object-handling.mdl`, tests `mdl/executor/mapping_customhandler_test.go`. Issue ako/mxcli#264", "refs": ["ako/mxcli#264"], "ce": ["CE0281", "CE5015"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| An export mapping's **array container** is written with an entity and association, so the MDL makes the author declare `Assoc/Entity` twice and the result matches no Studio Pro document | Studio Pro leaves the container BARE — 93 of the 93 entity-less object elements in the demo apps are array containers of the shape `et=Array entity=- assoc=- oh=Find` over `et=Object entity=… assoc=… oh=Find` at the `\\|(Object)` step (AgentCommons.EM_Agent, MxGenAIConnector.EM_ConverseRequest, SnowflakeIntegration.Export_AnyChart_Heatmap) | `mdl/executor/cmd_export_mappings.go` (the array branch of `buildExportMappingElementModel`, `exportArrayItemToPrint`) | Declare an array like a plain nested object — `Assoc/Entity as items { values }` — and GENERATE the container, the same rule #248 applied to a root array; only the object handling differs (Parameter on the root's item, Find on a nested one). **Keep honouring the old two-level spelling as written**: `Assoc/Entity as items { ItemAssoc/ItemEntity as ItemsItem { … } }` names TWO entities, one per level, which the bare-container shape cannot express — rewriting it produced **CE0295** \"Association … is not allowed\" because the item's association no longer reached its parent. It is also what DESCRIBE emitted before the change, so the doctype suite and any script in the wild use it; the integration run caught this, a unit test would not have. DESCRIBE unwraps only the BARE container (discriminate on the stored paths — the item's is the container's plus `\\|(Object)` — never on `Kind`, which the two engines' readers label differently), so an old-form mapping still round-trips to its own shape. **An entity-less PLAIN object element is a different thing**, written `group as toolConfig { … }`, and it may hold **object elements only** — a value under one is **CE0061 \"No entity selected.\"**, because a value has no entity to bind its attribute to. That constraint cost a detour worth copying: the first attempt put a value there, mxbuild refused it, and the syntax was withdrawn on the assumption that the SHAPE was unsupported. Transplanting the shipped document (`MxGenAIConnector.EM_ConverseRequest`) into an 11.13 project and checking it — **0 errors** — showed the shape was fine and the reproduction was not. **When a build error contradicts a shipped marketplace module, check the module itself before believing the construct is unsupported**; the demo corpus is a ready-made oracle for exactly that. Two traps in setting that check up: a base project another session has **upgraded** (local-test-app moved to 11.14) makes mxbuild refuse the whole file, and renaming a v2 `.mpr` needs `mprcontents/mprname` updated or the loader throws `StorageMprNameDiscrepancyException`. Repro `mdl-examples/bug-tests/mapping-262-export-array-container.mdl`, test `TestExportNestedArrayContainerIsBare`. Issue ako/mxcli#262 |", "refs": ["#248", "ako/mxcli#262"], "ce": ["CE0061", "CE0295"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| A mapping rooted at a **nested schema element** cannot be authored, and `describe` prints it as if it were rooted at the document root — output that PARSES and executes, producing a mapping whose members do not exist at that level | Studio Pro lets the author start a mapping at any element and stores that as the root element's `JsonPath`; 13 of the 327 demo-app documents do (`OpenAI_API.IM_OpenAI` at `(Object)\\|choices\\|(Object)\\|message`, `Teamcenter.Import_ChildrenParent`, `MxGenAIConnector.IM_Collection_RetrieveNearestNeighbors`). Both executors resolved the root from the structure and had nowhere to put a selection | `mdl/executor/mapping_customhandler.go` (`resolveSchemaRoot`, `schemaRootClause`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`, `mdl/grammar/MDLLexer.g4` (`ROOT`), `mdl/grammar/domains/MDLDomainModel.g4` | `root a/b/c` on the source clause, in member names. **The path may pass through an array where a value reference may not**: the mapping is then rooted at the array's ITEM (`root choices/message` → `(Object)\\|choices\\|(Object)\\|message`), which is why this walks the index itself instead of reusing `resolvePath` — that one refuses an intermediate array because many items cannot collapse into one value (CE0256). Thread the selection through as the root's `parentPath` rather than adding a parameter: the isRoot branch already takes its lookup from there, so `\"\"` keeps meaning \"the structure's own root\" and #248's fix is untouched. DESCRIBE **derives** the clause from the stored path rather than remembering it — drop the leading segment and every `(Object)`/`(Array)` marker, the inverse of how it resolves — so a Studio-Pro-authored mapping prints one too. The round-trip proof to aim for is `Unchanged import mapping …`: the rebuild is semantically equal and ADR-0008 elides the write entirely. Repro `mdl-examples/bug-tests/mapping-267-nested-schema-root.mdl`, tests `mdl/executor/mapping_schema_root_test.go`. Issue ako/mxcli#267 |", "refs": ["#248", "ako/mxcli#267"], "ce": ["CE0256"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| A mapping rooted below an array (`root choices/message`) builds a project mxbuild rejects with **CE0243** \"The mapping used to return a value of type 'X', but now returns a value of type 'List of X'\" | Such a mapping yields ONE OBJECT PER ITEM, so the import activity must bind a list. `mappingRootIsList` answered from the JSON **structure**'s root element, which for `root choices/message` is the document root — an Object — so it reported a single object. The mapping DOCUMENT is correct and cannot decide this: Studio Pro's own `OpenAI_API.IM_OpenAI` stores `MaxOccurs 1` on exactly that root (verified against the fixture), so list-ness lives only in the root's PATH | `mdl/executor/cmd_microflows_builder_calls.go` (`mappingRootIsList`, `mappingRootPathCrossesArray`) | An array contributes a marker segment for its item, so **any `(Object)`/`(Array)`/`(Wrapper)` segment after the first** means the root sits inside an array: `(Object)|choices|(Object)|message` and `(Array)|(Object)` are lists, `(Object)|data` is not. Skip the first segment — it is always the document's own root marker. Keep the existing structure-root and MaxOccurs checks as the fallback for XML-schema and message-definition mappings, which carry no JsonPath. **Found by building an app and running `mx check` on it** — every unit test in the package passed while this was broken, and so did the whole mapping fixture round-trip suite, because the defect is in the CALLER of the mapping, not the mapping. The wider lesson is the one #294 taught: a mapping that serializes correctly and builds cleanly can still do nothing at run time, so a mapping feature is not proven until data has moved through it. Repro + assertions: `mdl-examples/bug-tests/mapping-runtime-proof.mdl` and its `.test.mdl`, run with `mxcli run --local --test-endpoint` + `mxcli test --attach`. Tests `mdl/executor/cmd_microflows_nested_root_cardinality_test.go`. Follow-up to ako/mxcli#267 |", "refs": ["#294", "ako/mxcli#267"], "ce": ["CE0243"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "The nightly is green on recent Mendix versions and fails on older ones with `<mapping> now round-trips faithfully — remove it from knownLossy`", "cause": "`TestMappingFixtureRoundTrip`'s `knownLossy` is a version-blind expectation, but the document it is asserted against is not always version-stable. `loadMappingFixture` uses the **base project's own copy** whenever the blank app already ships a document of that name (FeedbackModule ships two), instead of the pinned `.bson` — and that copy changes with the Mendix version. `FeedbackModule.IMM_PostResponse` loses exactly one property, `MessageDefinition2`, which `modelsdk/gen/mappings/version.go` records as `Introduced: \"11.10.0\"`, so below 11.10 there is nothing to drop and the staleness guard fires", "file": "`mdl/executor/mapping_fixture_roundtrip_test.go` (`knownLossyFrom`, and the base-project log line in `loadMappingFixture`)", "insight": "Gate the entry with `knownLossyFrom` — `ProjectVersion().IsAtLeast(major, minor)` — rather than deleting it, or the real defect (#279) stops being caught on the versions that have it. **Only ONE of the two FeedbackModule mappings failed, and that asymmetry is the diagnosis**: the export twin also loses #277's `IsKey`/`MaxLength` and #279's `MinOccurs`, which exist on every version, so it stays lossy throughout — if both had failed, the cause would have been something else. Check a suspect property against `gen`'s `version.go` `Introduced` before theorising. The substitution that makes this possible is now **logged** (\"using the BASE PROJECT's copy\"); it was silent, which is what made a one-line cause cost a nightly. To reproduce another version locally: `mxcli setup mxbuild --version 11.6.0` then `MX_BINARY=~/.mxcli/mxbuild/11.6.0/modeler/mx go test -tags integration ./mdl/executor/`. Prove it in both directions — disable the gate and watch the nightly failure reappear on 11.6", "refs": ["#277", "#279"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE LAYOUT` prints a header and no widget structure at all, for a document with 84 elements. Nothing distinguishes it from a genuinely empty layout", "cause": "`getLayoutWidgetsFromRaw` read `rawData[\"Widget\"]`, a key `Forms$Layout` does not have. Its tree hangs off `Content` — a `Forms$WebLayoutContent` (or `Forms$NativeLayoutContent`) whose `Widgets` array holds the root. The type assertion failed and returned nil, silently", "file": "`mdl/executor/cmd_pages_describe.go` (`getLayoutWidgetsFromRaw`), `mdl/executor/cmd_pages_describe_parse.go` (`scrollContainerRegions`)", "insight": "**A `ScrollContainer` holds its regions in five named slots — `Top`, `Right`, `Bottom`, `Left`, `CenterRegion`** (the last spelled unlike its siblings), not in a list. The walk read `CenterRegion` alone, which was survivable for pages and wrong for layouts: the topbar is in `Top` and the navigation in `Left`, so the two things anyone describes a layout to see were the two it skipped. Each occupied slot is now a synthetic region node, the same way `TabControl` preserves tab pages. Controlled by restoring each half separately. ako/mxcli-ledger #136", "refs": ["#136"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A bulk `ALTER PAGES … SET LAYOUT` reports success and the build then fails with **CE1613** \"The selected placeholder … no longer exists\", naming a page rather than the statement", "cause": "The repoint rewrote `Form` and every `Parameter` without checking that the target layout declares the placeholders the page binds to, so a page bound to `HeaderLeft` got `NewLayout.HeaderLeft` pointing at nothing", "file": "`mdl/executor/cmd_pages_repoint.go` (`checkRepointPlaceholdersAgainst`), `mdl/backend/layoutplaceholders.go`, `mdl/backend/pagemutator/mutator.go` (`BoundPlaceholders`)", "insight": "**Check after MAP is applied** — `MAP (Old AS New)` exists precisely to rebind onto a placeholder the new layout does have, so checking before it would refuse the remedy. A target that reports *no* placeholders is one the backend could not read (MCP exposes none), not one that has none, so it skips rather than refusing everything. And **name the remedy in syntax that parses**: the grammar is `MAP (Old AS New)`, while the comment beside the rule had said `MAP (Main -> Main)` since it was written — the arrow reads plausibly and is a parse error", "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A caption/title/content written from MDL shows as the empty-caption placeholder (`<>`) in Studio Pro, with a \"no translation for this language\" warning, on a project whose language is not en_US. `mxcli`, `mx check` and mxbuild all report success", "cause": "Mendix has no language-neutral text — every `Texts$Translation` carries a `LanguageCode` — and every executor CREATION site hardcoded `\"en_US\"`, ignoring the project's `DefaultLanguageCode`. The read side had already been fixed for the same reason (#702, `describeDefaultLanguage`); the write side was never wired to it", "file": "`mdl/executor/describe_language.go` (`authoringLanguage`), then the ~23 creation sites: `cmd_pages_builder_v3*.go` (`pb.textLang()`), `cmd_microflows_builder_calls.go` (`fb.textLangOrDefault()`), `cmd_entities.go` / `cmd_enumerations.go` / `cmd_validationrules.go` (`authoringLanguage(ctx)`)", "insight": "**Resolve the write language from the project, never a literal.** `DefaultLanguageCode` is by definition enabled, so this cannot produce the unenabled-language case #257 warns about, and DESCRIBE reads the same language CREATE writes so describe→exec round-trips on a non-en_US project. **Two layers, two different seams.** The executor sites build a `model.Text` and can reach `ctx` — fix those first, they are the reported bug. The writer leaves (`sdk/mpr`, `modelsdk`, `widgetobj`, `pagemutator`, `modelsdk/mpr`) build a `Texts$Text` from a **bare Go string** and have no context: a widget `Label`, a pluggable column caption, a navigation item and a menu-document item all land there. **Do not thread a parameter to them** — measured, that is 183 function signatures across five packages (113 in `sdk/mpr` alone), nearly every widget writer, to carry a value constant for the whole run. They read `model.AuthoringLanguage()` instead, published once by `describeDefaultLanguage`. `ALTER PAGE … SET Caption` was never affected: it edits the stored translation in place and keeps its `LanguageCode`. The control that localises it is free: Studio Pro's own pages in the same project store the same word under the right language — and beware counting those as mxcli's, scope the search to the unit. `mx check` reports 0 errors before AND after, so it proves nothing here; assert on the stored `LanguageCode`. mendixlabs/mxcli#970", "refs": ["#257", "#702", "mendixlabs/mxcli#970"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Replaying a `create or replace snippet` silently resets its translated captions to the source language in every language. The run says `Created snippet` (on a document that already exists), `mx check` reports 0 errors, and the app renders in one language", "cause": "The snippet replace path was an unconditional **delete-then-create**. Nothing `canon.Reconcile` does survives that: by the time the create runs there is no stored document left to transplant identities from or to compare against, so translations — and anything else MDL cannot express — go with the deleted unit", "file": "`mdl/executor/cmd_pages_create_v3.go` (`execCreateSnippetV3`); the correct pattern is 40 lines above it in `execCreatePageV3`", "insight": "**A replace must be an UPDATE on the stored unit's ID, never delete+create.** Reuse `snippetsToDelete[0]` as the new document's ID, call `UpdateSnippet` (which already existed and was called nowhere), and delete only the *extra* duplicates. The verb is the tell: a path that prints `Created` on a replace is not going through the write choke point, so it gets neither the identity transplant nor the unchanged-elision. **The control is free and in the same run** — put a page and a snippet with the same shape in one script and replay it: before the fix the page reports `Unchanged` and keeps its Dutch while the snippet reports `Created` and loses it, which is what makes it a snippet defect rather than a fact about replacing documents. Second consequence the page path already documents: delete+add churns git and crashes Studio Pro's RevStatusCache. ako/mxcli-ledger #143", "refs": ["#143"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A mapping names a schema source that does not exist and mxcli writes it through — mxbuild reports it as **CE1613** \"… no longer exists\" at build time, while `mxcli check` and even `check --references` pass; and the same typo silently switches off EVERY member check in that mapping", "cause": "The schema index is empty whenever the structure cannot be loaded FOR ANY REASON, and `resolvable()` reads an empty index as \"there is nothing to validate against\" (its correct meaning for a schema-less mapping). So `with json structure M.NoSuchThing { create M.Loc { LocId = nonsense } }` had two errors and reported neither. Separately `null values` was written as free text, so `null values Banana` reached the stored NullValueOption verbatim — the enum is {LeaveOutElement, SendAsNil}", "file": "`mdl/executor/mapping_customhandler.go` (`resolveJsonStructureSource`, `canonicalNullValueOption`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`", "insight": "**Refuse at the SOURCE, do not make `resolvable()` stricter**: a NAMED but unresolvable source is an error, while NO source at all — XML schema, message definition, schema-less test mappings — must keep working, and conflating the two breaks every one of them. **An empty project and a backend that cannot LIST look identical from here**, so the refusal only fires when the listing succeeds; a listing error takes the name at face value. That distinction has teeth: two pre-existing mock tests named a structure their mock did not provide and started failing, and the right fix was to give the mock the structure rather than weaken the check — a mapping whose named source does not exist is an inconsistent model to assert against. Name what would have worked, the shape #882 established for members. **Still written through**: `with xml schema M.NoSuchThing`. A gen type exists (`modelsdk/gen/xmlschemas`) so it is verifiable, but it needs a new `ListXmlSchemas` across the interface, both engines and the mock; the silent-disabling half does not apply there, since an XML mapping never had member validation at all. Repro `mdl-examples/bug-tests/mapping-259-resolve-schema-sources.mdl`, tests `mdl/executor/mapping_source_resolution_test.go`. Issue ako/mxcli#259", "refs": ["#882", "ako/mxcli#259"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "Pages that were valid start failing **CE6206** \"Attribute paths with multiple steps cannot be used on pages that are accessible through an offline-based navigation\" — and nothing in the script that wrote them changed", "cause": "An offline navigation profile restricts every page it can reach to at most ONE association hop. Adding the PROFILE is what invalidates pages written earlier, so the error appears far from its cause. mxcli writes multi-step paths happily: a datagrid column bound `Req_Asset/Asset_Site/SiteName` stores an `IndirectEntityRef` with two steps and `mx check` reports 0 errors — correctly, until an offline profile exists", "file": "`mdl/executor/validate_offline_paths.go` (`MDL-OFFLINE01`), wired from `validate_program.go`", "insight": "**The threshold is two hops, not one** — pinned by a control inside the reference page, which carried both and had only the 2-step one flagged (`MaintenanceRequest_Asset → AssetName` accepted, `… → Asset_Site → SiteName` rejected). In MDL a hop is a slash, so the count is `strings.Count(path, \"/\")` and no BSON walk is needed. Two traps: an **XPath constraint** is also full of slashes and is NOT an attribute path, so scan attribute bindings only; and a dynamic text binds through **template parameters** rather than `Attribute:`, which is how the second reported error was written. The rule deliberately does NOT decide reachability — Studio Pro walks the whole page graph and `check` does not build the catalog — so it warns naming the profile rather than asserting an error it cannot prove. ako/mxcli-maintenance §6/§7 screenshots", "ce": ["CE6206"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create or replace navigation Phone` fails with `navigation profile not found: Phone (available: Responsive)`, and no other mxcli command adds one — so a device-specific front end cannot be built from MDL. A layout naming the missing profile then fails **CE1613**", "cause": "`CREATE OR REPLACE NAVIGATION` only ever REPLACED a stored profile. Mendix routes a phone to a Phone **profile** on the User-Agent, not on viewport width, so the profile is the thing that makes phone pages reachable", "file": "`mdl/executor/cmd_navigation.go` (creates when the name is a known kind), `mdl/backend/modelsdk/navigation_profile_add.go` (`newWebProfileBson`), `mdl/types/navigation_profile_kind.go` (the closed set)", "insight": "**Measure what Studio Pro CREATES, not what the reference project HAS.** All six web profiles store the same 14 keys and differ only in Kind and Name — offline profiles included, so there is one builder, not two. The trap is `ProgressiveWebAppSettings`: the reference app's Phone and TabletOffline profiles both carry `{Precaching: true, InstallPrompt: true}`, and a first draft copied that. Those are the USER'S settings — the schema defaults `Precaching` to false, makes the element optional, and a profile added through Studio Pro's own model API stores **null** for every kind. `mx check` reports 0 errors either way, so the only way to tell is to ADD a profile over PED (`ped_update_document`, add to `/profiles`) and read back what it materialised — reading an existing profile measures the user, not the platform. The kind set is **closed**: creating `Phone` adds what the platform routes to, creating `Mobile` would add one that never can, so an unknown name stays an error; Hybrid and native kinds are excluded for want of a reference. The kind table lives in `mdl/types` because both the executor and the backend need it and the executor must not import a backend implementation (ADR-0002). ako/mxcli-maintenance §7", "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`grant <Role> on System.User (...)` fails with `load domain model 00000000-0000-0000-0000-000000000002: open …/mprcontents/00/00/….mxunit: no such file or directory`, which reads like a corrupt project", "cause": "The System module's domain model is **not a stored unit** in any Mendix project — mxcli synthesises it from a built-in table so System entities can be REFERENCED. The write reached storage, missed the unit, and surfaced as a filesystem error", "file": "`mdl/executor/cmd_security_write.go` (`refuseSystemEntityGrant`, called right after `findModule`)", "insight": "**Refuse by name up front, not by letting the write fail.** A late failure also leaves half-applied state — the roles have already been validated by then. Say in the message that this is true of every Mendix project, or the reader goes hunting for corruption that is not there. Worth stating the consequence too: an XPath constraint that TRAVERSES System is equally unusable, so filtering `Administration.Account` by `[System.UserRoles/System.UserRole/Name = ...]` returns nothing — target a user ROLE and record who acted, which is what the maintenance app did. The guard must be case-insensitive on the module name and must not catch a module merely CONTAINING \"System\"; there is a control test. ako/mxcli-maintenance §4"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "An import mapping with `find` / `find or create` is accepted by `mxcli check` AND by `exec` (\"Created import mapping\"), and the project is then unbuildable: **CE0250** \"Object element must have a key defined if object handling is set to 'Search for an object'\" and/or **CE0251** \"Searching for an object is not allowed for the entity 'X', because it is not persistable\"", "cause": "Neither requirement was checked anywhere. `def.ObjectHandling` was carried to `elem.ObjectHandling` unconditionally, `elem.IsKey` was set nearby but never cross-checked against the handling, and the entity's persistability was not consulted at all. The failure lands a build later, so an agent generating MDL gets no signal at the point it can still fix the statement", "file": "`mdl/executor/validate_import_mapping_find.go` (`MDL-MAP02` key, `MDL-MAP03` persistable), wired from `validate_program.go` so BOTH `check` and `exec` run it", "insight": "**mxbuild reports ONE AT A TIME** — a keyless `find` over a non-persistent entity is CE0250 *only*, and CE0251 appears only once a key exists, so fixing the key half looks like it fixed everything until someone adds a key. **Persistability follows the GENERALIZATION CHAIN, not the entity's own flag**: `create entity Sub extends NpBase` stores `Persistable: true` (mxcli's own catalog reads it as PERSISTENT) and mxbuild still says CE0251 — a rule reading the flag misses exactly that case, and the control (`Sub extends Keeper`, persistable parent) must stay silent. Both errors are raised **per object element**, not only at the root (\"at Object mapping element 'Pet'\"). A **custom handler is exempt from both** — the executor stores ObjectHandling \"Custom\" whatever keyword was written, and 70 of the demo corpus's 88 `find` elements are that shape, so missing the exemption flags most real mappings. Resolve fail-OPEN: an entity that is in neither the script nor the project is *unknown*, never assumed non-persistable. Sweep control: describing all 151 corpus import mappings and re-checking gives 0 flags, and stripping the `key` markers from that same output gives 18 — a sweep that only shows zero proves nothing (an earlier run's \"0\" was a concatenated file that never parsed). ako/mxcli#253", "refs": ["ako/mxcli#253"], "ce": ["CE0250", "CE0251"], "rules": ["MDL-MAP02", "MDL-MAP03"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create entity X extends <parent>` passes `mxcli check --references` with \"All references valid\" whatever the parent is, then the build reports **CE1613** \"The selected entity 'X' no longer exists\" — or, if the parent was written unqualified, `mx check` dies with **System.AggregateException … 'Generalization' property** and validates nothing at all", "cause": "An entity's EXTENDS target was never collected as a reference. The generalization is stored BY NAME and written verbatim, so mxcli had no opinion about whether it resolved", "file": "`mdl/executor/validate_generalization.go` (`validateEntityGeneralization`, `checkGeneralizationQualified`, MDL069), wired from `validate.go` (`CreateEntityStmt` case), `cmd_enumerations.go` (`ValidateEntity`) and `cmd_entities.go` (`execCreateEntity`)", "insight": "**The two failures are different sizes and want different gates.** A qualified-but-missing name is recoverable (the project loads, the build reports it) and needs the project to detect, so it belongs in the reference check. An UNQUALIFIED name makes the .mpr unopenable — same shape as #973's bare attribute name — and is a static property of the statement, so it is also MDL069 (fires with no project, which is what makes a `.fail.mdl` catchable by `make check-mdl`) and an executor guard at the TOP of `execCreateEntity`, before the module is auto-created, so `exec --no-check` cannot write it and a statement that can never be valid leaves nothing behind. **Resolve against the whole script, not the statements before it**: a generalization is resolved lazily and `create entity A extends B; create entity B;` is correct — `eagerDefRefs` says so explicitly, and a per-statement executor guard would break it, which is why only the syntactic half runs there. Controls worth keeping: a forward reference, `System.Image`, and an entity from a marketplace module must all still pass.", "refs": ["#973"], "ce": ["CE1613"], "rules": ["MDL069"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DROP ENUMERATION Mod.Name` reports \"enumeration not found\" for one that `SHOW ENUMERATIONS`, `DESCRIBE ENUMERATION` and `ALTER ENUMERATION` all resolve in the same session", "cause": "The enumeration is inside a FOLDER, so its `ContainerID` is the folder's ID rather than the module's. DROP resolved the owning module with `findModuleByID`, which matches module IDs only, and the failed lookup `continue`d — dropping the candidate silently, so the match list came out empty", "file": "`mdl/executor/cmd_enumerations.go` (`execDropEnumeration`); the trap was `mdl/executor/helpers.go` (`findModuleByID`, now removed — DROP was its only caller)", "insight": "Resolve a container through `getHierarchy(ctx)` + `h.FindModuleID` + `h.GetModuleName`, which is what the other three commands already did — **never compare a `ContainerID` against the module list**, because it is only a module ID for an element at the module root. The helper that invited the mistake is gone rather than left for the next caller. Two controls belong in the fixture: an identical enumeration at the module ROOT (it passed before the fix, so it proves this is container resolution rather than \"drop is broken\") and one whose container walks to no module at all (must still be skipped, not dropped under a guessed name). Test-fixture trap met while writing it: an element created with the folder as its container has `ContainerID == folderID`, so registering `withContainer(h, enum.ContainerID, folderID)` writes folder → folder and hides the module behind a self-loop; register the FOLDER's parent only."}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `validation feedback $Var/Attr` on an INHERITED attribute builds as **CE1613** \"The selected attribute 'Mod.Child.Attr' no longer exists\", while `mxcli check --references` passes and DESCRIBE renders the statement back unchanged", "cause": "Mendix qualifies a member reference against the entity that DECLARES it, so an inherited attribute carries the ancestor's name. The builder used `fb.varTypes[variable]` — the variable's declared type — with no generalization walk. Both engines", "file": "`mdl/executor/cmd_microflows_builder_calls.go` (`addValidationFeedbackAction`, `declaringMemberRef`), walking via `mdl/executor/entity_hierarchy.go` (`DeclaringMemberRef`)", "insight": "Same rule as #758 (access rules) and #703 (mappings), unlearned one layer over — when a member reference is built anywhere, ask whether it needs the DECLARING entity. **Do not reuse `ResolveMemberRef` for this**: its walk stops at `System.User` because a user entity's platform members must not appear in an ACCESS RULE (CE0066), which says nothing about referring to one from a microflow — reusing it falls back to the child's name, the exact bug being fixed. `DeclaringMemberRef` is the full-chain walk; the two stops are different questions and are kept apart deliberately. Controls that must be in the fixture: an attribute the entity declares ITSELF (a walk returning an ancestor for everything passes the inherited cases and is just as wrong), and the no-backend path, which keeps the naive spelling rather than emptying the reference.", "refs": ["#703", "#758"], "ce": ["CE0066", "CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A list widget over `$currentObject/Mod.Assoc` builds as **CE1613** \"The selected attribute 'Mod.<WrongEnd>.Attr' no longer exists\" — the rows are typed as the association's other end — when the page's context object is a SPECIALIZATION of one end. `mxcli check --references` passes", "cause": "`resolveAssociationDestination` picks the end opposite the context by comparing qualified names with `==`. A specialization equals neither end, both ends resolve so neither empty-end fallback applies, and control reaches `return childEntity` under the comment \"default to the child (TO) side, which matches the common FROM=context pattern\"", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`resolveAssociationDestination`, `isSpecializationOf`, `generalizationOf`)", "insight": "**A comment saying \"the common pattern\" is a guess, and a guess that is silent when wrong is the bug.** Walk the generalization chain before falling through — over the domain models `pb` has ALREADY loaded, the same list the ends are resolved against, so the two cannot disagree about what an entity is (going through the backend would be a second source of truth for the same question). Apply it only when BOTH ends resolved: when one is empty the existing fallbacks are load-bearing (issuetracker #14) and a destination of \"\" makes the .mpr unloadable. The cross-association branch has the same `==` and needs the same treatment. Controls, ideally on one page: the context being the end ITSELF (reverse) and forward navigation from the other end — both passed before the fix, which is what makes this \"the context is a specialization\" rather than \"reverse navigation is broken\".", "refs": ["#14"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A microflow's `create` / `retrieve` / `create list of` naming an entity WITHOUT a module prefix passes `mxcli check --references` with \"All references valid\", then `mx check` fails to LOAD the project — `The text 'Name' is not a valid AttributeIdentifier` — so nothing else is reported either", "cause": "The reference collector skipped any entity reference whose `Module` was empty, and the builder writes the property only when both Module and Name are set. So an unqualified name was neither validated nor written: `create` stores no `Entity` key at all (its member assignments then reach disk as bare words) and `retrieve` stores the equally invalid `\".Thing\"`", "file": "`mdl/executor/validate_microflow.go` (`checkQualifiedEntityRef`, MDL008 — the rule that already covered PARAMETERS), plus the guards in `validate.go` (`refs.entities`) and `cmd_microflows_builder_actions.go` that let it through", "insight": "**This is upstream #973 and the reported trigger is not the cause** — omitting `$X =` reproduces nothing on either engine; the entity is stored correctly. Chase the *reported symptom* (\"Entity reference remains empty\") rather than the reported *cause*. Control that separates the two: a QUALIFIED name that resolves to nothing was always caught (`entity not found: … (referenced by create)`), so it is the absent prefix, not the absent entity, that opened the hole. Prefer a project-less lint rule over a reference-check entry for this class: it is a static property of the statement, so it also fires with no `-p`, gates `exec`, and makes a `.fail.mdl` that CI can actually run. Related trap found alongside: DESCRIBE prints `$NewObject = create …` for an activity whose output variable is empty — a name invented at format time (`cmd_microflows_format_action.go`), so reading a document back through describe cannot tell you whether the variable is set.", "refs": ["#973"], "rules": ["MDL008"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A task-page button \"does nothing\": the microflow runs, no error is shown, and the runtime log has `Client: You can't complete this user task, it is not assigned to you`. `mxcli check`, `mx check` and the build are all clean", "cause": "`SET TASK OUTCOME` was called on a user task nobody had claimed. `TARGETING XPATH` / `TARGETING MICROFLOW` decides who may SEE a task — it does NOT assign it, and there is no `ASSIGN TASK` statement", "file": "`mdl/executor/validate_task_claim.go` (`ValidateTaskClaims`, MDL-WORKFLOW10), wired from `validate_program.go`; the platform rule is in `.claude/skills/mendix/write-workflows/SKILL.md`", "insight": "Claiming is a plain write to the Assignees association and must come BEFORE the outcome: `change $Task (System.WorkflowUserTask_Assignees = [%CurrentUser%]); commit $Task; set task outcome …`. Two things the rule needs: walk the body **in order** (a claim written after the outcome does not help, so collecting all claims first would pass it), and match the association on its **member name** — it parses qualified, bare and quoted, and matching one spelling would warn about correct code. A WARNING, never an error: the task may be claimed in a microflow this one calls, so accept a claim inside a branch rather than trying to evaluate the condition. Related trap: `WorkflowUserTask.Name` holds the task CAPTION, not the activity name, so an inbox routed on the activity name silently never matches. ako/mxcli-maintenance-2"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A `CALL WORKFLOW` whose parameter mapping is written across two lines builds to **CE0109** `\"Undefined variable 'Request\\n  '\"`. The identical call on ONE line is fine, and `CALL MICROFLOW` is fine at any width", "cause": "The workflow context is stored as a variable NAME, but it is filled from an expression SOURCE — and the visitor deliberately preserves an expression's trailing whitespace so a multi-line expression round-trips byte-for-byte (`appendExpressionListTrailingWhitespace`)", "file": "`mdl/executor/cmd_microflows_builder_workflow.go` (`addCallWorkflowAction`)", "insight": "**Trim the NAME, not the expression.** The obvious fix — a `TrimSpace` in the visitor — breaks the round-trip the whitespace exists for, and there are tests pinning it (`TestRetrieveRangeExpressionsPreserveTrailingWhitespace` and friends). The asymmetry between CALL WORKFLOW and CALL MICROFLOW **is the diagnosis**: microflow arguments stay expressions, where trailing whitespace is harmless, so anywhere an expression source is used as a NAME is the place to look. Trim BEFORE stripping the leading `$`. The control must assert the exact string — the name looks correct in most output until printed with `%q`. ako/mxcli-maintenance-2", "ce": ["CE0109"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A page builds to **CE1571** \"No argument has been selected for parameter 'X' and no default is available\" while `mxcli check --references` passes — the microflow data source was written as `datasource: microflow M.F` with no arguments", "cause": "Nothing compared the flow's SIGNATURE against the data source's arguments. The microflow itself resolves, so the reference check was satisfied and the fault only surfaced at the far end of an `mx check`", "file": "`mdl/executor/validate_datasource_args.go` (`validateDataSourceArguments`, `dataSourceArgErrors`, `buildFlowParameterNames`), wired from `mdl/executor/validate.go` for both pages and snippets; `scriptContext.flowParams`", "insight": "**An ERROR, not a warning, and the measurement is what licenses that**: a page with NO parameters and a page WITH a `$Task` parameter of the microflow parameter's exact entity type BOTH get CE1571, so Studio Pro does not auto-map an object in scope and a missing argument is never filled in. Mendix's own wording (\"no default is available\") suggests otherwise — measure before trusting it. Three controls the rule needs or it is worse than nothing: a **parameterless** microflow with no parens must stay clean (the common case — flagging it would get the rule turned off), an **unresolvable** flow must be left to `validateWidgetReferences` (else a typo'd flow NAME is reported as a missing ARGUMENT, pointing at the wrong line), and the **correct** form must pass. Record script-defined flow signatures in `scriptContext.flowParams` the way `javaActions` already does, or the check only ever fires on a flow that already existed — one script creating a data source microflow and the page that binds it is the common shape. Verified both ways against mxbuild: the flagged widget is exactly the one CE1571 names, and the corrected example builds at 0 errors. ako/mxcli-maintenance-2", "ce": ["CE1571"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`create user role Administrator (...)` fails with `user role already exists`, and since `exec` halts on the first error every later statement in the security script is skipped — leading to the conclusion that `CREATE OR MODIFY USER ROLE` does not exist", "cause": "It does exist and is re-runnable; it requires the parenthesised module-role list, so `create or modify user role Administrator;` fails with `mismatched input ';' expecting '('` — which reads as \"unsupported verb\" rather than \"missing argument\"", "file": "`mdl/executor/cmd_security_write.go` (the `NewAlreadyExists` site)", "insight": "**Name the re-runnable form in the error.** A blank Mendix app already ships an `Administrator` user role, so this fires on the first realistic security script. Before adding \"missing\" MDL surface from a field report, run the statement — this one was filed as a missing feature and was a discoverability failure. ako/mxcli-maintenance-2"}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`ContentParams: [{1} = $PageVar]` comes back from DESCRIBE as `<unbound>`", "cause": "TWO different faults wearing one symptom. On the DEFAULT engine the write is CORRECT — the stored parameter carries `SourceVariable { LocalVariable: \"Name\" }` — and the READER looked only at `SourceVariable.PageParameter`, found no `AttributeRef` beside it, and fell through to `<unbound>`. On the LEGACY engine the write really was wrong: it put every binding in `PageParameter`, ignoring the kind", "file": "`mdl/executor/cmd_pages_describe_pluggable.go` (`sourceVariableBinding`, now shared), `mdl/executor/cmd_pages_describe_output.go`, `sdk/mpr/writer_widgets.go` (the legacy three-way branch)", "insight": "**Read the stored bytes before believing \"silently dropped\"** — half of this report was the tool disagreeing with itself, not with Mendix, and re-executing the describe output is what would have made it true. Studio Pro populates exactly one of `LocalVariable` / `PageParameter` / `SnippetParameter` on the same `Forms$PageVariable`; a local variable renders bare (`$Name`), the other two carry an `AttributeRef` and render `$Name.Attr`. **Two describers for one stored shape is the actual defect** — the pluggable one already read all three and the other did not, so they now share one resolver rather than being fixed twice."}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A page variable declared `Enumeration(Mod.Enum)` is stored and described as `String`; a variable typed `Unknown` reverts to `String` on the next page rewrite", "cause": "Two silent defaults, stacked. `mdlTypeToBsonType` had no enumeration case and returned `DataTypes$ObjectType` for anything unrecognised; `localVarTypeToGen` then had no ObjectType case and returned a `StringType`. A type nobody had mapped came out as \"String\", twice, without a word", "file": "`mdl/executor/cmd_pages_builder_v3.go` (`pageVariableType`, `pageVariableMDLType`), `mdl/backend/modelsdk/page_write.go` (`localVarTypeToGen`), `sdk/mpr/writer_pages.go` (`serializeLocalVariables`), `mdl/executor/cmd_pages_describe.go`", "insight": "The qualified name was in the AST all along — the visitor keeps the data type's raw SOURCE TEXT, so `Enumeration(Mod.Status)` arrives complete and only needed parsing; look there before adding a field. A `DataTypes$EnumerationType` needs its `Enumeration` by-name key or Mendix resolves it to null, so an enumeration with no qualified name is deliberately NOT written as one. Fix all four corners together — builder, both writers, and DESCRIBE — or the round trip loses the type at whichever end was missed; `Unchanged page …` on a describe → exec is the proof that reader and writer agree. Stacked defaults are the pattern to look for here: each one is individually defensible and together they erase information."}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`describe page` emits MDL that mxcli's OWN `check --references` rejects — `duplicate widget name 'row1' … (CE0495)` — on stock pages nobody edited", "cause": "The names are DERIVED at describe time and Mendix stores none of them: `Forms$LayoutGridRow` and `Forms$LayoutGridColumn` carry no `Name` key, and a DataGrid2 column's name is derived from its bound attribute (mxcli says so itself in MDL-WIDGET16). Rows and columns restart numbering per grid, and two columns over one attribute derive one name — so the check was citing a Mendix error for something Mendix does not check", "file": "`mdl/executor/validate_page_context.go` (`checkDuplicateWidgetNames`, `widgetKindsWithoutStoredNames`)", "insight": "**Ask whether the model even HAS the name before enforcing uniqueness on it** — dump the stored widget and look for the `Name` key. A name mxcli invented cannot be a duplicate of anything. This one is also worth remembering for how the triage was WRONG: the first read predicted describe should renumber and called exempting them \"the weaker choice\"; measuring reversed it twice, because there is no stored name to make unique AND `ALTER PAGE` already handles a repeated derived column name (\"column %q is ambiguous … qualify the reference as `ON gridName.%s`\"), so renaming would have broken documented addressing to fix a non-collision. The control is mandatory here: two widgets Mendix DOES name, sharing a name, must still be reported, or the change reads as \"stop checking for duplicates\".", "ce": ["CE0495"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| A literal tab typed into an MDL string reaches the model as the two characters `\\t`, so a tab-delimited export becomes one cell per row and the failure looks like a Java bug. A literal NEWLINE in the same string survives, which makes the asymmetry easy to miss | `quoteExpressionLiteral` escaped `\\n`/`\\r`/`\\t` before writing the **Mendix expression**, applying MDL's escaping rules to a different grammar. Mendix's expression engine has exactly one escape — an apostrophe is doubled — and no backslash escapes at all, so the stored `'a\\tb'` IS a backslash and a `t`. The newline survived for an unrelated reason: a multi-line expression is kept as raw SOURCE text (`ast.SourceExpr`) and never reaches the escaping | `mdl/executor/cmd_microflows_helpers.go` (`quoteExpressionLiteral`, `expressionToString`) | **Measure the value where it lands, not where it is written.** Proven end to end against a running 11.13 runtime, straight out of Postgres: before, `length 4, 61 5c 74 62` (`a \\ t b`); after, `length 3, 61 09 62` (a real tab). The escaping had a *documented rationale* that was simply false — \"STRING_LITERAL does not accept them raw\" — when the rule is `'\\'' ( ~['\\\\] \\| '\\\\' . \\| '\\'\\'' )* '\\''` and `~['\\\\]` admits every byte but an apostrophe and a backslash. **Read the grammar rather than the comment about it.** Round-trip is the thing to control: assert describe → exec reproduces the same stored bytes, and use the real parser (`visitor.Build`) rather than a hand-mirrored decoder — the old test asserted \"output contains no control bytes\", which was asserting the bug. A backslash followed by n/r/t is still doubled and still wrong for the same reason (3 stored chars where 2 were meant); it is load-bearing because describe emits the stored expression verbatim, so removing it needs describe to escape on output. Measured blast radius: 0 backslash escapes in any string value across 33,645 units in 90 projects. ako/mxcli-captrack #5 |", "refs": ["#5"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "An attribute or entity named `Month` / `Year` / `Quarter` / `Day` passes `check --references`, then a view entity added weeks later fails **CE0174** (\"The 'Month' part is incomplete or incorrect\")", "cause": "An **OQL** reserved word, used **unquoted**. Three grammars stack and each treats quoting differently: MDL parser keywords (quoting works), Mendix platform reserved words (MDL021/CE7247, quoting does *not* — the check strips them), and Mendix **OQL** keywords (quoting **does** work — double quotes, as in SQL)", "file": "`mdl/executor/validate_oql_reserved_names.go` (MDL071, at CREATE/ALTER ADD/RENAME); `mdl/executor/oql_type_inference.go` (MDL032, inside a view's OQL)", "insight": "**Read the CE0174 text before concluding a name is unusable — it lists `OPEN_QUOTE` among what the parser expects.** Measured on 11.13.0: `select s.\"Month\" as MonthNo` and `from Module.\"Year\" as s` both build at **0 errors**, and mxcli passes the quotes through unchanged, so the fix is normally a quote in the view, not a rename. The one place quoting is unavailable is an **alias**, and that limit is **OQL's own**: it takes a bare identifier there for *any* name (`as \"Total\"`, reserved nowhere, is CE0174 too — reported as MDL072), so a view entity's own attribute (whose name IS its select alias) must be renamed. Hence MDL071 is a warning at the point the name is chosen, not an error. **This entry has corrected itself twice, both times by finally reading the error text.** First it asserted OQL had no quoted-identifier form (disproved by `OPEN_QUOTE` in the CE0174 message, and by the source report's own narrative: `SELECT \"Year\" FROM …` works). Then it asserted the alias limit was MDL's grammar rather than OQL's (disproved by `as \"Total\"` — reserved nowhere — also failing CE0174). The two CE0174 texts differ precisely in whether `OPEN_QUOTE` is listed; that difference is the whole answer and was present in the output from the first measurement onwards. Also: adding a warning to `ValidateEntity` surfaced a pre-existing trap — the exec guard was `if len(vs) > 0 { fail(vs[0]) }`, so every warning blocked the write and MDL022 had been doing so since it shipped. Use `firstBlockingViolation`, never the count; control that an MDL021 error still blocks and is not shadowed. ako/mxcli-captrack #1", "refs": ["#1"], "ce": ["CE0174", "CE7247"], "rules": ["MDL021", "MDL022", "MDL032", "MDL071", "MDL072"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check` passes and `exec` prints `Created association`, then the project no longer OPENS — `KeyNotFoundException … at StreamingBsonUnitReader.ResolvePostponedProperties()`, a stack trace naming no document", "cause": "An association whose FROM entity lives in ANOTHER module. Mendix stores an association in the module of its FROM entity, so a remote FROM writes a `ParentPointer` aimed at an element in a different unit. Not a build error — a LOAD error, so Studio Pro cannot open it either", "file": "`mdl/executor/validate_association_module.go` (`ValidateAssociationModules`, MDL070), wired in `mdl/executor/validate_program.go`", "insight": "**Refuse; there is nothing to write instead.** Neither stored form can express it: `DomainModels$Association` holds two element IDs both local to the unit, and `DomainModels$CrossAssociation` holds a local `ParentPointer` plus a BY_NAME `ChildRef` — there is no by-name PARENT. Check the storage shape before treating a direction as a writer bug. The reported case was `from System.User`, but it is **not System-specific** — `from Administration.Account` fails identically, and a guard keyed on System would pass the general case through; the rule is the module boundary. Control both ways: the supported direction (`from MyModule.X to System.User`) and a plain same-module association must stay at 0 errors, and stubbing the guard must bring the KeyNotFoundException back. To locate a dangling GUID at all, scan every `.mxunit` for the raw 16 bytes in BOTH endiannesses (`uuid.bytes` and `uuid.bytes_le` — little-endian is the one that hits). **Run `make check-mdl` before pushing any new `mdl-examples/` file**: CI runs every example as a POSITIVE test unless it is named `*.fail.mdl`, so a fixture demonstrating a refusal fails the build. Split it — refused statements in the `.fail.mdl`, working forms in a sibling `.mdl`, each pointing at the other — so both halves are actually gated rather than only the negative one. ako/mxcli-captrack", "rules": ["MDL070"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| `mxcli check --references` refuses a page mxbuild builds, with \"microflow data source M.F has no argument for parameter 'P' … does not fill it in, even when an object of the right type is in scope\" (CE1571) | `mdl/executor/validate_datasource_args.go` | The rule was generalised from a sound measurement to a false one. A page **parameter** of the parameter's type does not auto-map (measured, still true); an enclosing **data context** of a compatible type **does**. The two are different things and the message asserted the wrong one as fact. Re-measured on mxbuild 11.13.0, five widgets in one `mx check`: nested in a dataview of the parameter's type → **no error**; matching context two levels up with a mismatched dataview between → **no error**; mismatched context → CE1571; no context → CE1571; page parameter of the exact type → CE1571. The walk now carries a `dataContext` (the entity types of the enclosing data containers), resolved from the container's data source — a flow's **return** type, a `database` source's entity, a `parameter` source's page-parameter type. An **association** or **selection** source marks the context *unresolved*, which **suppresses** the report: guessing wrong in that direction is exactly what rejected the working page. A **primitive** parameter is always reported (a data context can never supply a String), which is what keeps the rule sharp. The three rejected shapes are the controls — without them the fix is indistinguishable from deleting the rule. Generalisation is delegated to `entityCompatibility`, which accepts a relation in **either** direction: a missed CE1571 costs a build error mxbuild still catches, a wrong refusal costs a working page. |", "ce": ["CE1571"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| `mxcli check` warns MDL071 \"attribute 'Year' is an OQL reserved word — … a view entity referencing it unquoted fails to build with CE0174\" on a **non-persistent** entity | `mdl/executor/validate_oql_reserved_names.go`, `mdl/executor/cmd_enumerations.go` | The warning's premise cannot arise: an NPE has no table. Measured rather than reasoned about, by pointing a view entity at one — mxbuild 11.13.0 refuses the **reference**, not the name: `CE0174 \"Entity 'X' cannot be used in OQL, because it is a non-persistable entity\"`. `oqlUnreachable` skips a **known** non-persistent entity, for both the attribute name and the entity's own name. Persistence had to become **three-valued** (`entityPersistence`): `ALTER ENTITY … ADD ATTRIBUTE` carries no kind, and the two rules keyed on it want opposite defaults for \"unknown\" — MDL020 stays silent unless known persistent, MDL071 stays loud unless known non-persistent. The old boolean passed `false` for ALTER meaning *unknown*, so a naive gate on it would have silently dropped MDL071 from the path where a name lands on an entity that already has references. VIEW and EXTERNAL entities count as reachable — a view entity's own attribute name **is** its select alias, the one MDL071 case that genuinely needs a rename. |", "ce": ["CE0174"], "rules": ["MDL020", "MDL071"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| `mxcli check … --references` reports \"nanoflow not found: Mod.Flow\" for a nanoflow created **earlier in the same script**, printed directly under the line \"(Note: References to objects created within the script are skipped)\". `exec` runs the same file without complaint and `mx check` is 0 errors | `mdl/executor/helpers.go` (`validateWidgetReferences`) | One omission in a list of five. The function consults `sc.<kind>` — the same-script exemption — for microflows, pages, snippets and entities, and for **nanoflows alone** it did not, so every widget reference kind was exempt except that one. Fix is `&& !sc.nanoflows[ref]`, matching its four siblings. Note this is the **inverse** of MDL-ORDER01, which exists to catch a reference to something created *later*; a rule pair like that is worth checking in both directions when one half is added. The test asserts all the kinds in one table so the omission cannot reappear on a different line, and the control is a nanoflow in neither the project nor the script, which must still be reported. Reported as ledger #138; example `mdl-examples/bug-tests/ledger-138-snippet-nanoflow-same-script.mdl` |", "refs": ["#138"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`mxcli check --references` and `exec` both pass, then the native `mx check` fails **CE6681** \"It is not possible to jump to end activities or jump-to activities\" on a workflow `jump to`", "cause": "`buildJumpTo` set the jump activity's **`Name` to its target's name**. Mendix resolves `TargetActivity` **by name**, so the jump could resolve to itself — and CE6681 then describes a different fault than the real one (an unresolved target, or a stolen name)", "file": "`mdl/executor/cmd_workflows_write.go` (`buildJumpTo`, `deduplicateActivityNames`), `mdl/executor/validate_workflow_jump.go` (MDL-WF05)", "insight": "**A jump target is the only INTRA-document reference a workflow has, and nothing resolved it** — `validateWorkflowStatementRefs` covers external refs (microflows, pages, entities) and returns before looking at activity names. Two defects, and the second is not in the report: naming the jump after its target also breaks a **forward** jump to a *valid* activity, because deduplication renames the SECOND activity carrying a name — measured, `jump ... then StepB` gives the jump `StepB` and the real target `StepB2`. The reported \"works\" row of the trigger table holds only for a backward jump, which is why loops looked fine. So fixing only the unresolved case would have left the other half. Fix both ends: give the jump its own name (`JumpTo`, deduped) so it can never collide, **and** run deduplication in two passes with jumps LAST so a jump never claims a name a real activity wanted. Wire the rule into `ValidateWorkflow` **and** call the same function from `execCreateWorkflow` (the #833 lesson — exec is reachable without check). Compute the valid-target set by running the real builders over the AST rather than re-deriving names: a `call microflow M.SUB_X` activity is named `SUB_X`, and a second copy of that rule would drift into false refusals. List the valid names in the suggestion — they are not visible in the script, which is most of why the wrong one is easy to reach. Exclude jumps from the target set (CE6681 again). Two traps hit while doing it: a nested `if jumpPass { if !jumpPass {` from a careless bulk edit silently disabled all jump renaming (caught only by a two-jump uniqueness test — CE0495 would have been the next report), and `Inner` is an MDL keyword, so a test fixture using it fails to parse for reasons unrelated to the fix. mendixlabs/mxcli#1005", "refs": ["#833", "mendixlabs/mxcli#1005"], "ce": ["CE0495", "CE6681"], "rules": ["MDL-WF05"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE WORKFLOW` output fails `mxcli check` — `mismatched input '[%UserRole_Banker%]' expecting ';'` on a `targeting users xpath` line, and every later statement cascades", "cause": "The emitter wrote `fmt.Sprintf(\"… '%s'\", v)` — quotes in the format string, escaping (if any) at the call site. **6 of 23 emit sites did not escape**: both xpath variants, the user-task caption, the workflow-level due date, and both outcome values", "file": "`mdl/executor/cmd_workflows.go` (all 23 sites), `mdl/executor/identifier_quoting.go` (`mdlQuoted`)", "insight": "**Return the quotes WITH the escaping** — `mdlQuoted(s)` yields `'…''…'` complete, so an unescaped emit cannot be written by omission. Escaping at the call site is one thing to remember per site, and the count of sites only grows. Assert the emitted MDL **parses** (wrap the fragment in a minimal `create workflow … end workflow;` and run `visitor.Build`), never that it contains a particular escape — a substring assertion encodes the very escape under test, so it passes for the wrong reason. Route the harness through `formatWorkflowActivities`, not the per-activity formatter: the statement terminator is appended by the caller, so calling the formatter directly produces unparseable output for reasons unrelated to the bug. Emit tests only cover positions the test constructs, so add a **source scan** for a literal `'%s'` in the describers — the real failure mode is a *new* site added later, and `mdlQuoted` carrying its own quotes is what makes that scan sound. The reported symptom was the XPath (its payload is full of quoted constraints, so *every* XPath-targeted user task hits it); the caption one needs only an apostrophe — `Manager's review`. mendixlabs/mxcli#1006", "refs": ["mendixlabs/mxcli#1006"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`DESCRIBE WORKFLOW` output is refused by `mxcli check` with **MDL-WF04** — \"a standalone `annotation` … produces a model Mendix cannot load\"; 13 errors from one unmodified describe of a 23-activity workflow", "cause": "The describer emitted `annotation '<text>';` — the exact construct MDL-WF04 exists to refuse, and that `execCreateWorkflow` refuses again. Two parts of the tree disagreed **in comments**: the emitter said \"emitted as a parseable MDL statement so it survives round-trips\", the validator said it cannot be loaded. The emitter's comment was the stale one", "file": "`mdl/executor/cmd_workflows.go` (`formatAnnotation` + the `WorkflowAnnotationActivity` branch), refusals in `mdl/executor/validate_workflow.go` and `cmd_workflows_write.go`", "insight": "**When a describer and a validator disagree, one of them has a stale comment — read both before choosing a side.** The reporter framed these as canvas annotations; they are not. `formatAnnotation` is called at 10 sites, always with an activity's **attached** `Annotation`, and describe converted attached → standalone, which is the refused form. That distinction changes the fix: the issue's \"support writing annotations\" needs a grammar change, because `MDLWorkflow.g4` has only the standalone `workflowAnnotationStmt` — **no MDL input can express an attached annotation today**, even though the write path stores one. So a comment loses nothing that was reachable. Note the asymmetry that caused this: the **microflow** domain has `@annotation 'text'` as an activity prefix and round-trips it properly; giving workflow activities the same prefix is the non-lossy fix, and is a feature, not this bug. Two traps: a `--` comment runs to end of line, so a multi-line annotation must be prefixed **per line** or the tail becomes stray tokens (the same failure the statement form had), and the standalone branch must set `isComment` or the terminator logic appends `;` to a comment. Assert the emitted MDL **parses AND passes ValidateWorkflow AND still contains the text** — checking only that the keyword is gone also passes for an emit that dropped the annotation entirely. mendixlabs/mxcli#1007", "refs": ["mendixlabs/mxcli#1007"], "rules": ["MDL-WF04"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| Every `IMAGE` widget mxcli authors on Mendix 11.13 fails `mx check` with **CE0463** \"the definition of this widget has changed\", including the exact `pluggablewidget` form an existing bug-test documents as fixed. `mxcli fix widgets` clears it | `mdl/executor/widget_engine.go` (`hiddenUnnamedProperties`, the mapping loop) | **Case B**, established before any hypothesis (diagnose-ce0463 Step 0): the baseline blank project ships **10 Studio Pro-authored widgets of the same widget id** and reports **0** CE0463; one mxcli-authored Image makes it 1. So the tool is the variable — and those 10 are a known-good reference in the same project, better than a template extraction. The exhaustive path diff came back with **every path present on both sides** and four differing values, two of them content; the `Type` (PropertyTypes schema) subtree and the `TypePointer`→`PropertyKey` mapping were identical. **Two hypotheses tested and falsified, which is why they are recorded**: (a) *key order* — mxcli's node is not in the reference's alphabetical order, a documented CE0463 cause, but the same page's mxcli-authored Datagrid and Badge share that order and pass; (b) *the width value* — authoring `Width: 48` explicitly passes, so 48 is not rejected. The cause is the interaction: the widget **hides `width` when `widthUnit` is \"auto\"**, and a hidden property must hold its DECLARED default. The engine *skipped* the mapping for a hidden property, which leaves the widget **template's captured value** — image.json holds 48 while its own `ValueType.DefaultValue` says 100. mxcli's own **MDL-WIDGET10** already said so verbatim (\"a non-default value there fails the build with CE0463 (the default is \\\"100\\\")\"), so `check` refused what `exec` emitted: the fix makes the writer read `widgetPropertyDefaults`, the checker's own source, so the two cannot disagree again. The engine's comment already stated the invariant correctly — \"the hidden ones **at their default**, so hidden means default-valued, not absent\" — and skipping only coincides with that when the template happens to be at the default. Where no default can be looked up (a datasource has none) it still skips, so #956's File Uploader pruning is unchanged. **Control**: stub the `SetPrimitive` and CE0463 returns end-to-end. Follow-on the fix *revealed* (CE0463 was masking it): the default `ImageType: image` needs an image-collection entry MDL cannot name, so the bare form builds to Mendix's own \"No image selected.\" — now **MDL-WIDGET22** at check time, and it found the same breakage in four of the repo's own examples. Reported as mxcli-formula1 FINDINGS §69/§142 |", "refs": ["#956"], "ce": ["CE0463"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| An `image` widget mxcli wrote shows nothing, and `mx check` fails with **\"No image selected.\"**; and a `describe` → rename → `exec` copy of an Atlas layout (or any page with a brand image) comes out with the image gone, describe having emitted `image staticImage1 (Responsive: false)` with no reference at all | `mdl/executor/widget_engine.go` (the `image` operation), `mdl/executor/widget_defs.go` + `mdl/executor/widget_registry.go` (`operationForType`, `defaultKnownOperations`), `mdl/backend/widgetobj/builder.go` (`SetImage`, `setImageValue`), `mdl/backend/mutation.go` + `mdl/backend/mcp/widget.go`, `{modelsdk,sdk}/widgets/definitions/image.def.json` (`imageObject` → `Image`), `mdl/executor/cmd_pages_describe_pluggable.go` (`extractCustomWidgetPropertyImage`) + `cmd_pages_describe_output.go` (`describeImageWidgetProps`) | MDL had no spelling for **which** image an image widget shows, so its default source (`ImageType: image`, an image collection entry) could never be satisfied and describe had nothing to emit — mxcli-formula1 FINDINGS §142. The name is three parts like an icon reference, `Module.Collection.Image`, stored as a plain string on the `WidgetValue`'s `Image` key. Both halves are needed: with only the write, a round trip still loses it. `setImageValue` **replaces** the existing `Image` key and never adds one — adding a key the widget definition does not declare is the CE0463 shape. Controls: stub `setImageValue` → `TestSetImageValue_SetsTheQualifiedName` fails; stub the describe emission → `TestDescribeImageWidget_EmitsTheImageReference` fails |", "ce": ["CE0463"]}
+{"area": "mdl/executor", "date": "2026-08-31", "raw": "| `image imgTypo (Image: 'MyFirstModule.Images.NoSuchImage')` passes `mxcli check --references` (\"Check passed!\") and the build then fails **CE1613** \"The selected image '…' no longer exists.\" | `mdl/executor/validate_widget_image_ref.go` (new, `imageRefErrors`, `buildImageQualifiedNames`), `mdl/executor/helpers.go` (`widgetRefCollector.images`, `validateWidgetReferences`) | Wiring `Image:` created a new qualified name and nothing resolved it — every other name a widget carries (microflow, nanoflow, page, snippet, entity) already was. This one has **three** parts, so the two mistakes get two messages: a missing collection sends the reader to `show image collections`, a missing image to that collection's contents (which the diagnostic lists). A **nil** name set means the collections could not be read and nothing is reported; an empty non-nil one is a real answer. No same-script exemption — MDL cannot create an image collection entry, so the reference can only resolve against the project. Control: `TestImageRefErrors_KnownImageIsClean`, and `TestImageRefErrors_NoCollectionsMeansNoOpinion` for the failed-read direction |", "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`main` goes red on a test that passed in **both** PRs that touched it — here `TestDescribeWorkflow_NoAnnotationEmitsNoComment`: `unexpected violations [MDL-WF05] for a plain jump`", "cause": "Two PRs merged in sequence. One added a validator rule (MDL-WF05, dangling `jump to` target); the other's control test asserted `len(violations) == 0` over a fixture that was **not a valid workflow** — a lone jump whose target did not exist. Each CI run was green because neither saw the other's change", "file": "`mdl/executor/issue1007_annotation_emit_test.go` (the fixture), `mdl/executor/validate_workflow_jump.go` (the rule, which is right)", "insight": "**A test fixture that is not a valid instance of the thing under test is a landmine for the next rule.** \"No violations at all\" is only meaningful over input that *should* have none; over an invalid fixture it silently asserts \"no rule has been written yet that notices this\". Fix the **fixture**, not the rule. Generalise: when a test asserts the ABSENCE of diagnostics, make the input something you would be happy to ship. Two green PRs can still merge to red and **neither PR's CI can detect it** — the only protection is a fixture that does not depend on which rules exist today. Found by running `make test` on an unrelated docs branch cut from the merged main, which is an argument for doing that on any branch cut after a batch merge.", "refs": ["#350", "#351"], "rules": ["MDL-WF04", "MDL-WF05"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "`filter($L, Amount > 0)` — or any FILTER/FIND predicate with a bare attribute and an operator other than `=` — fails the build with CE0117 \"Error(s) in expression.\", while the same attribute with `=` builds fine. `mxcli check` and `check --references` both pass. Reported as a Mendix 11.13 regression.", "cause": "The unfinished half of bug #343. Mendix has two filter operations: `Microflows$Filter` takes a member NAME (filter by attribute) and `Microflows$FilterByExpression` takes an expression evaluated per item with the item bound to `$currentObject`. #343 rerouted only `attr = value` to the by-attribute form; every other predicate still fell through to the expression form, where mxcli stored the authored text verbatim — and a bare attribute is not a valid Mendix expression. So the split was on the OPERATOR and invisible to the author: `Status = 'x'` built, `Status != 'x'` did not.", "file": "`mdl/executor/cmd_microflows_builder_actions.go` (`qualifyIteratorAttributes`, `listElementEntity`, `iteratorMemberPath`, `qualifyNamesInSource`); `mdl/executor/validate_microflow_listop_iterator.go` (MDL-LISTOP01); syntax topic `cmd/mxcli/syntax/features_microflow.go`; repros `mdl-examples/bug-tests/1002-filter-find-bare-attribute.mdl` and `1002-filter-bad-iterator.fail.mdl`.", "insight": "Rewrite a bare name that PROVABLY resolves to a member of the list's element entity into `$currentObject/<member>`; refuse one that does not resolve (it used to surface as CE0117 at build time); pass through untouched when the element entity cannot be determined, which proves nothing either way. An association takes its module qualifier in the path, an attribute does not. The predicate is a frozen `SourceExpr` (`buildSourceExpression` in the visitor), so the rewrite has to patch the source TEXT, skipping single-quoted literals — `filter($L, Qty > 0 and Status != 'Amount')` must not rewrite the `'Amount'` inside the literal. Do not blame the Mendix version without running both: the issue reported \"reproduces on 11.13.0, not 11.11.0\" and the identical 7-error probe on mxbuild 11.11.0 and 11.13.0 disproves it — the fork is in mxcli, and nothing in it depends on the version. `mx check -j <file>` is the attribution tool: the console output names only the activity (\"List operation activity 'Filter by expression'\"), so two errors on one line read as one microflow; the JSON carries `document-name` per location. MDL-LISTOP01 keys on scope, not on the name — `$item` is valid in a predicate when it is the enclosing loop's iterator, which is exactly how CLAUDE.md's O(N) `find` idiom is written, so flagging the name would break the documented pattern. Control for the whole fix: stub `qualifyIteratorAttributes` to return the condition unchanged and the repro goes 0 → 7 x CE0117 with the two `=` cases staying green, which is also the #343 regression guard.", "refs": ["#1002", "#343"], "ce": ["CE0117", "CE0109"], "rules": ["MDL-LISTOP01"]}
+{"area": "mdl/executor", "date": "2026-08-31", "symptom": "A copied Atlas layout (or any page mxcli authors) fails `mx check` with **CE0463** on its Image widget, and a full field-level diff against Studio Pro's own widget differs in exactly **one line of 1480** — `maxHeight`, mxcli's `0` against the installed package's declared default", "cause": "Same class as the §69 width/height fix, which did not cover it — and why is the point. The reset was applied in a loop over the definition's **property mappings**, and a mapping is what gives a property an MDL keyword: `width`/`height` have one, `maxHeight` has none, so it was never visited and the widget TEMPLATE's captured value stood. Two further halves, each independently load-bearing (stub either and the test fails): a rule whose CONDITION is an unmapped property (`maxHeight` is hidden when `maxHeightUnit` = \"none\") was always indeterminable so never fired — the declared default is the right fallback there, because nothing can have moved an unnamable property off it; and `def.PropertyVisibility` is **empty** for every widget whose rules are lifted live from the `.mpk`, which is most of them, so a lookup keyed on that field silently finds nothing (both consumers now share `visibilityRules()`).", "file": "`mdl/executor/widget_engine.go` (`unmappedHiddenResets`, `visibilityRules`, the condition fallback in `hiddenUnnamedProperties`)", "insight": "The general rule: **the set of properties that must be default-valued is the widget's editorConfig to decide, not mxcli's** — making it a subset of what MDL has words for was the mistake. The third trap was found only end-to-end; the unit test passed while the command still wrote the wrong value. Control, end-to-end on a real 11.13 project with the Image `.mpk` patched to declare `maxHeight` 250 (the 1.6.0 value the finding measured, since that version was not obtainable): pre-fix binary writes 0 and all four mxcli-authored Images fail CE0463; fixed binary writes 250 and all four are clean, while `minHeight` stays at its own declared 0 — per-property from the package, not a blanket value. The project's ~60 Studio Pro-authored Images stay stale under both, which is the package change itself and not mxcli: the Step 0 discrimination diagnose-ce0463.md asks for. Reported as mxcli-ledger FINDINGS §142."}
diff --git a/.claude/skills/maintain-wiki.md b/.claude/skills/maintain-wiki.md
index fbb261879..02f758ce8 100644
--- a/.claude/skills/maintain-wiki.md
+++ b/.claude/skills/maintain-wiki.md
@@ -152,6 +152,19 @@ isn't better served by an existing page or a different doc artifact.
 | `bug-patterns/rewrite-drops-unauthored-state.md` | bug-pattern | CREATE OR REPLACE losing what the statement did not mention |
 | `bug-patterns/flow-graph-geometry.md` | bug-pattern | generated microflow coordinates and sequence-flow wiring |
 | `bug-patterns/integration-contract-drift.md` | bug-pattern | OData / REST / mappings, where neither check nor mxbuild is an oracle |
+| `bug-patterns/test-runner-cannot-fail.md` | bug-pattern | `mxcli test` reporting PASS for what did not hold, run or get evaluated |
+| `bug-patterns/local-loop-silence.md` | bug-pattern | the warm loop failing quietly across processes mxcli does not own |
+| `bug-patterns/styling-compiles-to-nothing.md` | bug-pattern | SCSS and tokens written correctly, compiled nowhere, checked by nothing |
+| `bug-patterns/package-operations-damage.md` | bug-pattern | marketplace / `mx` operations that change the project and report success |
+| `bug-patterns/cli-contract-defects.md` | bug-pattern | flags, paths, stdout and help — the class with no Mendix document in it |
+| `bug-patterns/engine-divergence.md` | bug-pattern | two backend implementations, and a gap in one that is invisible from inside it |
+| `bug-patterns/mutator-addressing.md` | bug-pattern | in-place edits to nodes the model does not name |
+| `bug-patterns/access-rule-reconciliation.md` | bug-pattern | GRANT is a read-modify-write, and both directions of loss report success |
+| `bug-patterns/capability-gap-as-parse-error.md` | bug-pattern | an unspelled capability presenting as `no viable alternative`, and the workarounds that follow |
+| `bug-patterns/keyword-collisions.md` | bug-pattern | MDL's keyword set occupying positions where user data lives |
+| `bug-patterns/scripts-that-cannot-rerun.md` | bug-pattern | statement-level idempotence, and why it is not write-level idempotence |
+| `bug-patterns/expression-translation-drift.md` | bug-pattern | MDL expression to Mendix expression, where the translation changes the meaning |
+| `bug-patterns/misleading-diagnostics.md` | bug-pattern | hints that fire on the wrong thing and send the reader somewhere the problem is not |
 
 ## Adding a new page
 
diff --git a/CLAUDE.md b/CLAUDE.md
index 8a05611db..7e94e06da 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -564,7 +564,7 @@ mxcli uses a layered documentation system — each artifact type has a single ca
 
 **ADRs are immutable once accepted.** Supersede with a new ADR rather than editing in place. Conventions and template in [`docs/13-decisions/README.md`](docs/13-decisions/README.md).
 
-**Bug findings are read in the opposite order from how they are written.** A fix *appends* one record to `.claude/skills/fix-issue/findings/<area>.jsonl`; a diagnosis *starts* at `docs-wiki/bug-patterns/`, which digests those records into failure classes, and drills into the findings only for the specific instance. The findings are append-only evidence — grep them, or query them with DuckDB (`select … from 'findings/*.jsonl'`), never read them whole. The digest covers `mdl/executor` (12 pattern pages, 83% of that area's findings) and little else; `make digest-status` reports the gap per area, so a pattern miss means "not yet digested", not "not seen before".
+**Bug findings are read in the opposite order from how they are written.** A fix *appends* one record to `.claude/skills/fix-issue/findings/<area>.jsonl`; a diagnosis *starts* at `docs-wiki/bug-patterns/`, which digests those records into failure classes, and drills into the findings only for the specific instance. The findings are append-only evidence — grep them, or query them with DuckDB (`select … from 'findings/*.jsonl'`), never read them whole. The digest covers `mdl/executor` (83% of its findings), `cmd/mxcli` (92%), `mdl/backend` (99%), `mdl/grammar` (92%) and `mdl/visitor` (96%) across 25 pattern pages; `make digest-status` reports the gap per area, so a pattern miss means "not yet digested", not "not seen before".
 
 **The wiki is synthesized, not stated.** It frames and connects across the other artifacts — it never restates content that has a canonical home. Rules and seed page list in [`.claude/skills/maintain-wiki.md`](.claude/skills/maintain-wiki.md).
 
diff --git a/docs-wiki/SYNC_LOG.md b/docs-wiki/SYNC_LOG.md
index b99fa30a6..74275c034 100644
--- a/docs-wiki/SYNC_LOG.md
+++ b/docs-wiki/SYNC_LOG.md
@@ -40,3 +40,18 @@ not capture, because sources are upstream of the commit.
 | 2026-08-31 | bug-patterns/rewrite-drops-unauthored-state.md | .claude/skills/fix-issue/findings/mdl-executor.jsonl (13 records), docs/13-decisions/0005-semantic-model-interface-currency.md, docs/13-decisions/0008-identity-and-idempotence.md | New page (added to seed table). Guard-don't-drop as a failure class rather than a decision: the loss is invisible at every checkpoint, the most expensive variant is identity rather than content, and delete-then-create opts out of every protection |
 | 2026-08-31 | bug-patterns/flow-graph-geometry.md | .claude/skills/fix-issue/findings/mdl-executor.jsonl (10 records), mdl/executor/layout.go, mdl/executor/cmd_microflows_builder_control.go | New page (added to seed table). A microflow is a graph with coordinates and mxcli generates both; geometry fails ugly, wiring fails invalid, and a flow that looks redundant is often load-bearing |
 | 2026-08-31 | bug-patterns/integration-contract-drift.md | .claude/skills/fix-issue/findings/mdl-executor.jsonl (30 records), mdl/executor/cmd_odata.go | New page (added to seed table). The one area where neither mxcli check nor mxbuild is an oracle, so a silent downgrade can return HTTP 200; defaults, EDM mapping and lagging modify paths |
+| 2026-08-31 | bug-patterns/test-runner-cannot-fail.md | .claude/skills/fix-issue/findings/cmd-mxcli.jsonl (14 records), cmd/mxcli/testrunner/parser.go, cmd/mxcli/testrunner/generator_endpoint.go | New page (added to seed table). First pass over cmd/mxcli. The one class whose cost is confidence rather than debugging time: silent absence (an annotation parsed and read by nothing), two result-assembly paths, and why the remedy is fail-closed plus a single call site |
+| 2026-08-31 | bug-patterns/local-loop-silence.md | .claude/skills/fix-issue/findings/cmd-mxcli.jsonl (16 records), cmd/mxcli/docker/localboot.go, cmd/mxcli/docker/runlocal.go | New page (added to seed table). The warm loop orchestrates processes mxcli did not write, so the thing that breaks is not the thing that reports — a missing bundle answers 200, a dead child does not stop the parent, and every resolved-for-another-tool value is a silent disagreement |
+| 2026-08-31 | bug-patterns/styling-compiles-to-nothing.md | .claude/skills/fix-issue/findings/cmd-mxcli.jsonl (11 records), cmd/mxcli/theme/block.go | New page (added to seed table). No validator exists for CSS, so location decides whether anything compiles, an unread token is indistinguishable from a design not applied, and contrast is a correctness property nothing measures |
+| 2026-08-31 | bug-patterns/package-operations-damage.md | .claude/skills/fix-issue/findings/cmd-mxcli.jsonl (11 records), cmd/mxcli/marketplace/update.go | New page (added to seed table). Damage from handing the project to tools mxcli does not control, reported as success — the v2 to v1 collapse at 0 errors being the worst of it |
+| 2026-08-31 | bug-patterns/cli-contract-defects.md | .claude/skills/fix-issue/findings/cmd-mxcli.jsonl (14 records), cmd/mxcli/syntax/ | New page (added to seed table). The class with no Mendix document in it: help that teaches unparseable syntax, unqualified success messages, accepted-but-inert flags, stdout as a data channel. Matters disproportionately because agents take the tool's word |
+| 2026-08-31 | bug-patterns/engine-divergence.md | .claude/skills/fix-issue/findings/mdl-backend.jsonl (30 records), mdl/backend/modelsdk/microflow.go, docs/13-decisions/0004-full-codec-engine.md | New page (added to seed table). First pass over mdl/backend. A gap on one engine is invisible from inside that engine, so the cross-engine DESCRIBE matrix is the only check that finds them; a refusal is honest and a `-- Empty action` placeholder is not; read against the WRITER's keys rather than gen's accessors |
+| 2026-08-31 | bug-patterns/mutator-addressing.md | .claude/skills/fix-issue/findings/mdl-backend.jsonl (19 records), mdl/backend/mpr/page_mutator.go, mdl/backend/modelsdk/page_write.go | New page (added to seed table). Many addressable nodes — DataGrid2 columns, object-list items, layout regions — store no Name, so addressing is derived or positional; ambiguity is refused rather than resolved, and hand-built BSON drifts from codec-built BSON in ways only a dump-diff shows |
+| 2026-08-31 | bug-patterns/access-rule-reconciliation.md | .claude/skills/fix-issue/findings/mdl-backend.jsonl (6 records), mdl/backend/modelsdk/domainmodel_security_write.go | New page (added to seed table). Small class graded high: GRANT is a read-modify-write and both directions of loss report success. Records that the writer was innocent in the instructive case — a later reconcile removed the rules — and that the reported trigger (WHERE) was a red herring |
+| 2026-08-31 | (no page) mdl/backend MCP findings | .claude/skills/fix-issue/findings/mdl-backend.jsonl | Deliberately NOT given a page: ~33 records touch the MCP/PED backend, which already has architecture/mcp-backend.md and models/ped-mutation-constraints.md. Restating them here would violate the never-restate rule; the findings link to those pages instead |
+| 2026-08-31 | bug-patterns/capability-gap-as-parse-error.md | .claude/skills/fix-issue/findings/mdl-grammar.jsonl (20 records), mdl/grammar/MDLParser.g4, docs/13-decisions/0003-mdl-is-sql-shaped.md | New page (added to seed table). First pass over mdl/grammar. A parse error is indistinguishable from a mistake the user made, so the reports in this class are workarounds rather than feature requests; the gap is bidirectional (DESCRIBE must do something too, and rebuilding a DIFFERENT document is worse than a parse error); a narrow/wide statement pair is a whitelist |
+| 2026-08-31 | bug-patterns/keyword-collisions.md | .claude/skills/fix-issue/findings/mdl-grammar.jsonl (8 records), mdl/grammar/MDLLexer.g4, mdl/executor/identifier_quoting.go | New page (added to seed table). The distinguishing question is how a collision fails, not whether one happens: a parse error is recoverable, a different valid parse is not. Records that a grammar alternative and its visitor case are one change, and the control-binary sweep for proving a relaxation |
+| 2026-08-31 | bug-patterns/scripts-that-cannot-rerun.md | .claude/skills/fix-issue/findings/mdl-grammar.jsonl (5 records), mdl/grammar/domains/MDLDomainModel.g4, docs/13-decisions/0003-mdl-is-sql-shaped.md | New page (added to seed table). Statement-level idempotence, kept explicitly apart from ADR-0008 write-level idempotence, which is what people usually mean when they say mxcli is idempotent. The silent variant (a duplicated index) is worse than the error |
+| 2026-08-31 | bug-patterns/expression-translation-drift.md | .claude/skills/fix-issue/findings/mdl-visitor.jsonl (13 records), mdl/visitor/visitor_microflow_expression.go, mdl/visitor/visitor_helpers.go | New page (added to seed table). First pass over mdl/visitor. Distinct from platform-semantics-gaps: there the MDL is illegal Mendix, here the MDL is correct and the TRANSLATION says something else — the worst case a microflow computing a different number with every check green. Records the ANTLR hidden-token trap and why the same expression text means different things in different slots |
+| 2026-08-31 | bug-patterns/misleading-diagnostics.md | .claude/skills/fix-issue/findings/mdl-visitor.jsonl (6 records), mdl/visitor/visitor.go | New page (added to seed table). Graded above "the message could be clearer": a wrong hint costs however long the reader spends acting on it, and in the reported cases they blamed their quoting, renamed an attribute that was fine, or concluded a construct was unsupported. A hint's precision matters more than its coverage |
+| 2026-08-31 | bug-patterns/visitor-wiring-gaps.md | .claude/skills/fix-issue/findings/mdl-visitor.jsonl, mdl/visitor/visitor_enumeration.go, mdl/visitor/visitor_helpers.go | **Re-sync** (first since the 2026-05-24 initial synthesis). Broadened from one size of gap to three — a field, a structure (ELSIF arms lowered into nested ifs), and a whole statement that parses and dispatches to nothing — and added the neighbouring failure where a field is wired to the WRONG thing, which reports success and changes meaning. sources: updated from the findings directory to the specific shard; wiki-links normalised to bare slugs |
diff --git a/docs-wiki/bug-patterns/access-rule-reconciliation.md b/docs-wiki/bug-patterns/access-rule-reconciliation.md
new file mode 100644
index 000000000..34181c2bb
--- /dev/null
+++ b/docs-wiki/bug-patterns/access-rule-reconciliation.md
@@ -0,0 +1,62 @@
+---
+title: Access Rules Are Reconciled, Not Appended
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-backend.jsonl
+  - mdl/backend/modelsdk/domainmodel_security_write.go
+---
+
+> **Do not duplicate**: the GRANT syntax and the security workflow live in
+> `.claude/skills/manage-security.md`; the CE numbers and per-member rules live
+> in the findings. This page describes why this small class is graded high.
+
+## What this is
+
+`GRANT` looks additive and is not. A grant is stored as an *entity access rule*
+carrying a complete picture of what a role may do, so writing one is a
+read-modify-write over an existing rule — and five `mdl/backend` findings are
+that reconciliation losing rights the statement never mentioned.
+
+The class is small and worth its own page because of what it costs when wrong.
+Every other silent loss in this wiki costs a feature; this one **quietly widens
+or narrows who can read data**, and both directions are reported as success.
+
+## How it fits
+
+**A grant that mentions one attribute must not revoke the others.** The reported
+symptom was attributes granted by an earlier statement coming back as `None`.
+Structural rights — create, delete, the default member access — went with them,
+which the report did not mention: **re-derive the blast radius rather than
+inheriting it from the reporter**.
+
+**The reported trigger is often not the trigger.** A constrained (`WHERE`) grant
+was blamed, and the same loss reproduced with no `WHERE` and with `READ *`. A fix
+scoped to the reported path would have passed the reporter's reproduction and
+left most of the defect in place.
+
+**When a value is written and then absent, instrument the later pass.** In the
+most instructive of these the writer was innocent — it stored all three rules —
+and a reconciliation running afterwards removed them. Starting at the writer is
+the natural instinct and the wrong end.
+
+**Preserve what cannot be checked.** Membership questions do not all resolve
+locally: an association is qualified by the module that *declares* it, so a
+specialization inheriting from a generalization in another module has members the
+local walk cannot see. Dropping what the walk cannot confirm produced
+`CE0066 "Entity access is out of date"` — the model claiming rights over members
+it no longer lists. The safe default is to carry an unconfirmable member through
+rather than to prune it.
+
+**Under-reporting access is the read-side twin.** A restricted page reported as
+having "no roles" is the same class seen from the query side, and it is the shape
+most likely to be believed, because "no roles" reads like a finding rather than a
+gap.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the member
+  walks, the CE numbers and the controls
+- [[association-pointers]] — why a member belongs to the FROM entity, which
+  decides where a MemberAccess may appear
+- [[engine-divergence]] — where the "no roles" read gap came from
diff --git a/docs-wiki/bug-patterns/capability-gap-as-parse-error.md b/docs-wiki/bug-patterns/capability-gap-as-parse-error.md
new file mode 100644
index 000000000..beea3e861
--- /dev/null
+++ b/docs-wiki/bug-patterns/capability-gap-as-parse-error.md
@@ -0,0 +1,74 @@
+---
+title: A Missing Capability Looks Like a Syntax Error
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-grammar.jsonl
+  - mdl/grammar/MDLParser.g4
+  - docs/13-decisions/0003-mdl-is-sql-shaped.md
+---
+
+> **Do not duplicate**: the syntax itself lives in `MDL_QUICK_REFERENCE.md` and
+> the skills; each construct's grammar rule and BSON shape live in the findings.
+> This page is about what a parse error costs when it means "not implemented".
+
+## What this is
+
+Roughly twenty of the `mdl/grammar` findings are the same event: someone tries to
+express something Mendix supports, the parser says `no viable alternative`, and
+they conclude **the feature is impossible**. It is not — the capability is simply
+unspelled, and a parse error is indistinguishable from a mistake the user made.
+
+That confusion is the expensive part. The reports in this class are rarely
+"MDL should support X"; they are workarounds. An admin screen hand-rolled as five
+pages with bespoke SCSS because a tab container was believed not to exist. "Use a
+Java action" for a binary upload. "Go to Studio Pro" as the standing answer to
+translating an app. A headless pipeline that ends with a manual step because
+anonymous access has no statement.
+
+## How it fits
+
+**The gap is bidirectional.** MDL not being able to *write* a construct is only
+half of it: `DESCRIBE` of a document that has one has to do something, and
+dropping it silently is the common outcome. Worse, in the mapping findings,
+DESCRIBE emitted MDL that **parsed and rebuilt a different document** — output
+that looks like a successful round trip and is not. When adding a spelling, the
+read side is part of the same change, not a follow-up.
+
+**A narrow/wide pair is a whitelist.** Where two statements can set the same
+property and one accepts less than the other — `SET` versus `REPLACE` here — the
+narrow one gets extended a bug report at a time, and the documented workaround
+routes users through the wide one, which rebuilds more than they asked. The fix
+that holds is to reuse the wide rule and its builder, not to add another case to
+the narrow one.
+
+**"Not in the metamodel" is not a conclusion until the namespace is right.** A
+search under one prefix "disproved" a capability that lives under another —
+`Microflows$…RequestHandling` rather than `Rest$…Body`. Asking for a Studio Pro
+example settled in minutes what a metamodel grep had ruled out, and CLAUDE.md's
+rule applies: when the shape is unknown, get a reference document rather than
+reason from an absence.
+
+**With no reference available, derive from something already proven.** Where no
+example could be obtained, the shapes came from the generated metamodel and from
+sibling writers that already ship the same by-name reference form — not from
+guessing and not from stopping. Where a reference *is* available, pin against it:
+a guess got four things wrong at once about one element — the type's namespace, a
+property that does not exist, append-versus-sort ordering, and a flag's default.
+
+**A reference is a reference, not a string.** An icon, an entity, a microflow —
+anything that names a model element is spelled as a qualified name, which is what
+makes the language consistent (ADR-0003) and what forces the quoting question
+into the describe emitter as well.
+
+**The documentation is part of the surface.** Several of these were found by
+running the statements quoted in mxcli's own skills through `mxcli check` rather
+than by reading them. Advice that cannot parse is the same defect as a missing
+rule, and it is the version an agent will follow confidently.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — each construct,
+  its rule, and the reference document that settled its shape
+- [[mdl-as-sql]] — why the language is shaped the way it is
+- [[describe-round-trip-gaps]] — the read half of every gap here
diff --git a/docs-wiki/bug-patterns/cli-contract-defects.md b/docs-wiki/bug-patterns/cli-contract-defects.md
new file mode 100644
index 000000000..80f95ca85
--- /dev/null
+++ b/docs-wiki/bug-patterns/cli-contract-defects.md
@@ -0,0 +1,64 @@
+---
+title: When the CLI Is the Defect
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/cmd-mxcli.jsonl
+  - cmd/mxcli/syntax/
+---
+
+> **Do not duplicate**: individual flags, paths and messages live in the CLI help
+> and the findings. This page is about the class where nothing is wrong with the
+> model at all.
+
+## What this is
+
+Roughly fourteen `cmd/mxcli` findings are defects in the tool's own contract with
+its caller — the flags it accepts, the paths it resolves, what it writes to
+stdout, and what its help teaches. No Mendix document is involved. They matter
+disproportionately because mxcli is driven by agents as often as by people, and
+an agent takes the tool's word for everything.
+
+## How it fits
+
+**Help that teaches syntax the parser rejects is worse than no help.** `mxcli
+syntax` documented spellings that fail to parse, so an agent following the
+reference produced MDL that could not run. The mirror image is just as expensive:
+a widget keyword the grammar accepts but the reference omits was concluded not to
+exist and worked around at length — two days for a construct that already
+existed. A syntax reference is an API surface and drifts like one.
+
+**An unqualified success message is a claim.** `check` printed `Check passed!`
+having resolved nothing against the project; a misspelled entity or page name
+sailed through the command whose entire job is to catch it. Where a command's
+depth depends on what it was given, the message has to say which check ran.
+
+**Accepted-but-inert flags.** `--require-assertions` parsed, appeared in `--help`,
+and was consulted in one of two code paths. A flag the tool advertises is a
+promise, and the cheapest guard is that its effect has exactly one call site.
+
+**stdout is a data channel.** `--format json | jq` failed because progress lines
+shared the stream. Anything with a machine-readable format has to keep
+diagnostics on stderr.
+
+**Path handling is where portability bugs live.** Windows backslashes mangled by
+escape processing, a relative `-p` rejected by a downstream tool with its own
+error text, a test directory resolved relative to the wrong base, `-` not
+accepted for stdin so MDL cannot be piped. Each is small and each stops a
+workflow completely.
+
+**Say what was skipped and why.** "Found 0 test(s) in 1 file(s)" counted a
+directory as a file, so it read as though a file had been opened and rejected.
+Naming the files that were skipped — and why — turns a dead end into a rename.
+
+**Shipped guidance is code.** The skills and skill packs mxcli embeds are
+compiled in and versioned with the binary, so they go stale against it, and a
+malformed one ships as-is if the test only checks that a file exists. Assert on
+the rendered content, not on presence.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the individual
+  flags, paths and messages
+- [[test-runner-cannot-fail]] — the same "accepted but inert" shape, where its
+  consequence is a false pass
diff --git a/docs-wiki/bug-patterns/engine-divergence.md b/docs-wiki/bug-patterns/engine-divergence.md
new file mode 100644
index 000000000..567adbfa8
--- /dev/null
+++ b/docs-wiki/bug-patterns/engine-divergence.md
@@ -0,0 +1,77 @@
+---
+title: Two Engines, One Interface
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-backend.jsonl
+  - mdl/backend/modelsdk/microflow.go
+  - docs/13-decisions/0004-full-codec-engine.md
+---
+
+> **Do not duplicate**: the abstraction's rationale is canonical in ADR-0002 and
+> ADR-0004 and framed in [[backend-abstraction]]; the per-field fixes live in the
+> findings. This page describes what goes wrong while two implementations exist.
+
+## What this is
+
+The backend interface has two implementations — the legacy `sdk/mpr` writer and
+the codec-based `modelsdk` engine — and roughly a quarter of the `mdl/backend`
+findings are one of them doing something the other does not. The default is the
+newer engine, so a gap in it is the behaviour most users get, while the tests and
+habits formed against legacy still pass.
+
+A gap on one engine is **invisible from inside that engine**. Everything is
+self-consistent: the write stores what the read returns, the round trip is
+stable, and the field that never existed is never missed.
+
+## How it fits
+
+**Two failure modes, and only one of them is honest.** A refusal —
+`… not yet supported by the modelsdk engine — rerun with MXCLI_ENGINE=legacy` —
+costs the user a flag and tells the truth. The alternative is a placeholder:
+`-- Empty action` from a describer that does not recognise an activity type, a
+sort clause silently absent, an argument list quietly dropped. The placeholder is
+worse than the refusal in every way, because `describe → edit → exec` then
+deletes the construct and everything reports success.
+
+**The worst instance was a read that under-reported access.** A restricted page
+came back as "no roles" on the default engine, so `SHOW ACCESS` and the security
+matrix both understated who could reach it. A missing field is a cosmetic bug
+almost everywhere and a security-relevant one here.
+
+**The check that finds these is the cross-engine matrix.** Write with engine A,
+read with engine B, all four combinations. Every other test shape is
+engine-local and therefore blind to exactly this class.
+
+**Read against the keys the writer builds, not against gen's accessors.** The
+generated bindings and the stored document disagree in places — one action's
+result is bound as `VariableName` where the model stores `OutputVariableName` —
+so an accessor-based reader silently returns nothing. Round-trip tests
+(`toGen → encode → decode → fromGen`) catch it; a reader test over hand-written
+BSON does not, because the hand-written BSON was written from the same wrong
+assumption. These have to be Go tests rather than MDL ones: `create or modify`
+rebuilds the document from MDL, so it cannot reproduce a read-back defect at all.
+
+**Count the gap before fixing the instance.** Decoding every `$Type` through the
+real reader turned one reported unsupported action into twenty-seven, one of
+which was a shipped feature that could not be described back. Related: several
+activity types live in **their own sub-metamodel** — `DatabaseConnector$…`, not
+`Microflows$…` — so a probe or a grep under one prefix systematically
+under-counts what is covered.
+
+**Fixing one field and not its sibling is the characteristic mistake.** A reader
+restored for `TableMappings` and not `Parameters`, a source type ported without
+its key parts. Enumerate every child of the element rather than the one the
+report named.
+
+**Guard the write side with a round trip, not with `mx check`.** Several of these
+produced models mxbuild accepts: a box size of zero renders every activity as a
+one-pixel sliver in Studio Pro and validates at 0 errors, because `mx check` does
+not look at geometry.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the individual
+  fields, sub-metamodels and round-trip guards
+- [[backend-abstraction]] — why the seam exists
+- [[describe-round-trip-gaps]] — the same read-side failure, engine-independent
diff --git a/docs-wiki/bug-patterns/expression-translation-drift.md b/docs-wiki/bug-patterns/expression-translation-drift.md
new file mode 100644
index 000000000..d0572cb46
--- /dev/null
+++ b/docs-wiki/bug-patterns/expression-translation-drift.md
@@ -0,0 +1,81 @@
+---
+title: The Expression Translation Loses Meaning
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-visitor.jsonl
+  - mdl/visitor/visitor_microflow_expression.go
+  - mdl/visitor/visitor_helpers.go
+---
+
+> **Do not duplicate**: the Mendix expression rules themselves are
+> [[platform-semantics-gaps]] and the skills; each translation's fix is in the
+> findings. This page is about the step in between.
+
+## What this is
+
+An MDL expression is not a Mendix expression. The visitor parses one and emits
+the other, and thirteen `mdl/visitor` findings are that translation changing
+what the expression *means*. This is a different class from writing something
+Mendix forbids: here the MDL is correct, the Mendix expression is well-formed,
+and it says something else.
+
+The worst of them is the quietest. An additive chain came back from the model
+with its operators reordered, so **a microflow computed a different number than
+its source said** — with `mxcli check`, `mx check` and the build all green, and
+the corruption in the stored document rather than in the description.
+
+## How it fits
+
+**Three ways meaning is lost.**
+
+*A literal changes type.* A decimal literal losing its fraction; an enumeration
+value stored as a quoted string instead of a qualified name; a bare identifier
+that needed a `$currentObject/` prefix and did not get one. Each produces an
+expression Mendix parses and evaluates differently, or rejects with a generic
+`CE0117` that names nothing.
+
+*An operator changes.* `/` is division in most languages and member navigation in
+Mendix, so the same characters mean two things depending on what is either side
+of them. An additive chain rebuilt without walking its children in order swaps
+operands.
+
+*A function resolves to the wrong overload.* `contains` and `find` exist as both
+string functions and list operations, and the visitor has to decide from the
+argument shapes which one was meant — a string literal in the second position
+means the string function, two bare variables are genuinely ambiguous at parse
+time and get decided later from the declared type.
+
+**Preserving raw source is the standard fix, and it carries hidden tokens with
+it.** Where the rebuilt expression is lossy, the visitor keeps the original text.
+The trap is that ANTLR's `GetText()` excludes hidden tokens while a source-interval
+slice *includes* them — so any code reaching for original text inherits every
+comment in that span, and a `--` comment between two operands ends up inside the
+Mendix expression. Replacing a comment with whitespace rather than with nothing
+matters for the same reason: `1 --c\n+ 2` must not become `1+ 2`.
+
+**Quoting is the other systematic leak.** The guidance to quote identifiers is
+about the MDL *parser*; a quote that survives into the stored expression produces
+`Mod."Entity".Attr`, which Mendix rejects. The tell is a **half-stripped** name in
+the error message — one half went through the unquoting reader and the other did
+not, which localises the bug to a `GetText()` call that should have been the
+structured accessor.
+
+**The same expression text means different things in different slots.** A widget
+`Visible:` is a client expression and needs bare identifiers prefixed; a
+datasource `where` is real XPath and must not be. An enum in the first stringifies
+to a qualified name and in the second to a quoted string. A fix applied to
+"expressions" rather than to a specific slot breaks the other one.
+
+**Nothing downstream can catch this.** The output is a syntactically valid Mendix
+expression, so `mx check` is satisfied, the build succeeds, and the only
+observable difference is a value at runtime. Verification has to be the round
+trip plus reading the stored bytes — `strings` on the `.mxunit` is what showed the
+swapped operands.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the individual
+  literals, operators and overloads
+- [[platform-semantics-gaps]] — expressions Mendix forbids outright
+- [[keyword-collisions]] — where the quoting leak starts
diff --git a/docs-wiki/bug-patterns/keyword-collisions.md b/docs-wiki/bug-patterns/keyword-collisions.md
new file mode 100644
index 000000000..f6fb8dd0a
--- /dev/null
+++ b/docs-wiki/bug-patterns/keyword-collisions.md
@@ -0,0 +1,72 @@
+---
+title: The Keyword Set Leaks Into User Data
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-grammar.jsonl
+  - mdl/grammar/MDLLexer.g4
+  - mdl/executor/identifier_quoting.go
+---
+
+> **Do not duplicate**: the quoting rules a user needs are in the skills and
+> CLAUDE.md ("Quoting Escapes Parser Keywords, Not Platform-Reserved Member
+> Names"); each collision's fix is in the findings. This page is about the shape.
+
+## What this is
+
+MDL has a large keyword vocabulary, and those keywords occupy positions where
+user data also lives — a widget called `List`, an attribute called `Template`, an
+XPath predicate calling `trim()`, a negative number, a string containing a
+newline. Eight `mdl/grammar` findings are a collision between the two.
+
+The distinguishing question is not whether a collision happens but **how it
+fails**. A parse error is recoverable: the user sees it and quotes the name. The
+same collision resolving to a *different valid parse* is not, and several of
+these did exactly that.
+
+## How it fits
+
+**Silent is the dangerous half.** A widget conditional using a function whose
+name is also a lexer keyword did not error — it was dropped, so the widget lost
+its visibility rule and the page built cleanly. A describer emitting a
+keyword-named widget bare produced output that failed only when someone re-ran
+it. The loud failures in this class cost minutes; the quiet ones cost a
+round trip.
+
+**A grammar fix alone can be worse than the bug.** Accepting an unquoted negative
+number in XPath made the parser succeed while the AST builder had no case for the
+new alternative — so the constraint serialized as `[Amount > ]`, a dropped
+operand instead of a loud error. **A grammar alternative and its visitor case are
+one change**, and only a round-trip helper caught it; the write path used the raw
+text and looked fine.
+
+**Prove a relaxation with a control binary, not by reading.** Making a keyword
+optional or a rule more permissive can change how unrelated input parses. The
+method that works: stash the `.g4`, regenerate, build a control binary, and sweep
+every example with both. Thirteen scripts failed with the change — the *same*
+thirteen, all pre-existing.
+
+**Derive the accepted set from the grammar, in a test.** Where a keyword list is
+maintained on one side and derived on the other, the next widget package
+re-opens the gap. A test that reads the accepted keywords straight out of the
+`.g4` cannot drift from it, and can carry the fix instructions in its failure
+message.
+
+**A renderer that stringifies an enum outgrows its grammar silently.** An emitter
+that formats a value by name will happily print the ninth member of an
+enumeration that the grammar knows eight of. Switching on concrete types cannot
+do that, which is why the sibling emitter never had the bug — and where
+stringifying is unavoidable, the guard is a describe-then-parse loop over the
+enumeration's full membership.
+
+**Quoting is not one question.** Quoting escapes MDL's *parser* keywords. It does
+not escape Mendix's platform-reserved member names, and it does not help in an
+OQL alias. Three vocabularies stack, and a rule that conflates them produces
+confident, wrong advice.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the individual
+  collisions and their controls
+- [[describe-round-trip-gaps]] — where an unquoted emit surfaces
+- [[platform-semantics-gaps]] — the other two vocabularies quoting does not reach
diff --git a/docs-wiki/bug-patterns/local-loop-silence.md b/docs-wiki/bug-patterns/local-loop-silence.md
new file mode 100644
index 000000000..13e97e0a7
--- /dev/null
+++ b/docs-wiki/bug-patterns/local-loop-silence.md
@@ -0,0 +1,76 @@
+---
+title: The Warm Loop Fails Quietly
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/cmd-mxcli.jsonl
+  - cmd/mxcli/docker/localboot.go
+  - cmd/mxcli/docker/runlocal.go
+---
+
+> **Do not duplicate**: the flags and their behaviour live in
+> `.claude/skills/mendix/run-local.md`; the individual fixes live in the
+> findings. This page describes the shape of failure in a loop mxcli only partly
+> owns.
+
+## What this is
+
+`mxcli run --local` orchestrates processes it did not write: mxbuild, a JVM
+runtime, a rollup bundler, PostgreSQL, and a browser. Sixteen `cmd/mxcli`
+findings are failures in that loop, and they share a signature — **the thing that
+breaks is not the thing that reports**. A page goes black with HTTP 200. The
+runtime is gone and the CLI sits at several hundred percent CPU. Styles do not
+change and nothing is stale. A login that is correct reports "Sign in failed".
+
+## How it fits
+
+**A missing asset answers 200.** Mendix serves an SPA shell before it knows
+whether the client bundle exists, so a deleted `deployment/web/dist` renders a
+black screen while every HTTP-level check passes. `curl /` is not a liveness
+probe for this app; the bundle is.
+
+**A dead child does not stop the parent.** A runtime that exited left a zombie
+under a CLI that kept polling, for hours. Anything that supervises a long-lived
+child needs to reap it and exit, or the failure presents as a hang rather than an
+error.
+
+**The log the user needs is not the log being captured.** Several rounds went
+into `runtime.log` holding only the JVM banner: the application's own logging
+goes through a subscriber that attaches after startup, so anything logged
+*during* the start action — which is exactly where the after-startup test runner
+logged — is not in the file. Capturing "the process's stdout" and capturing "the
+app's log" are different jobs.
+
+**Everything the loop resolves for another tool is a place to disagree
+silently.** A relative `-p` reaches mxbuild as its own error text plus a page of
+Windows JSON. A version resolved for one component and defaulted in another
+produces a project at a Mendix version nobody asked for. An architecture picked
+for `docker build` and not for `--local` gives `exec format error`. A credential
+that is right for one API is wrong for the other — the M2EE admin password and
+the test endpoint token are different secrets, and passing one where the other
+belongs reports "Authentication failed" after the model has already been
+modified.
+
+**Guards that name a cause can name the wrong one.** A port-in-use guard blamed a
+previous `run --local` that the user had already killed. A guard is a diagnosis,
+and a wrong diagnosis costs more than a plain error — this is why the port owner
+is now resolved from `/proc` rather than asserted.
+
+**Stale state has more than one home.** A theme edit that does not appear, a
+constant that does not reach a running app, a page that dies after ten
+hot-applies with a 404 for a hashed chunk — each is a cache or a running process
+holding something the file no longer says. The loop's value is that it does not
+restart; the cost is that "what is actually being served" and "what is on disk"
+are separate questions, and the answer has to be printed rather than assumed.
+
+**Half-applied is a state the loop can reach.** A watch that redeploys while an
+`mxcli exec` is mid-script can serve a partial model, and re-running the script
+fixes nothing because the write is idempotent and there is nothing left to write.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the individual
+  probes, guards and controls
+- `.claude/skills/mendix/run-local.md` — what the flags actually do
+- `.claude/skills/verify-in-runtime.md` — proving a fix in a real browser, which
+  is the only check that sees most of this class
diff --git a/docs-wiki/bug-patterns/misleading-diagnostics.md b/docs-wiki/bug-patterns/misleading-diagnostics.md
new file mode 100644
index 000000000..b03954989
--- /dev/null
+++ b/docs-wiki/bug-patterns/misleading-diagnostics.md
@@ -0,0 +1,66 @@
+---
+title: A Wrong Hint Is Worse Than No Hint
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-visitor.jsonl
+  - mdl/visitor/visitor.go
+---
+
+> **Do not duplicate**: the individual hints and their trigger conditions live in
+> the findings and in `mdl/visitor/`. This page is about why the class is graded
+> higher than "the message could be clearer".
+
+## What this is
+
+ANTLR's raw errors name tokens, not intentions: `no viable alternative at input
+'add<Name>'` for a missing keyword, `mismatched input '=' expecting ')'` for a
+caption written with the wrong separator. mxcli adds hints on top. Six
+`mdl/visitor` findings are those hints firing on the wrong thing and **sending
+the reader somewhere the problem is not**.
+
+A missing hint costs the reader a minute of confusion. A wrong one costs however
+long they spend acting on it — and in the reported cases they blamed their
+quoting, renamed an attribute that was fine, or concluded a construct was
+unsupported.
+
+## How it fits
+
+**A pattern broad enough to be useful is broad enough to be wrong.** The
+"unescaped apostrophe" hint matched any short lowercase word, so every genuine
+parse error on `on`, `in`, `as`, `to` or `by` was diagnosed as a quoting mistake.
+Narrowing it to the actual contraction suffixes — `s`, `t`, `d`, `m`, `re`, `ve`,
+`ll` — keeps the real cases and drops the false ones. A hint's precision matters
+more than its coverage, because its whole value is that the reader trusts it.
+
+**Key the hint off the source line, not the parser message.** The token error for
+a misplaced `index` clause lands on the index *name*, so the message never
+mentions `index` at all and no message-matching hint can fire. Reading the
+offending line is what makes the diagnosis possible — and it also lets the hint
+discriminate against the valid form of the same construct.
+
+**A hint that recommends a rename is a strong claim.** One offered three
+alternative names for an attribute that parsed perfectly well elsewhere, because
+it conflated two kinds of reserved word: an MDL *parser* keyword, which quoting
+escapes and the model keeps, and a name the *platform* reserves, which quoting
+does not help with at all. Conflating them is expensive in both directions —
+advising a quote where the platform reserves the name produces something that
+parses and then fails the build.
+
+**Some errors are the platform's, and the hint should say so.** Mendix XPath
+cannot compute values, so `[Seq = $Game/MoveSeq + 1]` is a limitation rather than
+a syntax mistake; a bare `mismatched input '+'` reads as the latter. Naming the
+constraint turns a dead end into a redesign.
+
+**The reachable-form question.** Several of these are not really about wording:
+the reader's next question is "then how *do* I write it?", and a hint that names
+the working spelling answers it. Where there is no working spelling, saying so is
+still better than a token error — that is the boundary with
+[[capability-gap-as-parse-error]].
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the hints,
+  their triggers and their controls
+- [[capability-gap-as-parse-error]] — when the honest hint is "you cannot"
+- [[keyword-collisions]] — the two kinds of reserved word, kept apart
diff --git a/docs-wiki/bug-patterns/mutator-addressing.md b/docs-wiki/bug-patterns/mutator-addressing.md
new file mode 100644
index 000000000..be6e76517
--- /dev/null
+++ b/docs-wiki/bug-patterns/mutator-addressing.md
@@ -0,0 +1,74 @@
+---
+title: Addressing Things the Model Does Not Name
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-backend.jsonl
+  - mdl/backend/mpr/page_mutator.go
+  - mdl/backend/modelsdk/page_write.go
+---
+
+> **Do not duplicate**: the ALTER PAGE / ALTER LAYOUT syntax lives in the skills
+> and `MDL_QUICK_REFERENCE.md`; the per-property fixes live in the findings. This
+> page is about the addressing problem underneath them.
+
+## What this is
+
+`ALTER PAGE`, `ALTER LAYOUT` and `ALTER WORKFLOW` edit a stored document in
+place, which means naming a node inside it. Roughly thirteen `mdl/backend`
+findings come from the fact that **many of the interesting nodes have no name**.
+A DataGrid 2 column, an Accordion group, a pop-up menu item and a layout region
+are all addressable in Studio Pro and store no `Name` at all.
+
+The resulting failures have a distinctive signature: the command reports
+success and nothing changes. Or it reports `widget "X" not found` for something
+`DESCRIBE` plainly shows.
+
+## How it fits
+
+**A derived name is the only option, and it is not stable.** A column's
+addressable name comes from its attribute or caption, so it moves when the
+caption is edited. Persisting the name the author wrote is not available either:
+there is no slot for it, and inventing one is the write-a-property-Studio-Pro-
+does-not-declare hazard. What is left is to make the derivation *visible* — warn
+at authoring time which name will be addressable, and on a lookup miss list the
+addressable names rather than reporting a bare not-found.
+
+**Ambiguity must be refused, not resolved.** Two columns deriving the same name
+is a real state, and taking the first is a data hazard rather than a wart. The
+same applies to a bare name that could mean either an object-list item or a
+widget: discriminate on the resolved node's `$Type`, name the qualified form in
+the error, and do not guess which grid was meant — guessing is what produced an
+invalid document.
+
+**A slot is not a name.** A layout region has neither, so it is addressed
+positionally (`layoutContainer.top`), reusing the dotted reference that also
+serves columns and disambiguated the same way. Only `INSERT INTO` accepts one:
+BEFORE and AFTER position a widget among siblings, and treating them as INTO
+would silently put widgets somewhere the script did not ask for.
+
+**Property lookup is per-shape, and the shapes differ.** A button's text is a
+`CaptionTemplate`, not a `Caption`. Page-level property names are case-sensitive
+while widget ones are matched lowercase. A column's value kind comes from the
+schema — expression, primitive or text template — and writing a string where a
+reference belongs is accepted by everything and visible to nothing.
+
+**Hand-built BSON drifts from codec-built BSON.** The mutator constructs
+documents directly while CREATE goes through the codec, so the two encodings of
+"the same" widget diverge — an empty-string value where the codec writes an
+explicit key, a typed-array marker present in one and not the other. The reliable
+method is to **diff the two encodings** with a BSON dump rather than eyeball the
+hand-built one. Getting the marker wrong is not a smaller version of the same
+bug: it turns a silent no-op into a project Studio Pro cannot open.
+
+**Check whether the symptom reproduces outside the reported context.** One
+"widget not found" turned out to be two independent defects, and the fix for the
+reported nesting alone would not have made the reporter's command work.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the individual
+  properties, shapes and refusals
+- [[unloadable-model-writes]] — where a wrong typed-array marker ends up
+- [[silent-property-drop]] — the executor-side twin of "reports success, writes
+  nothing"
diff --git a/docs-wiki/bug-patterns/package-operations-damage.md b/docs-wiki/bug-patterns/package-operations-damage.md
new file mode 100644
index 000000000..1c73469c4
--- /dev/null
+++ b/docs-wiki/bug-patterns/package-operations-damage.md
@@ -0,0 +1,66 @@
+---
+title: Package Operations That Damage the Project
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/cmd-mxcli.jsonl
+  - cmd/mxcli/marketplace/update.go
+---
+
+> **Do not duplicate**: the marketplace command surface lives in the CLI help and
+> `PROPOSAL_marketplace_module_upgrade.md`; the per-operation repairs live in the
+> findings. This page describes the shared hazard.
+
+## What this is
+
+Installing or updating a marketplace module, or running `mx update-widgets`,
+hands the project to a tool mxcli does not control — and several of those tools
+change things nobody asked them to. Eleven `cmd/mxcli` findings are damage from
+that hand-off, and the damage is usually reported as success.
+
+## How it fits
+
+**The v2 → v1 collapse is the worst of them.** Mendix's own tooling rewrites an
+MPR v2 project (`.mpr` plus a `mprcontents/` tree) into a single-file v1
+database. `mx check` afterwards reports **0 errors** and looks like a clean run;
+what has actually happened is that `mprcontents/` is gone, the `.mpr` has grown
+from tens of kilobytes to tens of megabytes, and per-document diffing no longer
+works. Nothing about the output says so. mxcli's repair commands exist because of
+this: let the tool convert, read the units back, restore v2, and write only the
+changed ones through mxcli's own writer.
+
+**Version numbers are not identity.** Matching an installed module against a
+marketplace release by version *number* is ambiguous — a blank project ships two
+different modules that both published a 4.1.0. The module's `AppStoreGuid` is the
+version UUID and is the thing to match on. Getting this wrong produces
+"version not found" for a module the project demonstrably has.
+
+**An update can move a dependency backwards.** Installing one module rolled a
+project's widgets from 3.11.3 to 3.4.0 because an unrelated package bundled an
+older copy, and `mx check` stayed clean throughout. Anything that copies bundled
+files needs to compare versions rather than overwrite, and to *report* what it
+skipped — "the package wanted a different version" is exactly the fact that was
+invisible.
+
+**A model that builds can still be running the old code.** After an update the
+model referenced new widget definitions while `widgets/` held the old binaries;
+`show modules` reported the new version. The model and the deployed artefacts are
+separate, and only one of them is what `mx check` inspects.
+
+**Report what could not be determined, never "unchanged".** Drift detection
+compares an installed module against a freshly imported reference, and an element
+that cannot be described is reported **unknown**. Reporting it as unchanged would
+turn a gap in coverage into a claim about the user's project — and the same
+report also has to say when "no modifications found" is not a conclusion.
+
+**Environment failures masquerade as project corruption.** A path too long, an
+`.mpk` built by a newer Studio Pro, a `mx` invocation resolving to a different
+cached version — each leaves output that looks like a broken install. The
+remedies are mostly diagnosis: say which version, which path, which binary.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the individual
+  repairs and their measurements
+- [[mpr-read-write]] — what v1 and v2 actually are, and why the collapse matters
+- `PROPOSAL_marketplace_module_upgrade.md` — the drift-detection design
diff --git a/docs-wiki/bug-patterns/scripts-that-cannot-rerun.md b/docs-wiki/bug-patterns/scripts-that-cannot-rerun.md
new file mode 100644
index 000000000..98e1b80fe
--- /dev/null
+++ b/docs-wiki/bug-patterns/scripts-that-cannot-rerun.md
@@ -0,0 +1,68 @@
+---
+title: Scripts That Cannot Be Re-Run
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-grammar.jsonl
+  - mdl/grammar/domains/MDLDomainModel.g4
+  - docs/13-decisions/0003-mdl-is-sql-shaped.md
+---
+
+> **Do not duplicate**: the `IF NOT EXISTS` / `create or modify` spellings live
+> in `MDL_QUICK_REFERENCE.md`; write-level idempotence is ADR-0008 and
+> [[element-identity]]. This page is about idempotence at the *statement* level,
+> which is a different thing.
+
+## What this is
+
+mxcli's writes are idempotent — a unit whose content has not changed is not
+written at all. Its *statements* are not, and the two get conflated. `create`
+follows SQL convention and fails on an existing object; `alter entity … add
+attribute` fails when the attribute is already there. Five `mdl/grammar` findings
+are the consequence, and the compounding one is that `exec` halts on the first
+error.
+
+Put together: **a domain script that is 90% already applied applies none of the
+remaining 10%.** The first `add attribute` that already exists ends the run, and
+every later statement — including the new ones — is skipped. The user's reading is
+usually that mxcli is broken, because re-running a script is the natural way to
+converge a project on a description of it.
+
+## How it fits
+
+**The silent variant is worse than the error.** `alter entity … add index` did
+not fail on a re-run: it reported "Added index" and appended a duplicate, and the
+build then rejected the project. An error that stops the script is recoverable; a
+success that corrupts is not, and the two live in the same statement family.
+
+**Non-idempotence is a design decision, not a bug — but it has to be
+discoverable.** MDL is SQL-shaped deliberately, and `CREATE TABLE` failing on an
+existing table is the behaviour that shape implies. What was missing was the
+signpost: the bare "already exists" error did not name `create or modify`, and
+the idempotent spellings existed without being reachable from the failure.
+
+**Two remedies, and they answer different questions.** `IF NOT EXISTS` /
+`IF EXISTS` on a statement says *this one is optional*, which is what a
+converging domain script wants. `exec --continue-on-error` says *attempt
+everything and tell me what failed*, which is what a partially-applied script
+wants — and it must still exit non-zero, or it trades a stopped run for a hidden
+failure.
+
+**Watch for the pair that cannot both be re-run.** `ADD EVENT HANDLER` errors
+when the handler exists and `DROP EVENT HANDLER` errors when it does not, so
+neither a plain script nor a defensive drop-then-add is re-runnable. A statement
+family needs the guard on both halves or the workaround is unavailable too.
+
+**A list rule without a separator reads as a value error.** Several parse
+failures in this area were reported against the *value* in the second item of a
+list — `add attribute A: integer default 9, add attribute B: …` — when the list
+rule simply had no comma alternative. When a parse error names something that is
+plainly valid in the first position, suspect the list before the value.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the guards, the
+  flags and the bug-tests
+- [[mdl-as-sql]] — why `create` is non-idempotent on purpose
+- [[element-identity]] — write-level idempotence, which is unrelated and is often
+  what people mean when they say mxcli is idempotent
diff --git a/docs-wiki/bug-patterns/styling-compiles-to-nothing.md b/docs-wiki/bug-patterns/styling-compiles-to-nothing.md
new file mode 100644
index 000000000..fc9612484
--- /dev/null
+++ b/docs-wiki/bug-patterns/styling-compiles-to-nothing.md
@@ -0,0 +1,62 @@
+---
+title: Styling That Compiles to Nothing
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/cmd-mxcli.jsonl
+  - cmd/mxcli/theme/block.go
+---
+
+> **Do not duplicate**: where SCSS compiles and the Atlas layering rules are
+> canonical in CLAUDE.md; the theme commands are in the skills. This page
+> describes why the failures are invisible.
+
+## What this is
+
+Eleven `cmd/mxcli` findings are styling that was written correctly, built
+successfully, and had no effect — or had an effect nobody could read. There is no
+validator for CSS. `mx check` says nothing, the build succeeds, and the rules are
+simply absent from the compiled stylesheet, which in a browser is
+indistinguishable from a specificity problem.
+
+## How it fits
+
+**Location decides whether anything compiles at all.** mxbuild walks the model's
+modules to find theme sources; it never globs the directory. SCSS written to a
+folder that does not match a real module is skipped without a warning. The
+same applies in reverse to files imported once per module, where a rule — as
+opposed to a declaration — is emitted N times.
+
+**A token nobody reads is indistinguishable from a design not applied.** Writing
+an unrecognised `--mxt-*` name produces a theme that applies cleanly and renders
+exactly as before. That is why an unknown token is refused rather than written:
+the alternative is a success message for a no-op.
+
+**Contrast is a correctness property, and nothing measures it.** Several findings
+are text at 1.02:1 or 1.13:1 — invisible, and reported as "contrast is low"
+rather than as a defect in a specific rule. Two Atlas rules assume a dark
+navigation rail and paint topbar text with a fixed colour, so a theme that
+lightens the rail loses its own labels. A literal colour outside the palette
+survives a theme swap and is wrong under every theme but one.
+
+**The compile-time failures are outside Go's reach.** A Sass variable holding a
+selector must be a quoted string; a bare selector is not a Sass expression, and
+the failure happens in mxbuild's SCSS compiler where no Go test and no `mx check`
+can see it. The only signal is the build log of a real build.
+
+**Writing into files the project already owns needs a fence, not a rewrite.**
+`theme/web/main.scss` is Mendix's own three lines and `custom-variables.scss`
+carries Atlas defaults, so mxcli replaces only a digest-fenced region and refuses
+a block a human has edited. The record lives in the file rather than in sidecar
+state, which is what keeps it from drifting — and it is the same guard-don't-drop
+rule as [[rewrite-drops-unauthored-state]], applied to files instead of BSON.
+Its failure mode is the mirror image: a project that has silently taken ownership
+of a file, reported as `skipped` forever after.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the individual
+  selectors, tokens and measurements
+- [[rewrite-drops-unauthored-state]] — the same guard, applied to model documents
+- `.claude/skills/verify-in-runtime.md` — the only way most of this class is
+  observable
diff --git a/docs-wiki/bug-patterns/test-runner-cannot-fail.md b/docs-wiki/bug-patterns/test-runner-cannot-fail.md
new file mode 100644
index 000000000..fa4f18647
--- /dev/null
+++ b/docs-wiki/bug-patterns/test-runner-cannot-fail.md
@@ -0,0 +1,82 @@
+---
+title: A Test Runner That Cannot Fail
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/cmd-mxcli.jsonl
+  - cmd/mxcli/testrunner/parser.go
+  - cmd/mxcli/testrunner/generator_endpoint.go
+---
+
+> **Do not duplicate**: the annotation reference and the `.test.mdl` format live
+> in `.claude/skills/test-microflows.md` and `docs/15-testing/`; the individual
+> fixes live in the findings. This page describes why the class is uniquely
+> dangerous.
+
+## What this is
+
+Fourteen `cmd/mxcli` findings are `mxcli test` reporting **PASS** for something
+that did not hold, or did not run, or was never evaluated. `@expect 1 = 2`
+passed. `@verify` — the annotation covering the harder half of Mendix testing,
+where a microflow's only observable effect is rows written — was parsed and read
+by nothing but `--list`. `--require-assertions` exited 0 on a suite where nothing
+asserted. A test with both `@throws` and `@expect` reported two assertions and
+made one.
+
+Every other class in this wiki costs a debugging session. This one **spends
+confidence that was never earned**: green output is the entire product, and a
+runner that cannot fail is worse than no runner, because a real suite gets
+written against it and believed.
+
+## How it fits
+
+**Silent absence, not silent breakage.** The recurring mechanism is not a wrong
+answer but a missing consumer. An annotation is parsed into a struct field, and
+nothing downstream reads it. `grep -n '\.Verify'` over the package was the whole
+diagnosis. The parse succeeding is what makes it invisible: `--list` prints the
+annotation back, so the feature looks wired.
+
+**Two result-assembly paths, and a decision that lives in one of them.** The
+runner has two backends — the after-startup runner and the HTTP test endpoint —
+and results were assembled separately in each. A flag consulted in one loop, a
+field populated at one of five `TestResult` literal sites, a verdict computed in
+the endpoint path only: each is the [[duplicate-resolver-drift]] shape landing
+where its consequence is a false pass. The remedy that held was structural — one
+constructor, one pre-run verdict function — pinned by a test asserting it is the
+*only* call site.
+
+**Fail closed.** An annotation that claims to assert something and cannot be
+honoured is now an **error**, and the test does not run. That is the opposite of
+the instinct (drop what you cannot handle and carry on), and it is the only
+policy under which a passing report means anything.
+
+**The default output has to distinguish an assertion from a silence.** A test
+that asserted nothing printed the same `PASS` as one with six assertions. Putting
+the count behind `--verbose` would have missed the point: the *unread* output is
+where the false confidence lives.
+
+**Substring where structure was needed.** Two defects came from searching text
+instead of parsing it. Unanchored annotation patterns matched inside prose, so a
+doc comment *explaining* `@expect $x = 1` gave the test that assertion — found
+while writing the reproduction for another bug, whose header caused it. And a
+line-number estimate searched reconstructed text inside the raw bytes, which
+cannot match under CRLF and panicked with a negative slice bound.
+
+**The environment is part of the assertion.** A suite that passes under
+`--attach` and fails under `--local` is usually neither: the two boot paths
+differed in whether constant overrides were applied and whether the project's own
+after-startup microflow was chained. Nothing in either output explained the
+difference. Both are now printed, and both boot paths share one options mapping.
+
+**A test run must not change the project.** The runner injects a module and takes
+it back out; restoring the model still moved the `.mpr`'s bytes, so a
+"tests pass and the tree is clean" CI step failed on a meaningless diff. Snapshot
+and restore the file, and refuse to restore when cleanup failed — a tree that
+reads clean while the project is not is worse than a visible discrepancy.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — each annotation,
+  its consumer, and the control that proves it can now fail
+- [[duplicate-resolver-drift]] — the same structural cause, in the executor
+- `.claude/skills/test-microflows.md` — the annotation reference itself
diff --git a/docs-wiki/bug-patterns/visitor-wiring-gaps.md b/docs-wiki/bug-patterns/visitor-wiring-gaps.md
index 35baee242..3b65149ac 100644
--- a/docs-wiki/bug-patterns/visitor-wiring-gaps.md
+++ b/docs-wiki/bug-patterns/visitor-wiring-gaps.md
@@ -1,28 +1,69 @@
 ---
 title: Visitor Wiring Gaps
 category: bug-pattern
-last-synced: 4e185f73
+last-synced: ced830e0
 sources:
-  - .claude/skills/fix-issue/findings/
+  - .claude/skills/fix-issue/findings/mdl-visitor.jsonl
   - mdl/visitor/visitor_enumeration.go
+  - mdl/visitor/visitor_helpers.go
 ---
 
-> **Do not duplicate**: the specific fix recipe (issue #393) lives in the `.claude/skills/fix-issue/findings/` symptom row, and the canonical wiring blocks live in `mdl/visitor/`. This page describes the pattern only.
+> **Do not duplicate**: the per-instance fix recipes and the exact blocks to copy
+> live in the findings; the canonical wiring lives in `mdl/visitor/`. This page
+> describes the pattern only.
 
 ## What this is
 
-A family of "parsed-but-not-stored" bugs: a property the user set in a `CREATE` statement silently vanishes after a roundtrip. The grammar accepts it, the AST struct has a field for it, the model and writer both carry it, and `DESCRIBE` knows how to print it — yet it never appears, because the value was never copied out of the parse tree into the AST.
+A family of "parsed-but-not-stored" bugs. The grammar accepts the input, the AST
+struct has a field for it, the model and writer both carry it, and `DESCRIBE`
+knows how to print it — and it never appears, because the value was never copied
+out of the parse tree into the AST.
+
+The visitor is the one **hand-written** bridge in the grammar → visitor → AST →
+executor → backend pipeline, and it is per-statement boilerplate with no compiler
+check that every field was copied. That is the whole mechanism.
 
 ## How it fits
 
-mxcli's pipeline runs grammar → visitor → AST → executor → backend, and the visitor is the one hand-written bridge in that chain. Each `ExitCreateXxxStatement` must explicitly read fields off the ANTLR parse-tree context and assign them onto the AST struct. When a new `CREATE` variant is added, it is easy to wire every other layer and forget one assignment in the visitor — so the field round-trips through nothing.
+**The gap comes in three sizes, and they present very differently.**
+
+*A field.* The original instance: an enum-level doc comment vanishing after a
+round trip, a `CREATE OR REPLACE` flag silently running as a plain `CREATE`. Every
+layer below the visitor is correct, and the loss is one document type wide. The
+canonical fix is to diff the broken visitor against a known-good sibling — the
+enumeration and constant visitors share the same two standard blocks verbatim.
+
+*A structure.* An `ELSIF` chain whose middle arms were dropped on write. Mendix
+has no native `elsif`, so each arm has to be lowered into a nested `if` in the
+previous arm's `else` branch; a visitor that reads only the first and last arms
+produces a valid microflow that is missing behaviour. The read path was never
+wrong — a round trip showed `if … else …` because the arms were absent from the
+model, which is the diagnostic that separates a write gap from a read gap.
+
+*A whole statement.* A `DROP` or a `SHOW` that parses, exits 0, prints nothing
+and does nothing, because the statement reached the AST and no dispatch case. The
+symptom reads as an empty result — "this page has no content", "there are no
+connections" — rather than as a missing feature, which is what makes it survive.
+Anything that can end in an empty output needs to distinguish *nothing found*
+from *nothing ran*.
 
-The tell-tale: every layer below the visitor is correct (the field exists in the AST, the writer serializes it, `DESCRIBE` prints it for other types) but a doc-comment or `OR MODIFY`/`OR REPLACE` flag disappears for one specific document type. The class recurs because visitor methods are per-statement boilerplate with no compiler check that all fields were copied.
+**The neighbouring failure is a field wired to the wrong thing**, which is worse
+than one not wired at all: a delete-behaviour keyword storing a different
+behaviour, a dollar-quoted SQL body overwritten by a parameter's default. Those
+report success and change the model's meaning, where an unwired field merely
+loses it.
 
-The canonical fix is to diff the broken visitor against a known-good sibling. The enumeration and constant visitors in [`mdl/visitor/`](../../mdl/visitor/visitor_enumeration.go) share the same two standard blocks verbatim — `stmt.Documentation = findDocCommentText(ctx)` and the `OR MODIFY`/`OR REPLACE` flag detection. The exact blocks to copy are in the symptom table.
+**Guard the class, not the instance.** These recur because the boilerplate is
+per-statement. The remedies that have held are structural: route every qualified
+name through one accessor rather than `GetText()`, and assert reachability — a
+test that every exported validator is called from the one entry point catches a
+whole statement that was never wired, which no per-feature test can.
 
 ## See also
 
-- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the per-instance fix recipes for this pattern
-- [[architecture/mdl-execution]] — the grammar → visitor → AST → executor pipeline this gap sits in
-- [[rationale/mdl-as-sql]] — why MDL statements roundtrip through `DESCRIBE`
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the per-instance
+  recipes and the blocks to copy
+- [[mdl-execution]] — the pipeline this gap sits in
+- [[duplicate-resolver-drift]] — the sibling shape one layer down
+- [[expression-translation-drift]] — where the visitor changes meaning rather than
+  dropping it
diff --git a/scripts/check-findings.sh b/scripts/check-findings.sh
index 48c326dcf..c6b988465 100755
--- a/scripts/check-findings.sh
+++ b/scripts/check-findings.sh
@@ -41,6 +41,12 @@ for path in sys.argv[1:]:
                 print("%s:%d: not a JSON object" % (path, n)); bad += 1; continue
             if not rec.get("area"):
                 print("%s:%d: missing `area`" % (path, n)); bad += 1
+            # A dateless finding is invisible to the digest report, which then
+            # says the wiki is current when it is not. Required rather than
+            # warned about: 249 records accumulated undated before this check
+            # existed, and nobody saw the warning that was not there.
+            if not rec.get("date"):
+                print("%s:%d: missing `date` (YYYY-MM-DD)" % (path, n)); bad += 1
             structured = all(rec.get(k) for k in ("symptom", "cause", "file", "insight"))
             if not structured and not rec.get("raw"):
                 print("%s:%d: needs either symptom/cause/file/insight or raw" % (path, n))
diff --git a/scripts/digest-status.sh b/scripts/digest-status.sh
index a303483b0..a85e201de 100755
--- a/scripts/digest-status.sh
+++ b/scripts/digest-status.sh
@@ -8,7 +8,20 @@
 # result was three pattern pages, all synthesised on one day in May, against a
 # corpus that kept growing.
 #
-# This makes the gap a number. It is ADVISORY and always exits 0 — a stale digest
+# Two limits worth knowing, because both make the number look BETTER than
+# reality and neither is worth over-engineering away:
+#
+#   - `date` is day-resolution, and the comparison is strictly greater-than, so
+#     findings appended on the same day as a sync count as digested. Measured:
+#     256 of mdl/executor's findings carry the sync's own date, ~250 of which
+#     landed after the pages were written.
+#   - `date` is now required (check-findings enforces it), but the 249 records
+#     that predate that requirement were backfilled from `git blame` — which
+#     that very backfill then invalidated for every line. The field is the only
+#     record from here on; there is no second source to recover it from.
+#
+# So read the per-area `in a page` column as the actionable signal and the
+# counts as a hint. This makes the gap a number. It is ADVISORY and always exits 0 — a stale digest
 # must not block an unrelated fix. The teeth are that check-findings prints the
 # one-line form on every run, so the number is in front of whoever just appended.
 
@@ -36,7 +49,12 @@ for fn in glob.glob(".claude/skills/fix-issue/findings/*.jsonl"):
         areas[a] += 1
         d = r.get("date")
         if not d:
+            # An undated finding is one this report cannot place. Counting it as
+            # digested is the failure mode that matters: the headline would read
+            # "0% outstanding" while a whole area went undigested. 249 records
+            # reached the corpus that way before the date field was required.
             undated += 1
+            since[a] += 1
         elif d > last:
             since[a] += 1
 
@@ -44,7 +62,7 @@ total, new = sum(areas.values()), sum(since.values())
 
 if brief:
     if new:
-        print("digest: %d of %d findings added since the last bug-pattern sync (%s, %d pages)"
+        print("digest: %d of %d findings not yet digested (last bug-pattern sync %s, %d pages)"
               " — /mxcli-dev:wiki-sync bug-patterns/" % (new, total, last, len(pages)))
     sys.exit(0)
 
@@ -52,9 +70,9 @@ print("Bug-pattern digest status\n")
 print("  pattern pages      %d" % len(pages))
 print("  last sync          %s" % last)
 print("  findings           %d" % total)
-print("  added since sync   %d  (%.0f%%)" % (new, 100.0 * new / total if total else 0))
+print("  not yet digested   %d  (%.0f%%)" % (new, 100.0 * new / total if total else 0))
 if undated:
-    print("  undated            %d" % undated)
+    print("    of which undated %d  (counted as not digested)" % undated)
 
 # Which areas does the existing digest even mention? A heuristic, deliberately:
 # the alternative is a covers: list in every page's frontmatter, which is one