diff --git a/.claude/commands/mxcli-dev/wiki-sync.md b/.claude/commands/mxcli-dev/wiki-sync.md
index 4adf46e3fb..80bfaed679 100644
--- a/.claude/commands/mxcli-dev/wiki-sync.md
+++ b/.claude/commands/mxcli-dev/wiki-sync.md
@@ -19,8 +19,14 @@ This command is the trigger; the skill is the contract.
 - `--all` — sync every page in `docs-wiki/`.
 - `--stale` — sync only pages whose `last-synced:` SHA is older than HEAD.
 
+For `bug-patterns/` specifically, run **`make digest-status`** first: it reports
+how many findings have landed since the last bug-pattern sync and which areas
+no page mentions. That is the scope question for this category — the pages
+digest `.claude/skills/fix-issue/findings/*.jsonl`, and an area with many
+findings and no page is an undigested failure class, not a missing file.
+
 If invoked with no arguments, ask the user which page(s) to sync. List the
-seed table from `maintain-wiki.md` as options.
+page list from `.claude/skills/maintain-wiki/pages.md` as options.
 
 ## Process
 
@@ -88,10 +94,10 @@ If the user is requesting a page that doesn't yet exist in
 2. Is it really a procedure (skill), reference (manual), implementation
    detail (source), state (proposal frontmatter / GitHub), or
    decision (ADR)? → route there instead.
-3. If it genuinely belongs in the wiki, add it to the seed table in
+3. If it genuinely belongs in the wiki, add a row to the page list in
    `maintain-wiki.md` first, with its category, before creating the file.
 
-The seed table is the wiki's table of contents — new pages outside it
+That file is the wiki's table of contents — new pages outside it
 should be the rare exception, not the default.
 
 ## Important reminders
diff --git a/.claude/skills/fix-issue.md b/.claude/skills/fix-issue.md
index 2643911339..5bab3138ff 100644
--- a/.claude/skills/fix-issue.md
+++ b/.claude/skills/fix-issue.md
@@ -2,22 +2,20 @@
 
 A fast-path workflow for diagnosing and fixing bugs in mxcli.
 
-Each fix appends one row to the symptom table below. That table is **evidence, not
-reading material** — it is ~1 MB and cannot be loaded whole. The entry point for a
-diagnosis is [`docs-wiki/bug-patterns/`](../../docs-wiki/bug-patterns/), which digests
-these rows into failure classes; the table is where you drill down for the specific
-instance.
+Each fix appends one finding to `findings/*.jsonl`. Those are **evidence, not
+reading material**: 630 findings at ~1.7 KB each. The entry point for a diagnosis
+is [`docs-wiki/bug-patterns/`](../../docs-wiki/bug-patterns/), which digests them
+into failure classes; the findings are where you drill down for the instance.
 
 ## How to Use
 
 1. **Start with the failure class.** Skim
-   [`docs-wiki/bug-patterns/`](../../docs-wiki/bug-patterns/) — it is small, and it tells
-   you which layer the bug lives in. Coverage is partial (three pages against 600+ rows),
-   so a miss there means the finding has not been digested yet, **not** that it is new.
-2. **Then find the instance**: `grep -i '<keyword>' .claude/skills/fix-issue.md`. Go
-   straight to the file the matching row names and follow its fix pattern. Do not open
-   this file's table whole — it is ~1 MB, and it is looked up by matching a symptom, not
-   read in order.
+   [`docs-wiki/bug-patterns/`](../../docs-wiki/bug-patterns/) — it is small, and it
+   tells you which layer the bug lives in. Coverage is partial (three pages against
+   630 findings), so a miss there means the finding has not been digested yet,
+   **not** that it is new.
+2. **Then find the instance** — see "Finding a prior fix" below. Go straight to the
+   file the matching record names and follow its insight.
 3. Write a failing test first, then implement.
 4. **Verify at the layer the symptom lives in.** Parser → unit test. BSON we write →
    unit test on the encoded document. Files on disk after `mx` runs → integration test
@@ -28,269 +26,88 @@ instance.
 5. **Prove the test detects the bug**: revert the fix and confirm it fails with the
    reported symptom. A test that has only ever run against fixed code has not been
    shown to detect anything.
-6. After the fix: **add a new row** to the table if the symptom is not already covered.
-   **Append it at the END of the table, never at the top.**
-
-> **Conflicts are handled by git, not by where you insert.** Every bug fix touches
-> this one file, so two branches fixing unrelated bugs write to the same place and git
-> raises a conflict. That cost five resolution rounds in one week when rows went in
-> under the header — and moving them to the end did **not** fix it: both sides still
-> append to the same line, so the collision moved with the convention. PRs #76, #77
-> and #78 each hit it again afterwards.
->
-> The actual fix is in `.gitattributes`:
->
-> ```
-> .claude/skills/fix-issue.md merge=union
-> ```
->
-> git's built-in `union` driver keeps **both** sides of a conflicting hunk instead of
-> raising a conflict. Two fixes that each append a row now merge with no intervention
-> and both rows present — verified by merging a simulated later fix into an open
-> branch. Where you insert no longer affects merging at all.
+6. After the fix: **append a finding** — see "Recording a fix" below.
+
+> **Why the findings are not in this file.** They were, as one Markdown table, and
+> it reached 1.05 MB / 630 rows — past what fits in a context window and past what
+> GitHub's web editor will open. It had also stopped being a table: only 227 of the
+> 630 rows were still under the header, the other 403 having accreted in twelve
+> separate runs through the document, most rendering as literal text.
 >
-> Append at the end anyway, for a human reason: it keeps a fix's diff readable and the
-> table roughly chronological. The table is looked up by matching a symptom, not read
-> top to bottom, so position carries no meaning.
+> `.gitattributes` gave `merge=union` to the whole file, which kept two concurrent
+> appends instead of conflicting. That was the right driver on the wrong unit: union
+> applies file-wide, so two branches editing the same *prose* line would silently
+> keep both. The note that shipped with it called this exact shot — "if that starts
+> happening, split the table into its own file so `union` covers only append-only
+> content" — and the union driver now sits on `findings/*.jsonl`, where every line is
+> an independent record and keeping both sides is always correct.
 >
-> **One caveat.** `union` applies to the whole file, so two branches editing the same
-> *prose* line would silently keep both rather than conflict — a visible duplicated
-> line, not corruption. If that starts happening, split the table into its own file so
-> `union` covers only append-only content.
+> It never solved the conflicts anyway: GitHub's server-side merge does not run merge
+> drivers, so every PR still had to merge `main` locally first. Sharding by area is
+> what actually reduces them — two fixes now collide only when they touch the same
+> area.
 
 ---
 
-## Symptom → Layer → File Table
-
-| Symptom | Root cause layer | First file to open | Fix pattern |
-|---------|-----------------|-------------------|-------------|
-| Every popup opened by an **mxcli-authored** button or Show Page action shows a **blank caption** — just the `×` — while Studio Pro / marketplace popups in the same project are fine. Also: `show page M.P with title = 'X'` is silently ignored | `Forms$FormSettings` / `Forms$PageSettings` `TitleOverride` was written as an **empty** `Microflows$TextTemplate` instead of `null`. An empty template is not the absence of an override — it overrides the title with the empty string. The same unconditional write also discarded `ShowPageAction.OverridePageTitle`, so an authored override never reached BSON (`grep -rn OverridePageTitle` matched only the struct field and its assignment) | `sdk/mpr/writer_microflow_actions.go` (`titleOverrideValue`), `sdk/mpr/writer_widgets_action.go`, `mdl/backend/modelsdk/microflow_write.go` (`showPageFormSettingsToGen`), `mdl/backend/modelsdk/widget_write.go` (`formSettingsToGen` + the `Forms$FormSettings`/`Forms$PageSettings` defaults) | Emit `null` when there is no override and a populated `TextTemplate` when there is. **Beware two traps.** (1) The old comments claimed TitleOverride "must be non-nil", reasoning by analogy from #295, which was about `Forms$PageVariable` — a different field; the repo's own `debug-bson.md` already documented `TitleOverride: nil` as correct. When a comment cites an issue as justification, check that the issue is about the same field. (2) `codec.RegisterTypeDefaults` **overwrites rather than merges**, so two registrations for one `$Type` resolve silently by init order — a `NullFields` entry added next to the microflow writer was clobbered by the one in `widget_write.go` and the null never appeared. Grep for duplicate registrations before debugging a default that "does not apply". Repro `mdl-examples/bug-tests/812-showpage-title-override.mdl`. Issue #812 |
-| 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" | `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` | `mdl/executor/layout.go` (`measureStatementsSpan`), used by `addLoopStatement`/`addWhileStatement` in `cmd_microflows_builder_control.go` | 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 |
-| A microflow writes and `mxcli` reports success, but Studio Pro cannot open the project: `System.Collections.Generic.KeyNotFoundException: The given key '<guid>' was not present in the dictionary`. Triggered by a `break`/`continue` inside an if/case within a loop | `microflowObjectToGen`'s `default:` branch returns nil for an unhandled object type, so the event object was dropped at serialization while the SequenceFlow pointing at it was written — a DestinationPointer to a GUID that exists nowhere. Exactly the shape already fixed once for `Microflows$ErrorEvent` | `mdl/backend/modelsdk/microflow_write.go` (`microflowObjectToGen`) — compare against `sdk/mpr/writer_microflow.go`, which handles the full set | Add the missing `case *microflows.XxxEvent:` returning the gen element with ID, position and size. **Diagnose without Studio Pro**: dump the microflow (`mxcli bson dump --type microflow --object M.F`), collect every `$ID`, and check every key ending in `Pointer` resolves — a dangling pointer is this bug. When a check-time rule exists only as a stopgap for a write-path bug (MDL051 was), remove it with the real fix, and check whether it covered every affected keyword (MDL051 covered `break`, not `continue`, which is how #791 reached users). Repro `mdl-examples/bug-tests/791-loop-continue-dangling-flow.mdl`. Issue #791, ledger #52 |
-| `mxcli test` leaves the project mutated: Security Level changed, after-startup pointing at the deleted `MxTest.TestRunner`, and only a `Warning:` line about it. Or: an empty `MxTest` module accumulates after every run | Three defects in one teardown. (a) `getAfterStartup` trimmed quotes *before* trailing punctuation, so a DESCRIBE SETTINGS line ending in `,` yielded `Module.Flow',` and the restore statement was unparseable; (b) cleanup dropped only the microflow, not the module it created; (c) the Security Level was forced OFF and restored to a hardcoded PRODUCTION | `cmd/mxcli/testrunner/runner.go` (`parseSettingValue`, `quoteMDLString`, `projectState`, `setupCommands`, `cleanupCommands`) | Strip trailing `,;` before unquoting; re-emit via `quoteMDLString` (doubling embedded quotes, never backslashes); capture a `projectState` before the first mutation and restore from it; drop the module only when the run created it (a pre-existing `MxTest` is the user's); leave Security Level alone entirely; return cleanup errors instead of printing warnings, and fail the run when they occur. Command lists are pure functions so the restore is testable without a project or Docker. Issues #802/#803/#804 |
-| `create or modify external entities` silently resets a per-entity setting the user had changed (e.g. allow-create-change-locally) | `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 | `mdl/executor/cmd_contract.go` (`applyExternalEntityFields`) | 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 |
-| An **external (OData) entity** loses its remote settings on any read-modify-write — `describe external entity` says `is not an external entity (source: )`, and `alter entity … set allow_create_change_locally = true` reports success but the flag stays off. Works under `--engine legacy` | `entityFromGen` recognised only `DomainModels$OqlViewEntitySource`, so the three `Rest$OData*` sources read back as no source at all: `Source` empty, every remote field zeroed. The write path was fine — it switches on `e.Source`, which the read never populated | `mdl/backend/modelsdk/domainmodel.go` (`entityFromGen`'s source switch, `odataKeyFromGen`) | Mirror the legacy parser (`sdk/mpr/parser_domainmodel.go`) for all three flavours: RemoteEntitySource (capabilities + CreateChangeLocally + key), EntityTypeSource (type name + IsOpen + key), PrimitiveCollectionEntitySource (service only). `Updatable` has no gen accessor and the writer does not emit it — leaving it zero is symmetric. **Check the read side first when a write-path field "does not stick"**: a switch on a field the read never fills looks like a write bug. Repro `mdl-examples/bug-tests/782-external-entity-create-change-locally.mdl`. Issue #782 |
-| A pluggable widget's datasource (or child widget, or client action) is **silently dropped at write time** — `exec` prints `Created page` but the widget lands with the piece missing, and only a `log` line mentions `not yet supported — rerun with MXCLI_ENGINE=legacy` | The converter *does* return an error, but it travels through `widgetobj.ChildSerializer`, whose methods return BSON with no error channel (the `TODO(shared-types)` in `mdl/backend/widgetobj/builder.go`), so the caller logged it and returned nil | `mdl/backend/modelsdk/widget_pluggable_write.go` (`recordChildSerializeErr`, `takeChildSerializeErr`) + the drains in `page_write.go` / `snippet_write.go` | Record the failure in a package-level accumulator and drain it at every page/snippet write entry point, so the statement fails instead of the write succeeding with data missing (ADR-0004: refuse, don't drop). The real fix is the deferred `ChildSerializer` interface change; until then, any **new** write entry point that builds pluggable widgets must drain too. Repro `mdl-examples/bug-tests/795b-flow-datasource-context-entity.mdl` |
-| `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 | `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) | `mdl/executor/cmd_pages_describe_flowcontext.go` (`dataSourceEntityContext`, `flowReturnEntity`) + the five assignment sites in `cmd_pages_describe_parse.go` | 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 |
-| `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 | 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 | `mdl/executor/cmd_pages_describe_pluggable.go` (`microflowSourceRef`, `nanoflowSourceRef`, `extractDataGrid2DataSource`, `extractGalleryDataSource`, `parseCustomWidgetDataSource`) | 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 |
-| Any `ALTER SETTINGS` (any section) reports success but the Default configuration's **Custom settings** are gone, **Tracing** is reset, and every **constant override** shows blank in Studio Pro — Integer/Long constants then fail the build | The configuration was re-serialized from `model.ServerConfiguration`, which carries only the modelled fields, so CustomSettings/Tracing/OpenAdminPort/OpenHttpPort were dropped, the list version markers downgraded 3→2, and overrides were written with a flat `Value` instead of the nested `SharedOrPrivateValue` the platform reads | `mdl/settingsoverlay/settingsoverlay.go` (`Configurations`, `ServerConfiguration`, `ConstantValues`) — called by both `mdl/backend/modelsdk/settings_write.go` and `sdk/mpr/writer_settings.go` | Overlay onto the raw document instead of rebuilding: write only the fields the read path populates, take each list's marker from what is stored, and update a constant override in the slot it already occupies (nested if nested, flat if flat). New override → nested. New configuration → clone a sibling's shape, empty its collections, mint a fresh `$ID`. Refuse the write when `RawParts` is empty. Repro `mdl-examples/bug-tests/801-alter-settings-preserves-configuration.mdl`. Issue #801 |
-| `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` | `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 | `mdl/executor/cmd_settings.go` (`settingsInt`, `settingsBool`) + `mdl/executor/validate_settings.go` (`typedSettingsKeys`, MDL-SET01/MDL-SET02) | 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 |
-| MCP op reports `MCP error -32000: Request timed out` but the page/document/entity EXISTS in Studio Pro afterwards | Studio Pro's ~30s server-side per-call limit fires while the op still applies — a client false failure, not a server rejection | `mdl/backend/mcp/timeout.go` (`isTimeoutErr`, `timeoutVerifyDelay`, `pedUpdateVerify`, `pedDocumentExists`) | Verify-on-timeout, never blind-retry a non-idempotent op: idempotent root-replace (`pgWritePage`) retries once; creates confirm via `ped_find_document`; entity adds confirm via a shallow `/entities` read. Unverified → error with save-before-re-run guidance (a blind re-run from a fresh session duplicates elements) |
-| Retrieve/datasource XPath with a `[%…%]` token (e.g. `[System.owner = '[%CurrentUser%]']` or `[Title = '[%CurrentUser%]']`) fails `mx check` CE0161, but `[Title='abc']` is clean | 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`) | `mdl/executor/validate.go` (`validateRetrieveConstraints`, `baseSystemMemberRe`) — diagnose with `mxcli bson dump --type microflow` + `mx check`; verify the token alone works | 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 |
-| `describe` shows `$var = list operation ...;` | Missing parser case | `sdk/mpr/parser_microflow.go` → `parseListOperation()` | Add `case "microflows$XxxType":` returning the correct struct |
-| `describe` shows `$var = action ...;` | Missing formatter case | `mdl/executor/cmd_microflows_format_action.go` → `formatActionStatement()` | Add `case *microflows.XxxAction:` with `fmt.Sprintf` output |
-| `describe` shows `$var = list operation %T;` (with type name) | Missing formatter case | `mdl/executor/cmd_microflows_format_action.go` → `formatListOperation()` | Add `case *microflows.XxxOperation:` before the `default` |
-| Compile error: `undefined: microflows.XxxOperation` | Missing SDK struct | `sdk/microflows/microflows_actions.go` | Add struct + `func (XxxOperation) isListOperation() {}` marker |
-| `TypeCacheUnknownTypeException` in Studio Pro | Wrong `$type` storage name in BSON write | `sdk/mpr/writer_microflow.go` | Check the storage name table in CLAUDE.md; verify against `reference/mendixmodellib/reflection-data/` |
-| 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" | 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 | `mdl/executor/cmd_pages_builder_v3.go` (`buildPageV3`, the `if page.LayoutCall != nil` block) | 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` |
-| `ALTER PAGE INSERT`/`REPLACE` into a list bound `from association` **or** `datasource: microflow/nanoflow` produces a widget whose Attribute binds to the WRONG entity (the outer data view's) or nothing — `mxcli check` ✓ but `mx check` fails **CE1613** ("attribute no longer exists") or **CE0402** ("No value specified"); DESCRIBE masks it by printing only the short attribute name | The ALTER mutator read the enclosing entity from `DataSource.EntityRef.Entity`, only set for a DIRECT ref (database). An `AssociationSource` stores its destination on the last `DomainModels$EntityRefStep` of an `IndirectEntityRef`; a `MicroflowSource`/`NanoflowSource` stores NO entity at all (its entity is the flow's RETURN type, in the flow document). Either way the list reported no entity, so the context stayed at the outer data view (or empty) | `mdl/backend/pagemutator/mutator.go` (`extractEntityFromDataSource`+`lastStepDestinationEntity` for association; `EnclosingDataSourceFlow`+`findNearestDataSourceDoc` for flows) + `mdl/executor/cmd_alter_page.go` (`resolveDataSourceFlowEntity`) | Association: read the `IndirectEntityRef`'s last `EntityRefStep.DestinationEntity`. Microflow/nanoflow: the mutator returns the nearest-enclosing (or own, for INTO) flow QN — a nearer non-flow source shadows an outer flow — and the executor resolves its return entity via `getMicroflowReturnEntityName`/`getNanoflowReturnEntityName`. Guards `TestEnclosingEntity_AssociationSource`, `TestEnclosingDataSourceFlow`; repro `mdl-examples/bug-tests/55-alter-page-insert-assoc-binding.mdl`. FINDINGS #55 |
-| `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 | 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 | `mdl/executor/cmd_microflows_builder_actions.go` (`resolveMemberChange`, the "Not an association in the authored module" branch) | 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 |
-| Runtime `Failed to load model: ... Class 'Workflows$CallMicroflowTask' could not be found` — the WHOLE app won't boot, yet `mxcli check` ✓ and `mx check` → 0 errors | Mendix 11.9 (WOR-2802) split MicroflowBasedActivity into CallMicroflowActivity + AIAgentTaskActivity, renaming the workflow call-microflow on-disk `$Type` from the pre-11.9 `CallMicroflowTask` to `CallMicroflowActivity`. Writing the old name to an 11.9+ project is fatal at boot only. Evidence: 11.6.3 modeler = only Task; 11.10 modeler = both (Task marked "Removed ... WOR-2802" + a conversion routine); 11.10+ runtime jars = only Activity | `mdl/backend/modelsdk/workflow_write.go` (`applyCallMicroflowStorageName`, `useCallMicroflowActivityName`) + legacy `sdk/mpr/writer_workflow.go` (`renameCallMicroflowTypeBSON`) | Version-gate the emitted `$Type` at 11.9 (same boundary as the `HasOwner`→`HasOwnerAttr` gate): build with the legacy name, rewrite the tree to `CallMicroflowActivity` for `pv.IsAtLeast(11,9)`; register codec TypeDefaults + list-marker under BOTH names; read path already folds both into one semantic type. Repro `mdl-examples/bug-tests/263-workflow-callmicroflow-storage-name.mdl`. FINDINGS #39 |
-| `mxcli check` rejects a **valid** microflow: **MDL048** on `retrieve … where [id = '[%CurrentUser%]']` (the standard signed-in-user idiom) — but `mx check` → 0 errors | 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 | `mdl/executor/validate_microflow.go` (`checkXPathIdConstraint`) | 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 |
-| `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 | 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) | `mdl/executor/validate_microflow.go` (`exprHasSlashDivision`) | 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 |
-| `describe microflow` prints `-- Empty action` for a `set task outcome` / `open user task` / `notify workflow` statement (default engine); a describe→drop→exec round-trip silently drops it. Legacy engine (`MXCLI_ENGINE=legacy`) describes it fine | The modelsdk read path (`actionFromGen`) had no case for the workflow microflow actions, so they read back as nil → "Empty action". The write path + DESCRIBE formatter already handled them; only the modelsdk read case was missing | `mdl/backend/modelsdk/microflow_read_actions.go` (`actionFromGen`) | Add cases for `genMf.SetTaskOutcomeAction` / `OpenUserTaskAction` / `NotifyWorkflowAction`, mirroring the legacy parsers. Test `TestActionFromGen_WorkflowActions`; repro `mdl-examples/bug-tests/54-describe-set-task-outcome.mdl`. FINDINGS #54 |
-| `create association X …` errors "association already exists" on re-run and aborts the script | 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 | `mdl/executor/cmd_associations.go` (the `NewAlreadyExists("association", …)` sites) | 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 |
-| `dynamictext x (Content: '')` builds with **CE0720** "Place holder index 1 is greater than 0" — `mxcli check` ✓, describe shows `Content: '{1}'` with no params | The builder unconditionally defaulted empty content to the template `{1}`, creating a placeholder with no matching parameter (orphaned) | `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildDynamicTextV3`, final `content == ""` guard) | 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 |
-| `dynamictext s (Content: '$318')` builds with **CE0402/CE1613** ("attribute '$318' no longer exists") — the literal was turned into an unbound `{1}` param | The auto-bind check treated ANY `$`-prefixed content as a variable; `$318` (dollar + digits) is not a valid Mendix variable | `mdl/executor/cmd_pages_builder_v3_widgets.go` (`isDynamicTextVariableRef` / `dynamicTextVariableRe`) | Treat `$` as a variable ONLY when followed by a letter/underscore (`^\$[A-Za-z_]`); `$318` stays literal content. Tests `TestBuildDynamicTextV3_DollarDigitLiteral`, `TestIsDynamicTextVariableRef`. traceops #10 |
-| `listview lv (… PageSize: 200)` always pages at 20 — `mxcli check` ✓, `mx check` ✓, describe shows no PageSize | 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 | `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildListViewV3`) + `cmd_pages_describe_parse.go` (Forms$ListView case) + `cmd_pages_describe_output.go` (listview case) | 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 |
-| `mxcli oql -p app.mpr "…"` fails against a `mxcli run --local` app — first `admin password required`, then (with the password) `OQL error: Action not found.` and 0 rows — even though the same query works under `mxcli docker up` | Two-part gap. (a) The local runtime booted the JVM with no system properties, so `/dev/preview_execute_oql` was never mounted (docker mode passes `-Dmendix.live-preview=enabled -Dmendix.running.locally.by.studiopro=true` via docker-compose; the local boot did not). (b) `run --local` never printed or wrote the admin password, and `mxcli oql` errored instead of defaulting to it | `cmd/mxcli/docker/localboot.go` (`LocalRuntimeOptions.jvmArgs` — new) + `cmd/mxcli/docker/m2ee.go` (`resolveM2EEDefaults` token fallback) + `cmd/mxcli/docker/oql.go` (Action-not-found hint) + `cmd/mxcli/docker/runlocal.go` (banner) | Always pass the two live-preview `-D` flags in `jvmArgs` (run --local is always DTAPMode=D, matching docker); default the oql admin token to `defaultLocalAdminPass` when nothing else supplies it (admin API is loopback-only); branch the "Action not found" hint to cover the `--local` case; print a `Query data: mxcli oql …` line in the run banner. Tests `TestJVMArgs`, `TestResolveM2EEDefaults_Defaults`. traceops #36 |
-| A custom Starlark lint rule can't detect a **microflow-datasource** widget (e.g. a ListView with no DB pushdown) — `widget.microflow_ref` is unavailable, so a rule keyed on it returns zero hits at any threshold, even though `CATALOG.WIDGETS.MicroflowRef` is populated | The linter's `Widget` projection (struct + `Widgets()` query + Starlark dict) dropped `MicroflowRef`/`NanoflowRef` — the catalog records them but they never reached the rule tier | `mdl/linter/context.go` (`Widget` struct, `Widgets()` SELECT+Scan) + `mdl/linter/starlark.go` (`widgetToStarlark`) | Carry `MicroflowRef`/`NanoflowRef` through from the catalog and expose `microflow_ref`/`nanoflow_ref` on the Starlark widget struct (mirroring `entity_ref`). Doc: `.claude/skills/mendix/write-lint-rules.md` widget field table. Test `TestWidgets_ProjectsMicroflowNanoflowRef`. traceops #35 |
-| A `/** … */` doc comment between `alter entity … add attribute` clauses is a **parse error** (`no viable alternative at input '/**'`) | `alterEntityAction` accepted a doc comment only INSIDE an `attributeDefinition` (after the ADD ATTRIBUTE keyword), not between clauses. `--` line comments are NOT an equivalent workaround — they are discarded, whereas a `/** */` doc comment is persisted as the attribute's Mendix documentation | `mdl/grammar/domains/MDLDomainModel.g4` (`alterEntityAction`) + `mdl/visitor/visitor_entity.go` (`ExitAlterEntityAction` ADD branch) | Add `docComment?` before `ADD ATTRIBUTE`/`ADD COLUMN`; the visitor attaches it as the added attribute's documentation when the attributeDefinition has none. `make grammar` regenerates the parser (not committed). Test `TestAlterEntityAddAttributeDocComment`; repro `mdl-examples/bug-tests/traceops-27-doc-comment-between-clauses.mdl`. traceops #27 |
-| `combobox (Association: Mod.Ref, …)` drops the binding — `mxcli check` ✓ but MxBuild fails **CE0642** "Property 'Attribute' is required" | 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 | `mdl/executor/widget_engine.go` (`case "Association"`) + `mdl/executor/validate_widgets.go` (`validateComboBoxAssociation`) | 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 |
-| A bare MDL keyword used as a WIDGET name (`container body`, `dynamictext content`) is a parse error (`mismatched input 'body' expecting {IDENTIFIER, QUOTED_IDENTIFIER}`) | `widgetV3`'s name only accepted `IDENTIFIER \| QUOTED_IDENTIFIER`, not `keyword` — unlike `attributeName`/placeholder names | `mdl/grammar/domains/MDLPage.g4` (`widgetV3`) + `mdl/visitor/visitor_page_v3.go` (`buildWidgetV3` name extraction) | Add `keyword` to the widget-name alternatives; the visitor reads `wCtx.Keyword()` too. `make grammar` regenerates the parser. Test `TestKeywordWidgetName`; repro `mdl-examples/bug-tests/traceops-11-12-16-strings-names.mdl`. traceops #12 |
-| A `'…'` string literal spanning multiple lines fails to parse (`missing END at '…'`) — the newline terminated the token | `STRING_LITERAL` excluded `\r\n` (`~['\r\n\\]`) | `mdl/grammar/MDLLexer.g4` (`STRING_LITERAL`) | Drop `\r\n` from the exclusion (`~['\\]`); mxbuild accepts a multi-line String value (verified). A missing close-quote now spans lines — the standard multi-line-string trade-off. Test `TestMultiLineStringLiteral`. traceops #11 |
-| `alter entity … add <name>: <type>` (missing the `attribute` keyword) fails with an opaque `no viable alternative at input 'add<Name>'` | ALTER ENTITY requires the `attribute` keyword (SQL-shaped); the raw ANTLR error doesn't say so | `mdl/visitor/visitor.go` (`enhanceErrorMessage` / `addMissingAttributeRe`) | Source-aware hint: when the offending line is `add <word>:` and `<word>` isn't a real clause keyword (attribute/column/index/event/value/…), append the correct `add attribute <name>: <type>` form. Gated to the primary "no viable alternative" error. Test `TestAlterEntityMissingAttributeKeywordHint`. traceops #16 |
-| CE0066 "Entity access is out of date" | MemberAccess added to wrong entity | `sdk/mpr/writer_domainmodel.go` | MemberAccess must only be on the FROM entity (`ParentPointer`), not the TO entity — see CLAUDE.md association semantics |
-| `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` |
-| CE0463 "widget definition changed" | Object property structure doesn't match Type PropertyTypes | `sdk/widgets/templates/` | Re-extract template from Studio Pro; see `sdk/widgets/templates/README.md` |
-| Parser returns `nil` for a known BSON type | Unhandled `default` in a `parseXxx()` switch | `sdk/mpr/parser_microflow.go` or `parser_page.go` | Find the switch by grepping for `default: return nil`; add the missing case |
-| MDL check gives "unexpected token" on valid-looking syntax | Grammar missing rule or token | `mdl/grammar/MDLParser.g4` + `MDLLexer.g4` | Add rule/token, run `make grammar` |
-| CE7054 "parameters updated" / CE7067 "does not support body entity" after `send rest request` | `addSendRestRequestAction` emitted wrong BSON: all params as query params, BodyVariable set for JSON bodies | `mdl/executor/cmd_microflows_builder_calls.go` → `addSendRestRequestAction` | Look up operation via `fb.restServices`; route path/query params with `buildRestParameterMappings`; suppress BodyVariable for JSON/TEMPLATE/FILE via `shouldSetBodyVariable` |
-| `CREATE X` returns "already exists — use create or replace to overwrite" but OR REPLACE is not valid for that type | Error message in executor points to wrong keyword | `mdl/executor/cmd_<type>_*.go` — find the `NewAlreadyExistsMsg` call | Change hint from `or replace` to `or modify`; verify the AST stmt uses `CreateOrModify` not `CreateOrReplace` |
-| `mx check` CE0126 "Missing value for parameter X" on `call java action ... ($Param = empty)` for typed (non-entity, non-microflow) parameters | Builder emitted `BasicCodeActionParameterValue.Argument: ""` instead of the literal `"empty"` keyword | `mdl/executor/cmd_microflows_builder_calls.go` → `addCallJavaActionAction` | 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 |
-| `DESCRIBE microflow` puts shared activities inside an `if … then` block — they should appear after `end if;` | Nested guard split inside `traverseFlowUntilMerge` crosses the outer merge boundary | `mdl/executor/cmd_microflows_show_helpers.go` — guard path in `traverseFlowUntilMerge` (~line 854) | Add `if contID != mergeID` guard before the `isMerge` skip-through so the guard continuation never crosses the outer merge |
-| `DESCRIBE microflow` on the **modelsdk** engine renders a branching microflow as `if cond then end if;` — the entire then/when body is dropped (legacy engine renders it fully). Affects projects Studio Pro saved with the older single-case storage | The split's branch case is stored under the BSON storage name `NewCaseValue` (single child), but (1) the codec had no `CaseValue`→`NewCaseValue` alias so it was never decoded, and (2) the adapter read only the plural `CaseValuesItems()`, not the singular `CaseValue()` | `modelsdk/codec/decoder.go` (`fieldAliases`) + `mdl/backend/modelsdk/microflow.go` (`caseValueFromGen`/`mapGenCaseValue`) | Add `"CaseValue": "NewCaseValue"` to `fieldAliases` (mirrors `Type`↔`NewType`); read the singular `g.CaseValue()` first, then the plural list, mapping `EnumerationCase`/`InheritanceCase`. A round-trip MDL bug-test can't reproduce it (the write path emits the new format) — covered by codec + adapter unit tests |
-| `DESCRIBE microflow` on the **modelsdk** engine renders a rule-based split as `if true then …` instead of the real `Module.Rule_X(args)` condition (body renders, only the condition text is wrong) | `splitConditionFromGen` only handled `*ExpressionSplitCondition`; a `RuleSplitCondition` returned nil → renderer fell back to `true`. Even when handled, the rule name lives under the `RuleCall.Microflow` storage key, but gen decodes the property as `Rule` (and `ByNameRef` decode bypasses `fieldAliases`), so `RuleQualifiedName()` is empty | `mdl/backend/modelsdk/microflow.go` (`splitConditionFromGen`) | Reconstruct `*microflows.RuleSplitCondition` from the gen `RuleCall`; read the rule name from `rc.Raw().Lookup("Microflow")` when `RuleQualifiedName()` is empty (same raw-storage-key pattern the action readers use). The existing `formatSplitCondition` renders it |
-| `DESCRIBE microflow`/`nanoflow` on the **modelsdk** engine omits the `grant execute on microflow … to <roles>;` line that legacy emits | `microflowFromGen`/`nanoflowFromGen` never read the allowed module roles, so `Microflow.AllowedModuleRoles` was empty and the describer skipped the grant block | `mdl/backend/modelsdk/microflow.go` (`microflowFromGen`/`nanoflowFromGen`) | Populate `out.AllowedModuleRoles` from the gen `AllowedModuleRolesQualifiedNames()` (BY_NAME role refs, stored as qualified-name strings) |
-| `DESCRIBE microflow` on the **modelsdk** engine renders a loop `break;`/`continue;` as `-- Empty action` | `flowObjectFromGen` had no cases for `Microflows$BreakEvent` / `Microflows$ContinueEvent`, so they fell through to the ActionActivity default with a nil action | `mdl/backend/modelsdk/microflow.go` (`flowObjectFromGen`) | Add both object cases (renderer already maps them to `break;`/`continue;`) |
-| `DESCRIBE microflow` on the **modelsdk** engine renders `export to mapping …` / `import from mapping …` as `-- Empty action`; and single-object mapping results render `as list of Entity` instead of `as Entity` | `actionFromGen` lacked `ExportXmlAction`/`ImportXmlAction` cases; `restResultHandlingFromRaw` set `SingleObject` only from `Range.SingleObject`, ignoring an object var type (REST) and `ForceSingleOccurrence` (XML import) | `mdl/backend/modelsdk/microflow_read_actions.go` (`actionFromGen`, `restResultHandlingFromRaw`, `readMappingCall`) | Add both XML-action cases reading mapping/arg/output from raw `ResultHandling`/`OutputMethod`/`ImportMappingCall`; extract `readMappingCall`; apply the object-type rule (REST) and force fallback (XML import) — mirrors legacy `parseExportXmlAction`/`parseImportXmlAction`/`parseResultHandling` |
-| `DESCRIBE microflow` on the **modelsdk** engine drops a database retrieve's `sort by …` clause | `retrieveSourceFromGen` read Entity/XPath/Range but not the sort columns, which live in the `DatabaseRetrieveSource`'s `NewSortings` child | `mdl/backend/modelsdk/microflow_read_actions.go` (`retrieveSourceFromGen`, `sortItemsFromRaw`) | Generalize `sortItemsFromRaw` to accept the `NewSortings` wrapper key (it already handled the Sort list-op `Sortings` key); set `s.Sorting = sortItemsFromRaw(g.Raw())` |
-| A database retrieve's `sort by …` is **completely missing** from DESCRIBE after any modelsdk **write** (regression on switching to the modelsdk engine; "no more sort") — reproduces on a fresh `create microflow … retrieve … sort by …` round-trip | The WRITE counterpart of the row above: `retrieveSourceToGen` set an **empty** `genMf.NewSortItemList()` and never serialized `s.Sorting`, so nothing was stored for the read to render. The generated `SortItemList` type also stores items under `"Items"`, but Mendix stores retrieve sort columns under `"Sortings"` (like the Sort list-op), so the gen convenience type is the wrong tool | `mdl/backend/modelsdk/microflow_write.go` (`retrieveSourceToGen`) | Build the envelope manually, mirroring the `SortOperation` branch: `newElem("Microflows$SortingsList","")` + `addPartList(sl,"Sortings", sortItemToGen(each))` + `g.SetSortItemList(sl)`. Guard with a toGen→encode→decode→fromGen round-trip test asserting the sort items survive. Note "completely missing" ⇒ write dropped it (nothing stored); a *blank-attribute* sort line ⇒ a read/name-resolution gap instead. Issue #727 |
-| Consumed OData service **Configuration microflow** has no effect in Studio Pro ≥ 11.10 — the "Configuration source" dropdown stays on "Constants only" even though `describe odata client` shows the microflow | Mendix **renamed the BSON storage field** across versions (from the `Rest$ConsumedODataService` reflection metadata): `ConfigurationMicroflow` was introduced 10.12.0 and **DELETED 11.10.0**; `ConfigurationEntityMicroflow` was introduced 11.10.0. mxcli wrote the pre-11.10 key on all versions, so ≥ 11.10 Studio Pro ignored the unknown field. Both engines were affected (identical BSON). The codebase had flip-flopped this key (573→`ConfigurationEntityMicroflow`, then reverted) — the reflection `VersionInfos` Introduced/Deleted is the authority | `model.ODataConfigMicroflowBSONKey` (new, version-gated), wired into `mdl/backend/modelsdk/odata_write.go` (`consumedODataServiceToGen` via `Backend.configMicroflowKey()`) **and** `sdk/mpr/writer_odata.go` (`serializeConsumedODataService` via `w.reader.ProjectVersion()`) | Gate the write key on project major/minor (≥ 11.10 → `ConfigurationEntityMicroflow`). On read, coalesce **all** historical keys (`model.ODataConfigMicroflowBSONKeys()` in the legacy parser; `firstNonEmpty(ConfigurationEntity…, Configuration…, Headers…)` of the gen getters in `integration_read.go`) so a service authored by any version round-trips. When a storage name looks version-dependent, check `modelsdk/gen/*/version.go` `VersionInfos` before guessing. Issue #728 |
-| 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) | 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) | `mdl/executor/cmd_odata.go` (`mendixAttrTypeToEdm`, `lookupEntityMembers`, `astEntityDefToModel`) + both writers (`publishedMemberToGen`, `serializePublishedMember`) + both reads | 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 |
-| Published OData service: `mx check` reports **CE5022** "Published association X has changed multiplicity" for every exposed association — modelsdk engine only | 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 | `mdl/executor/cmd_odata.go` (`assocMembership.Type`, `astEntityDefToModel`) + both writers/reads | 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 |
-| `DESCRIBE microflow` on the **modelsdk** engine renders an inheritance split header as `split type $` (empty variable) and drops its `@caption` | `flowObjectFromGen` created a bare `InheritanceSplit` without reading `SplitVariableName`/`Caption`/`Documentation` off the gen element | `mdl/backend/modelsdk/microflow.go` (`flowObjectFromGen`) | Populate `VariableName`/`Caption`/`Documentation` from the gen `InheritanceSplit` accessors |
-| `mx check` **CE4899** "concurrent execution: error message or microflow required" after a microflow round-trip (`GetMicroflow` → `UpdateMicroflow`), even though the microflow allowed concurrent execution | `microflowFromGen` never read `AllowConcurrentExecution`/`MarkAsUsed` back (the write path set them), so the round-trip reset them to `false` → "disallow concurrent execution" with no error message configured | `mdl/backend/modelsdk/microflow.go` (`microflowFromGen`) | Read both flags back from the gen getters (`mf.AllowConcurrentExecution()`, `mf.MarkAsUsed()`) — keep the FromGen converter lossless. Guarded by a `toGen→encode→decode→fromGen` Go test, not MDL (create-or-modify rebuilds the microflow from MDL, so it can't reproduce a read-back bug). Issue #723 A1 |
-| Studio Pro renders **every activity/decision as a 1-px sliver** (caption wraps one letter per line) after a modelsdk round-trip; `mx check` reports **NO** error (it ignores box size, so the corruption is silent) | `flowObjectFromGen` carried each object's `Position` but not its `Size`, so the round-trip rewrote every node with size `0;0` | `mdl/backend/modelsdk/microflow.go` (`sizeFromGen`, `splitFlowObjects`) | Add `sizeFromGen` (mirrors `pointFromGen`) and apply it at the `splitFlowObjects` call site — covers nested loop bodies via recursion; add `GetSize`/`SetSize` to `BaseMicroflowObject`. Go round-trip test (not MDL, same reason as A1). Issue #723 A2 |
-| `mx check` **CE0117** "Error in expression" when creating a rule-based decision (`if Module.SomeRule(...)`) via MDL on the **modelsdk** engine; the decision's subtype is demoted Rule→Expression on every round-trip | modelsdk `*Backend` never implemented `IsRule` → fell back to the embedded `unimplemented` stub (which errors); the builder's `isRule, err := backend.IsRule(...); if err != nil || !isRule` guard treated the error as "not a rule" and emitted an invalid `ExpressionSplitCondition` | `mdl/backend/modelsdk/microflow.go` (`IsRule`) | Implement `IsRule` on `*Backend` (list `Microflows$Rule` units, match qualified name via `moduleNameFor`), mirroring the legacy reader; it shadows the generated stub. With the existing builder mock-test this guards the full chain modelsdk.IsRule→RuleSplitCondition. Issue #723 A4 |
-| `create enumeration … ("Value" = 'Caption')` fails with cryptic `mismatched input '=' expecting ')'`; user blames the *quotes* | Not a quoting bug — enum value names quote fine (`enumValueName` accepts `QUOTED_IDENTIFIER`). The `=` is invalid: MDL enum values are `Value 'Caption'` (or `Value caption 'Caption'`), no equals sign | `mdl/visitor/visitor.go` (`enhanceErrorMessage`/`looksLikeEnumEquals`) | Add an error hint keyed on `mismatched input '=' expecting ')'` (specific to enum value lists — attribute-default `=` gives a different message) pointing at the `=`. Clarify in `check-syntax.md` that captions use `Name 'Caption'`, never `=` |
-| A genuine parse error on a short lowercase MDL keyword/identifier (`mismatched input 'on'`, `'in'`, `'as'`, `'to'`, `'by'`, …) is misdiagnosed with the "unescaped apostrophe" hint, sending the user to look for a quote that isn't there | `looksLikeUnescapedApostrophe` matched **any** 1–4 char lowercase token as a contraction leftover, so real short keywords tripped it | `mdl/visitor/visitor.go` (`looksLikeUnescapedApostrophe`, `contractionSuffixes`) | Match only the fixed contraction-suffix set (`s`/`t`/`d`/`m`/`re`/`ve`/`ll` — the leftovers from it's/don't/he'd/I'm/you're/we've/you'll), not arbitrary short lowercase words. Real apostrophe errors still hint; `on`/`in`/`as`/`to`/`by` no longer do. Findings #4 |
-| Docs/skills document MDL that doesn't parse (drift): `ALTER ENTITY X ADD (a, b)` / `DROP (a)` / `MODIFY (a)` / `RENAME a TO b`, `ALTER ENUMERATION … REMOVE VALUE`, `CREATE CONSTANT … TYPE X;` (no default), `DELETE_BEHAVIOR <invalid>` | Docs were written against a SQL-DDL mental model, never `mxcli check`-validated. Correct forms: `ADD ATTRIBUTE a: type` (one action/statement), `DROP ATTRIBUTE a`, `MODIFY ATTRIBUTE a: type`, `RENAME ATTRIBUTE a TO b`, `DROP INDEX <name>`; `DROP VALUE`; enum `ADD VALUE X CAPTION 'y'` (CAPTION keyword required for ALTER, unlike CREATE); a constant `DEFAULT` is mandatory; delete-behavior ∈ {DELETE_AND_REFERENCES, DELETE_BUT_KEEP_REFERENCES, DELETE_IF_NO_REFERENCES, CASCADE, PREVENT} | `scripts/check-skill-mdl.sh` + `make check-skill-mdl` (CI) | The guard extracts DDL statements from `.claude/skills/mendix/` **and** `docs-site/src/` and runs `mxcli check`; keeps this class of drift from recurring. Run it after editing any MDL example |
-| `DESCRIBE microflow` on the **modelsdk** engine renders `download file $X …;` as `-- Empty action` | `actionFromGen` lacked a `DownloadFileAction` case | `mdl/backend/modelsdk/microflow_read_actions.go` (`actionFromGen`) | Add the case reading `FileDocumentVariableName()`/`ShowFileInBrowser()`, defaulting an empty `ErrorHandlingType` to Rollback. Note: the storage key is `ShowFileInBrowser` (legacy's `parseDownloadFileAction` reads the wrong `ShowInBrowser` key — a latent legacy bug; the gen reads it correctly) |
-| `DESCRIBE microflow` on the **modelsdk** engine renders a legacy SOAP `call web service …` as `-- Empty action` | `actionFromGen` lacked a `WebServiceCallAction` case | `mdl/backend/modelsdk/microflow_read_actions.go` (`actionFromGen`, `webServiceActionRequiresRawBSON`) | Add the case: read the structured fields (ImportedService / OperationName / NewResultHandling / RequestHandling) and, when the action carries any field the structured form can't represent, set `RawBSON = a.Raw()` so the renderer emits `call web service raw '<base64>'`. Mirror legacy's supported-key set exactly; `canonicalRawBSON` makes both engines' base64 byte-identical |
-| `DESCRIBE microflow` on the **modelsdk** engine emits a REST `body mapping X` line with no `from $var`, which fails to re-parse (`mismatched input … expecting FROM`) — breaks the DESCRIBE roundtrip | `restRequestHandlingFromRaw` read the export-mapping source variable from the wrong key `ParameterVariable`; the real storage key is `MappingVariableName` (same key ExportXmlAction uses), so it came back empty and the renderer dropped the grammar-mandatory `from $var` | `mdl/backend/modelsdk/microflow_read_actions.go` (`restRequestHandlingFromRaw`) | Read `ParameterVariable` from `MappingVariableName` (fallback to `ParameterVariable`). Note this makes modelsdk *more* faithful than legacy, whose `parseRequestHandling` drops the REST request body mapping entirely ("would be parsed here if needed") |
-| MDL widget property `mxcli check`s clean but Studio Pro renders the default (e.g. `dataview ... (FormOrientation: Vertical)` always Horizontal) | 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 | `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildXxxV3`) + `sdk/mpr/writer_widgets_*.go` (`serializeXxx`) + `sdk/pages/pages_widgets_*.go` | 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 |
-| `ALTER <DOC TYPE> ...` parse error "no viable alternative at input 'ALTER<TYPE>'" but `CREATE <DOC TYPE> ...` works | The grammar lists ALTER variants explicitly per document type; a new doc type was added to `createStatement` but not to `alterStatement` | `mdl/grammar/MDLParser.g4` `alterStatement` block + dedicated visitor + new `Alter*Stmt` AST type + `register_stubs.go` | Add ALTER rule (mirror the closest sibling — `ALTER ODATA CLIENT` for SET-only, `ALTER PUBLISHED REST SERVICE` for SET+ADD/DROP); regenerate grammar; add `Alter*Stmt` with `Changes map[string]string`; route via `exitAlterStatement` dispatcher; register handler. Add the new AST type to `registry_test.go`'s `allKnownStatements()` |
-| Pluggable widget datasource property (`optionsSourceAssociationDataSource: Module.Entity`) passes `check` + `exec` but `mx check` reports CE0642 "Property 'Entity' is required" | 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) | `mdl/executor/validate_widgets.go` (`datasourceTypedKeys`) — and author via the `datasource:` clause | `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) |
-| 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 | `ValidateEntity` early-returned for NPEs; reserved-word check was not wired into the executor | `mdl/executor/cmd_enumerations.go` (`ValidateEntity`) and `mdl/executor/cmd_entities.go` (`execCreateEntity`) | 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 |
-| `SHOW ACCESS ON PAGE` / Page section of `SHOW SECURITY MATRIX` reports "no roles" for a restricted page on the **modelsdk** engine (legacy is correct) — under-reports page access, a security-audit hazard | `pageFromGen` never read the page's allowed module roles into `Page.AllowedRoles`, so it defaulted to empty. (The gen `Page` decode is correct — it has the storage-name override `allowedRoles`↔`AllowedModuleRoles`.) The microflow/nanoflow equivalent was fixed separately | `mdl/backend/modelsdk/page.go` (`pageFromGen`) | Populate `out.AllowedRoles` from the gen `AllowedRolesQualifiedNames()` (mirrors `microflowFromGen`). Fixes both `SHOW ACCESS ON PAGE` and the matrix Page section. Issue #722 |
-| `mxcli report` (and `lint`) hangs for many minutes on a large project — appears to deadlock after "Catalog ready", 130-byte banner-only output, process pinned at ~140% CPU (not blocked → not a lock deadlock) | O(N²) BSON re-decode: six lint rules loop `for mf := range ctx.Microflows()` and call `reader.GetMicroflow(mf.ID)` per microflow, but the modelsdk backend's `GetMicroflow` re-lists and re-decodes EVERY microflow unit on each call. N calls × N decodes → millions of full BSON parses. Diagnose with `kill -QUIT <pid>` (GOTRACEBACK=all) — the running-goroutine stack names the stuck rule + `ListUnitsWithContainer` | `mdl/linter/context.go` (`FullMicroflow`, `LintReader`) + the six rules (`validation_feedback`, `conv_loop_commit`, `conv_split_caption`, `conv_error_handling`×2, `mpr008_overlapping_activities`) | Add `LintContext.FullMicroflow(id)` — loads ALL microflows once via `ListMicroflows()` and serves lookups from a per-run cache (safe: lint is read-only). Swap every `reader.GetMicroflow(mf.ID)` in a loop to `ctx.FullMicroflow(mf.ID)`. Turns O(N²) into O(N); report went from >40min hang to ~5s on 3259 microflows. Issue #720 |
-| `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 | 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) | `mdl/executor/cmd_microflows_show.go` (`duplicateOutputVariableWarnings`) | 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 |
-| Microflow `set $x = <expr>` passes `mxcli check` but `mx check` reports a generic CE0117: (#17) `/` used as division (`$Dec / 2`), (#18) a decimal literal loses its fraction (`2.0` → `2`, breaks Decimal typing), or (#19) a small decimal becomes scientific notation (`0.000001` → `1e-06`, which Mendix rejects) | (#18/#19) the value is re-serialized from the AST when `shouldPreserveExpressionSource` returns false and the AST serializer is lossy for decimals (`%v` on a float64 drops `.0` and uses sci-notation). (#17) **MDL division is `div`, not `/`** — `/` is the member-access separator, so `/`-as-division is a user error that mxcli silently wrote instead of flagging. **Do NOT preserve source on `/`** — that source-freezes every legit association path (`$Order/Assoc/Name` → regressed `TestAssociationNavParsing`) | `mdl/visitor/visitor_microflow_statements.go` (`shouldPreserveExpressionSource`); `mdl/executor/validate_microflow.go` (`checkDivisionSlash`/`exprHasSlashDivision`, MDL045) | (#18/#19) preserve raw source only when the expression contains a **decimal literal** (`.` adjacent to a digit) — same philosophy as the XPath-where path. (#17) add **MDL045**: walk the expression tree for a `BinaryExpr` with operator `/` (`$Dec / 2`, `(...) / $x`) and reject with "use `div`". The variable/variable form `$Dec / $Dec2` parses as a member-access path (the `$` on the RHS is stripped), so the visitor narrowly preserves source when a `/` is immediately followed by `$` (a real association path never has `$` after `/`) and MDL045 flags it by scanning the preserved source for a `/ $` **outside string literals** (`exprHasSlashDollarDivision` / `sourceHasSlashDollarDivision`). **Round-2 gap (ledger #17 re-test): the `$a / $b` division must be caught even when EMBEDDED in a larger expression** — `$a / $b + 1`, `round($a / $b)`, `$a / $b * 100` — where it degrades to a member-path `AttributePathExpr` nested under a `BinaryExpr`/`FunctionCallExpr`, so the structural `/`-BinaryExpr walk (which only sees literal division) misses it. The earlier `exprIsSlashDollarDivision` matched only when the SourceExpr **directly** wrapped an AttributePathExpr, so embedded division slipped through silently. Fix: walk the tree for any `SourceExpr` and scan its raw source for `/ $` with a string-literal-aware scanner (skips `'path/$x'`). [verification round: the `$a / $b` form must be caught by bare `check`, not deferred to `--references`.] **Lesson: `/` is overloaded (path separator vs the division a user *wanted*) — a blanket source-preserve on `/` corrupts the common case to rescue the rare misuse; reject the misuse explicitly instead. And an operator misuse that "degrades to a path" can hide anywhere in an expression tree, not just at its root — detect it from source, walking every sub-expression.** Tests: `TestShouldPreserveExpressionSource_Decimals`, `TestValidateMicroflow_SlashDivision` (incl. embedded cases + string-literal guard); repros `mdl-examples/bug-tests/ledger-17-19-expression-serialization.mdl` (pass) + `ledger-17-slash-division.fail.mdl` (MDL045, incl. embedded). Ledger findings #17–19 (round 2) |
-| `DESCRIBE` of an entity/module emits `grant ... (read (Module.Entity.Attr))` that fails to re-parse with `mismatched input '.'` — breaks the DESCRIBE roundtrip | Member emitter used the fully-qualified BY_NAME reference; grant grammar accepts a bare `IDENTIFIER` only | `mdl/executor/cmd_entities_access.go` → `resolveEntityMemberAccess` | Strip `memberName` to the last `.`-segment before appending (bare names have no dot, so it's a no-op for them). Issue #633 |
-| `exec` of a pluggable widget from a bundled multi-widget `.mpk` fails "no definition for widget … (run 'mxcli widget init')" even after init (e.g. only AreaChart of Charts.mpk registers) | `ParseMPK`/`getWidgetIDFromMPK` read only `WidgetFiles[0]`; a bundled `.mpk` (Charts) holds many widgets so only the first is registered/augmented | `sdk/widgets/mpk/mpk.go` (`ParseMPKAll`/`ParseMPKWidget`, `FindMPK`) + def-gen loops in `mdl/executor/widget_defs.go` + `mdl/catalog/builder_widget_definitions.go` + `cmd/mxcli/cmd_widget.go` | Parse every widgetFile (`ParseMPKAll`); register all ids in `FindMPK`; augment the specific id (`ParseMPKWidget`); bump `WidgetDefGeneratorVersion` so existing projects regenerate. Issue #679. (Per-series datasource + chart CE0463 are separate, still open.) |
-| `buttonstyle: <value>` passes `mxcli check` but the button renders btn-default in Studio Pro (silent at build) — typically a mis-cased value (`Primary`) or one Mendix doesn't have (`secondary`, `link`) | Visitor stored the style verbatim and the executor cast it straight to `pages.ButtonStyle`; only an empty value got a default, so any unknown string was written as-is and MxBuild degraded it | `sdk/pages/pages_widgets_action.go` (`CanonicalButtonStyle`) + `mdl/executor/cmd_pages_builder_v3_widgets.go` (button builder) + `mdl/executor/validate_widgets.go` (`validateStaticWidget`) | Normalize case-insensitively against the metamodel `PagesButtonStyle` set (Default/Primary/Success/Warning/Danger/Info/Inverse); reject unknown values as MDL-WIDGET02 at check time and in the executor. Issue #672 |
-| `style:` on a `dynamictext` crashes MxBuild with a NullReferenceException (fails at build, not check) | The generic appearance applier wrote an inline Style into the DynamicText's `Forms$Appearance`; Mendix's metamodel can't handle it | `mdl/executor/cmd_pages_builder_v3.go` (`applyWidgetAppearance`) + `mdl/executor/validate_widgets.go` (`validateStaticWidget`) | 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 |
-| Quoted where-clause `where '[Title=''abc'']'` (with `''` escapes) fails `mx check` CE0161 "Error(s) in XPath constraint." on every retrieve/datasource — but inline `where [Title='abc']` is clean. `mxcli exec` reports no error | The quoted string un-quoted correctly to `[Title='abc']`, but the visitor preserved the **raw** token (outer quotes + doubled `''`) as the constraint source; the builder then bracket-wrapped it → `['[Title=''abc'']']`. Affected the microflow retrieve and page datasource `expression`-form paths (the `grant … where '…'` path was fine — it uses `unquoteString` directly) | `mdl/visitor/visitor_microflow_statements.go` (`buildRetrieveWhereExpression`) + `mdl/visitor/visitor_page_v3.go` (`bracketedXPathFromExpr`, datasource WHERE) | When the whole WHERE clause is a bare string `LiteralExpr`, use its **unquoted** `.Value` as the constraint source (bracket-wrap only if it isn't already `[...]`); don't re-serialize via `xpathExprToString`/preserve-raw-source (which re-doubles the `''`). Verify both forms store identically with `mx check` = 0 errors. Issue #642 |
-| `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" | `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 | `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildDynamicTextV3`) + `mdl/executor/validate_widgets.go` (`validateStaticWidget`/`validateDynamicTextPlaceholders`) | 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 |
-| 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" | The whole-script scriptContext used by reference validation tolerates forward refs (the page exists *somewhere*); the executor resolves page refs in statement order | `mdl/executor/validate.go` (`validateForwardPageRefs`) | 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 |
-| 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'` | `CreateWorkflowStmt` had **no** case in `validateWithContext` and no `ValidateWorkflow` at all — workflows received zero semantic validation | `mdl/executor/validate_workflow.go` (`ValidateWorkflow`, wired from `cmd/mxcli/cmd_check.go`) | 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` |
-| 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 …" | 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 | `mdl/executor/validate_page_button_context.go` (`ValidatePageButtonContext`, wired from `cmd/mxcli/cmd_check.go`) | **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 |
-| `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 | Action emitters prefixed `call_`; the page-action grammar (`actionExprV3`) accepts `MICROFLOW`/`NANOFLOW` only | `mdl/executor/cmd_pages_describe_output.go` (`extractButtonAction`) + `cmd_pages_describe_pluggable.go` (`extractCustomWidgetPropertyAction`) | Emit `microflow `/`nanoflow ` without the `call_` prefix. Issue #634 |
-| `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 | Body emitted only when `readJavaActionUserCode` returns non-empty, but the grammar requires `AS DOLLAR_STRING` (body is mandatory) | `mdl/executor/cmd_javaactions.go` → `describeJavaAction` | Always emit the `as $$ … $$;` block; when source can't be read, write a placeholder comment body. Issue #637 |
-| Studio Pro crashes on export/upgrade/Save-As with `System.InvalidOperationException: Null value found in primitive property 'ImageDataStorage' of object of type 'Mendix.Modeler.CodeActions.MicroflowActionInfo'` after a Java action was created via MDL `exposed as … in …` (project opens fine; only re-serialization crashes) | The `MicroflowActionInfo` sub-document was written in the legacy shape: `$Type` = `JavaActions$MicroflowActionInfo`, an obsolete `Icon` key, and the four icon/image bitmaps null or absent. Mendix maps `ImageData`→ the mandatory binary `ImageDataStorage`; a null/absent value crashes `UnitWriter`. **Both engines** were wrong: legacy `sdk/mpr` emitted `ImageData: null`; the default modelsdk engine used `gen/javaactions.MicroflowActionInfo` (also legacy `$Type`, no binary fields) | struct `mdl/types/javaaction_types.go` + legacy `sdk/mpr/writer_javaactions.go` (`microflowActionInfoBSON`) + `sdk/mpr/parser_javaactions.go` (`parseMicroflowActionInfo`, shared with `parser_misc.go` JS actions) + modelsdk `mdl/backend/modelsdk/java_write.go` (`patchMicroflowActionInfo`) + reads `mdl/backend/modelsdk/javascript_read.go` | Replace `Icon string`/`ImageData string` in the struct with four `[]byte` (`IconData`/`IconDataDark`/`ImageData`/`ImageDataDark`). Emit `$Type` = `CodeActions$MicroflowActionInfo` with all four as **empty-non-null** binaries (`primitive.Binary{Subtype:0, Data:[]byte{}}`), no `Icon`. Parser reads the four binaries and **tolerates** the legacy null/`Icon` shape so corrupted units load and self-repair on rewrite. The modelsdk gen models these bitmaps as `Primitive[string]` (serialises to BSON string, can't emit `binary(0)`), so leave the gen MAI null and post-patch the top-level `MicroflowActionInfo` field via `codec.PatchBSONField` instead of editing generated code. Verify by decoding the written `.mxunit` under both engines (`grep -rlF 'MicroflowActionInfo' mprcontents/`). Issue #656 |
-| `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 | #619 added `mdlIdent` (quote-if-reserved) for general widget names but missed datagrid column names | `mdl/executor/cmd_pages_describe_output.go` (`column %s` header, ~line 837) | Wrap the column name: `fmt.Sprintf("column %s", mdlIdent(colName))`. Issue #638 |
-| `CREATE JAVA ACTION`/`CREATE JAVASCRIPT ACTION` with an `Enumeration(Mod.Enum)`/`ENUM Mod.Enum` parameter or return type passes check+exec but `mxbuild`/Studio Pro fails: `Property 'Entity' of Java action parameter '…': The selected entity 'Mod.Enum' no longer exists` | The param/return converter mapped `ast.TypeEnumeration` to an `EntityType` (entity ref), because the parser records both a bare `Module.Name` *and* the explicit `ENUM`/`Enumeration(...)` syntax as `TypeEnumeration` with no distinguishing flag, and `EnumerationType` was never emitted/serialized | AST `mdl/ast/ast_datatype.go` (`ExplicitEnum`) + visitor `mdl/visitor/visitor_helpers.go` (`buildDataType`) + converter `mdl/executor/cmd_javaactions.go` (`astDataTypeToJavaActionParamType`/`…ReturnType`) + writers `sdk/mpr/writer_javaactions.go` (`serializeInnerType`/`serializeReturnType`) and `mdl/backend/modelsdk/java_write.go` (`codeActionInnerTypeToGen`/`codeActionReturnTypeToGen`) + reads `parser_javaactions.go` (already) / `mdl/backend/modelsdk/java_read.go` | Add `ExplicitEnum bool` to `ast.DataType`, set it in the `ENUM`/`Enumeration(...)` branch of `buildDataType` (a bare `Module.Name` stays ambiguous → entity). When `ExplicitEnum`, the converter emits `javaactions.EnumerationType{Enumeration: qn}`; both writers serialize `CodeActions$EnumerationType` (param wrapped in `BasicParameterType`) with the `Enumeration` by-name ref; modelsdk uses `genCa.NewEnumerationType().SetEnumerationQualifiedName(...)`. The legacy parser already read it; add the gen `*genCa.EnumerationType` case to the modelsdk read converters so DESCRIBE round-trips. Validate by decoding the `.mxunit` and `mx check` (build passes only after the fix). Issue #680 |
-| `DESCRIBE` of a page/snippet emits widget-action microflow args as `Param = $value` that fails with `mismatched input '=' expecting ':'` — breaks the DESCRIBE roundtrip | Arg emitters used `=`, but `microflowArgV3` accepts `IDENTIFIER COLON expr` (`Param: $value`) or `VARIABLE EQUALS expr` (`$Param = …`) — not `IDENTIFIER EQUALS` | `mdl/executor/cmd_pages_describe_output.go` → `extractMicroflowParameters` / `extractNanoflowParameters` | Emit the canonical colon form: `paramName+": "+value`. Issue #640 |
-| CE3637 "A data view cannot listen to the selection of Gallery 'X', because it is not available here." on a master-detail page generated from MDL | Gallery's `itemSelectionMode` pluggable-widget property was hardcoded to `clear` in the def.json; Mendix requires `toggle` for selection-listeners (DataViews bound via `DataSource: selection X`) to see the gallery's selection | `sdk/widgets/definitions/gallery.def.json` | Change the `itemSelectionMode` mapping from `value: "clear"` to `source: "ItemSelectionMode", default: "clear"` so MDL can write `gallery X (Selection: Single, ItemSelectionMode: toggle)`. The V3 engine's generic mapping path (`widget_engine.go` `resolveMapping` default case → `GetStringProp`) reads the value automatically — no grammar changes needed. Also add `ForceFullObjects: false` to `Forms$ListenTargetSource` serializer in `sdk/mpr/writer_widgets_display.go` |
-| DESCRIBE drops `DataSource: selection X` for a DataView bound to a gallery/listview selection (master-detail pages) | `extractDataViewDataSource` only handled `Forms$MicroflowSource` / `Forms$NanoflowSource` / `Forms$DataViewSource` / `Forms$DatabaseSource`; `Forms$ListenTargetSource` fell through to `return nil` | `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) | Add `case "Forms$ListenTargetSource":` returning `{Type: "selection", Reference: ds["ListenTarget"]}`; add `case "selection":` in the DataView output switch emitting `DataSource: selection <ref>` |
-| CE0463 "widget definition changed" on every pluggable widget that contains a caption/template parameter (gallery, datagrid2 captions, dynamictext with ContentParams) on Mendix 11.9 — cascades into CE3637 on master-detail pages | `serializeClientTemplateParameter` emitted `Forms$FormattingInfo` with a `TimeFormat: "HoursMinutes"` field, but the FormattingInfo reflection schema only declares CustomDateFormat / DateFormat / DecimalPrecision / EnumFormat / GroupDigits — the extra field made Studio Pro mark the embedded WidgetType as drifted | `sdk/mpr/writer_widgets.go` `serializeClientTemplateParameter` + `mdl/backend/mpr/widget_builder.go` (mirror copy of the same FormattingInfo block) | Drop the `TimeFormat` entry from both writers. Verify by diffing your BSON against a Studio Pro-saved page's FormattingInfo block — if you see keys outside the reflection schema, that's the trigger |
-| Pluggable widget `Selection` BSON value is lowercase (`single` / `multi` / `none`) but Studio Pro stores PascalCase — contributes to CE0463 drift on stricter widgets and looks wrong in diffs | MDL passes the user's typed value verbatim to `SetSelection`; the builder didn't normalise | `mdl/backend/mpr/widget_builder.go` `SetSelection` | Canonicalise via `canonicalSelectionValue` helper (lowercase-keyed switch → `Single` / `Multi` / `None`); unknown values pass through |
-| 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 | Engine has no per-property visibility metadata; the hide rules live in the widget's compiled `editorConfig.js` (`hidePropertyIn`/`hidePropertiesIn`), not `widget.xml` | `mdl/executor/widget_defs.go` `widgetVisibilityRules` table + `mdl/backend/mpr/widget_builder.go` `ApplyPropertyVisibility` | 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 |
-| CE0463 on a `datagrid` whose column uses `ColumnWidth: manual` + `Size: N` — Studio Pro resets the column `size` to `1` | 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")`) | `mdl/executor/widget_defs.go` `itemPropertyAliases` | 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 |
-| CE0463 on an MDL-created **Combobox** (or other platform widget) at `mxcli docker build/check` time — but the SAME widget passes `mx check` on a project whose installed `.mpk` matches mxcli's embedded template (Mendix 11.6 / combobox 2.5.0). NOT the old incomplete-template bug (#112, fixed — a matching-version combobox is clean) | Widget-VERSION mismatch: mxcli emits the embedded 2.5.0-shaped PropertyTypes, but the project has a NEWER combobox (e.g. 2.8.1) that reorders/regroups properties. `augmentFromMPK` patches presence + enum values but can't restructure the baseline; `GenerateFromMPK` is less faithful still (fails even on a matching version). The designed remediation is `mx update-widgets` (docker build/check runs it before `mx check`) | `cmd/mxcli/docker/check.go` + `build.go` (`updateWidgetsPathArg`) — the update-widgets *invocation*, not the widget emission | The real trap was that `mx update-widgets <bare-app.mpr>` **crashed** (`AddProjectDirAsAllowedPath` → `Path.GetDirectoryName("app.mpr")` = "" → `System.ArgumentNullException`) and some mx builds exit 0 after printing it, so the migration silently no-op'd and CE0463 survived. Pass an **absolute** path to update-widgets (always has a directory component). `mx check` is unaffected. Diagnosis: run the bundled `mx update-widgets <bare.mpr>` yourself — if it throws ArgumentNullException on AddProjectDirAsAllowedPath, the path lacks a dir. Faithful multi-version widget emission is the larger fix (#529). Issue #112; repro `mdl-examples/bug-tests/112-combobox-enum-ce0463-widget-version.mdl` |
-| **CE0463 "widget definition changed" at an `Image` widget** on Mendix 11.7+ (`mx check` without `update-widgets`) — a plain mxcli-authored Image, no custom config. `update-widgets` clears it (and on v2 destroys `mprcontents/`, so it's a data-loss trap) | NOT a version stamp, Type `$ID`s, property order, or missing properties (all ruled out empirically). The embedded `image.json` carried a **spurious default value**: a `WidgetValue.Image` pointing at `Atlas_Core.Content.Mendix` (Atlas's Mendix logo), captured when the template was extracted from a project that had it set. The installed 11.12 Image widget expects that field empty, so MxBuild flags the definition as changed | `modelsdk/widgets/templates/mendix-11.6/image.json` + `sdk/widgets/templates/mendix-11.6/image.json` (line ~63) | Clear the stale default: `"Image": "Atlas_Core.Content.Mendix"` → `"Image": ""` in both engine templates. **Diagnosis method for this whole CE0463 class**: dump the widget BSON, `mx update-widgets` on a COPY, dump again, diff the `CustomWidgets$CustomWidget` subtree **order-independently** (canonicalise key order + mask `$ID`/`TypePointer` blobs). Reordering and generic instance chrome (`LabelTemplate`, `Appearance.DesignProperties`) are cosmetic — a *passing* widget gets reordered/those-added too; the real cause is whatever value/structure survives that normalisation. Other hand-extracted templates likely hide similar stale defaults (audit with the same diff). Repro `mdl-examples/bug-tests/image-ce0463-stale-default.mdl`. DataGrid2 custom-content CE0463 (#600) is a *separate*, more complex delta — same method, own fix |
-| `mxcli docker check`/`build` (or a bare `mx update-widgets`) **silently deletes `mprcontents/`** and rewrites an MPRv2 project into single-file v1 — `check` reports **0 errors** and looks successful, but the git working tree diverges from tracked files, a running `mxcli run --local` loop breaks (it watches `mprcontents/`), and Studio Pro may crash on open (`LibGit2RepositoryProvider.WriteBaseFile`). Triggered by following the CE0463 remediation on a `mxcli new` (always v2) project | The pre-check `mx update-widgets` step (run to suppress false CE0463) **performs the conversion**: it inlines every unit into the `.mpr` (`Unit.Contents` column) and deletes `mprcontents/`. The `check` itself is read-only; `update-widgets` is the mutator. docker check/build invoked it with no storage-format protection | `cmd/mxcli/docker/update_widgets.go` (`runUpdateWidgets` / `snapshotStorageFormat`) — call sites in `check.go` and `build.go` | Snapshot `.mpr` + `mprcontents/` to a temp dir before `update-widgets`, `defer restore()` after the check (restore removes the post-conversion single-file `.mpr` residue and puts the v2 tree back); MPRv1 projects need no protection. The check still runs against the widget-normalized model, so CE0463 stays suppressed — only the on-disk format is preserved. **Never tell an agent to run bare `mx update-widgets` on a v2 project** — the synced skills (`create-page.md`, `custom-widgets.md`, `migrate-design-prototype.md`, `download-marketplace-content.md`) + dev `debug-bson.md` route to `mxcli docker check`/`build` (v2-safe) instead. **Fix the operation, not the call site**: PR #764 wrapped the invocation inside `Check` only, and `Build` had a second bare copy — so `docker build`/`run`/`reload` kept converting projects for another 40 issues, until #808. The snapshot now lives in `runUpdateWidgets`, which is the only place that may exec `update-widgets`; grep for `"update-widgets"` should return exactly one hit. When a mutating external step is guarded, put the guard in a function that also *performs* the step, so a new caller cannot get it wrong. Issues #763 / PR #764, #808 |
-| Nightly `mx check` reports `CE0117 "Error(s) in expression." at Log message activity 'Log message (warning)'` on Mendix 10.24.19+ but not 10.24.16 or 11.x | Mendix 10.24.19 tightened expression validation: `toString(<string>)` is now a type error (toString expects a non-string input). An example called `toString($OrderNumber)` where `$OrderNumber` was already a string parameter | The offending `log warning ... with ({1} = toString($stringVar))` — find via `~/.mxcli/mxbuild/{ver}/modeler/mx check`, then bisect with `drop microflow ...` until CE0117 disappears | Remove the redundant `toString()` wrapper around already-string values. Only wrap non-string values (integers, decimals, dates, enums) in `toString()`. The Mendix 11.x parser is more lenient and lets this slide, but 10.24.19+ rejects it |
-| A page-level property can't be set — `ALTER PAGE X { SET PopupWidth = 800; }` (or any page-level prop other than Title/Url) fails with `unsupported page-level property: …` | The page-level SET handler only special-cased a couple of properties; everything else fell through to the default error | `mdl/backend/pagemutator/mutator.go` → `applyPageLevelSetMut` (shared by both engines) | Add a `case` writing the field at the top level of the Forms$Page doc via `dSetOrAppend` with the on-disk BSON type (int64 for PopupWidth/PopupHeight, bool for PopupResizable — verify against a Studio Pro page with `mxcli bson dump --format bson`). Page-level prop names are **case-sensitive**. For DESCRIBE roundtrip, emit the values back in the CREATE PAGE header. CREATE-time support: add a generic `IDENTIFIER COLON propertyValueV3` to `pageHeaderPropertyV3` (regen grammar), recognize the keys in `parsePageHeaderV3` (`applyGenericPageHeaderProp`, error on unknown), carry `*int`/`*bool` on `CreatePageStmtV3`, default to 600/600/false in `buildPageV3`, and have both writers honour `page.Popup*` (legacy `sdk/mpr/writer_pages.go` int64; codec `mdl/backend/modelsdk/page_write.go` int32 via gen — tolerated by mx check). The MCP backend has its **own** `mcpPageMutator` (pg content tree, not raw BSON) — page-level SET there reaches `SetWidgetProperty("")`; map it or reject honestly (it rejects, pending a `pg_read_page` probe of the pop-up keys). Issue #661 |
-| `PopupWidth: 0` / `PopupHeight: 0` rejected ("must be a positive number") on CREATE or ALTER PAGE; user can't make an auto-size pop-up | 0 is actually Studio Pro's **default** for pop-up dimensions (auto-size) — verified live on 11.12: a pg-created PopupLayout page stores 0/0 and `mx check` = 0 errors. Two validators rejected ≤0, and both writers coerced ≤0→600, so even an allowed 0 became 600 | `mdl/visitor/visitor_page_v3.go` (`popupDimensionValue`) + `mdl/backend/pagemutator/mutator.go` (`coercePopupDimension`) + `mdl/executor/cmd_pages_builder_v3.go` (builder default) + `sdk/mpr/writer_pages.go` & `mdl/backend/modelsdk/page_write.go` (`popupDimension`) + `mdl/executor/cmd_pages_describe.go` | Relax both validators to reject only **negative**; default the builder to **0** (not 600, matching Studio Pro); drop the `≤0→600` coercion in both writers (clamp only negatives to 0); have DESCRIBE suppress only the real default 0 (emit an explicit 600). No `*int` needed — 0 is a valid stored value. Bug-test `mdl-examples/bug-tests/713-popup-zero-dimensions.mdl`. Issue #713 |
-| `CREATE EXTERNAL ENTITIES FROM Module.Service` imports external entities as plain **PERSISTED** entities and NPEs **without the "from Service" link** (regression on the default modelsdk engine; legacy `--engine legacy` was correct) | The modelsdk write adapters dropped all external-entity serialization: `entityToGen` only handled `DomainModels$OqlViewEntitySource`, `attributeToGen` always emitted `StoredValue`, and `assocToGen` forced `Source` null. So `e.Source = "Rest$ODataRemoteEntitySource"` (+ RemoteServiceName/EntitySet/KeyParts) was ignored and the entity fell to the plain NoGeneralization path | `mdl/backend/modelsdk/domainmodel_write.go` (`entityToGen`, `attributeToGen`, `assocToGen`) — the executor (`applyExternalEntityFields` in `mdl/executor/cmd_contract.go`) already stamps the right `domainmodel` fields; only the write adapter was lossy. The legacy serializer `sdk/mpr/writer_domainmodel.go` is the parity reference | Port the legacy logic into the codec adapters using the gen `Rest$OData*` types (all present in `modelsdk/gen/rest`): `externalEntitySourceToGen` builds `Rest$ODataRemoteEntitySource`/`…EntityTypeSource`/`…PrimitiveCollectionEntitySource` (+ `ODataKey`/`ODataKeyPart`, with fresh IDs since `assignEntityIDs` only stamps the top source); `attributeToGen` takes an `isExternal` flag and emits `Rest$ODataMappedValue` / `…MappedPrimitiveCollectionValue`; `externalAssociationSourceToGen` emits `Rest$ODataRemoteAssociationSource` / `…PrimitiveCollectionAssociationSource` (the `DomainModels$Association` NullFields:["Source"] default still nulls Source for plain associations because SetSource only emits when set). Tests in `external_entity_write_test.go`. Issue #718 |
-| `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 | 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) | `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` | 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 |
-| "Class is not a Page property" — can't set a CSS class/style on a page via `CREATE PAGE (Class: '…')` (grammar rejects it) or ALTER PAGE | A page's Class/Style live on its `Forms$Appearance` sub-doc, but nothing wired it to MDL: `pages.Page` had no Class/Style field, the writers hardcoded the appearance empty, and `Class`/`Style` are reserved lexer tokens so the header's generic `IDENTIFIER` branch never matched them | grammar `mdl/grammar/domains/MDLPage.g4` (`pageHeaderPropertyV3`) + `pages.Page` + AST `CreatePageStmtV3` + visitor `visitor_page_v3.go` + builder `cmd_pages_builder_v3.go` + writers `sdk/mpr/writer_pages.go` & `mdl/backend/modelsdk/page_write.go` + describe `cmd_pages_describe.go` + ALTER `mdl/backend/pagemutator/mutator.go` (`applyPageLevelSetMut`) | Add explicit `CLASS COLON STRING_LITERAL` / `STYLE COLON STRING_LITERAL` alternatives to `pageHeaderPropertyV3` (regen grammar — keyword tokens don't match `IDENTIFIER`); add `Class`/`Style` to `pages.Page` + AST + visitor header handling + builder; legacy `serializePage` and modelsdk `newAppearance(page.Class, page.Style, …)` honor them; describe reads `rawData["Appearance"].Class/Style` into the CREATE PAGE header; ALTER page-level SET writes the `Appearance` sub-doc (create if absent). Same pattern as PopupWidth #661/#713. Bug-test `mdl-examples/bug-tests/714-page-class.mdl`. Issue #714 |
-| `CreatePage: ListView source *pages.DatabaseSource not yet supported by the modelsdk engine — rerun with MXCLI_ENGINE=legacy` — a native `listview` with a `database`/`database from … where …` datasource fails on the default engine | `listViewSourceToGen` only handled `*pages.MicroflowSource`; database (and context/listen/association) sources fell through to the "not supported" error. DataView, DataGrid2, and Gallery database sources already worked — only native ListView was missing | `mdl/backend/modelsdk/widget_write.go` (`listViewSourceToGen`); mirror the `customWidgetDataSourceToGen` database branch and the legacy `serializeListViewDataSource` | Add a `*pages.DatabaseSource` case building `genPg.NewListViewXPathSource()` with EntityRef (`DirectEntityRef`), XPathConstraint, a `NewGridSortBar()` (GridSortItem per `d.Sorting`, note gen uses **SortBar** not the legacy `Sort`/`ListViewSort`), and a `NewListViewSearch()` — the codec already has all types. Verify with `mx check` = 0 errors. Tests in `listview_source_write_test.go` |
-| `Visible: [Attr != '']` / `Editable: […]` on a widget (CONTAINER, textbox, …) → CE0117 "Error(s) in expression." in Studio Pro on the legacy engine, and silently *ignored* on the modelsdk engine | Two bugs (NOT BSON structure): (1) the expression was emitted with a bare attribute reference (`Name != ''`) — a Mendix client expression must root attributes in the widget data context (`$currentObject/Name != ''`); (2) the modelsdk codec hardcoded `ConditionalVisibilitySettings` to null, dropping the expression entirely | `mdl/visitor/visitor_page_v3.go` → `buildConditionalExpression`/`conditionalExprToString`; `mdl/backend/modelsdk/widget_write.go` → `applyWidgetBase` + TypeDefaults | (1) For `VISIBLE`/`EDITABLE` xpath constraints, build the xpath AST and serialize via `conditionalExprToString`, which prefixes bare `IdentifierExpr` / non-variable-rooted `XPathPathExpr` with `$currentObject/` (leaves `$…`-rooted paths, literals, functions, enum qualified-names untouched). Do **not** apply this to datasource `where` clauses (those are real XPath). (2) In `applyWidgetBase`, type-assert `SetConditionalVisibilitySettings`/`SetConditionalEditabilitySettings` and emit a settings element when the model has one; register `Forms$ConditionalVisibilitySettings`/`…EditabilitySettings` TypeDefaults (`NullFields: Attribute,SourceVariable`; `MandatoryLists: Conditions[,ModuleRoles]`) so the null-when-unset slots stay null (the encoder only fills NullFields when not already emitted). **ALTER PAGE** had the same gap (`SET Visible = [expr]` parsed as a `propertyValueV3` array and silently no-op'd): add `VISIBLE/EDITABLE EQUALS xpathConstraint` alternatives to `alterPageAssignment` (regen grammar), route to `VisibleIf`/`EditableIf` in `buildAlterPageAssignment` (reusing `buildConditionalExpression`), and add `VisibleIf`/`EditableIf` cases to `setRawWidgetPropertyMut` (`mdl/backend/pagemutator/mutator.go`) that build the settings node via `setWidgetConditionalSettingMut` (rejecting editability on non-input widgets). The shared mutator covers both engines. Verify both engines with `mx check` = 0 errors. Issue #627 |
-| `visible: [$currentObject/Status = Mod.Enum.Value]` stored as `… = 'Value'` (string) → MxBuild CE0117 "Error(s) in expression" (v0.13.0 regression; both engines) | `conditionalExprToString` (added with #627) sent a qualified-enum `QualifiedNameExpr` to its `default` case → `xpathExprToString`, which converts a 3-part enum name to a string literal. Correct for an XPath *datasource* constraint (DB level), WRONG for a *client* visibility/editability expression (compares to the qualified enum value) | `mdl/visitor/visitor_page_v3.go` → `conditionalExprToString` | Add an explicit `*ast.QualifiedNameExpr` case returning `e.QualifiedName.String()` (the qualified literal) before the `default`. Leaves the datasource `where` path (`buildXPathString`/`xpathExprToString`) untouched, so DB-level enums still stringify to `'Value'`. Applies to CREATE and ALTER (both use `conditionalExprToString`). Verify the datasource enum still stores `'Value'` and the visibility enum stays qualified; `mx check` = 0 |
-| CE0488 "No entity configured for the data source of this data view" on a context (page-parameter-bound) data view authored over **MCP** — DESCRIBE looks correct (`dataview dvX (DataSource: $Param)`), but the model has no entity on the source. DataGrids with database sources are fine | `mapDataViewSource`'s `*pages.DataViewSource` case used a mutually-exclusive `switch`: when `ParameterName != ""` it wrote only `sourceVariable` and never `entityRef`. Studio Pro/pg write **both** entityRef AND sourceVariable for a context source (see `testdata/pg-page-contact-newedit.json`) | `mdl/backend/mcp/page_widgets.go` → `mapDataViewSource` | Drop the exclusive switch: set `entityRef` (DomainModels$DirectEntityRef) whenever `EntityName != ""` AND `sourceVariable` (Pages$PageVariable) whenever `ParameterName != ""`. The executor already resolves the parameter's entity into `EntityName` (`cmd_pages_builder_v3.go` parameter case), so both are available. MCP-only — the MPR engines were never affected |
-| 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 | Case-mismatched prefix strip: visitor emits uppercase `"MICROFLOW "` from `odataValueText`, but `extractMicroflowRef` only trimmed lowercase `"microflow "`, so the keyword survived into BSON | `mdl/executor/cmd_odata.go` → `extractMicroflowRef` | 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 |
-| `describe`/catalog reports a numeric BSON field (Length, MinOccurs, MaxOccurs, MaxLength, FractionDigits, TotalDigits, Interval, NumberOfPagesToClose, …) as `0` / `unlimited` even though Studio Pro shows a real value | BSON numeric width mismatch — Studio Pro writes the field as `int64`, but the parser asserted `raw["X"].(int32)` so the type assertion failed silently and the field defaulted to its zero value | `sdk/mpr/parser_*.go` — grep for the field name; the fix point is the narrow assertion | Replace narrow type assertions on BSON numeric fields with the existing `extractInt(raw["X"])` helper (`sdk/mpr/parser.go`). It handles int32/int64/int/float64. When a non-zero default must survive a missing field, gate with `if _, ok := raw["X"]; ok { … = extractInt(...) }`. Sweep `grep -n '\.(int32)' sdk/mpr/parser_*.go` and ignore matches whose comment says "marker" (BSON-array-prefix probes are intentional). Issues #583, #585 |
-| Studio Pro shows a dropdown / property as its default value even though MDL set it explicitly (e.g. CREATE ODATA CLIENT with `ConfigurationMicroflow:` set, but the "Configuration source" dropdown reads "Constants only") | The BSON key mxcli writes isn't what Studio Pro reads — either the key name is wrong, or multiple dropdown options actually share a single field discriminated by something other than the key name (return type of a referenced microflow, sibling property, etc.) | The `serializeXxx` function in `sdk/mpr/writer_*.go` for the affected document type | (1) Ask the user to duplicate the offending object in Studio Pro and **explicitly pick each dropdown option** on the duplicate(s). An unconfigured duplicate just looks like "Constants only" and tells you nothing about which field the option uses. (2) Re-dump the duplicates from `mprcontents/**/*.mxunit` **after every Studio Pro change** — cached `/tmp/svc-*.json` files go stale the instant the user edits the project (see [[feedback-refresh-bson-dumps]]). (3) Diff against mxcli's output to find the renamed key. (4) Don't assume one-state-per-key. The OData "Configuration microflow" / "Headers microflow" case stores BOTH options in the single `ConfigurationMicroflow` BSON field — Studio Pro picks the dropdown label from the referenced microflow's return type. When a discriminator like that exists, have both MDL keywords write to the same model field. Issues #573, #587 and 2026-05-27 unify-config-microflow fix |
-| `DESCRIBE` of a document type omits a property the user set in the CREATE (e.g. enum-level `/** doc */` vanishes after a roundtrip; `CREATE OR REPLACE` silently runs as plain CREATE for some types) — even though the AST struct has the field, the model has the field, the writer serialises it, and DESCRIBE prints it | Visitor never copied the parsed value into the AST struct — every layer below the visitor is wired but the visitor's `ExitCreateXxxStatement` is missing the assignment | `mdl/visitor/visitor_<type>.go` → `ExitCreateXxxStatement` | Diff the visitor against a known-good sibling (e.g. enumeration vs constant). Standard wiring: `stmt.Documentation = findDocCommentText(ctx)` for doc-comments; `if createStmt.OR() != nil && (createStmt.MODIFY() != nil \|\| createStmt.REPLACE() != nil) { stmt.CreateOrModify = true }` for OR MODIFY/REPLACE. When adding a new CREATE statement, grep `mdl/visitor/visitor_constant.go` and copy these two blocks verbatim. Issue #393 |
-| `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` | 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 | `mdl/executor/oql_type_inference.go` → `findEntity` | 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 |
-| `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 | 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 | `mdl/executor/cmd_styling.go` (`execAlterStyling`, `execDescribeStyling`) + `mdl/backend/mpr/page_mutator.go` | 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 |
-| `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") | `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 | `mdl/executor/validate_microflow.go` → `walkBody` `*ast.DeclareStmt` case | 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 |
-| `DESCRIBE PAGE` emits a widget whose name is a reserved keyword (`container List`, `dynamictext Template`) and the output fails `mxcli check` (`mismatched input 'List' expecting IDENTIFIER`); quoting it by hand (`container "List"`) also failed | The widget-name position `widgetV3` accepted only a bare `IDENTIFIER`, so neither the keyword nor a `QUOTED_IDENTIFIER` parsed; and DESCRIBE emitted the name unquoted. Note this is *not* the general reserved-word problem — qualified names / params / attributes already go through `identifierOrKeyword` (a 552-entry keyword allowlist). The gap is the ~103 strict-`IDENTIFIER` positions, of which widget names are the highest-impact | grammar `mdl/grammar/domains/MDLPage.g4` (`widgetV3`) + `mdl/visitor/visitor_page_v3.go` (`buildWidgetV3`) + `mdl/executor/cmd_pages_describe_output.go` | Widen the name position to `(IDENTIFIER \| QUOTED_IDENTIFIER)`, `make grammar`, and `unquoteIdentifier` it in the visitor. On output, quote via `executor.mdlIdent` (which lexes the name and quotes only when it does *not* lex as a bare `IDENTIFIER` — no hardcoded keyword list, no false positives like a widget named "Dot"). For other strict-`IDENTIFIER` name positions apply the same pattern: `pageParameter`/`snippetParameter` bare names were widened the same way (issue #114 — note the SHOW_PAGE colon arg it reported already worked via `identifierOrKeyword`, and DESCRIBE emits params `$`-prefixed so output was already safe; the fix only closed the bare-declaration gap). Security `read(...)`/`write(...)` member lists and the validation-rule `attributeReference` were widened to `(IDENTIFIER \| QUOTED_IDENTIFIER)` via dedicated sub-rules (`entityMemberName`, `attributeRefSegment`); the grant DESCRIBE emitter quotes members through `mdlIdent` for a clean roundtrip (issue #675). Issues #619, #114, #675 |
-| `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 |
-| Under the default modelsdk engine a SHOW/DESCRIBE errors `… not implemented yet — rerun with MXCLI_ENGINE=legacy`, OR the read "works" but DESCRIBE drops nested config (return type, parameters, exposed-as info) into a half-shell that's fine under `--engine legacy` | The modelsdk `Backend` never overrode the read method (falls through to the generated `unimplemented` embed), OR a gen-accessor converter read children under the codegen property names while real Studio-Pro BSON stores them under the original storage names — the gen codec decodes those keys into empty lists/parts | `mdl/backend/modelsdk/*_read.go` (add the override) + `mdl/backend/modelsdk/unimplemented_gen.go` (confirm the stub) | First confirm the gap: `comm -23 <(grep -hoP 'errUnimplemented\("\K[^"]+' mdl/backend/modelsdk/unimplemented_gen.go \| sort -u) <(grep -rhoP 'func \([a-z]* \*Backend\) \K[A-Za-z0-9_]+' mdl/backend/modelsdk/*.go \| grep -v _test \| sort -u)`. Then **dump the real raw keys before writing the converter** (a gen-accessor port silently half-shells): iterate `b.ListRawUnitsByType(typePrefix)` + `b.GetRawUnit(id)` and read the fidelity-sensitive children from the empirical keys, not the gen accessors. JS actions store `JavaReturnType`/`Parameters`/`TypeParameters`/`MicroflowActionInfo` (gen wants `ActionReturnType`/`ActionParameters`/`ActionTypeParameters`/`ModelerActionInfo`) — see `javascript_read.go`. Validate with describe-parity vs `--engine legacy` (modelsdk may be *more* correct, e.g. recovers `Enum X` where legacy drops to `Object`). Issue 7 |
-| `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 | 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 | `mdl/executor/cmd_pages_describe_parse.go` (`extractDesignProperties` → `parseDesignProperty`) + `cmd_pages_describe_output.go` (`formatDesignPropertiesMDL` → `joinDesignPropertyEntries`) + `cmd_styling.go` (DESCRIBE STYLING emitter) | 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 |
-| `mxcli <cmd> -p "C:\\path\\App.mpr"` (Windows backslash path) fails with `unable to open database file (14)` and the echoed path is mangled (`C:\temp` → `C:<TAB>emp`, backslashes dropped); forward slashes (`-p C:/path/App.mpr`) work | The CLI fabricates `CONNECT LOCAL '<path>'` MDL from the flag value and re-parses it, so the lexer's `unquoteString` interprets `\t`/`\n`/`\r` and escape backslashes in the path. The positional `.mdl` arg is a raw path, so it's unaffected | every `cmd/mxcli/*.go` `fmt.Sprintf("CONNECT LOCAL '%s'...", projectPath)` site + `mdl/visitor/visitor_helpers.go` | Never interpolate a raw filesystem path into MDL source. Wrap it in `visitor.QuoteString(projectPath)` (escapes `\`→`\\`, `'`→`''` — the exact inverse of `unquoteString`) at every CONNECT-string site. Round-trip test in `mdl/visitor/visitor_connection_test.go`. Issue #644 |
-| `ALTER ENTITY ... ADD ATTRIBUTE` (or any ALTER) succeeds and `DESCRIBE ENTITY` is byte-identical before/after, but `mx check` then reports CE1613 "attribute … no longer exists" — often on a *different* entity's inherited system member (`createdDate`) referenced by grids/sort-bars in another module | The ALTER target is rebuilt from the semantic `domainmodel.Entity` (`entityToGen` → fresh `NewEntity`, `raw==nil`), so the codec's `EmitGUID` default writes `GUID = $ID`, discarding the entity's real on-disk GUID. The GUID is the stable cross-reference identity inheriting entities/pages resolve members through, so changing it dangles those refs. The forgiving reader re-derives DESCRIBE from flags and never shows GUID, so mxcli can't see its own damage. (Legacy `sdk/mpr` had the broader form: it re-serializes the *whole unit* and forces `GUID = $ID` on every sibling too) | `mdl/backend/modelsdk/domainmodel_alter.go` → `UpdateEntity` | Transplant the original element's raw bytes onto the rebuilt target (`ge.SetRaw(orig.Raw())`) so the codec treats it as an EXISTING element: dirty properties re-encode from `ge`, unmodeled fields (GUID, Capabilities, …) pass through verbatim. Siblings already survive via the list-rebuild raw passthrough. When a write "succeeds" but `DESCRIBE` is suspiciously byte-identical, suspect an identity (`$ID`/`GUID`) the reader doesn't surface — assert on raw BSON, not DESCRIBE. Issue #657 |
-| `mx check` reports CE6621 "Attribute 'X' has max length '200' which is not the same as max length in the OData service which is 'unlimited'" on every unlimited-length string attribute of a `create external entities from …` import — **only under the default modelsdk engine**; `--engine legacy` is clean | The codec's encoder only emits *dirty* properties for a new element. `attributeTypeToGen` skipped `SetLength` when `Length == 0` (unlimited), so the `Length` property stayed non-dirty and the field was omitted from the BSON entirely. Studio Pro then applies its own UI default of 200, which contradicts the OData service's "unlimited" type. Legacy's `writer_domainmodel.go` always writes `Length: t.Length` (including 0), so it never regressed | `mdl/backend/modelsdk/domainmodel_write.go` → `attributeTypeToGen` (`*domainmodel.StringAttributeType` case) | Always call `g.SetLength(int32(at.Length))` — drop the `if at.Length > 0` guard — so `Length: 0` is emitted explicitly, matching the legacy serializer. General rule for the codec write path: any field whose *zero value is meaningful* (0 = unlimited here) must be Set unconditionally, because an omitted field falls back to Studio Pro's own default, not to zero. Assert on the serialized `NewType` map (not DESCRIBE) — the reader treats a missing Length as unlimited so it hides the damage. Test `TestEntityToGen_ODataRemoteEntitySource` in `external_entity_write_test.go`. Issue #718 |
-| `mxcli oql` against a docker-deployed app returns **0 rows** for tables that clearly have data (false negative — tester concluded "saving is broken") | NOT a database-config problem (that's a red herring — proven: aligning the runtime to Postgres with data still returned 0). The OQL preview servlet (`/dev/preview_execute_oql`) is registered by `com.mendix.basis.livepreview.LivePreviewRegistry` → `AppContainer.addDevelopmentServlet`, which **only mounts the servlet when the JVM system property `mendix.running.locally.by.studiopro=true` is set** (Studio Pro sets it; a deployed `bin/start` PAD doesn't). Without it the endpoint returns HTTP 200 `{"result":-5,"message":"Action not found"}`, which mxcli silently parsed as empty data. (Found by decompiling `com.mendix.mxruntime.jar` / `com.mendix.appcontainer.jar`.) | `cmd/mxcli/docker/templates/docker-compose.yml` (the `command`) + `cmd/mxcli/docker/oql.go` (`oqlDevError`) | Add `-J -Dmendix.running.locally.by.studiopro=true` to the start command (each JVM opt needs its own `-J`), next to the existing `-Dmendix.live-preview=enabled` — this mounts the dev servlets and `mxcli oql` returns live data (verified end-to-end; DTAP mode is NOT required, DB config is irrelevant — the preview runs in-process against the runtime DataStore). Separately, make `oqlDevError` surface `{"result":<0,"message":…}` (not just `{"error":…}`) so the failure isn't swallowed as 0 rows. **Related startup bug found:** the generated `etc/Default` inherits the project's ports, which are `0` when unset → the runtime rejects port 0 and won't start; `patchRuntimePorts` (patch.go) forces `runtime.http { port = 8080 }` / `admin { port = 8090 }`. Verified with a full docker build/run/seed cycle |
-| `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) | `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 | `mdl/executor/oql_type_inference.go` → `extractSelectClause` | 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 |
-| `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) | 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 | `mdl/executor/widget_defs.go` → `RegenerateWidgetDocs` | 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 |
-| Chart `series` datasource/attribute sub-properties don't parse — `staticDataSource: database from View` → `extraneous input 'from'`; and even if parsed, were silently dropped (`buildObjectListItem` `default: continue` for datasource) | Object-list item sub-properties of datasource/attribute type had no grammar, visitor, or executor support (deferred at #538). The **BSON layer already handled it** (`widgetobj/builder.go` `overlayItemValue` datasource case) — only the upstream plumbing was missing | grammar `mdl/grammar/domains/MDLPage.g4` (`widgetPropertyV3` generic datasource alt + `propertyValueV3` QUOTED_IDENTIFIER) + visitor `mdl/visitor/visitor_page_v3.go` (generic datasource branch + quoted value) + executor `mdl/executor/widget_engine.go` (`buildObjectListItem` pre-pass, `datasource` case, `DataSource:` alias, empty-CT emission) + `mdl/backend/mutation.go`/`widgetobj/builder.go` (`EmptyTemplate` flag) + `mdl/executor/widget_defs.go` (`ItemPropertyMapping.DataSource` from `PropertyDef.DataSource`, bump `WidgetDefGeneratorVersion`) | Add `(IDENTIFIER\|keyword) COLON dataSourceExprV3` (before scalar generic branches; leading DATABASE/MICROFLOW/etc token disambiguates from `propertyValueV3`) + `QUOTED_IDENTIFIER` to `propertyValueV3`; `make grammar`. Visitor stores the datasource under the property name and unquotes quoted values. In `buildObjectListItem`: a pre-pass resolves datasource sub-props (setting the item's entity context so `staticXAttribute` resolves against the SERIES' own datasource, not the parent); the friendly `DataSource:` alias routes to `staticDataSource`/`dynamicDataSource` by dataSet mode; emit the pre-built datasource from the `prebuiltDataSources` map (not the child.Properties lookup, which misses the alias). **CE0463 nuance**: a VISIBLE-but-unset texttemplate series sub-prop (staticName always in static mode; static·/dynamic· names once their datasource is configured) must serialize an empty `Forms$ClientTemplate`, not null. Visibility = dataSet-mode gate (from editorConfig `hideNestedPropertiesIn`) + dataSource-binding gate; scoped to SERIES/LINE containers so Accordion `GROUP`/DataGrid columns are untouched. **Diagnose CE0463** with the update-widgets diff: dump the page, `mx update-widgets`, dump again, `diff` the series WidgetObject — the delta was one `TextTemplate: null` → empty CT. The residual chart CE0463 (bare chart too, on a version-mismatched mxbuild) is orthogonal WidgetType drift (#529/#600) that `mxcli docker check`/`build` fix via update-widgets. Tests: `chart_series_test.go`, `visitor_chart_series_test.go`; bug-test `mdl-examples/bug-tests/bug9-chart-series-datasource.mdl`; spec `mdl-examples/doctype-tests/34-chart-widget-examples.mdl`. Bug 9a |
-| An **invalid enumeration value** on a pluggable-widget object-list sub-property passes `mxcli check` but silently defaults in Studio Pro/mxbuild — e.g. a Maps marker `LocationType: 'coordinates'` (real values are `address`/`latlng`) defaults to `address` → CE "a dynamic marker requires an address"; a chart series `Interpolation: 'wobbly'` degrades. The value is dropped with no diagnostic | The def.json never captured a property's enumeration member keys, so `check` had nothing to validate against. (This is *not* a persistence bug — a **valid** enum value round-trips fine.) | mpk parser `sdk/widgets/mpk/mpk.go` (`PropertyDef.EnumValues` from `<enumerationValues>`) + `mdl/executor/widget_defs.go` (`ItemPropertyMapping.EnumValues`, bump `WidgetDefGeneratorVersion`) + validator `mdl/executor/validate_widgets.go` (`validateObjectListItemEnums`) | Capture `<enumerationValue key=…>` keys into `PropertyDef.EnumValues` at all three PropertyDef build sites; carry into `ItemPropertyMapping.EnumValues`; add **MDL-WIDGET08**: for each object-list-item enum sub-property present in the AST, flag a value (case-insensitive) outside the member set, listing the valid values. Thread the parent's `ObjectListMapping` into `validateWidgetTreeIn` (was just the container-keyword set). Tests: `TestValidateObjectListItemEnums`, `TestParseMPK_CapturesEnumValues` (the MDL-WIDGET08 check needs project context/`-p`, so it can't be a `.fail.mdl` — `make check-mdl` runs those syntax-only; example `32-pluggable-widget-object-lists-v010.mdl` OL06/OL07 exercise the valid `latlng` path end-to-end). NOTE: top-level (non-object-list) widget enum props aren't validated yet — `PropertyMapping` doesn't carry `EnumValues`. Bug 9a follow-up |
-| `ALTER ENTITY … MODIFY ATTRIBUTE X: Type NULLABLE` reports "Modified attribute" but the attribute stays NOT NULL — no way to make a required attribute optional. Any specified constraint (NOT NULL / UNIQUE / DEFAULT) is likewise ignored; there is no `NULLABLE` keyword, and it "parsed" only because trailing tokens were swallowed | Three-layer drop: (1) the visitor's MODIFY branch captured only `CALCULATED`; (2) `AlterEntityStmt` had no constraint fields; (3) the executor only set `attr.Type`. NOT NULL / UNIQUE are stored as **entity ValidationRules** (`Type:"Required"`/`"Unique"`, keyed by AttributeID), not attribute flags — so making nullable means **removing** the Required rule. Gotcha: the modelsdk read sets `ValidationRule.AttributeID` to the qualified name (`Mod.Ent.Attr`) while a created attr's ID is a UUID, so matching by ID alone fails | grammar `mdl/grammar/MDLLexer.g4` (`NULLABLE` token) + `MDLDomainModel.g4` (`attributeConstraint`) + `MDLSettings.g4` (keyword lists) + AST `mdl/ast/ast_entity.go` (`ModifyNotNull *bool` etc.) + visitor `mdl/visitor/visitor_entity.go` (MODIFY constraint switch) + executor `mdl/executor/cmd_entities.go` (`setAttributeValidationRule`, `ruleTargetsAttribute`) | Add a real `NULLABLE` token (+ to both `keyword` lists so it stays a usable identifier) and an `attributeConstraint` alt; `make grammar`. **Semantics: apply-specified, preserve-unspecified** (non-breaking — the documented "DEFAULT survives a type change" behavior stays): NULLABLE→`ModifyNotNull=&false` (drop Required rule), NOT NULL/REQUIRED→`&true` (re-add), UNIQUE→add Unique rule, DEFAULT→set value; nil pointer = leave as-is. Match the existing rule via `ruleTargetsAttribute` (UUID **or** last-dot-segment name, since read-back rules use the qualified name); store new rules with the qualified name (`validationRuleToGen` writes a dotted AttributeID verbatim). Verify with `describe entity` + `mx check`=0. Bug-test `mdl-examples/bug-tests/bug12a-modify-attribute-nullable.mdl`; tests `TestModifyAttributeConstraintsCaptured`, `TestRuleTargetsAttribute`, `TestSetAttributeValidationRule`. Bug 12a |
-| `MOVE ENUMERATION … TO FOLDER` prints "Moved … to new location" but `DESCRIBE ENUMERATION` and `CATALOG.ENUMERATIONS.Folder` still show the module root (looks like a silent no-op) | **NOT a write bug** — the move persists (the enum's `Unit.ContainerID` becomes the folder; `show enumerations` shows it correctly). Two *read* paths misreported it: (1) `buildEnumerations` hardcoded the catalog Folder to the module name (`// Folder as module name for now`) instead of `buildFolderPath` — same latent bug in `builder_microflows.go`/`builder_rest.go`/nanoflows; (2) DESCRIBE ENUMERATION emitted no `FOLDER` clause (unlike DESCRIBE PAGE), and CREATE ENUMERATION had no folder grammar to round-trip one | catalog `mdl/catalog/builder_modules.go` (+ microflows/rest) + grammar `MDLDomainModel.g4` (`enumerationOption` `FOLDER`) + AST `ast_enumeration.go` (`Folder`) + visitor `visitor_enumeration.go` + executor `mdl/executor/cmd_enumerations.go` (`execCreateEnumeration` via `resolveFolder`, `describeEnumeration` emit) | Catalog: replace hardcoded `moduleName` Folder with `b.hierarchy.buildFolderPath(x.ContainerID)`. Grammar: add `FOLDER STRING_LITERAL` to `enumerationOption` (parity with pages' `Folder:`); place the enum via the shared `resolveFolder(ctx, moduleID, folder)`; DESCRIBE emits `) FOLDER 'path';` when `BuildFolderPath != moduleName`. **Diagnosis tip**: when a MOVE "doesn't persist," check the raw `Unit.ContainerID` and `show <type>` before assuming a write bug — a hardcoded catalog column or a missing DESCRIBE clause is a read-path illusion (cf. #722). Bug-test `bug12b-enumeration-folder.mdl`; tests `TestCreateEnumerationFolderCaptured`. Bug 12b |
-| `CREATE PAGE` with a widget `Action: nanoflow …` fails on the **default (modelsdk)** engine: `client action *pages.NanoflowClientAction not yet supported by the modelsdk engine — rerun with MXCLI_ENGINE=legacy` (legacy works). Blocks any nanoflow-triggered button/link written via MDL | `clientActionToGen` had cases for save/cancel/close/delete/page/microflow/create-object client actions but **no `*pages.NanoflowClientAction` case** → hit the `default` refuse-loudly branch. (The sibling microflow-arg drop was the separate Bug 1, already fixed on `microflowSettingsToGen`.) | `mdl/backend/modelsdk/widget_write.go` → `clientActionToGen` | Add a `*pages.NanoflowClientAction` case building a gen `CallNanoflowClientAction`. Unlike the microflow action (which nests a `Forms$MicroflowSettings`) it carries the Nanoflow name + `ParameterMappings` **directly**: `SetNanoflowQualifiedName`, `SetProgressBar("None")`, `SetDisabledDuringExecution(true)`, and one `NanoflowParameterMapping` per arg (`SetParameterQualifiedName(nanoflow+"."+param)` BY_NAME + `SetExpression($var)`); register `Forms$CallNanoflowClientAction` TypeDefaults (`MandatoryLists:[ParameterMappings]`, `NullFields:[ProgressMessage,ConfirmationInfo]`). Mirror the legacy `writer_widgets_action.go`. The modelsdk **read** already round-trips it (describe shows `nanoflow M.NF(Form: $Form)`). Verify both engines with `mx check`=0. Bug-test `bug2-modelsdk-nanoflow-widget-action.mdl`; tests `TestNanoflowClientAction_Serialized` (+ `TestMicroflowClientAction_PersistsParameters` guards Bug 1's mapping stays wired through the shared helper). Bug 2 |
-| A `create page` over a layout with **more than one placeholder** (e.g. Main + Right/Topbar) can only populate Main — there is no MDL syntax to target a second placeholder, so the layout renders wrong | The page body was a flat widget list; the executor built exactly **one** `Forms$FormCallArgument` for the Main placeholder (`getMainPlaceholderRef` → hardcoded `"<Layout>.Main"`). NOT a BSON/engine gap — placeholders are BY-NAME (`Parameter="<Layout>.<Placeholder>"`) and `layoutCallToGen` already iterates *multiple* arguments; the whole gap was upstream (grammar/AST/visitor/executor produced a single arg). DESCRIBE also *flattened* every argument's widgets into one list | grammar `mdl/grammar/domains/MDLPage.g4` (`placeholderBlockV3`) + AST `mdl/ast/ast_page_v3.go` (`PagePlaceholderV3`) + visitor `mdl/visitor/visitor_page_v3.go` (`buildPagePlaceholdersV3`) + executor `mdl/executor/cmd_pages_builder_v3.go` (one FormCallArgument per placeholder) + describe `mdl/executor/cmd_pages_describe.go` (`getPageWidgetGroupsFromRaw`) | Add a `placeholder <Name> { … }` block (name = `identifierOrKeyword` so `Right`/`Left`/`Content` parse); bare widgets still bind to Main (backward-compatible). `make grammar`. Executor groups widgets by placeholder (Main = bare body + any `placeholder Main` block) and emits one arg each with `ParameterID = "<Layout>.<Name>"` and a numbered `conditionalVisibilityWidget<N>` wrapper. DESCRIBE groups by argument's `Parameter` and emits explicit `placeholder` blocks only when >1 placeholder has widgets (single-Main stays bare → no test churn). Verified both engines `mx check`=0; stable describe→exec→describe round-trip. Bug-test `mdl-examples/bug-tests/532-page-layout-placeholders.mdl`; tests `TestPagePlaceholderBlocksParsed`, `TestPageWithoutPlaceholdersUnaffected`. Layout placeholder names come from the layout's `Forms$Placeholder` widgets (e.g. Atlas_SideBar = Main + Topbar). Issue #532 |
-| `GRANT VIEW ON PAGE Module.Page TO Module.Role` prints success but the page's allowed roles appear to stay empty: `mxcli lint` still reports `CE0557`/`MPR007` ("used as home page … but has no allowed roles") across a freshly rebuilt catalog, while entity-access grants on the same roles verify fine (`describe entity` shows them). Reported on **modelsdk** engine (default), Mendix 11.11 | NOT a write bug — the grant **does** persist (`AllowedModuleRoles: [3, "Module.Role"]` on disk; `mx check` = 0 errors; Studio Pro would load clean). The regression was on the **read** path: modelsdk `pageFromGen` didn't populate `Page.AllowedRoles`, and `mxcli lint`'s CE0557 rule counts `len(pg.AllowedRoles)` from `ListPages()` — so it read every page as having zero roles and false-fired. `SHOW ACCESS ON PAGE` / `SHOW SECURITY MATRIX` under-reported the same way. The entity-vs-page asymmetry the reporter saw = different read paths (entity `describe` worked; page `lint` didn't), not different writes | `mdl/backend/modelsdk/page.go` → `pageFromGen` | Already fixed by `88a2d50b1` (issue #722): populate `out.AllowedRoles` from the gen `AllowedRolesQualifiedNames()`, mirroring `microflowFromGen`. Guard for the reporter's exact end-to-end flow: `TestUpdateAllowedRoles_PagePersistsForLintRead` (`mdl/backend/modelsdk/page_roles_test.go`) writes a page role then reopens fresh and asserts the lint read path (`ListPages`→`AllowedRoles`) sees it. **Diagnosis tip**: when a write "reports success but the value stays empty" *only in a read/lint/show command*, dump the raw unit (`mxcli bson dump`) — if the bytes are there, it's a read-adapter (`*FromGen`) gap, not a write bug; confirm by reverting the suspected read commit and re-running | 
-| `MOVE ENTITY X to OtherModule` where a **view entity's OQL** joins through `X`: passes `mxcli check`, but `mx check` on **Mendix 10.x** reports `CE0174 "…path '…/DmTest.Customer' does not resolve to an entity"` at the view entity — **only on the modelsdk engine**, only on 10.x (11.x is clean; legacy is clean) | Mendix <11 stores a view entity's OQL in **two** places: the top-level `DomainModels$ViewEntitySourceDocument` unit AND inline on the entity's `DomainModels$OqlViewEntitySource` (see `entityToGen`, gated `major < 11`). modelsdk's `UpdateOqlQueriesForMovedEntity` rewrote only the source document, leaving the inline copy pointing at the old module. 11.x doesn't write the inline copy (OQL lives only on the source doc), so it was never affected — hence 10.x-only. Legacy updates the inline copy incidentally by re-serializing the domain model | `mdl/backend/modelsdk/move_view_write.go` → `UpdateOqlQueriesForMovedEntity` | After the ViewEntitySourceDocument sweep, also iterate every domain model (`ListDomainModels` → `loadDomainModelGen`), find each entity whose `Source()` is `*genDm.OqlViewEntitySource` with an `Oql()` containing the old qualified name, `SetOql(strings.ReplaceAll(...))`, and `persistDM`. Mirrors the `UpdateEnumerationRefsInAllDomainModels` walk. **Diagnosis tip**: when a value updates in one storage location but a stale copy elsewhere still breaks `mx check`, dump raw `mprcontents` and grep for the value across `$Type`s — Mendix often duplicates a field (OQL, captions) and a version gate (`major < 11`) can make one copy version-conditional. Repro: `mdl-examples/bug-tests/move-entity-oql-view-inline-ref.mdl` |
-| `MOVE ENTITY` / `MOVE ENUMERATION` cross-module prints `Warning: Could not update OQL queries` / `Could not update enumeration references: load domain model 00000000-0000-0000-0000-000000000002: open …/mprcontents/00/00/00000000-…002.mxunit: no such file or directory` — **modelsdk engine only**. The move itself succeeds and (today) user modules are still updated, because `ListDomainModels` appends the failing System DM **last** — but the warning is spurious and the ordering dependence is fragile | Both reference-update sweeps iterate `ListDomainModels()`, which **injects the virtual System-module domain model** (ID `…002`, `buildSystemDomainModel`) so platform entities resolve. Each sweep then re-loads every listed DM from disk via `loadDomainModelGen(info.ID)` — but the System module isn't stored in `mprcontents`, so its `.mxunit` read fails. Legacy never hit this: it walks in-memory `*domainmodel.DomainModel` objects and never re-reads from disk | `mdl/backend/modelsdk/association_move_write.go` → `UpdateEnumerationRefsInAllDomainModels`; `mdl/backend/modelsdk/move_view_write.go` → `UpdateOqlQueriesForMovedEntity` | Skip the System DM at the top of each DM loop: `if string(info.ID) == meta.SystemDomainModelID { continue }` (import `modelsdk/meta`). It never holds user enum refs or user view-entity OQL, so skipping is correct and removes the disk-read failure regardless of iteration order. **Diagnosis tip**: a "no such file / not found" on the fixed ID `…002` (or module `…001`) means code is trying to load the *virtual* System unit from disk — filter it out, don't try to read it. Regression: `TestUpdateRefsForMovedEntity_SkipsSystemDomainModel` (`move_refs_system_test.go`) |
-| A page whose widget has a **conditional visibility/editability** setting fails to **load** on **Mendix 11.12** — `StorageLoadException: Conditional editability settings … has an invalid value '' for property Attribute. The text '   ' is not a valid AttributeIdentifier` (the `'   '` is `\x03\x00\x00\x00` = an int32 list marker; sometimes the value is the object's own `$Type` string). **Both engines**, ≤ 11.11 tolerated it. Reproduces only in the full doctype gate, not minimally — a red herring: it looked like `mx update-widgets` (harness step) was the cause, but the corruption is on disk from mxcli. My pymongo scans missed it because the value is a non-string type / the reader mis-parses | mxcli serialized `Forms$ConditionalVisibilitySettings` / `ConditionalEditabilitySettings` `Attribute` as **BSON null** when there's no attribute-based condition. Studio Pro writes the **empty string `""`** (Attribute is a BY_NAME `AttributeIdentifier`). 11.12's stricter streaming reader rejects the null and mis-reads the following bytes. Found by comparing a Studio-Pro-authored settings node (`str ""`) against mxcli's (`NoneType`) | legacy: `sdk/mpr/writer_widgets.go` (`serializeConditionalVisibility`/`serializeConditionalEditability`); modelsdk: `mdl/backend/modelsdk/widget_write.go` (RegisterTypeDefaults) + new `codec.TypeDefaults.EmptyStringFields` | Emit `Attribute: ""` not null. Legacy: change the `bson.D` value. Modelsdk: move `"Attribute"` from `NullFields` to the new `EmptyStringFields` (encoder emits `""`). **Diagnosis pattern**: when mx reports a corrupt value that pymongo *can't see on disk*, and the value looks like a `$Type` string or `\x03\x00\x00\x00`, suspect a wrong BSON *type* for a field (null where a string is required) that the streaming reader mis-aligns — compare field types against a Studio-Pro-authored node, don't just compare key presence. Repro: `mdl-examples/bug-tests/conditional-settings-attribute-empty-1112.mdl` |
-| A CLOSE PAGE microflow/nanoflow activity (`close page;`) fails `mx check` on **Mendix 11.12** with `CE0117 "Error(s) in expression"` at the Close page activity — **legacy engine only** (modelsdk passes; ≤ 11.6 tolerated it). Any annotation (`@caption`/`@color`/`@position`) on the activity reliably exposes it | The legacy `sdk/mpr` writer serialized the `Microflows$CloseFormAction` page-count under the field name `NumberOfPagesToClose`, but the metamodel storage name is `NumberOfPages` (the codec/modelsdk already used it — found by diffing the two engines' BSON: `legacy=NumberOfPagesToClose, modelsdk=NumberOfPages`). 11.12 doesn't recognise the old name, so the real `NumberOfPages` field is absent → defaults to an empty expression → CE0117 | `sdk/mpr/writer_microflow_actions.go` (`*microflows.ClosePageAction` case) + `sdk/mpr/parser_microflow_actions.go` | Write `NumberOfPages` (not `NumberOfPagesToClose`); the reader accepts both (`NumberOfPages` first, legacy `NumberOfPagesToClose` fallback) for round-trip fidelity on existing projects. **Diagnosis pattern**: a CE that says "invalid/empty expression" on an activity with no visible expression usually means a *renamed/missing* field defaulting to empty — diff the passing engine's BSON against the failing one to spot the field-name drift. Repro: `mdl-examples/bug-tests/close-page-numberofpages-1112.mdl` |
-| On **Mendix 11.12**, `mx check` fails to load projects on the **legacy** engine for several doctypes (`01-domain-model`, `10-odata`, `14-project-settings`, `22-published-rest`) with `System.InvalidOperationException: Expected '$ID' as the first property of a storage object, but got 'X'` at `StreamingBsonUnitReader`. The bad first-key varies run-to-run (`ThemeModuleOrder`, `EnableRspackBundler`, `Oql`, `MarkAsUsed`, `PopupResizable`…) — the tell-tale of random map-key order. modelsdk passes; ≤ 11.11 tolerates any order | Several legacy `sdk/mpr` writers preserve round-trip fidelity by carrying parsed subtrees as Go maps (`ProjectSettings.RawParts`, ref-marking `raw`, rename `raw`, domain-model `raw`) and marshalling them back. `bson.Marshal` emits **map keys in random order**, so `$ID` only lands first by luck. 11.12 rejects any storage object whose first key isn't `$ID`. The earlier `$ID`-first fix (bson.D reorder in writer_domainmodel/security) missed every map-passthrough site | `sdk/mpr/writer_settings.go` (+ `writer_refs`, `writer_rename`, `writer_domainmodel`, `writer_odata`, `writer_rest`, `writer_customblob`, `writer_security`, `writer_modules`, `writer_microflow`, … — all unit-boundary marshals) via new `sdk/mpr/writer_order.go` | Wrap every unit-boundary `bson.Marshal(doc)` in `marshalUnitIDFirst(doc)` = `bson.Marshal(bsonutil.HoistStorageID(doc))`. **Use the non-sorting `HoistStorageID`, NOT `OrderStorageValue`**: `OrderStorageValue` *sorts* the non-`$ID` keys, which corrupts template-derived pluggable-widget/datagrid page trees (mx then aborts with `got 'LabelTemplate'`, regressing `29-datagrid`/`33-alter-page`). `HoistStorageID` only lifts `$ID`/`$Type` to the front and preserves every other key's order → no-op on already-correct writers, fixes only the map-passthrough ones. **Do NOT normalize `writer_pages.go` or the page/workflow mutators** — their output is already `$ID`-first and they embed delicate widget maps the hoist would sort-corrupt. Verify on 11.12 with the doctype gate; regression-check `29`/`33` specifically. (Left unfixed: `03-page` LabelTemplate — a separate pre-existing issue where on-disk bytes read `$ID`-first yet mx still objects) |
-| A `NUMBERFILTER` in a DataGrid column passes `mxcli check` but corrupts the `.mpr`: MxBuild / Studio Pro **fails to load** the whole project on **Mendix 11.12** with `System.InvalidOperationException: Type …CustomWidgets.WidgetProperty does not contain a constructor with a parameter of type …CustomWidgets.WidgetValue` at `StreamingBsonUnitReader.ConstructObject`. `TEXTFILTER`/`DATEFILTER`/`DROPDOWNFILTER` in identical grids load fine; ≤ 11.11 loads even the number filter. Isolating it needs dropping widgets one-by-one under `mx check` | The embedded `datagrid-number-filter.json` template authored its 3 placeholder / screen-reader `Forms$ClientTemplate` blocks with **markerless empty arrays** — `"Items": []` and `"Parameters": []`. Every Mendix list serializes with a leading marker int (`Texts$Text.Items`→`[3]`, `ClientTemplate.Parameters`→`[2]`, `Widgets`/`Objects`→`[2]`); a bare `[]` has no marker. 11.12's stricter streaming reader mis-parses the markerless array and mis-associates the following bytes, so a nested `WidgetValue` lands where the reader is constructing a `WidgetProperty`. The template shape is otherwise identical to the working filters — the only diff is the missing markers (the blocks had hand-authored `dd2b3c4d…` placeholder IDs, i.e. not cleanly extracted from Studio Pro) | `sdk/widgets/templates/mendix-11.6/datagrid-number-filter.json` **and** `modelsdk/widgets/templates/mendix-11.6/datagrid-number-filter.json` (both engines embed their own copy) | Add the marker int to every empty `TextTemplate` array: `"Items": []`→`"Items": [3]`, `"Parameters": []`→`"Parameters": [2]`. Rebuild (`go:embed`), re-exec, verify with `scripts/mx-check.sh --version 11.12.0` (0 errors; regression-check 11.9 still clean). Guard: `TestTemplates_NoMarkerlessEmptyArrays` (in both `sdk/widgets` and `modelsdk/widgets`) walks every embedded template and fails on any bare `[]` — a Mendix list must always carry its marker. Repro: `mdl-examples/bug-tests/datagrid-numberfilter-array-marker.mdl`. **Diagnosis tip**: when a widget "passes check, fails 11.12 load" with the WidgetProperty/WidgetValue constructor error, suspect a markerless empty array in the template (shape-diff the failing widget's template against a working sibling; the smoking gun is `[]` vs `[<int>]`) |
-| `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 | 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 | `mdl/executor/cmd_enumerations.go` (`mendixReservedWords`, `mendixSystemAttributeNames`) — no code change needed; docs only | 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 |
-| A clickable `CONTAINER` can't be expressed: `OnClick: MICROFLOW …` / `Click:` error in the parser (`mismatched input 'MICROFLOW' expecting {',', ')'}`), and the one form that parses (`Action: MICROFLOW …`) is silently dropped — the container's BSON always has `OnClickAction = Forms$NoAction` | Layers all hardcoding "no click": (1) only the `Action:` keyword's `actionExprV3` accepted an action value, so `OnClick:`/`Click:` had no rule taking `MICROFLOW …`; (2) `buildContainerV3` never read `GetAction()`; (3) the `Container` model had no `OnClickAction` field and both writers (`serializeContainer`, modelsdk `widgetToGen`) emitted `serializeClientAction(nil)`/`noActionGen()`; (4) DESCRIBE never read it back | grammar `mdl/grammar/domains/MDLPage.g4` (`widgetPropertyV3`) + `mdl/visitor/visitor_page_v3.go` (`buildWidgetPropertyV3`) + `sdk/pages/pages_widgets_container.go` (`Container`) + `mdl/executor/cmd_pages_builder_v3_layout.go` (`buildContainerV3`) + `sdk/mpr/writer_widgets_layout.go` (`serializeContainer`) + `mdl/backend/modelsdk/widget_write.go` (DivContainer case) + `mdl/executor/cmd_pages_describe_parse.go`/`cmd_pages_describe_output.go` | Add an `ONCLICK COLON actionExprV3` alternative aliasing `Action:` (`make grammar`), stored under the same `Properties["Action"]` key. Add `OnClickAction ClientAction` to `Container`; in `buildContainerV3` read `GetAction()` → `buildClientActionV3()`; both writers serialize the real action (nil falls back to NoAction, so non-clickable containers are unchanged). DESCRIBE: extract `w["OnClickAction"]` via `extractButtonAction` (synthesize `{"Action": …}`) and emit `Action: <action>` in the container output. Verified with `mx check` = 0 errors. `Forms$DivContainer.OnClickAction` is required & introduced 8.3.0, so no version gate. Issue #603 |
-| A **quoted** association/attribute name in a microflow `SET`/`Change` target (`SET $x/Module."Assoc" = $y`, following the "always quote identifiers" guidance) passes `mxcli check` and `exec` but corrupts the `.mpr` — Studio Pro/MxBuild fails to load with `StorageLoadException: … 'Module."Assoc"' is not a valid AttributeIdentifier`. The unquoted form (`SET $x/Module.Assoc = $y`) is fine | The SET target was captured via `ap.GetText()` (raw source, quotes intact) and later sliced on `/` into the member name; `resolveMemberChange` then compared the quoted `"Assoc"` against the unquoted domain-model `a.Name`, never matched, and wrote the quoted string verbatim into `AttributeQualifiedName`. Attributes in `CREATE (…)` were unaffected because that path unquotes per-segment | `mdl/visitor/visitor_microflow_statements.go` (`buildSetStatement`) + `mdl/visitor/visitor_microflow_actions.go` (`buildAttributePathFromContext`, `attributePathTargetText`) + `mdl/executor/cmd_microflows_builder_actions.go` (`resolveMemberChange`, `isValidMemberIdentifier`) | Build the SET target from the structured path with each qualified-name segment unquoted (`getQualifiedNameText`, not `qn.GetText()`), so `Target` is normalized (`$x/Module.Assoc`) at parse time for every downstream consumer (check + exec). Defense-in-depth: `resolveMemberChange` rejects a non-empty member name that isn't a valid identifier (`isValidMemberIdentifier`) so a leaked quote errors instead of corrupting. Tests: `mdl/visitor/visitor_microflow_set_quoted_test.go`, `mdl/executor/cmd_microflows_member_identifier_test.go`. Repair a corrupted microflow in place with `CREATE OR REPLACE MICROFLOW …` (unquoted form) |
-| `set $IntVar = $a * 100 div $b;` (or `declare $I Integer = $a div $b;`) passes `mxcli check` but `mx check` rejects it with **CE0117** — Mendix integer division (`div`) yields a Decimal, so the target must be Decimal (or the result rounded) | `mxcli check`'s expression checker (`mdl/exprcheck`) was only wired into the Starlark linter, not `mxcli check`, and `inferKind` didn't type arithmetic operators (`div`/`*`/`-`/`mod` fell through to `KindUnknown`); nothing compared a SET/declare value's kind against the Integer/Long target | `mdl/exprcheck/parser.go` (`inferKind` + `arithResult`), `mdl/exprcheck/infer.go` (`InferSourceKind`, `SourceIsArithmeticDecimal`), `mdl/executor/validate_microflow.go` (`ValidateMicroflow` → MDL041) | Type `div`→Decimal and propagate Decimal through `+`/`-`/`*`/`mod` (`arithResult`); add **MDL041** in `ValidateMicroflow` (runs in syntax-only `check`, no project) flagging a Decimal-valued *arithmetic* expression assigned to an Integer/Long var. Narrow to arithmetic roots only via `SourceIsArithmeticDecimal` — a rounding-function result (`round(sqrt($x))`, `floor($a div $b)`) is accepted by Mendix into an Integer and must NOT be flagged (that was a false positive on `04-math-examples.mdl`). Tests: `mdl/exprcheck/infer_test.go`, `mdl/executor/validate_microflow_div_test.go` |
-| `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 | `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"` | `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` | 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` |
-| 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 | `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 | `mdl/executor/executor_dispatch.go` → `executeInner`/`syncBack` | 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) |
-| A widget's `DynamicClasses: '<expr>'` passes `mxcli check` but is silently dropped on write — `describe page` shows `Class` but no `DynamicClasses`; on `alter page ... set DynamicClasses` a core widget instead hard-errors "widget has no pluggable Object" | `DynamicClasses` (a `Forms$Appearance` string, sibling of `Class`) was unwired at every layer: parked in the generic Properties map, never read by `applyWidgetAppearance`, no `BaseWidget` field, both writers hardcoded `DynamicClasses: ""`, mutator had no case (fell to the pluggable-property setter), and describe never surfaced it | `sdk/pages/pages_widgets.go` (`BaseWidget.DynamicClasses`) + `mdl/ast/ast_page_v3.go` (`GetDynamicClasses`) + `mdl/executor/cmd_pages_builder_v3.go` (`applyWidgetAppearance`) + `mdl/executor/widget_engine.go` (`isBuiltinPropName`) + both writers (`sdk/mpr/writer_widgets.go` `serializeAppearance`; `mdl/backend/modelsdk/widget_write.go` `newAppearance`) + describe (`cmd_pages_describe*.go`) + `mdl/backend/pagemutator/mutator.go` (`case "DynamicClasses"`) | Carry it on `BaseWidget` (the appearance path — one place — covers core + pluggable widgets since `applyWidgetAppearance` runs for both); thread it through the appearance serializer of **both** engines (it's just a sibling string of `Class`); add a mutator `case "DynamicClasses"` writing `Appearance.DynamicClasses`; add a read at each `appearance["Class"]` site + an emit in `appendAppearanceProps`. Add `"DynamicClasses"` to `isBuiltinPropName` so the pluggable explicit-property pass skips it and the unknown-property guard permits it. Bug-test `mdl-examples/bug-tests/widget-dynamicclasses.mdl`; `mx check` = 0 on both engines. |
-| A widget's conditional visibility set via the **string / static-boolean** form — `Visible: '<expr>'`, `set Visible = "<expr>"`, or `Visible: false` — passes `check`+`exec` but is silently dropped (only the `[ … ]` bracket form worked) | The visitor routes a bracket constraint to `Properties["VisibleIf"]` (consumed by `applyConditionalSettings`) but any other value to `Properties["Visible"]`, which nothing consumed; the ALTER mutator's `case "Visible"` wrote a bare `Visible` string (a DataGrid2-column alias) that Studio Pro ignores on a general widget. A page widget has **no** plain boolean Visible field — visibility is always `ConditionalVisibilitySettings` | `sdk/pages/pages_widgets.go` (`StaticVisibleExpression`) + `mdl/executor/cmd_pages_builder_v3.go` (`applyConditionalSettings`) + `mdl/backend/pagemutator/mutator.go` (`case "Visible"`) | Add `pages.StaticVisibleExpression(v)` mapping the value to a client expression: `false`→`"false"`, an expression string passes through (caller roots it; the bracket form auto-roots), `true`/`""`→"no settings / clear". CREATE's `applyConditionalSettings` reads `Properties["Visible"]` as a fallback after `VisibleIf`; the ALTER mutator's `case "Visible"` builds the `ConditionalVisibilitySettings` node via `setWidgetConditionalSettingMut` (or clears it to nil for `true`). Both engines: CREATE via the shared model→`applyWidgetBase`, ALTER via the shared raw-BSON mutator. describe converges every form to the canonical `Visible: [expr]`. NB datagrid **column** visibility is a separate `columnPropertyAliases` path — untouched. Bug-test `mdl-examples/bug-tests/widget-visible-expression.mdl`; `mx check` = 0 on both engines. |
-| 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) | `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 | `mdl/executor/validate_widgets.go` (`staticWidgetKnownProps`, `validateStaticWidgetUnknownProps`, wired in `validateWidgetTree` gated on `lookupWidgetDef==nil`) | 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`. |
-| A **quoted** attribute/association name inside an *expression* — a microflow decision/`if`/`while`/`return` (`if $Expense/"Justification" != empty`), a widget `contentparams` entry (`contentparams: [{1} = "Amount"]`), a `visible:`/`editable:` expression (`visible: [ "Amount" > 1000 ]`), or an **XPath database datasource WHERE** (`datasource: database from M.E where [ "Status" = 'Submitted' ]`) — passes `mxcli check` (and `--references`). The first three fail MxBuild "Error(s) in expression"; the **datasource WHERE is the worst variant** — it *also* passes MxBuild, then **silently returns zero rows at runtime** because Mendix reads the quoted `"Status"` as the string literal `'Status'`, making the constraint `'Status' = 'Submitted'` always false. The unquoted form is fine. Sibling of the SET/Change-**target** row above, but for expression contexts (the "always quote identifiers" guidance is parser-safe, not platform-safe here) | Two sub-causes. (a) Expression contexts stored the **raw source text verbatim** — `SourceExpr.Source` from `extractOriginalText` (microflow), `expr.GetText()` (contentparams), the serialized visibility string. (b) The **inline-bracket XPath** path built member names via `buildXPathQualifiedName` (`words[i].GetText()`, no unquote) → an `IdentifierExpr{Name:"\"Status\""}` that `xpathExprToString` re-emits verbatim. Either way the quotes leaked, whereas binding contexts route each identifier through `unquoteIdentifier`. The general (non-XPath) expression AST was already unquoted | `mdl/visitor/visitor_helpers.go` (`stripExpressionIdentifierQuotes`) + `mdl/visitor/visitor_microflow_statements.go` (`buildSourceExpression`, `buildXPathSourceExpression`, `buildRetrieveWhereExpression`) + `mdl/visitor/visitor_page_v3.go` (`buildConditionalExpression`, `buildParamAssignmentV3`) + `mdl/visitor/visitor_xpath.go` (`buildXPathQualifiedName`) | Strip double-quote/backtick identifier quotes at the source. For raw-text slots: `stripExpressionIdentifierQuotes` (tracks single-quote string state incl. `''` escapes, so `'he said "hi"'` is untouched — safe because in Mendix expr/XPath only identifiers are double-quoted). For the inline-bracket XPath AST: `unquoteIdentifier` each `xpathWord` in `buildXPathQualifiedName` (root fix, feeds datasource WHERE + inline retrieve + conditional visibility); guard the `empty`/`true`/`false` special-value switch to fire only on the **unquoted** form so a quoted `"empty"` stays a member name. `dbSource.XPathConstraint = ds.Where` verbatim, so the visitor value is the persisted BSON constraint. Not caught by the expression **type** checker (`PROPOSAL_expression_type_checking.md`) — it works on the clean AST, not the raw string, and is microflow-scoped. Tests: `mdl/visitor/visitor_expr_quoting_test.go`; bug-test `mdl-examples/bug-tests/expr-quoted-identifiers.mdl` |
-| A `dynamictext`/`datagrid` **contentparams**/**captionparams** entry that navigates an association (`[{1} = Module.Assoc/Attr]`, e.g. `Expense_Employee/Name`) passes `mxcli check --references` but fails MxBuild "Value of text template parameter {1} … No value specified." A **direct** attribute (`[{1} = Title]`) persists fine — the drop is specific to association navigation | The value string (`Module.Assoc/Attr`) reached the AttributeRef serializer, which rejects any path with `< 2` dots (the association hop has 1 dot; `/Attr` is navigation, not counted) → **null AttributeRef** → CE0402. Nothing built the association-step structure Mendix needs. Verified against a Studio-Pro-authored page: the binding is a `DomainModels$AttributeRef` whose `Attribute` is the FINAL attr (`Module.Employee.Name`) and whose `EntityRef` is a `DomainModels$IndirectEntityRef` of `DomainModels$EntityRefStep{Association, DestinationEntity}` hops | `sdk/pages/pages_widgets_display.go` (`ClientTemplateParameter.AttributeRefSteps`, `AttributeRefStep`) + `mdl/executor/cmd_pages_builder_v3.go` (`resolveTemplateAssociationPath`, `associationEndpoints`) + `mdl/backend/modelsdk/widget_write.go` (`attributeRefWithStepsToGen`) + `mdl/executor/cmd_pages_describe_output.go` (`associationTemplateParamPath`) | **modelsdk engine only.** Resolver splits the path into association hop(s) + final attribute, resolves each association's destination entity from the domain model (ParentID=FROM, ChildID=TO; direction from the context entity), and stores `AttributeRef`=final attr QN + `AttributeRefSteps`. The writer emits `AttributeRef.EntityRef` via `entityRefToGen` (reused from microflows — identical `IndirectEntityRef`/`EntityRefStep` storage names); the `< 2 dots` guard no longer trips since the final attr is 2-dot. DESCRIBE reconstructs `Assoc/Attr` from `EntityRef.Steps`. Legacy engine still drops it (out of scope). Generated BSON is byte-structurally identical to Studio Pro. **Non-String final attribute needs NO `toString()`** — verified against Studio Pro, an association-navigated param uses `AttributeRef` + `FormattingInfo` (DecimalPrecision/DateFormat/EnumFormat) for any type; the `toString()` wrapping is only the *direct*-attribute path's behavior. Do not "fix" the assoc path to wrap non-String — that diverges from Studio Pro. Tests: `mdl/backend/modelsdk/widget_template_assoc_test.go`, `mdl/executor/cmd_pages_describe_assoc_test.go`; bug-test `mdl-examples/bug-tests/dynamictext-contentparam-association.mdl` |
-| Under the **default (modelsdk)** engine, any page widget with an **association datasource** (`datasource: $currentObject/Module.Assoc`, the master-detail idiom) fails at exec: `CreatePage: DataView source *pages.AssociationSource not yet supported by the modelsdk engine — rerun with MXCLI_ENGINE=legacy`. Same for a nested `listview` | `customWidgetDataSourceToGen` (pluggable widgets) already handled `*pages.AssociationSource`, but `dataViewSourceToGen`/`listViewSourceToGen` had no case → hit the "not yet supported" default. (Legacy doesn't error but writes a **broken** `Forms$AssociationSource{EntityRef: nil}` in `serializeListViewDataSource`, so legacy is not a valid reference — tracked as **L1** in [`docs/03-development/LEGACY_ENGINE_KNOWN_ISSUES.md`](../../docs/03-development/LEGACY_ENGINE_KNOWN_ISSUES.md); do **not** fix legacy, it will be removed when modelsdk matures) | `mdl/backend/modelsdk/widget_write.go` (`associationSourceToGen`, wired into `dataViewSourceToGen`+`listViewSourceToGen`) + `mdl/executor/cmd_pages_describe.go` (`associationSourcePath`) + `cmd_pages_describe_parse.go` (DataView/ListView datasource cases) + `cmd_pages_describe_output.go` (`associationDataSourceExpr`) | **modelsdk engine only.** Extract the proven `AssociationSource` block from `customWidgetDataSourceToGen` into a shared `associationSourceToGen` (Forms$AssociationSource → `IndirectEntityRef` of `EntityRefStep{Association, DestinationEntity}` + optional page-param `SourceVariable`; `$currentObject` → nil source var) and add a `case *pages.AssociationSource` to the DataView and ListView source builders. Matches the canonical legacy `serializeAssociationSource` (writer_widgets.go) and the Studio-Pro-verified `EntityRefStep` structure — NOT the broken `serializeListViewDataSource` stub. DESCRIBE reconstructs `$currentObject/Module.Assoc` from `EntityRef.Steps`. **An association source is valid only on LIST-producing widgets (listview/datagrid/gallery/templategrid), NOT a plain DataView** — Studio Pro rejects a DataView association source ("cannot have a data source of type association"); the widget still exec-creates (valid BSON), so `check` flags it with **MDL-WIDGET08** (`validateStaticWidget`). Tests: `mdl/backend/modelsdk/widget_assoc_source_test.go`, `mdl/executor/cmd_pages_describe_assoc_source_test.go`, `validate_widgets_test.go`; bug-tests `mdl-examples/bug-tests/assoc-datasource-modelsdk.mdl` (valid listview) + `dataview-association-source-rejected.fail.mdl` (MDL-WIDGET08) |
-| `IF … ELSIF … ELSE … END IF` silently drops every ELSIF arm on write — DESCRIBE round-trips `if … else …` with the middle arms gone (read path unchanged by the fix ⇒ the arm was absent from the stored model — dropped on write); no error from `check`/`exec` (both engines) | `buildIfStatement` read only `exprs[0]`/`bodies[0]` and the trailing ELSE body; the grammar's `(ELSIF expression THEN microflowBody)*` pairs were never visited | `mdl/visitor/visitor_microflow_statements.go` (`buildIfStatement`) | Lower each ELSIF arm into a nested `IfStmt` in the ELSE branch of the arm before it (built innermost-first) — Mendix has no native elsif, nested exclusive splits are the canonical shape. Guarded by visitor tests (chain, no-else, plain-if regression) + `mdl-examples/bug-tests/745-elsif-arms-dropped.mdl`. Issue #745 |
-| Under the **default (modelsdk)** engine, any page widget with an **association datasource** (`datasource: $currentObject/Module.Assoc`, the master-detail idiom) fails at exec: `CreatePage: DataView source *pages.AssociationSource not yet supported by the modelsdk engine — rerun with MXCLI_ENGINE=legacy`. Same for a nested `listview` | `customWidgetDataSourceToGen` (pluggable widgets) already handled `*pages.AssociationSource`, but `dataViewSourceToGen`/`listViewSourceToGen` had no case → hit the "not yet supported" default. (Legacy doesn't error but writes a **broken** `Forms$AssociationSource{EntityRef: nil}` in `serializeListViewDataSource`, so legacy is not a valid reference — tracked as **L1** in [`docs/03-development/LEGACY_ENGINE_KNOWN_ISSUES.md`](../../docs/03-development/LEGACY_ENGINE_KNOWN_ISSUES.md); do **not** fix legacy, it will be removed when modelsdk matures) | `mdl/backend/modelsdk/widget_write.go` (`associationSourceToGen`, wired into `dataViewSourceToGen`+`listViewSourceToGen`) + `mdl/executor/cmd_pages_describe.go` (`associationSourcePath`) + `cmd_pages_describe_parse.go` (DataView/ListView datasource cases) + `cmd_pages_describe_output.go` (`associationDataSourceExpr`) | **modelsdk engine only.** Extract the proven `AssociationSource` block from `customWidgetDataSourceToGen` into a shared `associationSourceToGen` (Forms$AssociationSource → `IndirectEntityRef` of `EntityRefStep{Association, DestinationEntity}` + optional page-param `SourceVariable`; `$currentObject` → nil source var) and add a `case *pages.AssociationSource` to the DataView and ListView source builders. Matches the canonical legacy `serializeAssociationSource` (writer_widgets.go) and the Studio-Pro-verified `EntityRefStep` structure — NOT the broken `serializeListViewDataSource` stub. DESCRIBE reconstructs `$currentObject/Module.Assoc` from `EntityRef.Steps`. A `Forms$AssociationSource` is valid on **LIST-producing** widgets (listview/datagrid/gallery/templategrid). A plain **DataView** cannot use `Forms$AssociationSource` (MxBuild **CE6705**) — but the DataView *association* case is still valid via a **different** source type; see the "data from context over association" row below (an earlier fix wrongly rejected it with MDL-WIDGET08, now removed). Tests: `mdl/backend/modelsdk/widget_assoc_source_test.go`, `mdl/executor/cmd_pages_describe_assoc_source_test.go`; bug-test `mdl-examples/bug-tests/assoc-datasource-modelsdk.mdl` (valid listview) |
-| A **DataView bound to a to-one referenced object over an association** ("data from context", e.g. an inner DataView showing the referenced Employee's `Name`/`Email` inside an `Expense` DataView) can't be authored/round-tripped: `dataview dvEmp (datasource: $currentObject/Module.Assoc)` was rejected (MDL-WIDGET08), a bare nested `dataview { textbox (attribute: Name) }` bound children to the **parent** entity (CE1613), and `describe` dropped the source → describe/exec **silently strips** the association DataView (round-trip corruption) | A DataView over an association is **not** a `Forms$AssociationSource` (that's list-widgets-only; CE6705 on a DataView). It is a `Forms$DataViewSource` whose `EntityRef` is a `DomainModels$IndirectEntityRef` navigating the association (a DataViewSource *is* an `EntityPathSource`, so its EntityRef may be indirect — `generated/metamodel/types.go:558`). mxcli generated the wrong source type, then (Bug 5 v1) wrongly rejected the whole case | `mdl/backend/modelsdk/widget_write.go` (`dataViewContextAssociationSourceToGen`, wired into `dataViewSourceToGen`'s `*pages.AssociationSource` case) + `mdl/executor/cmd_pages_builder_v3_widgets.go` (removed the `buildDataViewV3` association guard) + `mdl/executor/validate_widgets.go` (removed MDL-WIDGET08) + `mdl/executor/cmd_pages_describe_parse.go` (`Forms$DataViewSource` reads `EntityRef.Steps` via `associationSourcePath`) | **modelsdk engine only.** For a DataView association datasource, emit `Forms$DataViewSource` with `EntityRef = IndirectEntityRef{EntityRefStep{Association, DestinationEntity}}` (+ optional page-param `SourceVariable`; `$currentObject` → none) — mirrors `associationSourceToGen` but wraps the IndirectEntityRef in a DataViewSource. Children then bind to the destination entity. DESCRIBE reconstructs `$currentObject/Module.Assoc`. Removes the earlier MDL-WIDGET08 over-rejection. **When two widget kinds share a navigation but MxBuild accepts it on only one, the distinction is the source `$Type` wrapper, not the EntityRef inside it** — check `generated/metamodel/types.go` for the widget's allowed `DataSource` subtypes. mxbuild-validated (`mxcli docker check --no-update-widgets` = 0 errors) + full describe→re-exec round-trip. Tests: `mdl/backend/modelsdk/widget_assoc_source_test.go` (`TestDataViewAssociationSource_Serialized`); bug-test `mdl-examples/bug-tests/dataview-context-association-source.mdl`. Bug 5 (reclassified) |
-| **DataGrid2** (`datagrid`) columns fail MxBuild **CE0463** "widget definition changed" on the **default (modelsdk)** engine — reported for custom-content columns, but actually **every** column (attribute too). Legacy is fine | The column WidgetObject's `Properties` were serialized in **alphabetical** order (`alignment, allowEventPropagation, attribute, …`) instead of the template's `PropertyTypes` order (`showContentAs, attribute, content, dynamicText, …`). Studio Pro hashes the object structure against the type and flags CE0463 on any order mismatch. Cause: the object-list item builder (`mdl/backend/widgetobj/builder.go:274`) orders by `NestedKeyOrder`, falling back to alphabetical when empty; the **modelsdk** registry loader never captured it (`types.PropertyTypeIDEntry` had no such field), while the MPR/legacy loader did → legacy correct, modelsdk broken. Top-level widget props were unaffected (ordered by a different path), which is why only the nested column object-list broke | `mdl/types/widget_property_type.go` (`PropertyTypeIDEntry.NestedKeyOrder`) + `modelsdk/widgets/loader.go` (thread `nestedKeyOrder` through `jsonValueToBSONWithNestedObjectType`→`extractNestedObjectType`→`extractNestedPropertyTypes`, append in template array order) + `mdl/backend/modelsdk/widget_pluggable_write.go` (`convertPropTypeIDs` copies `NestedKeyOrder`) | Mirror the `sdk/widgets` loader's existing `nestedKeyOrder` capture in the parallel `modelsdk/widgets` loader (dedup on first occurrence, append in PropertyTypes array order), add the field to `types.PropertyTypeIDEntry`, and copy it in the modelsdk `convertPropTypeIDs`. **Diagnose column-order CE0463 by mapping each column WidgetProperty's `TypePointer` → the type's `WidgetPropertyType.PropertyKey` and comparing the sequence to the template's PropertyTypes order.** Verified: modelsdk column order now equals the template (and legacy) order for both attribute and custom-content columns, and **`mxcli docker check --no-update-widgets` (raw output, no widget normalization) = 0 errors** for the report's exact pattern (attribute column + custom-content dynamictext-over-association + custom-content actionbutton with `show_page`). The custom-content child-widget subtree needed no separate fix — ordering was the whole cause. Tests: `modelsdk/widgets/nested_key_order_test.go`; bug-test `mdl-examples/bug-tests/datagrid2-custom-content-column.mdl`. **To validate CE-class MxBuild errors locally: `mxcli setup mxbuild -p app.mpr --force` then `mxcli docker check -p app.mpr --no-update-widgets`** (the `--no-update-widgets` is essential — the default runs `mx update-widgets` which auto-normalizes pluggable widgets and masks a real CE0463) |
-| 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 | 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 | `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`) | 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 |
-| A **compound** (nested) design property authored inline on a widget — `designproperties: ['Card style': on, 'Spacing': ['margin-bottom': 'Large', 'margin-top': 'Medium']]`, e.g. the Atlas `Spacing` group, and any block copied in via `use building block` — is silently dropped on write: `check`, `exec`, **and `mx check`** all pass, but the nested styling is simply gone (only the flat toggle/option props survive). The **legacy** builder write path. Sibling of #668, which fixed the describe **read** side but not this CREATE write path | `serializeDesignProperties` switched on `p.ValueType` with cases for `toggle`/`option`/`custom` and a `default: continue` that dropped `compound` entirely. A compound property's value is itself a set of sub-properties stored in a `Forms$CompoundDesignPropertyValue`, whose `Properties` list has the SAME marker-prefixed `Forms$DesignPropertyValue` shape as the outer array — but nothing serialized it, so the whole entry (key included) vanished | `sdk/mpr/writer_widgets.go` (`serializeDesignProperties`) | Add a `case "compound"` emitting `{$ID, $Type: Forms$CompoundDesignPropertyValue, Properties: serializeDesignProperties(p.Compound)}` — recurse into the sub-entries, which the marker-prefixed array handling already covers. The AST (`DesignPropertyEntryV3.Nested`), visitor (`buildDesignPropertyEntryV3`), and builder (`astDesignPropToValue` → ValueType `"compound"`, `Compound`) all already produced the nested model; only the serializer's terminal switch dropped it. Verified: `mxcli docker check` = 0 errors on 11.12.1 (authoritative) + write→describe round-trip preserves `Spacing` on **both** engines. Test `TestSerializeDesignProperties_Compound` (`sdk/mpr/writer_widgets_test.go`); bug-test `mdl-examples/bug-tests/compound-designproperties.mdl`. **Diagnosis pattern**: when a value passes every check *including `mx check`* yet the construct is absent, suspect a terminal `default: continue`/`default:` drop in a type-switched serializer — the value never reaches BSON, so nothing downstream can complain |
-| 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 | `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" | `mdl/executor/cmd_pages_builder_v3.go` (`expandFragments`) | 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` |
-| A single `alter entity` with **comma-separated** `add attribute` clauses fails to parse — e.g. `add attribute A: integer default 9, add attribute B: integer default 9` → `no viable alternative at input '9'`. Looks like "only the first `add` can carry a `default`" but the real cause is the comma | `alterStatement`'s `ALTER ENTITY qualifiedName alterEntityAction+` had **no separator** — commas between actions weren't allowed at all; the error surfaced on the second clause's `default` value token, which misdirects. Sudoku findings #5 | `mdl/grammar/MDLParser.g4` (`alterStatement`, ALTER ENTITY alt) | Change `alterEntityAction+` → `alterEntityAction (COMMA? alterEntityAction)*` (optional comma, mirroring `entityOptions`); `make grammar`. Newline-separated actions still parse. Bug-test `mdl-examples/bug-tests/f5-alter-entity-comma.mdl`. **Diagnosis pattern**: a parse error on the *value* inside the *second* item of a list usually means the list rule lacks a separator, not that the value form is wrong |
-| 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` | `ValidateEntity` had no autonumber-seed rule; the writer emits no `AttributeValue` when `!attr.HasDefault`, so Studio Pro has no start value. Sudoku findings #6 | `mdl/executor/cmd_enumerations.go` (`ValidateEntity`) | 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` |
-| 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) | 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 | `mdl/executor/cmd_enumerations.go` (`ValidateEntity`, `autoMemberNames`) | 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` |
-| `mxcli run` warm-loop ergonomics from Sudoku findings: (a #17) a **relative** `-p` fails with MxBuild's raw "should be an absolute path" + a Windows JSON sample; (b #15/#23) a **build failure in the watch loop** (incl. a SCSS compile error like `Expected expression. _x.scss 180:35`) printed only the generic `build failed: <message>`, swallowing the real detail | (a) `cmd_run.go` passed `-p` straight through without `filepath.Abs`; (b) the watch path at `runlocal.go` printed only `build.Message` while `build.Raw` (the full serve `/build` body, which the cold-build path already prints) held the compiler/model detail | `cmd/mxcli/cmd_run.go` + `cmd/mxcli/docker/runlocal.go` (watch build-failed branch) | (a) `projectPath, _ = filepath.Abs(projectPath)` after reading the flag; (b) also print `strings.TrimSpace(string(build.Raw))` (indented) when it differs from `build.Message`, matching the cold path. **Diagnosis pattern**: when a dev-loop error is unhelpfully generic, check whether a `Raw`/full-body field is already captured and just not printed on that code path |
-| 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.) | 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 | `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`) | 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 |
-| 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 | 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 | `mdl/executor/widget_defs.go` (`itemPropertyAliases`, `columns.columnClass`) + `mdl/executor/widget_engine.go` (`WidgetDefGeneratorVersion` bump) | 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 |
-| A standard widget's generic property written in **lowercase** (e.g. `dynamicclasses:` instead of `DynamicClasses:`) is silently dropped on write, though the canonical-case form persists. Documented lowercase examples (`create-page.md`) don't work | Generic (non-tokenized) widget properties are stored in `WidgetV3.Properties` under the **user's original casing** (`visitWidgetProperty` generic branch: `Properties[id.GetText()]`). The builder reads appearance props via `GetStringProp("DynamicClasses")` — an exact-case map lookup — so a lowercased key never matched. MDL property names are documented case-insensitive (mirrors `lookupProperty` in the widget engine, used by the pluggable path) | `mdl/ast/ast_page_v3.go` (`GetStringProp`) | Make `GetStringProp` case-insensitive: exact-match fast path, then a lowercased scan (mirrors `lookupProperty`). Fixes any generic-stored standard-widget property read via `GetStringProp`/`GetDynamicClasses`, not just DynamicClasses. Test: `mdl/ast/ast_page_v3_getprop_test.go`; same bug-test as 10a. Bug 10b |
-| 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" | 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 | `mdl/executor/validate_widgets.go` (`validateStaticWidget`, MDL-WIDGET09) + `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildDataViewV3` exec refusal) | 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) |
-| A **list** widget (listview/datagrid/gallery) reverse-navigating an association (`datasource: $currentObject/Module.Assoc` on a Customer showing its Orders) passes `mxcli check` but fails MxBuild **CE8812** "A grid association path must result in a list." — **only** when the association is `owner both` **and** its FROM entity has another association. Default-ownership references work; a DataView (to-one) over the same reverse works | **Not an mxcli encoding bug** — the `Forms$AssociationSource` + `EntityRefStep{Assoc, DestinationEntity}` is correct (verified via `bson dump`). It's correct MxBuild behavior: `owner both` on a plain `type reference` makes the reverse navigation **to-one**, so a *list* widget over it is invalid (a DataView is fine). The single-ref-vs-multi-ref inconsistency (single owner-both allows the reverse listview; adding a sibling association flips it to-one) hints at a **separate, unfixed `owner both` domain-model serialization quirk** — not yet root-caused (needs a Studio-Pro owner-both reference for comparison) | domain-model writer (`sdk/mpr/writer_domainmodel.go` / `mdl/backend/modelsdk/domainmodel_write.go` association owner/navigability) — **investigate before adding any check** | **No check added** (deliberately — the condition isn't statically precise and isn't always-wrong; adding one would repeat the MDL-WIDGET08 over-rejection mistake). Guidance only: use `default` ownership for a normal to-one reference (reverse is then to-many, list widgets work); reserve `owner both` for `ReferenceSet`. Documented in `generate-domain-model.md` (Owner Options). Diagnose CE8812 by dumping the widget source (encoding is usually right) then checking the association's `owner` — bisect the domain model, not the page. **Method note:** bisected this with `mxcli docker check --no-update-widgets` over a fresh test-project copy per variant |
-| 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 | `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 | `mdl/executor/cmd_pages_builder_v3.go` (`associationDestination`, new `entityIsOrDescendsFrom` + `entityGeneralizations`) | 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) |
-| A documented object-list widget child keyword parse-errors: `line lRevenue (...)` inside a LineChart/TimeSeries/BubbleChart, or `scalecolor scLow (...)` inside a HeatMap → `mismatched input 'line' expecting '}'`. `series` (etc.) works | The executor side was already complete — `deriveObjectListKeyword` maps `lines`→`LINE` and `scaleColors`→`SCALECOLOR`, and `buildObjectListItem` routes any object-list child generically via the widget's `.def.json`. The **grammar** just lacked the tokens: `LINE`/`SCALECOLOR` weren't lexer tokens nor `widgetTypeV3` alternatives | `mdl/grammar/MDLLexer.g4` (token) + `mdl/grammar/domains/MDLPage.g4` (`widgetTypeV3`) + `mdl/grammar/domains/MDLSettings.g4` (`keyword` rule) | Add the token, the `widgetTypeV3` alternative (alongside `SERIES`/`MARKER`), **and** the `keyword` rule entry (so a very common word like `line` stays usable as an identifier via `identifierOrKeyword`); `make grammar`. No executor/def changes needed — `deriveObjectListKeyword` already produces the singular-uppercase keyword and the def.json carries the mapping. Verify child data lands in BSON (`Lines`/`Series` array). Confirmed via `mdl-examples/doctype-tests/34-chart-widget-examples.mdl` (exec 0 errors; `line`/`scalecolor` persist). DESCRIBE round-trip is handled by the row below |
-| `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 | 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`.) | `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) | 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`. |
-| 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 | 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 | `mdl/executor/widget_defs.go` (`itemPropertyAliases`, `heatmap.scaleColors.colour`) + `mdl/executor/widget_engine.go` (`WidgetDefGeneratorVersion` bump) | 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 |
-| 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 | 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 | `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) | 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 |
-| 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 | 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) | `mdl/executor/oql_type_inference.go` (`ValidateOQLSyntax`, `oqlReservedWords`, **MDL032**, **MDL072**); `mdl/executor/validate_oql_reserved_names.go` (**MDL071**) | **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. |
-| 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 | 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 | `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** | 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` |
-| 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** | 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 | `mdl/executor/oql_type_inference.go` (`passthroughStringLengthMismatch`, called in `validateViewEntityTypes` before the generic `typesCompatible`) | 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 |
-| `DESCRIBE` of a view entity on the **default (modelsdk)** engine omits the `as (… OQL …)` clause entirely (legacy renders it) — the describe→exec round-trip silently drops the query, leaving a queryless view. Reproduces on any Mendix **11.x** project | On Mendix 11.0+ the OQL is stored **only** in the separate `DomainModels$ViewEntitySourceDocument`; the inline `OqlViewEntitySource.Oql` field was removed (see the writer's `if !pv.IsAtLeast(11,0)` gate in `serializeOqlViewEntitySource`). The modelsdk read (`entityFromGen`: `out.OqlQuery = src.Oql()`) only read the now-empty inline field and never followed the `SourceDocumentRef`. Legacy was correct — `loadViewEntityOqlQueries` in `sdk/mpr/reader_documents.go` already joins the source docs | `mdl/backend/modelsdk/domainmodel.go` (`populateViewEntityOql`, wired into `ListDomainModels` + `GetDomainModel`) | After building the domain models, list `ViewEntitySourceDocument` units (`mprread.ListUnitsWithContainer[*genDm.ViewEntitySourceDocument]`), map `moduleName.docName → Oql()`, and fill `OqlQuery` for any view entity with an empty `OqlQuery` + a `SourceDocumentRef` (mirrors the legacy join; guarded by a cheap pre-check so non-view projects pay nothing). When a view-entity read differs between engines on 11.x, suspect a field the platform moved out-of-line into a source document. Test: `TestGetDomainModel_ViewEntityOqlFromSourceDocument` (round-trips via both read paths) |
-| An `actionbutton`/`linkbutton` `icon:` property is silently dropped on write (flagged `MDL-WIDGET07` "property `icon` … will be silently dropped") — no way to give a button an icon, so the button renders without one. `linkbutton` (Link render mode) itself already worked | The button builder read Caption/Action/ButtonStyle but never the `icon` property, and the `Forms$ActionButton` codec default nulls the `Icon` field. Nothing built the Mendix icon element | `sdk/pages/pages_widgets_action.go` (`Icon` struct + `IconTypeIconCollection`) + `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildButtonV3` reads `icon`) + `mdl/backend/modelsdk/widget_write.go` (`iconToGen`, wired into the `ActionButton` case) + describe (`cmd_pages_describe_parse.go` `extractIconRef`, `cmd_pages_describe_output.go` emit) + `validate_widgets.go` (`staticWidgetKnownProps` += `Icon`) | Build the modern **icon-collection** icon: `icon: 'Atlas_Core.Atlas_Filled.pencil'` → `Forms$IconCollectionIcon{Image: QN}` (verified against a Studio-Pro button — storage `$Type` is `Forms$`, not `Pages$`; no typed gen struct, so build it via `newElem`/`addStr`). `g.SetIcon(...)` overrides the null-Icon default. DESCRIBE reconstructs `Icon:` from the element's `Image`; add `Icon` to the known-props list so MDL-WIDGET07 stops warning. A non-existent icon name is (correctly) rejected by MxBuild with **CE1613** "selected custom icon … no longer exists". Tests: `TestBuildButtonV3_Icon`, `TestOutputWidgetMDLV3_ButtonIcon`; bug-test `mdl-examples/bug-tests/602-button-icon.mdl`. Issue #602 |
-| `DESCRIBE WORKFLOW` on the **default (modelsdk)** engine renders some activities as non-round-trippable comments — `-- [Workflows$StartWorkflowActivity]`, `-- [Workflows$JumpToActivity]`, `-- [Workflows$WaitForTimerActivity]`, `-- [Workflows$WaitForNotificationActivity]` — so `describe → exec` drops those activities and you can't learn their syntax from an existing workflow. User tasks, decisions, splits, call-microflow/workflow round-trip fine (legacy round-trips all of them) | The describe **formatter** (`formatWorkflowActivities`) already has typed cases for jump/wait/start/end, but the modelsdk **reader** never produced them: these activities have no `genWf` struct (written via generic `newElem`), so `workflowActivityFromGen`'s type switch fell through to `GenericWorkflowActivity`, which the formatter renders as `-- [$Type]`. Legacy's `parser_workflow.go` had dedicated cases, so legacy was correct — modelsdk-only gap | `mdl/backend/modelsdk/workflow_read.go` (`workflowActivityFromGen` default → new `workflowSimpleActivityFromGen`) | Recognise the untyped simple activities by `el.TypeName()` and rebuild the semantic struct, reading fields from raw BSON via `genWf.RawFieldString` (`TargetActivity` for jump, `Delay` for the timer) — mirrors the legacy parser. Start/end become typed so the formatter **skips** them (implicit in MDL); jump/wait become executable statements. When an engine emits `-- [$Type]` in describe, the *formatter* usually already handles the type — the gap is the *reader* decoding it to `GenericWorkflowActivity`. Test: `TestWorkflowSimpleActivities_ReconstructedTyped`; round-trip validated describe→drop→exec→`docker check` = 0 workflow errors. Bug 11b (11a = the missing `write-workflows.md` authoring skill) |
-| A built-in widget action (`actionbutton`/`container`/`linkbutton` `Action: microflow M.Flow(Param: $x)`) **silently drops the argument** on the **default (modelsdk)** engine — `describe` shows `Action: microflow M.Flow` (no args), the flow runs with no parameter, and a required-param flow never fires so the button/row no-ops at runtime. `mxcli check`/`docker check`/`docker build` all pass (0 errors) — silent break. Legacy persists it (the workaround) | `clientActionToGen`'s `MicroflowClientAction` case built the `Forms$MicroflowSettings` from the microflow **name only** (`microflowSettingsToGen(x.MicroflowName)`), never serializing `x.ParameterMappings` — the executor builds them correctly into the model, the writer threw them away. (NOT the same as `custom-widgets.md`'s "action mapping too complex for auto-mapping" — that's about *pluggable-widget action-typed properties* in def.json generation, a different path.) | `mdl/backend/modelsdk/widget_write.go` (`microflowSettingsToGen`) | Give `microflowSettingsToGen` the mappings param; emit one `genPg.MicroflowParameterMapping` each — `SetParameterQualifiedName("<MicroflowQName>.<ParamName>")` (BY_NAME) + `SetExpression(variable-or-expression)` — mirroring the legacy `writer_widgets_action.go` BSON. The client-action caller passes `x.ParameterMappings`; the microflow-datasource callers pass `nil`. Verified: default-engine describe now keeps `(Param: $x)`; a type-correct page = 0 mxbuild errors (both engines give the *same* CE0117 on a type-mismatched arg — that's a model error, not the writer). Tests: `TestClientActionToGen_MicroflowParameterMappings`; bug-test `mdl-examples/bug-tests/bug1-widget-action-param-mapping.mdl`. Nanoflow widget actions were a separate gap (the whole `NanoflowClientAction` case was missing) — now fixed in Bug 2 below. Bug 1 |
-| 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) |
-| No way to change an existing **enumeration value's caption** in place — `alter enumeration` had only `ADD`/`RENAME`/`DROP VALUE` + `SET COMMENT`; `RENAME VALUE X TO Y` changes the *name*, not the caption. The only route was drop + recreate, which fails while the enum is referenced by an attribute | Missing grammar action + AST op + executor case — a full-stack gap, not a code bug | `mdl/grammar/domains/MDLDomainModel.g4` (`alterEnumerationAction`) → `mdl/ast/ast_enumeration.go` (`AlterEnumOp`) → `mdl/visitor/visitor_enumeration.go` (`ExitAlterEnumerationAction`) → `mdl/executor/cmd_enumerations.go` (`execAlterEnumeration`) | Add `MODIFY VALUE IDENTIFIER CAPTION STRING_LITERAL` (reuses existing `MODIFY`/`CAPTION` tokens, so no lexer change); add `AlterEnumModifyCaption` op reusing the `Caption` field; executor finds the value by name and replaces only the `en_US` translation (preserves the value's ID + other locales). Re-captions in place, so it works while referenced (mxbuild 0 errors) — no drop needed. Value names in `alter` must be plain identifiers (a reserved-word-named value like `Created` can't be targeted — pre-existing, shared by ADD/RENAME/DROP). Tests: `TestAlterEnumeration_ModifyValueCaption` (visitor) + `TestAlterEnumeration_ModifyValueCaption_Mock` (executor); example in `01-domain-model-examples.mdl` |
-| A page with a native **LISTVIEW** over a `database from` (XPath) datasource passes `mx check` but **crashes the browser client at runtime** and redirects to login: `TypeError: Cannot read properties of undefined (reading 'length')` at `processResult` → `retrieveByXPath`. Pluggable Gallery/DataGrid2 database sources are fine | The serialized `Forms$ListViewXPathSource` omitted the arrays the client reads `.length` of. **Codec (default):** `Forms$ListViewSearch` emitted without its `SearchRefs` list — the encoder drops an empty, never-`Set` PartList unless the `$Type` is in `RegisterTypeDefaults` (GridSortBar.SortItems was registered; ListViewSearch was not). **Legacy:** wrote a bogus `Forms$ListViewSort` + a `Paths` key (renamed `SearchRefs` in 7.11.0) and no `Forms$GridSortBar`. NOT a `SortItems` marker issue — an empty `[2]` compiles fine when search is off; the crash is the absent `SearchRefs`. Diagnose by building a Deploy target and reading the compiled `deployment/web/pages/<Page>.js` (the client model) + `mxcli bson dump --type page` on the source | `mdl/backend/modelsdk/widget_write.go` (`init` RegisterTypeDefaults) + `sdk/mpr/writer_widgets_display.go` (`serializeListViewDataSource`, `emptyListViewXPathSource`) | Codec: `RegisterTypeDefaults("Forms$ListViewSearch", {MandatoryLists: []string{"SearchRefs"}})` (emits empty marker-3 list). Legacy: emit `Forms$GridSortBar`/`SortItems` (mirror `SerializeCustomWidgetDataSource`) + `Forms$ListViewSearch`/`SearchRefs` + `ForceFullObjects`; drop the bogus `Sort`/`Paths`. Tests: `TestListViewSourceToGen_SearchRefsEmitted` (codec, encode-level), `TestSerializeListViewDataSource_Database` + `TestEmptyListViewXPathSource_Shape` (legacy). Repro `mdl-examples/bug-tests/listview-database-source-searchrefs.mdl` |
-| Editing `themesource/**/main.scss` (or `theme/web/main.scss`) while `mxcli run --local` serves on `:8080` keeps showing **old styles** — reads exactly like a stale compiled-CSS cache. `rm -rf theme-cache/ .mendix-cache/ deployment/` "fixes" it only because a restart came with it | THREE distinct causes, none a CSS cache: (1) **no `--watch` = no watcher at all** — `mxbuild --serve` only rebuilds on a `/build` request (startup, or a watch tick), so a save changes nothing; (2) **stale process silently adopted** — a leftover serve/runtime on the ports answers the startup readiness probes (`waitReady`/`waitAdminReady` only check "port answers"), so a new run attaches to the OLD process and its own child is torn down by `defer`; a backgrounded `run --local` whose wrapping shell exited non-zero dies while its serve+runtime keep serving; (3) the theme source was **watched by nothing** — the `--watch` signal was model-only (`.mpr`+`mprcontents/`). The incremental theme step itself is FINE: one `/build` after an scss **content** edit does rewrite `theme-cache/web/theme.compiled.css` (verified), so there is no cache to clear | `cmd/mxcli/docker/runlocal.go` — `checkTargetPortsFree` (guard), `themeSourceMTime`/`sourceMTime` (watch signal), `watchAndApply` (generation log) | (2) Refuse to boot when `:8080/:8090/:6543` already answer, with an actionable message (never auto-kill — user's call). (3) Add `theme/`+`themesource/` scss/css/js to the `--watch` mtime-poll signal (`sourceMTime` = max(model, theme)); poll-based so it's container-safe (unlike the rollup chokidar/inotify web-client watcher). Log a build-generation counter (`build #2`) so "did it take?" is answerable. Docs: `docs-site/src/tools/run-local.md` + skill `run-local.md` — "SCSS needs a rebuild (`--watch` or clean restart), never a cache-clear; kill the old serve/runtime first". Tests `TestThemeSourceMTime_WatchesThemeAndThemesource`, `TestCheckTargetPortsFree` |
-| Re-running a domain script that is 90% already-applied applies **none** of the remaining 10%: `alter entity … add attribute X` errors `attribute 'X' already exists` and, because `exec` halts on the first error, everything after it is skipped. No idempotent add/drop and no continue-past-errors | Two gaps: (1) `ADD ATTRIBUTE` / `DROP ATTRIBUTE` had no `IF NOT EXISTS` / `IF EXISTS` guard, so a re-apply was a hard error; (2) `ExecuteProgram` returns on the first statement error | grammar `mdl/grammar/domains/MDLDomainModel.g4` (`ifNotExists`/`ifExists`, `alterEntityAction`) + AST `mdl/ast/ast_entity.go` (`IfNotExists`/`IfExists`) + visitor `mdl/visitor/visitor_entity.go` (`ExitAlterEntityAction`) + executor `mdl/executor/cmd_entities.go` (add/drop guards) + `mdl/executor/executor.go` (`ExecuteProgramContinueOnError`) + `cmd/mxcli/cmd_exec.go` (`--continue-on-error`) | Add `IF NOT EXISTS`/`IF EXISTS` to the grammar (regen), carry the flag on the AST, and in the executor turn the already-exists / not-found error into a skip-with-notice when the guard is set. Separately add `mxcli exec --continue-on-error`: attempts every statement, prints each failure as `statement N: …`, exits non-zero if any failed (never masks a real error; `exit`/`quit` still stop the run). Bug-test `mdl-examples/bug-tests/f10-idempotent-alter-entity.mdl`. Findings #10 |
-| `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) | 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 | `mdl/executor/cmd_enumerations.go` (`ValidateAlterEntity`, `validateEntityAttribute`) wired from `cmd/mxcli/cmd_check.go` + `cmd/mxcli/lsp_diagnostics.go` | 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) |
-| `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 | `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" | `mdl/executor/cmd_entities.go` (`droppedEntityMembers`, the warn block before `UpdateEntity`, and the `execCreateEntity` already-exists message) | 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 |
-| A microflow expression calls a function that doesn't exist (e.g. `randomInt(9)` — in some docs but not a Mendix built-in): parses, passes `mxcli check`, then fails the build with CE0117 "Error(s) in expression". Also: a Decimal-returning function (`random()`, `secondsBetween`, the duration `*Between` family) assigned to an Integer/Long variable fails CE0117, but `mxcli check` only caught bare `div` | (1) The func checker only validated arity for *known* functions; an unknown call name was ignored. (2) `checkNumericAssignment` used `SourceIsArithmeticDecimal`, which fires only on arithmetic roots, so a Decimal *function* result slipped through. Also the `*Between` duration funcs were mistyped Integer in `funcTable` | `mdl/exprcheck/unknown_funcs.go` (`UnknownFunctionCalls`, `SourceRejectedForIntegerTarget`, `nearestFunc`) + `mdl/exprcheck/func_checker.go` (`funcTable` between-date return kinds) + `mdl/executor/validate_microflow.go` (`checkExprFunctions` → MDL044; `checkNumericAssignment` now uses `SourceRejectedForIntegerTarget`) | Walk each expression for `CallExpr` names not in `funcTable` (which lists *every* built-in — a bare `name(...)` is always a built-in call) → **MDL044** with a Levenshtein/prefix "did you mean" hint. Extend the Decimal-into-Integer check to Decimal-returning non-rounding functions → **MDL041**. Correct `secondsBetween`/`minutesBetween`/`hoursBetween`/`daysBetween`/`weeksBetween` to Decimal (calendar variants stay Integer, millisecondsBetween stays Long). When adding a new Mendix built-in, add it to `funcTable` or MDL044 will false-positive. Bug-tests `f1-unknown-expression-function.fail.mdl`, `f2-decimal-func-into-integer.fail.mdl`. Findings #1, #2 |
-| `index name on (cols)` inside `create entity` (or `alter entity add index name on (cols)`) fails with `extraneous input 'on' expecting '('` — the SQL-like form docs/users expect. The bare `index name (cols)` worked | `indexDefinition` had no `ON` token: `IDENTIFIER? LPAREN indexAttributeList RPAREN` | `mdl/grammar/domains/MDLDomainModel.g4` (`indexDefinition`) | Make `ON` optional: `IDENTIFIER? ON? LPAREN indexAttributeList RPAREN`, regen grammar. `buildIndex` reads columns from `IndexAttributeList` only, so ON can't be mistaken for a column and no visitor change is needed. Covers both CREATE (entityOption) and ALTER ADD INDEX (shared rule). Bug-test `mdl-examples/bug-tests/f4-entity-index-on.mdl`. Findings #4 |
-| `retrieve … where [Seq = $Game/MoveSeq + 1]` fails with a bare `mismatched input '+' expecting ']'` — no hint that Mendix XPath can't compute values (this is a Mendix limitation, not an mxcli bug) | Mendix XPath constraints take a literal/token/variable/path on the value side, never an arithmetic expression; the parse error named the token but not the cause | `mdl/visitor/visitor.go` (`enhanceErrorMessage`, `looksLikeXPathArithmetic`/`xpathArithmeticRe`) | Do NOT add grammar support (mxbuild would still reject the XPath). Add an error hint keyed on `mismatched input '<+|*|div|mod>' expecting ']'` (`expecting ']'` only occurs inside a `[…]` constraint) explaining the limitation and the workaround: compute into a variable first, then compare. Also documented in `xpath-constraints.md`. Bug-test `mdl-examples/bug-tests/f8-xpath-arithmetic.fail.mdl`. Findings #8 |
-| 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 | 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 | `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`) | 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` |
-| 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` | `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 | `mdl/executor/cmd_pages_builder_v3.go` (`resolveDesignPropertyValueType`, now takes the value and reuses `themeOptionAllowed`) | 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 |
-| The **nightly** matrix (Mendix 10.24 / 11.6 / 11.12) fails only on **10.24**: `TestMxCheck_DoctypeScripts/15c-fragment-bindings-examples` → `Execution error: failed to build page: building block not found: Atlas_Web_Content.List_Cards` (both engines). 11.6/11.12 pass; unit tests + push-test (single-version) pass. Looks like a "design property on 10.24" issue but isn't | `15c` demonstrates `use building block Atlas_Web_Content.List_Cards`, an Atlas UI building block that ships in **11.x but is absent from the 10.x Atlas** (the example comment wrongly said "present in every standard Mendix app"). The example had **no `-- @version:` gate**, so on a 10.24 project the whole file ran and mxbuild couldn't resolve the block. (12-styling gates its design-property section at line 186; 31 gates the whole file at line 1 — both already skip on 10.24) | `mdl-examples/doctype-tests/15c-fragment-bindings-examples.mdl` | Add `-- @version: 11.0+` immediately before the `create page … P002_Rebound_Block` block (its last statement) so `filterByVersion` skips only the building-block demo on 10.x; the fragment-binding statements above stay ungated and keep 10.24 coverage. Verified: 15c passes on **10.24** (10 lines skipped, 0 errors) and still runs+passes the section on **11.6.3** (0 errors). **Diagnosis pattern**: a nightly-only, version-specific doctype failure = an example using a construct (building block, widget, syntax) that doesn't exist in the oldest matrix version and lacks a `-- @version:` gate; reproduce locally with `MX_BINARY=~/.mxcli/mxbuild/<ver>/modeler/mx go test -tags integration -run TestMxCheck_DoctypeScripts/<file>` |
-| Same nightly pattern, **CE6083** this time: `TestMxCheck_DoctypeScripts/15b-fragment-slots-examples` fails only on **10.24** (both engines) — `[CE6083] "Design property Card style is not supported by your theme"` at every `cardWrap` container. `Card style` is an **Atlas v3 design property (11.x); the 10.x Atlas theme doesn't define it** | The shared `define fragment Card` used `designproperties: ['Card style': on]` and is instantiated by every page in the file, so a `-- @version:` gate would have to gate the whole file (killing 10.24 coverage of the slot feature the example is actually about). Unlike 15c's building block, the design property was **incidental** to the example | `mdl-examples/doctype-tests/15b-fragment-slots-examples.mdl` | **Drop the incidental v3 design property**, keep `class: 'card'` (Atlas card styling works on every version) — the example demonstrates content *slots*, not design properties (those live in 12-styling, gated 11.0+). Verified: 15b passes on 10.24 **and** 11.6.3 (0 errors, both engines). **Gate vs remove rule**: if the version-specific construct IS the point of a self-contained section → `-- @version:` gate it (15c); if it's incidental and in a shared/expanded definition → remove it and use a cross-version equivalent (15b). **Proactive sweep** after any such fix: `grep -lE 'designproperties|use building block' mdl-examples/doctype-tests/*.mdl` and confirm each usage is either gated or version-safe (note the doctype test skips `*.test.mdl`/`*.tests.mdl`) |
-| `mxcli run --local`: when a page action throws, the browser shows the generic Mendix error dialog and there is nothing to correlate it against — the runtime's own stdout/stderr (server stack trace, microflow `LOG` output) is swallowed, so a server-side bug can't be told apart from a client one | The runtime JVM was spawned with `cmd.Stdout=log; cmd.Stderr=log` where `log` is an in-memory `syncBuffer` surfaced only on a *startup* failure; during normal operation it goes nowhere on disk | `cmd/mxcli/docker/localboot.go` (`spawnAndConfigure`, `openRuntimeLog`, `LocalRuntime.logFile`, `LocalRuntimeOptions.RuntimeLogPath`) + `cmd/mxcli/docker/runlocal.go` (default `<projectDir>/.mxcli/runtime.log`) + `cmd/mxcli/cmd_run.go` (`--runtime-log`) | Tee the JVM's stdout+stderr to `<projectDir>/.mxcli/runtime.log` via `io.MultiWriter(log, file)` (the in-memory buffer still backs startup-error reporting). Append across restarts with a `=== runtime start … ===` marker; close the handle on Stop/reopen. Default on; `--runtime-log <path>` relocates, `-` disables. Print the path at boot. Test `TestOpenRuntimeLog`. Findings #25 |
-| Follow-up to the above (#25 re-test): `run --local` writes `runtime.log` but it stays **nearly empty** — the JVM tee captures startup/JVM output only; **application** logs (microflow `LOG`, server-side exception stack traces) never reach stdout, so a page-action error still can't be diagnosed | A standalone runtime (launched via `runtimelauncher.jar`) attaches **no log subscriber** by default — unlike a Studio Pro / m2ee run, which calls `create_log_subscriber` **after** start. Mendix application logs flow to log *subscribers*, not stdout, so with none attached they go nowhere | `cmd/mxcli/docker/runtime_controller.go` (`RuntimeController.LogSubscriberFile`/`Stdout`, `attachFileLogSubscriber`, called at the end of `Start`) + `cmd/mxcli/docker/localboot.go` (`StartLocalRuntime` sets `ctrl.LogSubscriberFile` to the abs runtime-log path) | After a successful `start` (and on every restart's `Start`, since each fresh JVM has no subscriber), call the `create_log_subscriber` admin action with `{type:"file", name:"mxcli-run-local", autosubscribe:"INFO", filename:<abs runtime.log>, max_size:1GiB, max_rotate:0}`. **`max_rotate:0` is load-bearing**: the JVM stdout tee holds an fd on the same file, and a rotate-rename would detach it. Best-effort (a logging failure must not fail an up runtime — warn to Stdout instead). Pass an **absolute** path (the runtime's cwd is `<install>/runtime`, not mxcli's). Tests `TestStart_AttachesLogSubscriber`, `TestStart_NoLogSubscriberWhenUnset`, `TestStart_LogSubscriberFailureNonFatal`. Findings #25 (round 2) |
-| `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 | `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 | `mdl/executor/cmd_entities.go` (`execCreateEntity`) | 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 |
-| `alter page P { set class = 'x' on <builtin> }` (lowercase property) hard-errors on EVERY built-in widget: `property "class" not found (widget has no pluggable Object)` — but `create page` accepts the same lowercase prop, and these aren't pluggable widgets | The MPR page mutator dispatched first-class props via a case-SENSITIVE switch on canonical casing ("Class"/"Caption"/"DynamicClasses"); a lowercase name missed every case and fell through to the pluggable-Object path. `create page` was fine (WidgetV3.GetStringProp is case-insensitive); the sibling MCP mutator already lowercased | `mdl/backend/pagemutator/mutator.go` (`setRawWidgetPropertyMut`) | `switch strings.ToLower(propName)` with lowercase case labels; keep the pluggable fallback (default) on the original casing (template keys are case-sensitive). Test `TestSetWidgetProperty_LowercaseFirstClassProps`; repro `mdl-examples/bug-tests/alter-page-lowercase-set-on-builtin.mdl`. Findings #1 |
-| `call javascript action` (e.g. NanoflowCommons.OpenURL) passes `check --references` + `exec` but persists as `-- Empty action`; `mx check` fails CE0008 "No action defined." + CE0109 on the output variable. Affects microflows AND nanoflows | The default `modelsdk` engine's `microflowActionToGen` had no case for `*microflows.JavaScriptActionCallAction` → returned nil → ActionActivity written with no Action. Read path + legacy engine both handled it (hence check/exec looked green); nanoflows reuse the same converter | `mdl/backend/modelsdk/microflow_write.go` (`microflowActionToGen`) | Add the `JavaScriptActionCallAction` case, built directly to mirror the legacy serializer (storage keys JavaScriptAction/OutputVariableName; JS parameter mappings use the `ParameterValue` key, not the Java-style `Value`). Test `TestMicroflowActionToGen_JavaScriptActionCall`; repro `mdl-examples/bug-tests/javascript-action-call-persist.mdl`. Findings #11 |
-| 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 | 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 | `mdl/executor/validate_widgets.go` (`validateWidgetExpressionAssociations`, called from `validateStaticWidget`) | 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 |
-| 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) | Message-only defects in the linter | `mdl/executor/validate_microflow.go` (MDL001 message ~216; `checkExprFunctions` ~283; `mendixAggregateFuncs`) | 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 |
-| 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" | 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 | `mdl/executor/cmd_microflows_builder_validate.go` (`validateOutputVariable`, `validateScopedStatements`) | 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) |
-| `textbox` silently drops `placeholder` and `onchange` (MDL-WIDGET07 warns "unrecognized property … dropped"); after `create page` + `DESCRIBE`, both are gone — the live-search box degrades to a button, the field loses its hint text | The `pages.TextBox` model already had `Placeholder`/`OnChangeAction` fields, and the modelsdk (default) engine's `widgetToGen` already serialized them — but (a) the grammar had no `onchange:`/`placeholder:` property, (b) `buildTextBoxV3` never populated the model, (c) the legacy `serializeTextBox` hardcoded empty, (d) they weren't in `staticWidgetKnownProps` | grammar `mdl/grammar/domains/MDLPage.g4` (`widgetPropertyV3`); visitor `mdl/visitor/visitor_page_v3.go`; `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildTextBoxV3`); `sdk/mpr/writer_widgets_input.go` (`serializeTextBox`) + `writer_widgets.go` (`serializePlaceholderTemplate`); `validate_widgets.go` known-props | Add `ONCHANGE COLON actionExprV3` + `PLACEHOLDER COLON STRING_LITERAL` (tokens already existed); visitor → `Properties["OnChange"]`/`["Placeholder"]`; `GetOnChange()`/`GetPlaceholder()` accessors; builder sets `tb.Placeholder` (a `*model.Text`) + `tb.OnChangeAction` (via `buildClientActionV3`, reusing the button path); legacy serializer emits `serializePlaceholderTemplate(tb.Placeholder)` + `serializeClientAction(tb.OnChangeAction)`; add `OnChange`/`Placeholder` to `staticWidgetKnownProps`. Tests `TestSerializeTextBox_PlaceholderAndOnChange`; repro `mdl-examples/bug-tests/textbox-placeholder-onchange.mdl`. Finding #9 |
-| `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` | 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 | `mdl/executor/validate.go` (`flowRefCollector` → `codeActionCallRef`, `validateCodeActionParams`) | 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 |
-| `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 | The describe read path (`parseRawWidget`) only read `LabelTemplate` + `AttributeRef` for a textbox; `PlaceholderTemplate` and `OnChangeAction` were never read back into `rawWidget` | `mdl/executor/cmd_pages_describe_parse.go` (`extractPlaceholderText`), `cmd_pages_describe.go` (`rawWidget` fields), `cmd_pages_describe_output.go` (`renderClientActionMDL`/`extractOnChangeAction` + TextBox emit) | 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) |
-| `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) | 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 | `mdl/executor/cmd_pages_describe_output.go` (`unwrapToStringAttrParam` in `extractClientTemplateParameters`) | 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 |
-| 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 |
-| 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 | No check inspected date-construction arguments; the function name resolves so the unknown-function check (MDL044) is silent | `mdl/executor/validate_microflow.go` (`checkDateTimeLiterals`/`exprHasNonLiteralDateTime`, MDL046) | 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 |
-| 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 | No check inspected constraint strings for an association compared to `empty`; a bare attribute `= empty` IS valid, so a blanket ban would false-positive | `mdl/executor/validate_microflow.go` (`checkXPathAssociationEmpty`/`xpathAssocEmptyRe`, MDL047) | 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 |
-| Two sibling `dynamictext` widgets in a container render as `€ 310Last import: 7/24/2026` — concatenated with no separator, regardless of each one's RenderMode | 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 | `mdl/executor/validate_widgets.go` (`validateConsecutiveDynamicText`, called from `validateWidgetTreeIn`) | 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 |
-| `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 | 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 | `mdl/executor/validate.go` (CreateAssociationStmt case) + `mdl/executor/cmd_entities.go` (`isViewEntity`) | 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 |
-| 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 ()`) | 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 | `mdl/executor/cmd_entities.go` (`reconcileDroppedIndexes`, before `UpdateEntity`) + `mdl/backend/modelsdk/domainmodel_alter.go` (`UpdateEntity` empty-index dirtying) | (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 |
-| `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 | No check inspected retrieve constraints for an id comparison; `id` is a reserved member so it resolves loosely | `mdl/executor/validate_microflow.go` (`checkXPathIdConstraint`/`xpathIdConstraintRe`, MDL048) | 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 |
-| 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 | 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 | `mdl/executor/validate_microflow.go` (`checkAssociationObjectArgs`/`exprIsAssociationObjectPath`, MDL049; wired for CallMicroflowStmt + CallNanoflowStmt) | 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 |
-| ~~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 | 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 | `mdl/executor/validate_microflow.go` (removed `checkFormatWithAssociation`/`exprHasRenderFunc`/`exprHasAssociationNav`/`renderFuncsIncompatibleWithAssoc`) | 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) |
-| **Attribute-over-association navigation in a microflow EXPRESSION** (`$T/Mod.Assoc/Attr` in a Change Variable / if-condition / return) passes `mxcli check` but `mx check` fails with **CE0117** "Error(s) in expression". Trips hardest when the module or entity name ends in a digit (`L48.`, `Account2.`) or when a decimal literal co-occurs (`$T/Mod.Assoc/Bal + 2.0`). Studio Pro supports this pattern | Mendix expression syntax needs the **target-entity step** in the path (`$T/Mod.Assoc/Mod.Entity/Attr`); the builder inserts it via `resolveAssociationPaths`→`resolvePathSegments`. Two bugs skipped that insertion: (1) `shouldPreserveExpressionSource` treated a `.` **preceded by a digit** as a decimal literal, so a name segment ending in a digit froze the whole expression's source and bypassed resolution (source is written verbatim); (2) a **legitimately** source-frozen expression (real decimal / whitespace) also bypassed resolution, so association nav + decimal in one expression broke even for non-digit modules | `mdl/visitor/visitor_microflow_statements.go` (`shouldPreserveExpressionSource` + `dotIsQualifiedNameSeparator`/`isIdentByte`); `mdl/executor/cmd_microflows_builder.go` (`resolveAssociationPaths` SourceExpr arm + `collectAttributePaths`) | (1) A `.` is a decimal point only when its adjacent digit run is a standalone number — NOT when the preceding token contains a letter/underscore (a qualified-name segment). `dotIsQualifiedNameSeparator` walks back over ident chars; a letter/`_` means name, not decimal. (2) For a source-preserved `SourceExpr`, still rewrite association paths **inside the raw source**: for each `AttributePathExpr`, `expressionToString(orig)` vs `expressionToString(resolve(orig))`; if they differ, `strings.ReplaceAll` in the source. Keeps decimal/whitespace fidelity AND inserts the entity step. Tests: `TestShouldPreserveExpressionSource_Decimals` (digit-module cases); example `mdl-examples/bug-tests/ledger-48-assoc-nav-digit-module.mdl`. **Verified: `mx check` → 0 errors on 11.12.1** for plain nav, if-then-else enum compare, and decimal-mixed. **Lesson: a heuristic that keys on a single character (`.`→decimal) collides with other grammar (qualified names); and "preserve source" and "resolve semantics" are in tension — a frozen source still needs its association paths fixed.** Ledger finding #48 (root cause) |
-| 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 | 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 | `mdl/executor/widget_defs.go` (`GenerateDefJSON` `case "action"` + `actionSourceForKey`); `mdl/executor/widget_engine.go` (`resolveMapping` `case "OnChange"`; `WidgetDefGeneratorVersion` bump 12→13) | 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) |
-| **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) | 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 | `mdl/executor/widget_defs.go` (`GenerateDefJSON` — populate `KnownProperties`); `WidgetDefGeneratorVersion` bump 13→14 | 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) |
-| **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 | 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 | `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) | 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) |
-| 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 | 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 | `mdl/executor/validate_microflow.go` (`checkDuplicateLoopVariables`, MDL052) | 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 |
-| 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 | 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 | `mdl/executor/validate_microflow.go` (`loopBodyHasConditionalBreak`/`stmtsContainBreak`, MDL051) — **interim check**, pending the serialization fix | 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 |
-| `set $Match = contains($Hay, $Needle)` over two **String** values was serialized as a **List operation** activity 'Contains', so string `contains(haystack, needle)` was unusable: a pre-declared Boolean `$Match` collided (**CE0111** "Duplicate variable name"), and a String input to a list op is otherwise rejected (CE0023/CE0097). `contains` in an IF condition worked (stayed an expression) | `contains` is overloaded — a LIST operation `contains(list, object)` **and** a STRING function `contains(haystack, needle)` — but the visitor unconditionally rewrote `set $x = contains(...)` into a `ListOperationStmt`, **dropping literal arguments** (`extractVariableName` returns "" for a literal). A list operation CREATES its output variable; the string function assigns to a pre-declared one | `mdl/visitor/visitor_microflow_statements.go` (`buildSetStatement` CONTAINS case + `isPlainVariableArg`) + `mdl/executor/cmd_microflows_builder_actions.go` (`addListOperationAction`) + `mdl/executor/cmd_microflows_builder_validate.go` (ListOperationStmt case) | **Write-path fix, two parts.** (1) Visitor: a literal/computed argument means the string function unambiguously → fall through to `MfSetStmt` (a Change Variable value expression); both-plain-variables stays a `ListOperationStmt` (ambiguous, kind unknown at parse). (2) Flow builder: when `declaredVars[InputVariable] == "String"`, emit a **Change Variable** action carrying `contains($In, $Second)` instead of a `ContainsOperation`; the validate pre-pass mirrors this (validate the target IS declared, don't flag CE0111 duplicate). Genuine list form (list var + object var) unchanged. Tests `TestContainsOverloadParsing` (visitor), `TestBuildContains_StringVsList` (builder); example `mdl-examples/bug-tests/ledger-53-string-contains.mdl`. **Verified: `mx check` → 0 errors on 11.12.1** for literal-arg, two-String-var, and genuine-list forms. Ledger finding #53 |
-| `set $At = find($Raw, '"id":"')` — the STRING function `find(haystack, needle)` (substring index) — was serialized as a List operation activity 'Find by expression', so a pre-declared `$At` collided (**CE0111** "Duplicate variable name 'At'"). String `find()` was unusable. Same overload trap as #53 (contains) | `find` is overloaded — the LIST operation `find(list, condition)` (filter by a boolean condition) and the STRING function `find(haystack, needle)` → index — but the visitor unconditionally rewrote `set $x = find(...)` into a `ListOperationStmt` (list find), and a list op CREATES its output variable | `mdl/visitor/visitor_microflow_statements.go` (`buildSetStatement` FIND case + `isStringLiteralArg`) + `mdl/executor/cmd_microflows_builder_actions.go` (`addListOperationAction`) + `mdl/executor/cmd_microflows_builder_validate.go` (ListOperationStmt case) | **Write-path fix, mirrors #53.** (1) Visitor: a **string-literal** second argument (you never filter a list by a bare string literal) means the string function → fall through to `MfSetStmt`; a boolean condition or both-plain-variables stays a `ListOperationStmt`. (2) Flow builder + validate pre-pass: when `declaredVars[InputVariable] == "String"`, emit a **Change Variable** carrying `find($in, <arg1>)` (arg1 is stored in the stmt's `Condition`) instead of a list FindOperation, and validate the target as a pre-declared SET (no CE0111). The contains and find String-input handling now share one branch. Tests `TestFindOverloadParsing` (visitor), `TestBuildContains_StringVsList` find cases (builder); example `mdl-examples/bug-tests/ledger-63-string-find.mdl`. **Verified: `mx check` → 0 errors on 11.12.1** for literal-arg, two-String-var, and genuine-list-condition forms. Ledger finding #63 |
-| 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 | 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`) | `mdl/executor/widget_engine.go` (`applyColumnHeaderFallback`) | **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) |
-| Follow-up to round 2 (#25 re-test): the subscriber is registered but `runtime.log` **still** holds only the 4 JVM-banner lines — a probe microflow's `log info/warning/error` and a forced runtime exception produce **zero** lines. Isolation test: boot+subscriber → 0 probe lines; then call `start_logging` → 6 lines | A standalone runtime boots with logging **not started**, so a registered subscriber sits **inert** — nothing is delivered until the logging subsystem is activated. `create_log_subscriber` alone is necessary but not sufficient | `cmd/mxcli/docker/runtime_controller.go` (`configureRuntimeLogging` — renamed from `attachFileLogSubscriber`; now also calls `start_logging`) | After `create_log_subscriber`, call `CallM2EE(c.opts, "start_logging", nil)` in the same step (order: create subscriber → start_logging). Treat an "already started" response as success (`start` re-runs on the DB-update retry / restart paths on a still-running JVM). Still best-effort (warn to Stdout, never fail an up runtime). Test `TestStart_StartLoggingAlreadyStartedIsSuccess`; `TestStart_AttachesLogSubscriber` now asserts the `[start, create_log_subscriber, start_logging]` sequence. **Diagnosis pattern**: when a registered sink receives nothing, check whether the subsystem that feeds it is even *running* — registration ≠ activation. Findings #25 (round 3) |
-| `mxcli new --version X` prints "Resolving MxBuild X..." and then produces a project at a **different** Mendix version — silently. Every later step (init, mxbuild, runtime, `run --local`) follows the wrong version | `ResolveMxForNewProject` delegated to `ResolveMxForVersion`, whose last resort is `AnyCachedMxPath()` — *any* cached mx, of any version. That fallback is fine when the project already exists and its version is a preference; for `new` the requested version **is** the output, because `mx create-project` stamps the project with the version of the binary that ran it | `cmd/mxcli/docker/check.go` (`localMxForVersion`, `ResolveMxForNewProject`) + `cmd/mxcli/cmd_new.go` (postcondition) | Resolve **exactly** the requested version for `new` (exact Studio Pro install → exact versioned install path → exact download cache; **not** PATH, which carries no version guarantee), and download otherwise. Then check the postcondition: reopen the created `.mpr`, compare `ProductVersion` to `--version`, and fail loudly on a mismatch — resolution bugs are invisible without it. **Generalisable**: when a flag names the version/identity of the artifact being produced, a "close enough" local substitute is never valid, and the produced artifact should be verified against the request rather than the resolution trusted. Found while reproducing #812 in a browser — cost a full project rebuild before it was noticed |
-| A **DataView** property parses, passes `mxcli check`, and has no effect — `FormOrientation: Vertical` (#762) or `showFooter: true` (#813). `FormOrientation` works under `--engine legacy` | Two different causes that look identical. (a) `FormOrientation` has no BSON field: Studio Pro's radio **is** `LabelWidth` (0=Vertical, 3=Horizontal default). Only the legacy writer translated it; the modelsdk writer emitted `LabelWidth` solely when set explicitly, so the orientation was read into the model and dropped — the #812 shape, a model field no active-engine writer reads. (b) `ShowFooter` was only ever set implicitly by a `footer { … }` block; the property sat in the validator allow-list, so it parsed and was discarded | `sdk/pages/pages_widgets_data.go` (`ResolvedLabelWidth`), `mdl/backend/modelsdk/widget_write.go`, `sdk/mpr/writer_widgets_display.go`, `mdl/executor/cmd_pages_builder_v3_widgets.go` | Put the derivation **on the model** (`ResolvedLabelWidth`) so both writers share one definition instead of one owning it, and emit `LabelWidth` unconditionally. For the property, read it explicitly and let it win over the implicit block in both directions. **Trap**: `WidgetV3.GetBoolProp` is case-SENSITIVE and accepts only a real `bool`, unlike `GetStringProp` — so `showFooter: true` read as `false` even after the key was found. Coerce from the looked-up value and refuse a nonsense one instead of defaulting to false. Repro `mdl-examples/bug-tests/762-813-dataview-properties.mdl`. Issues #762, #813 |
-| Every mxcli-authored page carries a container nobody asked for — a `Forms$DivContainer` named `conditionalVisibilityWidget<N>` wrapping the page's top-level widgets. Creating a single button yields a button **and** a container | The builder wrapped each non-empty layout placeholder, because `pages.LayoutCallArgument` declared a **single** `Widget` field while the BSON `Forms$FormCallArgument` carries a **`Widgets` array**. The wrapper existed only to squeeze N widgets through a 1-widget field — never a BSON requirement | `sdk/pages/pages_parameters.go` (`LayoutCallArgument.Widgets`), `mdl/executor/cmd_pages_builder_v3.go`, `sdk/mpr/writer_pages.go`, `mdl/backend/modelsdk/page_write.go`, `mdl/backend/mcp/page.go` | Make the field a list and place widgets directly. **Check the claim against Mendix's own output before believing a comment**: ours said the wrapper is what "mxcli (and Studio Pro) adds", but `Administration.Account_Overview` in a `mx create-project` app has *two* top-level widgets in one placeholder and zero wrappers — same reasoned-by-analogy error as #812/#295. Corroborating signal that a construct is wrong: DESCRIBE already unwrapped it as a "phantom CONTAINER" and the catalog skipped it as "transparent" — three places working around something that should not be created. **Keep those readers**: projects authored before the fix still contain wrappers. Repro `mdl-examples/bug-tests/760-no-placeholder-wrapper.mdl`. Issue #760 |
-| `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 | 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 | `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` | 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 |
-| Any `ALTER SETTINGS` / `CREATE CONFIGURATION` corrupts a **private** constant override: the stored `Settings$PrivateValue` comes back carrying `"Value": ""`. Studio Pro then throws `System.InvalidOperationException: Sequence contains no matching element` at `MprProperty.cs:25` on open. `describe settings` separately renders the override as `value ''`, so replaying describe's own output converts it to a *shared* empty override | A constant override's value is either a `Settings$SharedValue` (carries `Value`, lives in the shared model) or a `Settings$PrivateValue` — a **marker type with no properties at all**, meaning the value is on the developer's workstation and deliberately out of version control. The overlay assumed SharedValue and wrote `cv.Value` (always `""` for a private override) into whichever node it found; the read type-asserted to `*SharedValue`, failed, and returned `""` with no way to distinguish private from empty | `mdl/settingsoverlay/settingsoverlay.go` (`constantValue`, `PrivateValueType`), `mdl/backend/modelsdk/settings_read.go` (`isPrivateConstantValue`), `sdk/mpr/parser_settings.go` (`parseConstantValue`), `mdl/executor/cmd_settings.go` (`describeSettings`, `alterSettingsConstant`) | Carry the distinction in the model (`model.ConstantValue.IsPrivate`) and **preserve, never author**: leave a PrivateValue node byte-identical, have `describe` emit a comment instead of a re-executable statement, and refuse an `alter settings constant` that would flip private→shared (drop is still allowed — it discards the whole override, which is what was asked). **Generalisable**: a polymorphic child whose variants differ in *arity* (one carries a value, one is a bare marker) cannot be overlaid by field assignment — branch on `$Type` first. Blast radius is wider than it looks: configurations are shared in version control, so one developer's unrelated edit corrupts every developer's private overrides and pushes the result. Found from a user describing their workflow, not from a filed issue |
+## Finding a prior fix
+
+The findings live in `findings/*.jsonl`, one JSON object per line, sharded by
+area. They are **data, not reading material**: 630 findings at ~1.7 KB each do
+not fit in a context window, and the table they used to live in had grown past
+the point where GitHub's web editor would open it.
+
+Grep is the fast path — the shard name narrows it, and every line is
+self-contained:
+
+```bash
+grep -il 'CE0463' .claude/skills/fix-issue/findings/*.jsonl        # which areas
+grep -h  'CE0463' .claude/skills/fix-issue/findings/mdl-executor.jsonl | jq .
+```
+
+For anything with a shape to it, the records have fields — `area`, `symptom`,
+`cause`, `file`, `insight`, plus `refs` / `ce` / `rules` where the text carried
+them — and DuckDB reads the files in place, no import step:
+
+```bash
+duckdb -c "select symptom, file from '.claude/skills/fix-issue/findings/*.jsonl'
+           where list_contains(ce, 'CE0463')"
+```
+
+A finding whose original row could not be split into four columns keeps its
+`raw` line instead; `symptom` and friends are then absent, so filter on `raw` as
+well when a query must cover everything.
+
+`docs-wiki/bug-patterns/` is the layer above this: the *classes* of failure,
+small enough to read. Start there, come here for the instance.
+
+## Recording a fix
+
+Append one line to the shard for the area you touched — a new shard is fine if
+none fits. Keep it one line: `merge=union` in `.gitattributes` resolves two
+concurrent appends by keeping both, which is correct for a file of independent
+records and is not correct for prose.
+
+```bash
+cat >> .claude/skills/fix-issue/findings/mdl-executor.jsonl <<'JSON'
+{"area":"mdl/executor","date":"2026-08-31","symptom":"...","cause":"...","file":"...","insight":"...","refs":["#123"]}
+JSON
+make check-findings
+```
+
+`check-findings` prints one line saying how far `docs-wiki/bug-patterns/` has
+fallen behind; `make digest-status` breaks it down by area. **If the class of
+failure keeps recurring, sync its pattern page** (`/mxcli-dev:wiki-sync
+bug-patterns/<page>.md`). Nothing else will ask: the digest is on demand, and
+every page in it was written on one day in May while the findings went on
+accumulating — 607 of the 631 arrived afterwards. Neither number is a target to
+drive to zero; they are there so the decision is made deliberately rather than
+by default.
+
+Write the **insight**, not the changelog: what would have made this cheaper to
+find, what measurement settled it, and which plausible-sounding wrong turn to
+skip. Position carries no meaning — these are looked up by matching a symptom,
+never read in order.
+
 
 ---
 
@@ -343,57 +160,6 @@ cases for these three BSON types — they fell to `default: return nil`.
 | A `create json structure … snippet` produces a structure whose **import mappings silently import zero objects** — the REST call succeeds, the mapping looks right, and no data arrives. No validation error, `mx check` passes. Dumping the stored BSON shows every element at `MinOccurs=0, MaxOccurs=0` | Mendix reads `MaxOccurs=0` **literally as "never occurs"**, not as "unspecified". The snippet→element builder hardcoded `0/0` at all nine construction sites; `cmd_import_mappings.go` then copies MinOccurs/MaxOccurs straight onto the mapping elements, so the dead bound propagates from the structure into every mapping bound to it | `mdl/types/json_utils.go` (`BuildJsonElementsFromSnippet` + `buildElementFromRawObject` / `buildElementFromRawRootArray` / `buildElementFromRawArray` / `buildValueElement`) | Derive occurrences from the JSON shape: root `1..1`, Object/Value `0..1`, Array `0..1` with its **item** child `0..*` (`MaxOccurs = -1`), primitive-array Wrapper `0..*`. Added the named constant `occursUnbounded` so `-1` is not a bare literal. **Generalisable — the shape to look for**: when a tree comes out uniformly wrong except for *one* node, that node proves the writer is capable of the correct value and localises the bug to the construction sites that hardcode it — here the nested object-array item was already `0..-1` while the root-array item beside it was `0..0`, i.e. the same construct written two ways in two builders. **Trap**: `0` looks like a harmless default for a numeric field, so this reads as correct in review and survives every checker; only a BSON dump or a runtime import reveals it. **Follow-up that the first cut missed**: Mendix cross-validates every *mapping* element's occurrence against its bound *schema* element and reports **CE5015** ("Attribute 'MaxOccurs' does not match schema element") on a mismatch. Import writers already propagated occurrences; all **three** export writers (`modelsdk/mpr/serialize_mappings.go`, `sdk/mpr/writer_export_mapping.go`, `mdl/backend/modelsdk/mapping_write.go` — the last is the one the default engine actually uses) hardcoded `MaxOccurs: 0` on value elements, so raising the schema broke every export mapping. **Generalisable — the shape to look for**: changing a value that another document is validated *against* is never a one-sided edit; grep every writer that emits the same key, and expect more than one engine to have its own copy. **Verification trap that caused the miss**: the repro created JSON structures but no mapping bound to one, so it passed `mx check` while the integration suite went red — when a fix changes a field that other documents reference, the repro must instantiate a *referencing* document, not just the changed one. Repro `mdl-examples/bug-tests/841-json-structure-occurrences.mdl` (now includes an import+export mapping); verified end-to-end (`mx check` 11.13.0 0 errors on the repro and on both doctype scripts that failed CI). Issue #841 |
 | A workflow **`DECISION`** whose expression uses the documented lowercase `$workflowContext` fails `mx check` with **`[error] [CE0117] "Error(s) in expression." at Decision 'Decision'`**, while the *same spelling* in a `CALL MICROFLOW … WITH` clause works. `mxcli check` and `mxcli exec` both report success | The context parameter is named `WorkflowContext` and Mendix expressions are case-sensitive on 11.9+, so `$workflowContext` is an undefined variable. `normalizeWorkflowContextExpr` existed and was well-tested, but was only *applied* in `autoBindCallMicroflow` (the FINDINGS #39 fix) — `buildExclusiveSplit` stored `n.Expression` verbatim. The working WITH clause is what disguised it: the user reasonably concludes the spelling is fine | `mdl/executor/cmd_workflows_write.go` (`buildExclusiveSplit`, and the sibling `buildWaitForTimer` whose delay may reference a context date attribute) | Run the authored expression through the existing `normalizeWorkflowContextExpr` at every site that accepts a user expression — there are three in the workflow writer, and only the parameter-mapping one was covered. **Generalisable — the shape to look for**: a *normalizer that exists and is unit-tested* is not evidence it is *called*; grep the call sites, not the helper. When one input spelling works and an identical one fails, compare the two code paths before questioning the data. **Also fix the docs that teach the broken form** — `.claude/skills/mendix/write-workflows.md` showed lowercase in its DECISION example and is synced into user projects by `mxcli init` via `cmd/mxcli/skills/`, so the bug propagated to every generated project. Repro `mdl-examples/bug-tests/845-workflow-decision-context-casing.mdl`; verified end-to-end (`mx check` 11.13.0: 1 error → 0). Issue #845 |
 
-| `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 | 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 | `mdl/executor/validate_grant_roles.go` (`ValidateGrantRoles`, MDL-GRANT01), `mdl/executor/cmd_security_defaults.go` (`validateCrossModuleGrant`), wired in `cmd/mxcli/cmd_check.go` | 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 |
-
-| `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 | `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" | `mdl/executor/cmd_microflows_show_helpers.go` (`formatErrorHandlingSuffix`) | 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 |
-
-
-| `mxcli check` **segfaults** (`SIGSEGV` in `visitor.(*Builder).ExitSqlDisconnect`) on the one-line script `SQL DISCONNECT source;` — which is the exact line in mxcli's own `mxcli syntax sql` example. Other aliases (`mydb`, `src`) are fine | Two defects. **Grammar**: every `sqlStatement` alternative took a bare `IDENTIFIER` for the alias/driver/table, but `source` lexes as `SOURCE_KW` (`MDLLexer.g4:317`), so no alternative matched. `IMPORT FROM identifierOrKeyword` in the same file already accepted a keyword alias, so `import from source …` worked while `sql source …` did not. **Robustness**: ANTLR error-recovers and still walks the tree, so the listener received a context whose `IDENTIFIER()` was nil and `.GetText()` crashed the process — sibling handlers guarded their children (`if len(ids) < 2 { return }`), this one did not | `mdl/grammar/domains/MDLSettings.g4` (`sqlStatement` → `identifierOrKeyword`), `mdl/visitor/visitor_sql.go` (`sqlWords` helper + guards at all five handlers) | Use `identifierOrKeyword` for every user-chosen word, and read children through a helper that tolerates a missing node. **Generalisable — the shape to look for**: a listener that dereferences `ctx.X()` without a nil check is a crash waiting for the first input that fails to parse *that rule* — ANTLR does not stop the walk on a syntax error. Grep for `ctx\.[A-Z][A-Za-z]*()\.GetText()` and treat each as unguarded. **Second shape**: when a bare `IDENTIFIER` names something a user picks (alias, table, column, prefix), it silently forbids every keyword; `identifierOrKeyword` is nearly always what was meant, and the inconsistency shows up as "works in one statement, not the neighbouring one". **Watch the index shift** when converting: the alias joins the `AllIdentifierOrKeyword()` list, so downstream `[0]`/`[1:]` offsets move (this bit `ExitSqlGenerateConnector`, where getting it wrong would generate a connector into a module named after the connection). **How it was found — and the trap it hid**: `TestExamplesParse` (new) feeds every `mxcli syntax` example through the parser; the panic **aborted the test binary**, masking ten further failures in entries sorted alphabetically after `sql`. A crash in a table-driven test is not one failure, it is an unknown number. Repro `mdl-examples/bug-tests/sql-keyword-alias-crash.mdl` |
-
-| `mxcli syntax <topic>` teaches MDL that does not parse — `Binds:` (removed in favour of `Attribute:`, and hard-rejected by the parser), workflow decision outcomes without the `->` arrow, `ALTER WORKFLOW … SET DUE DATE = '…'` (no `=`), `INSERT <activity> AFTER <name>` (operands reversed), `IMAGE 'name'` (identifier, not string), a `BEFORE` that does not exist. Nothing failed, because nothing checked | The registry (`cmd/mxcli/syntax/features_*.go`) is hand-maintained while the grammar moves underneath it, and every existing test checked *structure* — fields populated, aliases resolve, see-also targets exist — never whether the documented MDL is real. 26 of 120 entries had a non-parsing example | `cmd/mxcli/syntax/example_parses_test.go` (new guard), plus corrections across `features_page.go`, `features_workflow.go`, `features_integration.go`, `features_microflow.go`, `features_misc.go` | Parse every `Example` and fail the build if it does not. Examples come in several legitimate shapes, so each blank-line-separated **block** is tried as a statement, a microflow activity, a page widget, a workflow activity, and a retrieve clause — a failure means it parses as none of them. Only `Example` is checked; `Syntax` carries metasyntax (`[OR MODIFY]`, `<statements>`) by design. **Generalisable — the shape to look for**: documentation that is *data in the binary* can be executed against the real parser, which turns "the docs drifted" from a review problem into a test failure. The same trick applies to any embedded example corpus (skills, `--help` text, README snippets extracted at build time). **Why it matters more than it looks**: the registry is the first surface an agent consults, so a gap there does not read as "undocumented", it reads as "unsupported" — a contact-management app built with mxcli worked around three features that already existed, including replacing a `SAVE_CHANGES CLOSE_PAGE` button with a bespoke microflow because only the two halves were listed separately. **Close the opt-out** — a guard that skips empty input is a guard you can silence by emptying the field; `TestFeatureFieldsPopulated` already rejects a blank `Example`, and the new guard additionally fails an example that is all comments |
-| SCSS written to **`themesource/<name>/web/main.scss` never reaches the app** — no error, no warning, the build succeeds and the rules are simply absent from `theme-cache/web/theme.compiled.css`. Looks exactly like an SCSS cache problem, so the usual reflex (`rm -rf theme-cache/`) wastes the session | A theme source folder is only compiled when `<name>` matches a **real module in the model**. mxbuild walks the model's modules and pulls each one's `themesource/<lowercased module name>/web/main.scss`; it never globs the `themesource/` directory, so an invented folder (`themesource/my_theme/`) is silently skipped. Verified on 11.13: a probe rule in `themesource/myfirstmodule/` compiled, the identical rule in `themesource/mxcli_theme/` did not | `cmd/mxcli/theme/theme.go` (package doc records the compile order); the target paths live in `cmd/mxcli/theme/assets/<theme>/files/` | Put app-level styling in **`theme/web/`**, not in an invented theme source folder: `theme/web/main.scss` is compiled **last** — after Atlas Core *and* after every module theme source — so a partial imported from it overrides any Atlas rule without `!important`. Use a module's theme source only when the styling genuinely belongs to that module (it exports with the `.mpk`). **Generalisable — the shape to look for**: when CSS "doesn't apply", first prove the file is *compiled at all* (grep a unique probe selector in `theme-cache/web/theme.compiled.css`) before debugging specificity or caches — absent and overridden look identical in the browser. Note also that `theme/web/custom-variables.scss` is imported once **per module**, so it must hold declarations only; a rule there is emitted N times |
-
-| A **`CREATE JAVASCRIPT ACTION`** succeeds, `mxcli check` passes and the build is clean, but calling the action in the running app throws **`JavaScript action was not implemented`** and the nanoflow aborts | mxcli wrote the source to `javascriptsource/<ModuleName>/actions/` using the module's own casing. Mendix reads a **lowercased** directory — a blank Mendix 11 app ships `javascriptsource/nanoflowcommons/`, `/datawidgets/`, `/webactions/` for modules named `NanoflowCommons`, `DataWidgets`, `WebActions`. Finding no source at the path it reads, mxbuild generates a stub whose body is `throw new Error("JavaScript action was not implemented")` and bundles that. Only reproduces on a **case-sensitive filesystem**, which is why it survived: on macOS and Windows the two spellings are the same directory | `mdl/backend/modelsdk/javascript_write.go` and `sdk/mpr/writer_javascriptactions.go` (`jsActionSourceDir`) | `strings.ToLower(moduleName)` in both writers — the comment in each previously asserted the opposite ("unlike javasource, which is lowercased"), so the belief was documented, not tested. **Generalisable — the shape to look for**: when generated *source files* pair with model units, the model unit is not evidence the file is found; the filesystem path is a separate contract, and a case-only mismatch is invisible on the developer's own machine. Check against the directories a blank project already ships rather than against what the code says. Nothing short of running the app catches it: parse, check and build all pass. Test `mdl/backend/modelsdk/javascript_write_dir_test.go`; verified end-to-end (button click flips the theme instead of throwing) |
-| 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 | **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 | `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) | 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 |
-| A widget datasource bound to a **parameterized** microflow/nanoflow (`datasource: microflow Mod.MF(Name: $x)`) fails with **CE1571** "No argument has been selected for parameter 'X'". `mxcli check` and `exec` both report success; `describe page` shows the microflow but no arguments | The grammar parsed the arguments into `DataSourceV3.Args`, but the builder never read them and `pages.MicroflowSource` had **no field to hold them**, so they were dropped between AST and model. The writer's `microflowSettingsToGen(d.Microflow, nil)` passed a literal `nil` at all three datasource sites, with a comment asserting datasources never carry mappings — true when only actions could take arguments, stale once the grammar accepted them on a datasource | `sdk/pages/pages_datasources.go` (`MicroflowSource`/`NanoflowSource` gain `ParameterMappings`), `mdl/executor/cmd_pages_builder_v3.go` (`flowArgsToParameterMappings`, shared with the action path), `mdl/backend/modelsdk/widget_write.go` (three sites pass `d.ParameterMappings`) | Reuse the action path's `$`-variable-vs-expression rule rather than writing a second one — the two must agree or the same argument binds through different BSON fields depending on where it appears. **Generalisable — the shape to look for**: a hardcoded `nil` argument whose comment explains *why* the data can't exist is a dated assumption; when the grammar grows a construct, grep for the `nil`s that were correct before it. **Also check the model type can hold the value at all** — here the AST parsed it and the writer would have written it, but the struct in between had no field, so nothing was "dropped" by any single line. **Remaining gap**: `describe page` does not yet emit the mappings, so a describe → exec round-trip still loses them (read-back only; the write path is correct). Repro `mdl-examples/bug-tests/835-datagrid-microflow-datasource-params.mdl`; verified end-to-end (`mx check` 11.13.0: CE1571 → 0 errors). Issue #835 |
-| Quoted identifiers inside a `create import mapping { }` / `create export mapping { }` body produce **CE1613** "The selected entity `'Mod."Entity"'` no longer exists" on every reference, while the same quoting works everywhere else. `mxcli exec` reports success with no warning | The mapping-body builders read entity/association names with `ctx.QualifiedName().GetText()`, which returns **raw parse text including the quotes**, instead of `buildQualifiedName` (which strips them via `identifierOrKeywordText`, as the rest of the visitor does) | `mdl/visitor/visitor_import_export_mapping.go` (`buildImportRootElement`, `buildImportChild`, `buildExportRootElement`, `buildExportChild` — five sites: root entity, nested association + entity, value-transform converter) | Route every qualified name through `buildQualifiedName(...).String()`. **The error message names the bug**: `'Mod."Entity".RouteId'` mixes a *quoted* entity with an *unquoted* attribute, because the attribute half already went through `identifierOrKeywordText` — when a stored name is half-stripped, one of the two readers is raw. **Generalisable — the shape to look for**: `GetText()` on a parser context is almost always wrong for a name; it is the raw source slice, so any lexical decoration (quotes, whitespace) survives into the model. Grep for `.GetText()` next to `QualifiedName` whenever a reference looks right in the script but not in the .mpr. Repro `mdl-examples/bug-tests/842-mapping-quoted-identifiers.mdl`; verified end-to-end (`mx check` 11.13.0: 3 errors → 0). Issue #842 |
-| `ALTER PAGE … ON <col>` targeting a DataGrid2 column: (a) the authored MDL column name (`column colFoo`) fails with a bare `widget "colFoo" not found`, and (b) a name shared by two columns (duplicate captions) **silently mutates the first** and reports `Altered page`, leaving the second unreachable | DataGrid2 columns carry **no stored name** in the Mendix model (their WidgetObject has no `Name` property), so the authored name is dropped on write and mxcli addresses a column by a *derived* name (attribute leaf, else caption, else `col{N}`). The bare-name resolver `findInWidgetArray` returned on the **first** derived-name match, so duplicates collided silently; the miss path emitted a generic "widget not found" with no hint that columns use a derived name | `mdl/backend/pagemutator/mutator.go` — the column loop in `findInWidgetArray` (now counts matches → `bsonWidgetResult.matchCount`), `findBsonColumn` (returns `(result, error)`), and the mutation entry points `SetWidgetProperty`/`DropWidget`/`InsertWidget`/`ReplaceWidget` (reject `matchCount > 1`, use `widgetNotFoundError` which lists derived names) | Persisting the authored name is **not possible** — columns have no name slot, and inventing one is the Studio-Pro-won't-open hazard (ADR-0005 guard-don't-drop). So implement the finding's two fallbacks: reject an ambiguous `ON <name>` with an actionable error instead of silently taking the first (a *data hazard*, not just a wart), and on a miss list the addressable derived names + explain the derived-name model (run DESCRIBE PAGE). **Generalisable**: a resolver that returns the first of N matches hides ambiguity — count matches and reject >1 at every *mutating* entry point, not just the read path. Repro `mdl-examples/bug-tests/ledger-78-datagrid-column-addressing.mdl`; A/B: pre-fix binary reports `Altered page` for the duplicate-caption `ON "Amount"`, fixed errors with "ambiguous". Ledger #78 |
-| `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 | 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 | `mdl/executor/cmd_microflows_builder_control.go` (`addLoopStatement` body loop) | 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 |
-
-| 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 | 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 | `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) | **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. |
-
-
-| 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 | `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 | `mdl/executor/cmd_pages_builder_v3.go` (`resolveAssociationDestination` fallbacks + a hard guard in the `association` case of `buildDataSourceV3`) | 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 |
-| `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 | `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 | `mdl/executor/cmd_workflows.go` (`JumpToActivity` case in `formatWorkflowActivities`) | 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 |
-| 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 | 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 | `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) | 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 |
-| 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 | 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 | `mdl/executor/cmd_pages_builder_v3.go` (`associationEndpoints`, `resolveAssociationDestination`), `mdl/executor/widget_engine.go` + `cmd_pages_builder_input.go` (`resolveAssociationPathIn`, `storedSystemMemberName`) | **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 |
-| 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 | 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 | `mdl/executor/cmd_security_write.go` (`execGrantEntityAccess`, `storedAuditMembers`, `otherModuleBothOwnerAssociations`), `mdl/backend/modelsdk/domainmodel_security_write.go` (`ReconcileMemberAccesses`) | **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 |
-| An unquoted negative number in an XPath constraint fails to parse: `where [Amount > -7]` → `Parse error: extraneous input '7' expecting {',', ')'}`. Reported as "negative numeric literals truncate (`-7` becomes `-`)" | `xpathWord` — the name-part rule inside XPath — is a **negated token set** that did not exclude `MINUS`, so the sign was consumed as a name word and the digits were left stranded (hence the truncation appearance). The lexer deliberately keeps `-` out of `NUMBER_LITERAL` (a leading sign there mis-tokenises `$x -2`), leaving negation to the parser; the general grammar has `unaryExpression` for this and the XPath grammar simply never got the equivalent | `mdl/grammar/domains/MDLPage.g4` (`xpathValueExpr` gains `MINUS xpathValueExpr`; `MINUS` added to the `xpathWord` exclusion set), `mdl/visitor/visitor_xpath.go` (`buildXPathValueExpr`), `mdl/visitor/visitor_page_v3.go` (`xpathExprToString` emits `-7`, not `- 7`) | **The grammar fix alone is worse than the bug.** With the parser accepting `-7` but the XPath AST builder having no case for the new alternative, the constraint parses and silently serializes to `[Amount > ]` — a dropped operand instead of a loud parse error. Caught only because the visitor has a round-trip helper; the microflow write path uses `GetText()` and looked fine. **When adding a grammar alternative, check every consumer of that rule, not just the one your repro exercises.** **Scope correction**: the finding's own example (`addDays([%CurrentDateTime%], -7)`) still fails — `addDays` is a *microflow expression* function, not an XPath one, and it fails `CE0161` with a POSITIVE argument too, so the sign was never its problem. Repro `mdl-examples/bug-tests/it-18-xpath-negative-literal.mdl`; A/B on Mendix 11.12.1: pre-fix the script does not parse, fixed binary writes it and `mx check` reports 0 errors. issuetracker #18 |
-
-| Text painted by an **Atlas topbar widget is invisible in a dark theme** — the language selector measures ~1.13:1 contrast, glyph pixels spanning 4 luminance values out of 255. A theme override exists and *names the right element*, so it looks handled | Two separate mistakes stacked. (1) **Specificity**: Atlas's own rule is `.navbar-brand .widget-language-selector .current-language-text` at (0,3,0); a bare `.current-language-text` at (0,1,0) never wins, and only appears to on layouts that do not nest the selector under `.navbar-brand`. (2) **Wrong value**: `color: inherit` inherits *body ink*, which is dark, while the rail is dark in both palettes — so even at the winning specificity it measures 1.00:1. Atlas paints from `--bg-color-secondary` with a `#fff` fallback because it assumes a dark rail | `cmd/mxcli/theme/assets/*/files/theme/web/_mxcli-atlas-map.scss` (the "Atlas fixups" block) | Re-declare **Atlas's own selector shape** so the weights match and source order decides, and resolve the colour through the rail token (`var(--mxt-rail-ink-active, var(--mxt-rail-ink))`) rather than `inherit`. List the bare and the `.navbar-brand`-nested selectors together — each is matched at its own specificity, so one rule covers both layouts. **Generalisable — the shape to look for**: a guard that names the right element is not evidence it applies. Read the *winning* declaration (`CSS.getMatchedStylesForNode` in DevTools, or the computed value) instead of the one you wrote. **Measure contrast, not colour**: reading `getComputedStyle(el).color` once and seeing a plausible value proves nothing — compute the WCAG ratio against the first non-transparent ancestor background, which is what turns "looks fine" into 1.13 vs 19.47. Reported from the RssReader test build; tests in `cmd/mxcli/theme/theme_test.go`, verified in a browser at 17.79:1 light / 19.47:1 dark |
-
-| A themed app is on-palette everywhere except a few widget details — the **Data Grid 2 pager caption is invisible** (1.02:1 on a dark ground), row-select checkboxes stay stock Mendix blue, popovers cast light-mode shadows. Re-pointing tokens changes nothing, and the same widget's other parts (the pager *buttons*) are fine | The theme source shipped by the **widget modules** (`themesource/datawidgets`, `atlas_web_content`) styles some things with Sass variables and literals — `datawidgets/web/variables.scss:18` is `$pagination-caption-color: #0a1325`. Sass resolves those at compile time, before any custom property exists, so the value is baked into `theme.compiled.css` and no `--mxt-*` can reach it. The parts that *do* work resolve `var(--gray-darker, …)` through Atlas: same bar, two mechanisms | `cmd/mxcli/theme/assets/*/files/theme/web/_mxcli-widgets.scss` (the shared widget layer, imported after the theme partial) | Add a CSS rule per baked declaration, resolving through a token so both palettes follow. **The obvious fix does not work**: each module's `main.scss` imports `theme/web/custom-variables` before its own `!default` vars, so `$pagination-caption-color: var(--mxt-ink-muted)` there *would* win — but (1) the names collide with Atlas Core's, which feeds them to Sass colour functions (`atlas_core/web/_variables.scss:20` computes `mix($brand-primary, #e7e7e9, 10%)`; handing `mix()` a `var()` is a compile error) and (2) the worst offenders are not behind a variable at all — `_three-state-checkbox.scss` writes `#264ae5` and `rgba(#264ae5, 0.4)` directly. **Generalisable — the shape to look for**: read the **compiled CSS, not the SCSS**, when deciding what to override. The sources are full of `var(--token, #fallback)` declarations that already resolve correctly; in one measured app `#264ae5` appeared in 46 declarations and **24 were harmless fallbacks**, so grepping the source would have produced twice the rules for no benefit. Reported from the Formula1 test build (§33); verified in a browser: pager caption 1.02:1 → 6.99:1 console dark, 6.39:1 light, 6.78/5.93 on signal |
-| 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) | 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 | `mdl/executor/validate_microflow_loop_scope.go` (new `MDL053`, wired from `microflowValidator.validate`), skill `.claude/skills/mendix/write-microflows.md` | 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 |
-| `mxcli oql` silently omits a whole column: a `select A, B …` renders only `A`, and the JSON output has no `B` key at all — no error, no empty column. Reproduces whenever the value of `B` is **null in the first row** | The runtime omits a null-valued column from a row's JSON object entirely, and `parseOQLFeedback` took the column list from `extractColumnOrder(rows[0])` — one row, chosen for its key *order*. Every later row was then projected onto that short list, so the column vanished from the result rather than showing NULLs | `cmd/mxcli/docker/oql.go` (`parseOQLFeedback`, `mergeColumnOrder`, `hasOnlyKnownKeys`) | Union the keys of **all** rows, inserting each new key directly after the last key already known rather than appending — merging `[A, C]` with `[A, B, C]` must give `[A, B, C]`, not `[A, C, B]`, or a column that is null early in the result set jumps to the end of the table. The per-row re-scan is skipped when a row carries no unseen key, so the uniform case still costs one length check. **Generalisable**: any "take the shape from the first element" over a sparse encoding is a silent-wrong-answer bug, not a formatting bug — the output looks complete. Tests `TestParseOQLFeedback_ColumnUnionAcrossRows`, `TestMergeColumnOrder`; proven by stubbing the union back to first-row-only and watching the reported symptom return. sudoku #39, first half |
-| `mxcli test` cannot run at all in a container without a Docker daemon — parsing, runner generation, model injection and the **entire mxbuild build** succeed natively, then `docker up` fails with "failed to connect to the docker API at unix:///var/run/docker.sock". So microflow tests are unavailable in exactly the environment mxcli targets (Claude Code web containers ship `/usr/bin/docker` with no daemon) | Only one step of the run was containerised — start the runtime and read its log — but it was wired directly to `docker compose`, with no seam for another way to run the app. `run --local` had all three pieces already (boot a standalone runtime, tee its log, restore) | `cmd/mxcli/docker/localapp.go` (new `StartLocalApp`), `cmd/mxcli/testrunner/runner_local.go` (new), `cmd/mxcli/testrunner/runner.go` (docker path extracted to `runDockerAndCapture`), `cmd/mxcli/cmd_test_run.go` + `main.go` (`--local`) | Give the run a seam — `runLocalAndCapture` / `runDockerAndCapture` — so both modes share parse/inject/parse-results/cleanup and differ only in how the app is started. **Two traps, both found by running it rather than reasoning about it.** (a) The runner reports via an **after-startup** microflow, so its LOG output happens DURING the start action, before the runtime's log subscriber attaches; registering the subscriber early is not possible (the runtime answers `LoggingException` pre-start). What actually carries the output is the JVM console tee, live from spawn — verified by A/B running with the early attach removed. (b) A **failing** test makes the runner return false, which makes the after-startup action fail, which makes `start` return an error — the first version reported that as a broken run and dumped a stack trace instead of the test report. A failed boot whose log shows a verdict is a normal outcome. Local runs use their own ports (8081/8091) and a `<project>_test` database so a `run --local` dev loop can keep serving. Verified end-to-end in a daemon-less container: 2 passed; then 1 passed / 1 failed with exit 1, project restored. sudoku #41 |
-| A solution's apps are served on one host with different ports, so they share a cookie jar (cookies key on host name and **ignore the port**) — logging into one silently replaces the other's `XASSESSIONID`. Giving each app a host name in **App Settings -> Configurations -> Application root URL** appears to do nothing under `run --local` | `runtimeConfigParams` builds the entire boot `update_configuration` payload from `LocalRuntimeOptions`, and `ApplicationRootUrl` was only ever populated from a `--hub` registration. The model's own value had no path into the payload — and since the admin action REPLACES rather than merges, nothing else could supply it either | `cmd/mxcli/docker/runlocal.go` (`configuredApplicationRootURL`, `applicationRootURLFrom`, `customHostRootURL`) | Read the setting off the project at boot and use it when no hub URL was assigned (hub wins — that URL is the one actually serving the app). **The trap is that a blank Mendix app already ships `ApplicationRootUrl = http://localhost:8080/`**, so "is set" does not mean "was chosen": honouring every value would change behaviour for every existing project and, under `--app-port`, advertise a port the app is not serving on. Only a **non-loopback host** is passed through, and a port that disagrees with `--app-port` warns. Serving under the host name needs no flag at all — the runtime accepts any `Host` and the client uses relative URLs (verified: 200 via `/etc/hosts`, nip.io and localtest.me); the setting matters only for the **absolute** URLs Mendix generates. **Generalisable**: before defaulting from a model setting, check what a blank project already has in it — a non-empty default makes "fall back to the model" a behaviour change, not a no-op. Verified end-to-end on 11.12.1: with `backend.local` configured, boot prints `Application root URL from configuration "Default"` and the app answers 200 on both the host name and the listen address. Tests `TestApplicationRootURLFrom`, `TestCustomHostRootURL` |
-| 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 | 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`) | `mdl/executor/cmd_pages_builder_input.go` (`declaringEntityFor`, `entityAttributeOwners`), `mdl/executor/cmd_pages_builder_v3.go` (final attribute of the association path) | 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 |
-| The SessionStart hook `mxcli init` writes cannot survive an idle reap: it is guarded on `test -x ./mxcli`, and `.gitignore` excludes that binary (~85 MB) on purpose. The container is reclaimed, the repo re-cloned without it, the guard fails and the hook no-ops through `\|\| true` — the next session has no mxcli, no MxBuild cache, no database, and no message saying so | The hook inlined the whole bring-up in one shell line, so "binary missing" could only be expressed as "skip". A hook line cannot reasonably do OS/arch detection and a download; something committed has to | `cmd/mxcli/init_hook.go` (`bootstrapScriptTemplate`, `writeBootstrapScript`, `sessionStartHookCommand`, `sessionStartHookMarkers`) | Emit a committed `.claude/bootstrap-mxcli.sh` that resolves OS/arch, fetches the binary when absent (`MXCLI_TAG` to pin), then runs the setup; the hook becomes `sh .claude/bootstrap-mxcli.sh \|\| true`. **Changing the hook command breaks dedupe**, which matched on the old command string — so `addSessionStartHook` now recognises *any* known marker and **rewrites the entry in place**, migrating an old project instead of leaving it with two hooks that both run. **Generalisable**: a guard whose condition is something you deliberately do not commit is a silent no-op waiting for a fresh clone — make the guard able to satisfy itself. Verified by reproducing the reap: moved `./mxcli` out of the project, ran the hook command verbatim, watched it re-download (88 MB, new mtime) and finish with "Setup complete … database ready". Tests `TestAddSessionStartHook_MigratesLegacyCommand`, `TestEnsureSessionStartHook_WritesFile`. mxcli-todo #2 |
-| `mxcli exec -p app.mpr - <<'EOF' … EOF` fails with `Error reading file: open -: no such file or directory` — `-` is taken literally as a filename, so MDL cannot be piped or written as a heredoc and every ad-hoc script needs a temp file first | `exec` (and `check`) called `os.ReadFile(path)` directly, with no case for the conventional stdin spelling | `cmd/mxcli/mdlsource.go` (new `readMDLSource`, `mdlSourceLabel`), `cmd/mxcli/cmd_exec.go`, `cmd/mxcli/cmd_check.go` | One helper both commands share, so `check` gained the same spelling rather than only the reported one; `check` reports the source as `<stdin>` instead of a bare `-`. Verified live: a heredoc through `exec` and a pipe through `check` both run. Tests `cmd/mxcli/mdlsource_test.go`. mxcli-todo #5 |
-| `mxcli syntax` documents spellings the parser rejects, so an agent following the reference writes MDL that fails — `TEXTBOX … (Binds: Attr)` ("'Binds:' is no longer supported, use 'Attribute:' instead") and `DataSource: MICROFLOW Module.MF()` (a zero-arg microflow datasource takes NO parens, unlike RETRIEVE/CALL) | Nothing checks the `syntax` corpus against the parser. `make check-skill-mdl` validates MDL blocks in the skills and the docs site, but the `Syntax`/`Example` strings in `cmd/mxcli/syntax/*.go` are not covered, so a retired spelling can sit there indefinitely | `cmd/mxcli/syntax/features_page.go` (10 × `Binds:` → `Attribute:`, the datasource parens), `cmd/mxcli/syntax/retired_spellings_test.go` (new guard) | Fix the text **and** pin it: a table-driven test fails if a retired spelling reappears in any topic's Syntax or Example. It is a spelling guard rather than a parse — the snippets are fragments (a DATAVIEW body, a property line) that do not stand alone as statements, so they cannot just be fed to the parser. Proven by reintroducing `Binds:` and watching the test name the topic and field. **A third claim in the same report did not reproduce**: `CONTAINER (OnClick: SHOW_PAGE M.P(Param: $currentObject))` parses fine on current main, so only the two verified ones were changed. mxcli-todo #8 |
-| `mxcli test … --local` (or any other `StartLocalApp` caller) fails with MxBuild's `the project file path should be an absolute path`, followed by a page of Windows sample requests, whenever `-p` is given a **relative** path | `ServeServer.Build` forwarded `ProjectFilePath` verbatim. `mxcli run` had learned to absolutize at the CLI layer (findings #17), but that fix lived in `cmd_run.go`, not in the code that talks to MxBuild — so the next caller re-hit it | `cmd/mxcli/docker/mxserve.go` (`ServeServer.Build`) | Absolutize `req.ProjectFilePath` in `Build` itself, the single place that talks to MxBuild, so no future caller can miss it; also resolve `LocalAppOptions.ProjectPath` in `applyDefaults` so `DeployDir` and the runtime log path are not derived from a relative value. Test by pointing a `ServeServer` at an `httptest` fake and asserting on the request body — the CLI-layer fix cannot be tested that way, which is part of why it did not generalise |
-| `mxcli test --attach` fails with `reload_model failed: Authentication failed.` — after the test microflows have already been injected into the project | The M2EE admin API and the test endpoint are **different secrets**. `attach` built its `RuntimeController` with `M2EEOptions{Token: hs.Token}` — the endpoint token — instead of the runtime's admin password | `cmd/mxcli/testrunner/runner_attach.go` (`attach`), `cmd/mxcli/testrunner/handshake.go` (`Handshake`) | Carry `AdminPass` in the handshake alongside `Token` and pass that to `M2EEOptions`. The hosting `run --local` publishes it via `docker.LocalAppInfo` (the resolved value, not the package default, so a `--admin-pass` override still works). Whenever one process drives another's M2EE API, check which credential is being passed — `defaultLocalAdminPass` and any app-level token are unrelated |
-| `alter page … set Editable = [expr]` (or `set Visible`) writes a project Studio Pro refuses to open: `StorageLoadException: Conditional editability settings has an invalid value '' for property Attribute`. `mxcli check` ✓ and `mx check` ✓ — neither inspects the stored value. The identical settings written by `create page` load fine | The ALTER path builds the `Forms$Conditional{Visibility,Editability}Settings` node by hand and wrote `Attribute: null`. `Attribute` is a **BY_NAME** `AttributeIdentifier`, so its unset value is the empty string, not null — exactly what the CREATE path already encodes via `codec.RegisterTypeDefaults(..., EmptyStringFields: []string{"Attribute"})`, whose comment records this same StorageLoadException from #627. Only the hand-built ALTER node missed it | `mdl/backend/pagemutator/mutator.go` (`setWidgetConditionalSettingMut`) | Write `{Key: "Attribute", Value: ""}`, not `nil`. **General rule: when one path hand-builds BSON that another path builds through the codec, diff the two encodings rather than eyeballing the hand-built one** — `mxcli bson dump --type page --object M.P` on a CREATE-authored and an ALTER-authored widget makes the divergence a one-line diff (key sets and values were otherwise identical). `SourceVariable` stays `nil`: it is BY_ID, where null *is* the absent value, so "null is wrong" is per-field, not a blanket rule. Test `TestSetWidgetConditionalSetting_AttributeIsEmptyString`; repro `mdl-examples/bug-tests/851-alter-page-conditional-attribute.mdl`. Issue #851 |
-| A widget conditional using a function whose name is also an MDL lexer keyword — `visible: [trim($currentObject/Slug) != '']`, `[length(…) > 0]`, `empty`/`count`/`find` — **silently drops the whole property**; `mxcli check` ✓, `mx check` ✓, and the widget renders unconditionally visible. `toUpperCase`/`isMatch`/`contains` in the same position work | `xpathFunctionName` (MDLPage.g4) enumerated only `IDENTIFIER \| HYPHENATED_ID \| NOT \| TRUE \| FALSE \| CONTAINS`, so `trim(` never matched `xpathFunctionCall`. The enclosing `[...]` then failed to parse as an `xpathConstraint` and matched the generic `propertyValueV3` alternative instead, so the visitor set `Visible` (an array) rather than `VisibleIf`, and the builder's `else if pages.StaticVisibleExpression(...)` — which reads only bool/string — never fired | `mdl/grammar/domains/MDLPage.g4` (`xpathFunctionName`) + `mdl/executor/validate_widgets.go` (`validateConsumableConditional`) | Define `xpathFunctionName : xpathWord \| NOT` — `xpathWord` is a negated token set, so it self-maintains as the lexer gains keywords; an enumerated list reacquires this bug with the next promoted function name. Safe because `xpathFunctionCall` requires a following LPAREN and no `xpathStepValue` may be followed by one, so bare `empty` still parses as a path word. `NOT` is spelled out (xpathWord excludes it). **Also add the general guard**: MDL-WIDGET19 errors when `Visible`/`Editable` holds a value that is neither routed to `VisibleIf`/`EditableIf` nor a bool/string — that is the residue signature of any conditional the visitor could not build, so the next one fails loudly instead of vanishing. `make grammar` regenerates the parser (not committed). **Verify in a browser, not at `mx check`** — a dropped property is still a valid model, so `mx check` reports 0 errors before AND after; the symptom only exists at render time (see `verify-in-runtime.md`). The repro script carries a `Bug852.Verify` page for this: `Slug` is three spaces, so `trim()` changes the outcome and a dropped `Visible` renders (Mendix defaults to visible). Pre-fix all 5 markers render; post-fix only the 3 that should. **One rule, two contexts**: `xpathConstraint` serves both `Visible:`/`Editable:` (a Mendix *client expression* — trim/length/toUpperCase/find) and a datasource `where` (real *XPath* — contains/starts-with/ends-with/string-length/not, `length()` = list length, aggregates Java-only, and `empty`/`NULL` are KEYWORDS not calls). The sets differ, so the grammar must not enumerate either; mxbuild adjudicates. Regression-test the XPath side when touching this rule — `[Name = empty]`, `[Name = NULL]`, `not()`, `contains()`, `starts-with()`, `string-length()` all still parse and `mx check` clean. Tests `TestConditionalVisibility_KeywordFunctionNames`, `TestValidateStaticWidget_UnconsumableConditional`; repro `mdl-examples/bug-tests/852-conditional-keyword-functions.mdl`. Issue #852 |
-| `download file $Doc;` is accepted by `mxcli check` and `mxcli exec` ("Created microflow") but the activity lands with **no action at all** — `describe` renders `-- Empty action` and `mx check` fails `[CE0008] "No action defined."`. Same for `download file $Doc show in browser;` | `microflowActionToGen` (the modelsdk write path) had no `*microflows.DownloadFileAction` case, so it hit `default: return nil` and the enclosing ActionActivity was serialized with a nil Action. Grammar, visitor, flow builder, read path and DESCRIBE formatter were all already in place, so the statement passed every stage that reports anything and vanished at the one that does not | `mdl/backend/modelsdk/microflow_write.go` (`microflowActionToGen`) | Add the case, setting `FileDocumentVariableName`, `ShowFileInBrowser` and `ErrorHandlingType` (Rollback default). **The storage key is `ShowFileInBrowser`, not `ShowInBrowser`** — the gen setter binds the right one; legacy's `parseDownloadFileAction` reads the wrong key. **Test at the round trip, not the reader**: a reader-only test starts from BSON the writer never had to produce, so `TestActionFromGen_DownloadFile` was green throughout. `roundTripMicroflow` (model→gen→codec→model) is the harness; assert the ActionActivity's `Action` is non-nil, which is the CE0008 shape itself. This is the same silent-drop mechanism as the `microflowObjectToGen` default branch (#791) — when auditing, diff the write switch's cases against `sdk/mpr/writer_microflow_actions.go`. Test `TestMicroflowRoundTrip_DownloadFile`; repro `mdl-examples/bug-tests/850-download-file-action.mdl`. Issue #850 |
-| 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` | 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 | `mdl/executor/cmd_microflows_helpers.go` (`normalizeMendixOperatorCase`, applied in the `SourceExpr` branch) | 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 |
-| `ALTER ENTITY X ADD EVENT HANDLER …` errors when the handler exists and `DROP EVENT HANDLER …` errors when it does not, so a script containing either cannot be re-run — and a defensive drop-then-add fails on whichever half does not match. `ADD ATTRIBUTE` has `IF NOT EXISTS`; event handlers had no equivalent | The idempotency guards added for attributes (findings #10) were never extended to the event-handler clauses, which are the one member with no other re-run route | `mdl/grammar/domains/MDLDomainModel.g4` (`ifNotExists?` / `ifExists?` on the event-handler clauses), `mdl/visitor/visitor_entity.go`, `mdl/executor/cmd_entities.go` | Reuse the existing `ifNotExists`/`ifExists` grammar rules rather than inventing a second spelling, so the guard reads the same everywhere. The error messages now name the flag, so the fix is discoverable from the failure. Verified by running the same script twice: first run drops (skipping, absent) then adds; second run skips both, exit 0, and the project still builds 0 errors. mxcli-todo #18 |
-| `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 | 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 | `mdl/executor/cmd_security_write.go` (`warnDemoUsersInert`, called after a successful create) | 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 |
-| 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 …` | 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 | `mdl/executor/cmd_entities.go` (`checkBeforeCreateHandlerHasNoParameters`, called from `buildEventHandlers`) | 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 |
-| "Contrast is low and not everything uses the dark theme" — and switching theme does not help, because `signal`, `ledger` and `console` all render the same defects. The worst of it is the **login page**: Atlas's stock photograph fills half the viewport on a dark app, and the Sign in button is green while the app's primary button is the brand colour | The login page is served from `theme/web/login.html`, which loads the SAME compiled theme CSS (`{{themecss}}`) — so it IS themeable, but nothing themed it. Two Atlas rules do the damage: `.loginpage-image` layers a brand-tinted gradient over `url("./resources/work-do-more.jpeg")`, and the submit button is `.btn-success`, so it follows the **success** colour rather than the brand. Separately, `--link-color` was mapped straight to the brand, and console's light-variant teal is 3.74:1 on white — under AA for body text | `cmd/mxcli/theme/assets/*/files/theme/web/_mxcli-atlas-map.scss` (login block + `--mxt-link` indirection, all three copies stay byte-identical), `cmd/mxcli/theme/assets/console/.../_mxcli-console.scss` (light `--mxt-link`) | Replace the photo with a token-built gradient and point the login button at the brand; give link TEXT its own `--mxt-link` token defaulting to the brand, because a link needs 4.5:1 as text while a brand used as a button FILL only needs 3:1 plus contrast against its own ink — darkening the brand everywhere would have been the wrong lever. Console light gets `#0f766e` (5.47 / 5.10 / 4.92 against surface / ground / surface-alt). **The project's own `theme/web/logo.png` is deliberately left alone** — it is the app's asset to replace, and hiding it would strip a real logo from apps that have one. **Verification boundary, stated plainly**: verified at the compiled-CSS layer (the overriding `.loginpage-image` is last and carries no photo; the button and link declarations resolve), NOT in a browser — raising the scratch project's security level to serve a login page surfaced pre-existing model errors there that block deploy. The `#999` empty-state label could not be reproduced: every `#999` in the compiled CSS is a Bootstrap default (popover arrows, modal border, print styles), so that one needs the reporter's app. mxcli-todo #19 |
-
-| 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'` | 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 | `mdl/executor/validate_icon_refs.go` (`validateIconRefs`), wired into `validateProgram` | 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) |
-| `ALTER PAGE … SET Action = microflow M.F ON btn` does not parse — `extraneous input 'M' expecting {DROP, ADD, SET, INSERT, REPLACE, '}'}`. The documented workaround is `REPLACE`, which works but silently drops every property the statement does not restate (ButtonStyle, Class, design properties, tooltip) | `alterPageAssignment` special-cases `DATASOURCE`, `VISIBLE` and `EDITABLE`, then falls through to `identifierOrKeyword EQUALS propertyValueV3` — and `propertyValueV3` has no `microflow <name>` form, so the value position could not hold an action at all. `CREATE PAGE` has had `ACTION COLON actionExprV3` all along | `mdl/grammar/MDLParser.g4` (`alterPageAssignment` gains `ACTION EQUALS actionExprV3`), `mdl/visitor/visitor_alter_page.go` (`buildAlterPageAssignment`), `mdl/executor/cmd_alter_page.go` (`convertASTAction` + routing), `mdl/backend/mutation.go` + `pagemutator/mutator.go` + `mock/` + `mcp/` (`SetWidgetAction`) | Reuse `actionExprV3` — the same rule CREATE PAGE uses — and build through the **CREATE PAGE builder** (`pb.buildClientActionV3`) rather than a second switch. **Generalisable — the shape to look for**: when `SET` and `REPLACE` (or any narrow/wide pair) can express different vocabularies for the same property, the narrow one is a whitelist that will be extended one bug report at a time — #855 was the identical bug for `DataSource`, filed separately. Delegate instead of enumerating, and the pair cannot drift. **Guard-don't-drop**: refuse `SET Action` on a widget with no `Action` property rather than writing it — Studio Pro resolves every stored property against the type's property list and throws, while mxbuild tolerates the unknown key, so a silent write **builds clean and fails to open**; the build is not a safety net. **Measurement trap**: reverting only the grammar rule does not produce a failing test, it produces a *compile* error (the visitor references `ctx.ActionExprV3()`), so prove causation by reverting grammar+visitor together and re-running the original statement through the CLI. **Do not be misled by CE1571 on a `SHOW_PAGE` action** — authoring the same action through CREATE PAGE reproduces it exactly, so it is the builder's `$currentObject` auto-binding outside a dataview, not this change; always author the control before blaming the new path. Note `OPEN_LINK` still refuses on the modelsdk engine (`LinkClientAction` is unsupported by the codec) — also pre-existing, and CREATE PAGE refuses it identically. Repro `mdl-examples/bug-tests/alter-page-set-action.mdl`; verified end-to-end (Mendix 11.13.0, `mx check` 0 errors, `Class` survives four retargets without being restated) |
 
 **Key insight:** `microflows$ListRange` stores offset/limit inside a nested
 `CustomRange` map — must cast `raw["CustomRange"].(map[string]any)` before
@@ -405,360 +171,5 @@ extracting `OffsetExpression`/`LimitExpression`.
 
 - [ ] Failing test written before implementation
 - [ ] `go test ./mdl/executor/... ./sdk/mpr/...` passes
-- [ ] New symptom row added to the table above (if not already covered)
+- [ ] New finding appended to `findings/<area>.jsonl` (if not already covered), and `make check-findings` passes
 - [ ] PR title: `fix: <one-line description matching the symptom>`
-| A login that is known to be correct starts failing on `run --local` — the page says only **"Sign in failed"**, as if the password were wrong. `--screenshot-user` silently produces screenshots of the login page instead of the requested page | The local runtime is unlicensed, and an unlicensed runtime caps concurrent sessions. Past the cap it refuses the sign-in and logs `Maximum number of sessions exceeded! (You are currently using a trial license)` to `.mxcli/runtime.log` only; the page reports the refusal identically to a bad password. mxcli's own login helper never noticed either — it filled the form, waited, and saved whatever session it had | `cmd/mxcli/docker/screenshot_login.go` (`loginScript` failure detection, `loginFailureHint`, `readLogTail`), `cmd/mxcli/docker/runlocal.go` (passes `RuntimeLogPath`), `.claude/skills/mendix/run-local.md` | Not an mxcli defect in the model layer — but mxcli held both halves and joined neither. Mendix answers a rejected sign-in by re-rendering the same form, so **the username field still being present after the click is the signal** that login did not complete; on that signal read the tail of the runtime log and name the cap. **Generalisable**: when a browser-driven helper "succeeds" with a degraded result, look for a server-side log that already says why — the page is often the least informative witness. Sessions are released by restarting `run --local`; a browser-driving script should sign out at the end, or the fifth or sixth run is the one that fails and it looks like a regression. Tests `TestLoginFailureHint`, `TestReadLogTail`. mxcli-todo #16 |
-| A fresh clone of a project created by `mxcli new` goes dirty the first time anyone builds it: ~50 **tracked** files modified that nobody edited — every `javascriptsource/*/actions/*.js` gains a banner, `import { Big } from "big.js"` and `export async function`, plus the matching `javasource` stubs. In a cloud session with a stop-hook git check it reads as "uncommitted changes" at the end of clean work | The template ships the generated action stubs in a slightly older shape and MxBuild rewrites them all on the first build. `mx check` does **not** — only a build does — so nothing before the first `run --local` could reveal it, which is after the user has already committed | `cmd/mxcli/docker/settle.go` (`SettleGeneratedSources`), `cmd/mxcli/cmd_new.go` (step 5/6, `--skip-build`), `cmd/mxcli/init.go` (`/theme-cache/` in the generated ignore list) | Fix the *timing*, not the content: run the build while the project is still being created, so the settled form lands in the first commit. Do **not** reimplement the rewrite — it is mxbuild's generator and version-specific; run the real thing. Best-effort by contract (no JDK, no mxbuild, failed build → warning, never a failed creation), because a settled tree is a nicety and a usable project is the deliverable. The other half is gitignore: `theme-cache/` is a cache and says so. A/B on 11.12.1, both git-init'd then built: `--skip-build` → 50 dirty files, default → **0**. Tests `cmd/mxcli/docker/settle_test.go`. mxcli-todo #7 |
-| `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 | 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 | `mdl/executor/validate_page_order.go` (`ValidateScriptPageOrder`, MDL-PAGE01), wired in `cmd/mxcli/cmd_check.go` beside the other project-free validators | 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 |
-| A sidebar navigation label renders truncated — "All tasks" shows as "All task" — under every theme (`signal`, `ledger`, `console`) and both variants, so switching theme does not help. Measured on the live DOM as `scrollWidth=56` inside `clientWidth=48` | Atlas's **closed** sidebar is an icon rail: `--navsidebar-width-closed: 48px` in Atlas's own `themesource/atlas_core/web/themes/_theme-default.scss`. The label is wider than the rail, and the closed rail expects an *icon*, not text. No mxcli theme sets any navigation width — the themes map colours — which is exactly why every theme reproduces it | `.claude/skills/mendix/theme-styling.md` (documented; no code change) | **A fix was written, verified, and reverted** — record the reason: adding `text-overflow: ellipsis` to the nav item helps only where Atlas also sets `white-space: nowrap`; elsewhere the label wraps to two readable lines, and the rule turns `All / tasks` into `All / t…`. Screenshotted both ways against the real compiled CSS. The answer belongs to the app (give nav items icons — what the rail is for — or keep the sidebar open), not to a theme that would impose it on every app. **Generalisable**: when a reported symptom traces to an upstream layout constant, reproduce the geometry against the real compiled CSS (48px container, real class names, Playwright measurement) — it takes minutes, tells you whose constant it is, and shows when the "obvious" CSS fix is a regression. mxcli-todo #19d |
-| `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" | `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 | `mdl/executor/cmd_enumerations.go` (`validateNPEValidationRules`, called from `ValidateEntity`) | 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 |
-| `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" | Mendix XPath reaches at most ONE hop off a variable, and nothing checked the hop count | `mdl/executor/validate_microflow.go` (`checkXPathVariableTraversal`, `xpathVarTraversalRe`), called from the `*ast.RetrieveStmt` arm beside MDL047/MDL048 | 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 |
-| `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 | 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 | `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`) | 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 |
-| `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 | 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 | `mdl/executor/validate_microflow.go` (the `*ast.EnumSplitStmt` arm; `checkEnumSplitEmptyBranch`) | 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` |
-| A microflow using `split type` writes a project mxbuild cannot **load**: `KeyNotFoundException: The given key '<guid>' was not present in the dictionary` at `StreamingBsonUnitReader.ResolvePostponedProperties`. `mxcli check` ✓ and `mxcli exec` ✓; reproduced on 11.6.6 and 11.13.0 | Two gaps in the modelsdk writer, both the #791 shape. (1) `microflowObjectToGen` had no `*microflows.InheritanceSplit` case → `default: return nil`, so the split was dropped while three sequence flows kept pointing at its `$ID`. (2) `caseValueToGen` had no `InheritanceCase` case → every branch degraded to a bare `Microflows$NoCase`, losing the entity it selects on. Its value-receiver normalisation also omitted the type, so a pointer-only fix would still miss half the calls | `mdl/backend/modelsdk/microflow_write.go` (`microflowObjectToGen`, `caseValueToGen`) — mirror `sdk/mpr/writer_microflow.go` | Add both cases. **Diagnose with the #791 recipe**: `mxcli bson dump --type microflow`, collect every `$ID`, check each key ending in `Pointer` resolves (before: 27 objects / 3 dangling; after: 28 / 0). **Take field lists from the GENERATED type, not from legacy** — legacy writes `ErrorHandlingType` on the split but `initInheritanceSplit` has no such property, i.e. legacy writes a field Mendix does not define. **When adding a case-value type, update the value-receiver normalisation too.** Modelling rules confirmed on both versions while verifying: a type split needs an outgoing flow for every type INCLUDING the base (CE0090), and an `else` does NOT substitute for the base-type case. Tests `TestMicroflowRoundTrip_InheritanceSplit`, `TestCaseValueToGen_InheritanceCase{,ValueReceiver}`; repro `mdl-examples/bug-tests/split-type-dangling-pointer.mdl` |
-| The `split type` docs and examples teach a shape that fails the build: `case Spec` + `else`, with no branch for the base entity → **CE0090** "The 'X' value should be configured for an outgoing flow". `mxcli check` passes, so the drift survived; `mdl-examples/bug-tests/365` and `475` both shipped it, and 475's own header claimed "mx check reports 0 errors" | `else` on an inheritance split serializes as `Microflows$NoCase` and IS accepted, so it looks like it covers the remainder — but it does not satisfy type coverage. The base entity needs its own `case` | `.claude/skills/mendix/write-microflows.md` (Type Split section) + `mdl-examples/bug-tests/365-…`, `475-…` | Cover EVERY type including the base; `else` is then redundant. Also give the split somewhere to go: branches converge on a merge continuing to the end event, so a non-void microflow needs a `return` after `end split;` (else MDL003 + **CE0067**). Matrix verified on 11.6.6 AND 11.13.0: `specs+base` 0 errors, `specs+base+else` 0 errors, `specs+else only` CE0090. **When repairing a bug-test fixture, preserve the scenario it pins** — 475 tests "exactly ONE non-split branch continues", so its added base case must TERMINATE; an empty (falling-through) body would make two branches continue and silently retire the regression. Confirmed after the edit that the post-split activity still renders outside both case bodies and the describe→exec roundtrip is mxbuild-clean. Known cosmetic artifact: DESCRIBE emits an empty `else` block that was never authored; it re-parses and builds clean |
-| 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 | 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 | `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`) | **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 |
-| A typo in an OData property — `ReadMicroflow:` for `ReadMode:`, `ServiceNam:` for `ServiceName:` — passes `mxcli check` and `exec` reports success, but the model does not have the property. Hours can go into wondering why a published resource ignores its read microflow | The grammar accepts any `name: value` pair inside an OData property list, and the visitor's `switch` had no `default` — so an unrecognised name was dropped between parse and AST. The ALTER path has always answered `"unknown OData service property: %s"`; CREATE, PUBLISH ENTITY, the client and the external entity had nothing | `mdl/ast/ast_odata.go` (`UnknownProperties` on four statements), `mdl/visitor/visitor_odata.go` (four `default:` arms), `mdl/executor/validate_odata_properties.go` (`ValidateODataProperties`, MDL-ODATA01), wired in `cmd/mxcli/cmd_check.go` | The visitor is where the name is lost, so the visitor is where it must be recorded — a validator over the AST alone cannot see a key that was already discarded. Carry it as `UnknownProperties` and report at check time, before anything is written. The message names the property AND guesses the intended one (prefix/substring, then one edit), because a bare known-property list still leaves the reader diffing two spellings by eye. **Correction to the report**: `Pagesize:` is *not* silently dropped — the visitor lowercases before matching, so casing is never a typo, and the test pins that. Verified against every `mdl-examples/**/*.mdl` for false positives (0). Tests `mdl/executor/validate_odata_properties_test.go`. mxcli-formula1 suggested issue 8 |
-| A read-microflow-backed OData resource must declare a `System.ODataResponse` parameter and compute a count, even when the count is expensive (a full CSV scan) and nobody asked for it — with no MDL to say otherwise. Same for `$skip`/`$top` support | `Countable`, `SkipSupported` and `TopSupported` were written as literal `true` in the BSON writer's `ODataPublish$QueryOptions`; nothing above the writer could express them | `mdl/ast/ast_odata.go` + `mdl/visitor/visitor_odata.go` (`*bool` on `PublishedEntityDef`, `odataBoolPtr`), `model/types.go`, `mdl/executor/cmd_odata.go` (`astEntityDefToModel`), `mdl/backend/modelsdk/odata_write.go` (`boolOrDefault`), `odata_read_detail.go` (`falseOnly`) | Tri-state (`*bool`) is load-bearing: these default to **true**, so "unset" and "false" cannot share a representation or every existing script would silently turn them off. The reader maps a stored `true` back to nil (`falseOnly`) so DESCRIBE prints only what the author wrote instead of three defaults on every resource. Verified end to end on 11.12.1: `Countable: No` + a read microflow with **no** `$Response` parameter builds 0 errors, which is exactly the combination that was impossible before. Tests `cmd_odata_query_options_test.go`, `odata_write_test.go`. mxcli-formula1 #10.3 |
-| `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 | 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) | `mdl/executor/cmd_odata.go` (`odataModeToMDL`, `bareMemberName`, entity-set exposed name, `KEY` over `IsPartOfKey`) | 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 |
-| 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 | 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 | `mdl/executor/validate_database_type.go` (`ValidateDatabaseConnectionType`, MDL-DB01), wired in `cmd/mxcli/cmd_check.go`; `.claude/skills/mendix/database-connections.md` | **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 |
-| `mxcli init` run from a solution root (several app folders, no `.mpr` at the root) reports success and writes tooling that points at `project.mpr` — a file that does not exist. Nobody is told which project it picked, because it did not pick one | `findMprFile` looks only in the target directory; an empty result fell through to a hardcoded `"project.mpr"` default and initialisation continued as if that were a real project | `cmd/mxcli/init.go` (`findMprFilesInSubdirs` + the three-way branch on the candidate count) | Look one level down, then branch on the **count**: 0 → warn that generated paths will be placeholders; 1 → announce the project and initialise **that** directory; 2+ → refuse, list them, and print the exact command naming one. One level only — a Mendix app keeps its `.mpr` at its own root, and walking deeper starts finding deployment copies and backups. Candidates are sorted so the refusal and its suggested command are stable rather than directory-order dependent. **Generalisable**: a "sensible default" that names a file which does not exist is not a default, it is a silent wrong answer — count the candidates and let the count choose the behaviour. Tests `cmd/mxcli/init_discover_test.go`. mxcli-formula1 #3 |
-| `alter settings configuration 'Default' …` is the write form, but `describe settings configuration 'Default'` is a **parse error** — and `show settings configurations` summarises the configuration without `ApplicationRootUrl`, so the obvious command for "did my root URL land?" cannot answer it (and renders an empty DatabaseUrl as a bare `, ,`) | The grammar's `DESCRIBE SETTINGS` alternative took no object, so the read form of a write statement simply did not exist; the summary builder listed database/port fields and never gained the root URL when that property was added | `mdl/grammar/domains/MDLCatalog.g4` (`DESCRIBE SETTINGS (CONFIGURATION STRING_LITERAL)?`), `mdl/visitor/visitor_query.go` (reuses `DescribeStmt.Qualifier`), `mdl/executor/cmd_settings.go` (`writeSettingsConfiguration`, `describeSettingsConfiguration`, summary) | **Read forms should mirror write forms** — where MDL has `alter X <selector>`, `describe X <selector>` should parse, and reaching for it and getting a parse error teaches the wrong lesson. Factor the emit into one helper so the whole-settings dump and the single-configuration dump cannot drift. An unknown name lists the ones that exist, or the user is guessing. **Watch for**: changing `describeSettings`'s signature broke three existing callers, and the same commit's `IsPartOfKey`→`KEY` change broke an OData round-trip test that only the FULL suite caught — run `go test ./mdl/...`, not just the new test. Tests `cmd_settings_configuration_test.go`. mxcli-formula1 #8 |
-| `ALTER MODULE X ADD JAR DEPENDENCY (…)` succeeds, `list jar dependencies` reports it, the build is **green** — and the runtime throws `SQLException: No JDBC driver found in app for URL`. `deployment/build.gradle` has no dependencies block and `find deployment -iname '*<artifact>*'` returns nothing | Not a bad write. Declaring and resolving are **separate steps**: the model records the coordinate, and `mx sync-java-dependencies <project.mpr>` is what downloads it into `vendorlib/`. Studio Pro runs that when you edit Module Settings; nothing headless was running it. Confirmed on 11.12.1 — a full `mxbuild --target=deploy` resolves nothing, and the sync command then fetches the jar | `cmd/mxcli/docker/javadeps.go` (`SyncJavaDependencies`, `UnvendoredJarDependencies`), `cmd/mxcli/cmd_sync_java_deps.go` (`mxcli sync-java-deps [--check]`), `cmd/mxcli/docker/runlocal.go` (vendors before boot), `mdl/executor/cmd_modules.go` (`warnUnvendoredJarDependencies`) | **How to find the missing step**: the reporter's open question was "does mxbuild skip Maven resolution, or does mxcli write it somewhere MxBuild cannot read?" — neither. `strings mx.dll | grep -i dependenc` surfaced `ISyncJavaDependenciesRunner`/`SkipManagedDependencySync`, and `mx --help` listed `sync-java-dependencies`. When a model-level write "works" but the artefact never appears, check whether the **toolset** has a separate command for it before suspecting the write. Wired at three levels so the gap cannot stay silent: the executor says so the moment it writes an unvendored coordinate, `run --local` resolves it before boot, and `--check` exits non-zero as a build gate. Resolution needs network, so every call site is best-effort with an actionable message. Tests `cmd/mxcli/docker/javadeps_test.go`. mxcli-formula1 #12 |
-| `$Total = 5;` does not parse — `no viable alternative at input '$Total=5'` — while `DECLARE $Total Integer = 0;` does, and so do `$X = HEAD($List)`, `$X = create M.E (…)` and `$X = execute database query …`. The error names the token, not the missing keyword | Assignment existed only as a **prefix** on specific activity statements (`(VARIABLE EQUALS)?` on CALL/CREATE/RETRIEVE/…), plus a `SET $Var = expression` statement. A plain value therefore required `SET`, which nothing in the error or the surrounding syntax suggested | `mdl/grammar/domains/MDLMicroflow.g4` (`setStatement : SET? …`), `cmd/mxcli/syntax/features_microflow.go` | Make the guessable form work rather than improve the error: `SET` is now optional and both spellings produce the same `MfSetStmt`/`ChangeVariableAction`. **Prove a grammar relaxation causes no regressions with a control binary, not by reading**: `git stash` the `.g4`, `make grammar`, build `bin/mxcli-control`, sweep every `mdl-examples/**/*.mdl` with both — 13 scripts fail, the *same* 13, all pre-existing. ANTLR's adaptive prediction picks the activity-prefixed alternatives over `setStatement` on its own; no ordering change was needed. Executed against a real .mpr, mxbuild reports 0 errors. Tests `mdl/visitor/visitor_microflow_bare_assign_test.go` (bare and keyword forms must agree on the AST, not merely both parse). mxcli-formula1 #13 |
-| `mxcli test tests/ -p app/App.mpr` fails with "no such file or directory" for a `tests/` that sits right next to the `.mpr` | Test paths resolved against the process CWD only. Defensible in isolation, but mxcli otherwise encourages naming the project (`-p`) rather than standing in its directory, and project auto-discovery searches outward — so the two conventions collide and the failure looks like a missing directory | `cmd/mxcli/cmd_test_run.go` (`resolveTestPaths`) | Fall back to project-relative **only when the CWD-relative path does not exist**: a `tests/` in both places must resolve to the one the user is standing in, since silently preferring the project's copy would run the wrong suite. A path that exists in neither is passed through unchanged so the error names what was typed, not a rewritten path the user never mentioned. Tests `cmd/mxcli/cmd_test_run_paths_test.go`. mxcli-formula1 #13 |
-| A test annotated `@cleanup rollback` (or with no `@cleanup` at all — rollback is the documented default) still leaves its rows in the database; a misspelled strategy like `@cleanup rollbak` does the same, silently, while the run reports PASS | `TestCase.Cleanup` was parsed and then used nowhere. The after-startup runner had no seam to implement it — tests run inside the startup action, so there is no context the runner owns. The test endpoint creates that seam: it builds the `IContext` each test runs on | `cmd/mxcli/testrunner/endpoint.go` (the handler's execute block), `cmd/mxcli/testrunner/cleanup_strategy.go` | Wrap the call in `ctx.startTransaction()` … `ctx.rollbackTransaction()` in a **finally** (a throwing test is the one most likely to leave half-written data), gated on a `rollback=1` query parameter the client sends per test. Report `rolledBack`/`rollbackError` in the response and warn per test — a rollback that fails silently is worse than none. Reject an unknown `@cleanup` value at **parse** time so `--list` catches it too. Verify against the database, not the endpoint's own claim: run one test with rollback and one with `@cleanup none` in the same suite and query Postgres — the `none` row must be the only survivor |
-| A suite passes under `mxcli test --attach` and fails under `--local`, with assertions that depend on startup state (a loaded cache, seeded reference data) seeing zero rows | The `--local` runner pointed after-startup at its own registration microflow and did **not** chain the project's own, so the app's startup logic never ran. It was a deliberate choice (a known baseline) but was invisible: the run printed only `After-startup set to MxTest.RegisterEndpoint`, never that the user's microflow had been displaced | `cmd/mxcli/testrunner/runner.go` (`runEndpoint`), `cmd/mxcli/testrunner/cleanup_strategy.go` (`describeStartup`) | Capture project state **before** generating the endpoint MDL, and pass `state.afterStartup` to `GenerateEndpointMDL` so the generated flow chains it — the hosted `--test-endpoint` path already did this, and the mismatch between the two was the bug. Add `--skip-app-startup` for a deterministic empty baseline, and always print which of the two happened. Note the startup microflow's writes run at boot, outside any test transaction, so `@cleanup rollback` does not undo them. mxcli-formula1 findings #19 |
-| `mxcli test tests/ -p app/App.mpr --list` fails with `stat tests/: no such file or directory` while the same command without `--list` runs fine | The `--list` branch passed raw `args` to `ListTests`, bypassing `resolveTestPaths` — so a path relative to the project (rather than the working directory) resolved for execution but not for listing | `cmd/mxcli/cmd_test_run.go` (the `if list` branch) | Pass `resolveTestPaths(args, projectPath)` there too. When a command has two entry points into the same input, check both go through the same path resolution. mxcli-formula1 findings #15 |
-| After `SET` became optional, `mx check` on a project built from `02-microflow-examples.mdl` reports six errors that no MDL change caused: `[CE0109] "Undefined variable 'ProductList.Price'."` at four Aggregate list activities, and `[CE0015] "Aggregate function must specify a valid attribute."` at the expression-based one. Identical on both engines. `mxcli check` on the same script is silent | Two conversions existed for one syntax. `$Sum = sum($List.Price)` used to reach the dedicated `aggregateListStatement` rule; making `SET` optional put `setStatement` — alternative 5 of ~50 — in front of it, so ANTLR matched the lower-numbered alternative and the statement fell through to `buildSetStatement`'s fallback conversion, which joined list and attribute into one name and dropped the per-item expression entirely. Underneath, `buildListAggregateAsFunction` never appended the expression argument, so the SET path could not have seen it either | `mdl/grammar/domains/MDLMicroflow.g4` (`setStatement` moved LAST in `microflowStatement`), `mdl/visitor/visitor_microflow_statements.go` (`buildSetAggregate` replaces `extractVariableAndAttribute`), `mdl/visitor/visitor_microflow_expression.go` (`buildListAggregateAsFunction` appends the expression argument) | **A permissive alternative belongs last.** `$X = <expr>` overlaps every `VARIABLE EQUALS <function-call>` statement in the rule — aggregates, list operations, RANGE — and ANTLR's ALL(*) picks the lowest-numbered alternative that matches, so a new general form silently steals from every specific one above it. **The measurement trap that let this ship**: the `SET?` change was swept with a control binary over every `mdl-examples/**/*.mdl` and found no difference — but with `mxcli check`, which parses and validates and never serializes. This defect lives between the AST and the BSON, where only `exec` + `mx check` can see it. Sweeping with `check` proves the grammar still *parses*; it proves nothing about what the visitor *builds*. For a grammar change, the control sweep must run the integration gate (`go test -tags integration -run TestMxCheck_DoctypeScripts`), not `check`. Fix proven by reverting both halves and watching the new tests fail with the reported symptom. Tests `mdl/visitor/visitor_microflow_aggregate_test.go`. Upstream CI on the ako→mendixlabs sync PR |
-| `DESCRIBE microflow` prints a bare `else` on a `split type` the author never wrote one for, and each describe→exec pass accumulates another | 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 | `mdl/executor/cmd_microflows_show_helpers.go` (the `elseFlow` block in the inheritance-split traversal) | 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) |
-| `alter page … set <prop> on <widget>` reports `widget "X" not found` when the widget sits inside a datagrid column rendered as `customContent`; only CREATE OR REPLACE PAGE can touch it | `findInWidgetChildren`'s pluggable branch searched the grid's own `Object.Properties[].Value.Widgets` and matched columns by derived name, but never descended into a COLUMN's own content. Columns live at `Object.Properties[columns].Value.Objects[]`; their widgets are one level deeper at `Properties[content].Value.Widgets[]` | `mdl/backend/pagemutator/mutator.go` (`findInWidgetChildren`, the columns loop) | Descend into each column's `Properties[].Value` and reuse `findInWidgetArray(…, "Widgets", name)`. **Address by the nested widget's OWN name, not a `grid.column.widget` path**: DataGrid2 columns carry no stored name in the MPR (see `findBsonColumn`), so a column segment could only be a derived name that changes when the caption is edited — a path that goes silently stale. Keep the existing column-by-derived-name lookup working (a test pins it, or the descent could shadow it). Test `TestFindBsonWidget_InsideCustomContentColumn`; repro `mdl-examples/bug-tests/834-alter-customcontent-column-widget.mdl`. Issue #834 |
-| `alter page … set Caption = '…' on <actionbutton>` fails with `widget has no Caption property` — for EVERY action button, nested or top-level | An ActionButton has no `Caption` document: its caption is a `Forms$ClientTemplate` under **`CaptionTemplate`** (Template → Items[] → Translation.Text), the same shape `setWidgetContentMut` already walked for `Content`. `setWidgetCaptionMut` only looked for `Caption` | `mdl/backend/pagemutator/mutator.go` (`setWidgetCaptionMut`, `setClientTemplateText`) | Fall back to `CaptionTemplate` via a shared `setClientTemplateText` helper, which `setWidgetContentMut` now uses too. **Found while fixing #834 — check whether a symptom reproduces OUTSIDE the reported context before attributing it**: this failed on a top-level button as well, so it was a second, independent defect and the #834 finder fix alone would not have made the reporter's command work. When a widget property will not set, dump the widget's key list (`mxcli bson dump --type page`) before assuming the setter is wired — the field is often stored under a different, template-shaped key |
-| 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."` | `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* | `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) | **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 |
-| `create or modify external entity Mod.E (… Countable: false)` — touching only an entity-level property — detonates every attribute: `[CE6612] "Attribute 'circuitId' of external entity 'Stg_Circuit' is not supported."`, one per attribute, leaving a project that cannot build | Not the executor: it already preserves attributes it was not asked to change (`if len(attrs) > 0`). One layer down, `attributeFromGen` handled `StoredValue` and `OqlViewValue` but **not** `Rest$ODataMappedValue`, so every attribute of an external entity read back with no `RemoteName`, and the writer's `isExternal && a.RemoteName != ""` arm then fell through to a plain StoredValue on the next read-modify-write | `mdl/backend/modelsdk/domainmodel.go` (`attributeFromGen` gains the `ODataMappedValue` / `ODataMappedPrimitiveCollectionValue` arms) | **The attribute-level half of #782**, which fixed the entity level and stopped there — when a read-modify-write loses data, check every *nesting level* of the read, not just the one named in the report. A polymorphic `Value` switch that silently ignores a variant is the shape to look for: it compiles, it reads, and it drops. Reproduce with a **local metadata file** (`MetadataUrl: './contract.xml'`) — no server needed, and the import is the same code path. Also learned here: the reported attribute *rename* (`name` → `Stg_Circuitname`) is a different thing entirely — it happens at import, from `reservedEntityAttrNames`, and `name` is **not** actually reserved (verified: Mendix builds an external entity with an attribute literally named `name`). Tests `external_entity_read_test.go`. mxcli-formula1 #25 |
-| `execute database query … dynamic $Sql` reaches the runtime as the literal string `'$Sql'` — `Parser Error: syntax error at or near "$"` from the database, not from Mendix. Runtime-built SQL, and therefore query pushdown, is impossible | The builder quoted any dynamic query not already starting with a quote — right for `dynamic 'SELECT …'`, wrong for an expression — and the AST kept one `DynamicQuery` string whichever branch of the grammar produced it, so nothing downstream could tell them apart | `mdl/ast/ast_microflow.go` (`DynamicQueryIsExpression`), `mdl/visitor/visitor_microflow_actions.go` (set it in the `expr` branch), `mdl/executor/cmd_microflows_builder_calls.go` (`dynamicQueryExpression`) | **When a grammar has two alternatives that mean different things, the AST must record which one fired** — a shared field plus a "does it look quoted?" heuristic is a guess, and the workaround users find (`dynamic '' + $Sql`, which starts with a quote so the heuristic leaves it alone) is proof the heuristic is the bug. Verified by reading the stored BSON rather than by describe: `DynamicQuery\x00\x05\x00\x00\x00$Sql` — five bytes, no quotes. Tests `cmd_microflows_dynamic_query_test.go`. mxcli-formula1 #21 |
-| `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 | 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 | `mdl/executor/cmd_odata.go` (`metadataFetchAuth`, `metadataAuthFromStmt`, `fetchODataMetadata`), `mdl/ast/ast_odata.go` + `mdl/visitor/visitor_odata.go` (`HttpUsernameIsLiteral` / `HeaderDef.ValueIsLiteral`) | **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 |
-| 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 | The modify branch updated the service's scalar properties and never touched `EntityTypes` / `EntitySets` | `mdl/executor/cmd_odata.go` (modify branch rebuilds published entities via `astEntityDefToModel`, and carries `AllowedModuleRoles` through) | **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 |
-| `create external entities from` a contract that restricts capabilities produces a project that will not build: `'Seasons' is marked Countable=False in the OData service, but True in the app`, `'latitude' is marked Filterable=False …` — one per restricted resource or property | Insert/Update/Delete restrictions were parsed; **Count/Filter/Sort were not**, so the import had nothing to honour and defaulted all three to true — on the one command whose entire job is fidelity to the contract | `mdl/types/edmx.go` (`EdmEntitySet.Countable`, `NonFilterableProperties`, `NonSortableProperties` + the three `applyCapabilityAnnotations` arms), `mdl/executor/cmd_contract.go` | An unannotated set still means countable/filterable/sortable — **silence in a contract is not a restriction**, it is OData's own default, so `nil` and `false` must stay distinguishable (`*bool`, as with the publish-side query options). The generated entity is compared against the contract at *build* time, so anything the contract can say is something the importer must be able to read. Tests `mdl/types/edmx_test.go`. mxcli-formula1 #24 |
-| 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 | `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` | `mdl/executor/cmd_contract.go` (`reservedEntityAttrNames` loses one entry; the import now reports the renames it does make) | **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 |
-| `MOVE JAVA ACTION …` / `MOVE ODATA SERVICE …` is a parse error (`no viable alternative at input 'MOVEJAVA'`), and neither `CREATE` form takes a folder clause — so those documents can never leave the module root from MDL | The `moveStatement` rule listed seven doctypes and nothing else; the missing ones were never unimplemented, just unlisted | `mdl/grammar/MDLParser.g4` (two alternatives), `mdl/ast/ast.go`, `mdl/visitor/visitor_entity.go` (dispatch **and** the MOVE FOLDER discriminator), `mdl/executor/cmd_move.go`, backend `MoveJavaAction` / `MovePublishedODataService`, `sdk/mpr` exports `MoveUnitByID` | Both reduce to the existing reparent primitive — a top-level document move is one containment row, so a new doctype is a list entry plus a lookup, not new machinery. **Watch the discriminator**: `MOVE FOLDER` is told apart from a document move by the *absence* of a doctype keyword, so every keyword added to the rule must also be added to that condition or a folder move starts parsing as a document move. **Verify placement by differential count, not by reading the model**: run the script with and without the MOVE lines and diff `select ContainmentName, count(*) from Unit` — three new Folders rows (a nested path creates two) and an unchanged Documents count says reparented rather than copied or dropped. Grepping blobs for names is a trap; stock modules are full of the same words. Tests `visitor_move_doctypes_test.go`, example in `18-folder-examples.mdl` — which must sit **before** that script's `drop module`, a mistake the integration gate caught and `mxcli check` did not. mxcli-formula1 #32 |
-| `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 | `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 | `mdl/executor/cmd_odata.go` (`resolveCredential`, `constantReference`, `designTimeConstants`) | **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 |
-| An app themed dark still shows light-mode drop shadows under the datagrid's filter-operator popover and dropdown filter lists | The generated widget layer re-pointed `.column-selectors` but not the four rules in `_datagrid-filters.scss` that bake the same two-layer shadow. Each already takes its *background* from `--bg-color-secondary`, so Atlas re-colours the panel and leaves the shadow — which is why it reads as a partial fix rather than an untouched widget | `cmd/mxcli/theme/assets/*/files/theme/web/_mxcli-widgets.scss` | **Read the selectors out of the shipped `themesource/`, not the bug report** — the fourth here is `.dropdown-container .dropdown-list`, nested under a parent the report did not name. **Verify in the compiled CSS, never the source** (the §33 rule): apply the theme to a real project, run `mxbuild --target=deploy --java-home=… --java-exe-path=…`, then grep `theme-cache/web/theme.compiled.css` and check the *line number* — the fix must land after the widget module's own rule (30794 vs 27765 here) or the cascade eats it. A theme-cache file older than the SCSS you just wrote is a stale compile, and mtime is the cheapest way to catch it. mxcli-formula1 #33 / suggested issue 4 |
-| 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 | The read side of folders was simply never built. `MOVE`/`DROP FOLDER` write containment; nothing read it back | 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` | **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 |
-| Every page in a locally-run app is a black screen. `mxcli check` passes, the build reports success, the runtime log is quiet, `curl /` returns 200 with a valid HTML shell, and every OData service answers — only a browser sees it. It also comes and goes between runs of the same command at the same version | `run --local` bundles the browser client at step 5b, then the runtime boot runs Gradle `clean-custom-classes compile package`, whose package pass repopulates `deployment/web` and takes `dist/` with it — deleting the bundle 51 seconds after the same command wrote it. It only bites when Gradle has work to do (a new Java action, a full recompile), which is why the app boots fine for weeks and then stops | `cmd/mxcli/docker/webclient.go` (`WebClientBundled`, `EnsureWebClientBundle`, `ReportLostWebClientBundle`), `cmd/mxcli/docker/runlocal.go` (step 6b, after the boot), `cmd/mxcli/docker/localapp.go` (headless boots warn instead of paying ~30s) | **A pre-condition established before a step that rewrites the same directory is not a post-condition** — verify after, not before. The guard is a `stat` when the bundle survived, which is what makes it affordable at every boot; re-ordering the bundle to after the boot instead would leave the app reachable-but-blank for ~30s on every cold start. **`curl /` returning 200 is not evidence the app renders**: the shell is served by the runtime, the client by a file the shell references. The one-line check is `curl -o /dev/null -w '%{http_code}' <app>/dist/index.js`. **Do not silently pay for a repair on a path that does not need it** — `test --local` destroys the bundle too, but tests are headless, so it prints the loss and the remedy rather than spending 30s on a two-second loop. Tests `webclient_bundle_test.go`; both controls run (guard never fires → the wipe test fails; guard always fires → the survivor test fails). mxcli-formula1 §35 |
-| `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 | 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 | `mdl/executor/cmd_pages_describe_output.go` (`pageActionParameters`, `targetPageParameterNames`), stale comment corrected in `sdk/mpr/writer_widgets_action.go` | **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 |
-| `create or modify odata service` silently revokes the service's access; the next build fails with "At least one allowed role must be selected for the published OData service to be accessible." Re-granting fixes it until the next modify | `serializePublishedODataService` never wrote `AllowedModuleRoles`. The document is serialized wholesale and written with `updateUnit`, so a field the serializer omits is not left alone — it is deleted. The grants were read correctly and carried through the executor, then dropped one layer down | `sdk/mpr/writer_odata.go` (`AllowedModuleRoles`, marker 1 / BY_NAME, matching the working `GRANT` path's `makeMendixStringArray`); stale executor comment corrected in `mdl/executor/cmd_odata.go` | **A wholesale re-serialization deletes every field it does not write, so the writer's field list is a data-retention policy.** Audit it against the parser, not against the struct — the round trip is the contract. **Where you look decides what you conclude**: an earlier pass looked for this loss at model level, found the value present and carried, and recorded "reported but does not reproduce" — the loss only exists after the BSON round trip, so a model-level check could never have seen it. When a report says a value disappears, reproduce at the persistence boundary before disbelieving it. For the marker, copy the shape from the code path that already works (`GRANT` writes marker 1 and builds fine) instead of reasoning from an unrelated type. Tests `writer_odata_test.go`; the control (field omitted again) reproduces the empty-grants document. mxcli-formula1 §26 |
-| `.ai-context/skills/` still carries the previous release's guidance after the mxcli binary is upgraded — binary rebuilt at 12:05, skills stamped the day before — with no warning that they disagree | The skills are embedded in the binary and written exactly once, by `mxcli init`. Nothing re-ran init on upgrade, and nothing compared what was on disk against what the binary carried | New `cmd/mxcli/init_skills_sync.go` (`syncAIContextSkills`, `reportSkillSync`), `--sync-skills` flag in `cmd/mxcli/init.go`, and a sync step in the SessionStart bootstrap in `cmd/mxcli/init_hook.go` | **Stale guidance is worse than missing guidance**, because an agent reads it with identical confidence either way — so the failure mode is silent and confident. Fix it where it is consumed, not where it is authored: the SessionStart bootstrap already runs on every session and can fetch the binary, so it is the one place guaranteed to execute immediately before an agent reads the files. Two properties keep an every-session job acceptable: **write only what differs** (an mtime that moves every session makes "when did this last change" unanswerable — a test asserts the mtime holds) and **stay silent when current**. Never fatal: a skills refresh must not block a session, hence `|| true`. A test asserts the bootstrap script actually calls it *before* the exec'd setup, since a step ordered after an `exec` never runs. Tests `init_skills_sync_test.go`; the control (write-once) leaves the stale file in place. mxcli-formula1 §16 |
-| `publish entity … (TopSupported: No)` (or `SkipSupported`/`Countable`) parses, `DESCRIBE` reads it back as `No`, and the published `$metadata` still advertises `true`. A client then believes paging works when nothing implements it | `serializeEntitySet` hardcoded all three `QueryOptions` to `true`, ignoring the `*bool` fields the model already carried — the AST/model/DESCRIBE half of the feature shipped without the writer half | `sdk/mpr/writer_odata.go` (`boolOrTrue`, entity-set `QueryOptions`) | **A capability annotation on a microflow-backed resource is load-bearing, not decorative.** Mendix applies *no* query options to a read-microflow resource — it hands the request over and returns what comes back — so the annotation is the only thing a client has to go on, and an over-claim is not cosmetic: the client reads a whole collection believing it is a page. **Check the writer whenever a property round-trips correctly through DESCRIBE**: DESCRIBE reads the model, so a model-only feature describes perfectly and publishes wrong, and the round-trip test everyone reaches for cannot see it. A tri-state `*bool` needs an explicit nil policy at the boundary (`nil` = the platform default, only an explicit `false` opts out) or the pointer is pointless. Tests `writer_odata_test.go`; the control (hardcoded true) reproduces the over-claim. mxcli-formula1 §20 |
-| 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 | 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 | 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` | **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 |
-| No way to see what a running app's subsystem is doing: everything logs at `INFO`, the detail is not in the log at all, and raising the whole runtime to `TRACE` is unusable on a busy app | Nothing in mxcli drove the runtime's per-node log levels, though the M2EE admin API has exposed them all along | New `cmd/mxcli/docker/loglevels.go` (`GetLogSettings`, `SetLogLevels`, `NormalizeLogLevel`, `MatchLogNodes`), `cmd/mxcli/cmd_log.go` (`mxcli log list` / `log set`), documented in `.claude/skills/mendix/analyze-runtime.md` | **Probe an undocumented API before designing the command around it.** Every fact here came from a live 11.12.1 runtime: `get_log_settings` requires one of `node`/`subscriber`/`sort`; `sort` accepts only `node` and `subscriber`; `set_log_level` takes `{"nodes":[{name,level}],"force":bool}`. **The HTTP response for an AdminException says only "See logging output for details" — the actual message ("Please specify node, subscriber or sort option in params", "Unknown sort option: name", "Unknown LogNode X. Use the 'force' parameter…") is in the runtime log**, so probe with the runtime log open or you learn nothing. `force` means "allow a node that does not exist yet" and **permanently registers the name**, so a typo becomes a real empty node — hence it is opt-in, and an unknown node is an error by default. **Resist the subsystem-specific command**: this was proposed as `mxcli odata trace`, but `set_log_level` takes a list of nodes, so the primitive is generic and the OData knowledge belongs in docs. **The node list is a property of the APP, not of Mendix** — a node appears only once something registers it. A first pass concluded "there is no log node for a published OData service" from a project that had none; adding one service turns 57 nodes into 58 and `OData Publish` (with a space) appears, logging the full incoming URI at TRACE — exactly the question that motivated the command. Enumerating capabilities against one sample app and generalising is the trap; `log list` against *this* app is the answer. Distinguish "cannot reach the admin API" from "the runtime refused the request" (`ErrAdminUnreachable`) or the wrong hint buries the real one. Tests `cmd_log_test.go`, `loglevels_test.go`; verified end-to-end against a booted runtime (both arg forms, multi-node, typo refused, `--force` accepted, unreachable port). mxcli-formula1 suggested issue 4 |
-| A headless browser cannot log in to an app started with `--hub`, so every screenshot silently shows the login page and rendering defects survive every other check | Under `--hub` the runtime boots with the public **https** root URL, so it marks session cookies `Secure` and prefixes them `__Host-`; a browser on a non-trustworthy http origin cannot store them | `cmd/mxcli/docker/screenshot_login.go` — the login browser context declares `X-Forwarded-Proto: http` when the target is http (Mendix 10.24+ lets that header override `ApplicationRootUrl`) | **The reported cause did not reproduce as stated, and saying so is part of the fix.** On 11.12.1 an https root URL does *not* block a headless browser on `127.0.0.1`: loopback is a **trustworthy origin**, so Chromium accepts `Secure`/`__Host-` cookies there — the app rendered clean, no console errors, no failed requests. The mechanism is real only for a **non-loopback** http origin (a container hostname, a LAN address). Fix shipped anyway because the header is *accurate* rather than a workaround (the request genuinely is http), it costs nothing on an already-http root URL, and real users over https are unaffected. Verified at the layer the bug lives in: the captured Playwright storage state goes from `__Host-XASSESSIONID(secure=true)` to `XASSESSIONID(secure=false)`. **`curl` cannot see this class of bug and neither can a loopback browser** — when a report blames cookie flags, check whether the origin is trustworthy before believing the flags are the blocker. mxcli-formula1 §38 / suggested issue 7 |
-| A `--` comment written between two operands of a Mendix expression ends up **inside** the expression; the build fails **CE0117** "Error(s) in expression". `mxcli check` passes and `DESCRIBE` round-trips the comment, so nothing before mxbuild objects | `extractOriginalText` reads the raw input stream between two token positions — which is exactly what preserves an expression's spacing, and also drags in every token the lexer sent to a hidden channel. MDL's `--` and `/* */` are `-> skip`, so they never appear in `ctx.GetText()` but always appear in the source slice | `mdl/visitor/visitor_helpers.go` (`stripMDLComments`, `extractExpressionText`), applied at the six microflow-expression sites in `visitor_microflow_statements.go` / `visitor_microflow_actions.go` | **The ANTLR trap: `ctx.GetText()` excludes hidden tokens, a source-interval slice includes them.** Any code reaching for original text to preserve formatting inherits every comment in that span. **Replace a comment with whitespace, never with nothing** — `1 --c\n+ 2` must not become `1+ 2`, and `'a'--c\n'b'` must not weld into one token. **Respect single-quoted strings**: a Mendix string may legitimately contain `--` or `/*`, and stripping those corrupts the value (tested both, plus the `''` escape that keeps a string open). **Left OQL alone on purpose** — `visitor_entity.go` uses the same helper for view-entity queries, where `--` is legitimate SQL comment syntax; stripping it would change a different language's meaning. **The unit test alone would not have caught a wiring mistake**: it still passed with `extractExpressionText` bypassed, and only the mxbuild run (1 error → 0, same script, same project) proved the call sites were converted. Tests `visitor_strip_comments_test.go`, repro `mdl-examples/bug-tests/comment-in-expression.mdl`. mxcli-formula1 §34 / suggested issue 11 |
-| 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 | 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 | `mdl/executor/validate_odata_read_contract.go` (suggestion text), `mdl-examples/doctype-tests/10-odata-examples.mdl`, `.claude/skills/mendix/odata-data-sharing.md` | **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 |
-| 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 |
-| A navigation menu item cannot be given an icon at all — the grammar has no `ICON`, and every item mxcli writes gets `Icon: null`, so a menu authored in MDL is flat text next to one authored in Studio Pro | The syntax was never added, and the reason it stayed unadded is instructive: the metamodel names the element `Pages$IconCollectionIcon`, but Mendix **stores** it as `Forms$IconCollectionIcon` — one more instance of the "Form was the original term for Page" rename CLAUDE.md documents for `ShowFormAction`. There was no way to know that from the metamodel alone, and inventing a `$Type` for a polymorphic child is the failure mode where mxbuild builds green and Studio Pro cannot open the document | `mdl/grammar/MDLParser.g4` (`navMenuItemDef`, both alternatives), `mdl/ast/ast_navigation.go`, `mdl/visitor/visitor_navigation.go` (positional `AllQualifiedName()` — the PAGE/MICROFLOW target and the icon share one indexed list), `mdl/types/navigation.go`, `mdl/executor/cmd_navigation.go` (`convertMenuItemDef`, `printMenuMDL`), `sdk/mpr/writer_navigation.go` (`buildMenuIconBson`), `mdl/backend/modelsdk/navigation_write.go`, `sdk/mpr/parser_misc.go`, `mdl/backend/mpr/convert.go` (`convertNavMenuItem` is a field-by-field copy and drops anything new) | **The icon is a `qualifiedName`, not a string** — it is a reference into the model, so it is spelled like every other reference (ADR-0003). Atlas names are hyphenated, and `align-center` lexes as HYPHENATED_ID, so that *segment* is double-quoted: `ICON Atlas_Core.Atlas."align-center"`. The DESCRIBE emitter (`quoteQualifiedName` in `mdl/executor/qualified_name_quoting.go`) must therefore decide quoting per segment, and **must not reuse `mdlIdent`**: mdlIdent quotes anything not lexing as a bare IDENTIFIER, but a qualifiedName segment is an `identifierOrKeyword`, which accepts keywords — and `home`, `user`, `add`, `folder` are all keyword tokens, so mdlIdent would quote nearly every icon. Decide acceptance by running the real parser on the segment, never a hardcoded keyword list. The invariant worth testing is not "which names get quotes" (I guessed that wrong twice) but **"does the emitted statement re-parse"** — feed DESCRIBE output back through `visitor.Build`. **Get the reference before writing the BSON.** A Studio Pro-authored project (`ako/mxcli-ledger`) settled in one dump what no amount of metamodel reading could: the storage name, the field (`Image`, a 3-part `Module.Collection.name`), the exact key set (`$ID`/`$Type`/`Image`, nothing more), and that **all three variants coexist** — `Forms$IconCollectionIcon{Image}`, `Forms$ImageIcon{Image}` (indistinguishable by name alone; it points into an *image* collection), `Forms$GlyphIcon{Code: int}`. Only the first is written; DESCRIBE emits a `-- icon … is not reproducible` comment for the other two rather than an `icon` clause that would convert the variant on replay. To dump a v2 unit: `grep -rl 'Menus$MenuItem' mprcontents` then `bson.Unmarshal` into a `bson.D`. **`mx check` reporting 0 errors is not the proof here** — its deserializer tolerates unknown properties; the proof is diffing the written element against the Studio Pro one (done: byte-shape identical, same key order). Icon *names* are also not guessable — `Atlas.list` and `Atlas_Filled.user-check` do not exist while `list-bullets` and `user` do; verify against the collection. **Second trap, in the read path**: `codec.Decode` returns a bare `*element.Base` for an *unregistered* `$Type` but a generated struct (which only *embeds* Base) for a registered one, so `icon.(*element.Base)` silently returns nothing for exactly the variants that exist in real projects — DESCRIBE printed every icon under `legacy` and none under `modelsdk`. Assert on `interface{ Raw() bson.Raw }`, which both shapes satisfy. A unit test passing `nil` did not reach this; **running `describe` against a real Studio Pro project under both `MXCLI_ENGINE` values did**, and that engine-vs-engine diff is the cheapest way to find a read-path divergence. Note `modelsdk/codec` is on bson **v2** while `mdl/backend/modelsdk`'s write path is on v1 — a test touching both needs an alias. Tests `sdk/mpr/writer_navigation_icon_test.go`, `mdl/visitor/visitor_navigation_icon_test.go`, `mdl/executor/cmd_navigation_icon_test.go`, `mdl/backend/modelsdk/navigation_icon_test.go`; example `mdl-examples/doctype-tests/11-navigation-examples.mdl`. mxcli-formula1 #9 |
-| `authentication microflow Module.Auth` on a published OData service parses, checks clean and reports `Created OData service` — then the build fails **CE0333** "Please select a microflow to use for authentication", and `DESCRIBE` shows `authentication Microflow` with no name. Custom authentication is unreachable from MDL, which matters because it is the only way to avoid a full BCrypt hash on every OData request (60–80% of a page turn measured) | The grammar had accepted `MICROFLOW qualifiedName?` all along and both writers already serialized `AuthenticationMicroflow` from `svc.AuthMicroflow` — but nothing ever *assigned* it. `parseODataAuthTypes` recognised the `microflow` keyword and discarded the name, so the field was only ever populated by reading a model Studio Pro wrote. DESCRIBE then emitted it as a comment (`-- Auth Microflow: …`), so a custom-auth service could not round-trip either | `mdl/ast/ast_odata.go` (`AuthMicroflow`), `mdl/visitor/visitor_odata.go` (`parseODataAuthTypes` returns the name), `mdl/executor/cmd_odata.go` (assign on create AND modify; `odataAuthClause` for DESCRIBE), `mdl/executor/validate_odata_auth.go` (MDL-ODATA04) | **When a feature "silently drops" one field, check whether the plumbing already exists at both ends** — here only the middle assignment was missing, so the fix was ~10 lines across four files rather than a new write path. The grammar already parsed the name: `at.QualifiedName()` was simply never read. **DESCRIBE emitting a value as a comment is the same defect class as dropping it** (§39): the output looks complete and replays into a model the build rejects — so the round-trip test asserts the emitted clause re-parses to the same microflow, not that it contains some text. Two Mendix rules bound the feature and are easy to hit while verifying: **CE0333** if no microflow is named (now MDL-ODATA04 at check time), and **CE6600** "App security is off, but custom authentication is enabled" — so a fixture project needs `alter project security level prototype` before it can prove anything. That second one is why this is NOT in the doctype gate: those projects run with security off, so any custom-auth service there fails CE6600 regardless of correctness. Verified instead by writing the service from MDL into a real project and running `mx check` (0 errors). Tests `mdl/executor/odata_auth_microflow_test.go`. mxcli-formula1 §40 |
-| MDL cannot declare an OData action. `publish microflow …`, `publish action …` and every variant is a parse error at `missing ENTITY`, so a service's `$metadata` has an `EntityContainer` with `EntitySet` elements and no `ActionImport` — and every parameterised resource has to be modelled as an entity set that echoes its own arguments back as columns | `createODataServiceStatement` admitted `publishEntityBlock*` and nothing else. Unlike the custom-auth gap the write path was missing too: neither `sdk/mpr/writer_odata.go` nor `mdl/backend/modelsdk/odata_write.go` had a single reference to `PublishedMicroflow`, though `modelsdk/gen/odatapublish` has `NewPublishedMicroflow()`/`NewPublishedMicroflowParameter()` with every setter wired | `mdl/grammar/domains/MDLService.g4` (`publishMicroflowBlock`, reusing `exposeClause`), `mdl/ast/ast_odata.go`, `mdl/visitor/visitor_odata.go`, `model/types.go` (`PublishedMicroflow`/`…Parameter`), `mdl/executor/cmd_odata_actions.go` (resolve the microflow, derive types), `sdk/mpr/writer_odata.go` + `parser_odata.go`, `mdl/backend/modelsdk/odata_write.go` + `odata_read_detail.go` + `integration_read.go`, `mdl/executor/cmd_odata.go` (`printPublishedMicroflowMDL`) | **With no Studio Pro reference available, derive every shape from something already proven rather than stopping.** Property names/kinds came from the generated metamodel; the `Module.Microflow.Param` form of the `MicroflowParameter` by-name ref from `published_rest_write.go`, which already ships it; the `DataTypes$ObjectType`/`ListType` `Entity` key and `EnumerationType` `Enumeration` key from `serializeMicroflowDataType`. **Do not restate what the model already declares** — parameter types and the return type are read off the microflow, so they cannot drift. Store a data type as **kind + ref, never one string**: `Module.X` cannot say whether X is an entity or an enumeration. **`mx check` reporting 0 errors is near-worthless for a NEW element type** (mxbuild ignores unknown properties); the test that settles it is to delete the referent — dropping the microflow makes mxbuild answer `CE1613 … at Published microflow parameter DriverId from published microflow RecordPrediction`, naming the elements back in its own vocabulary. **A test that calls the emitter helper directly does not prove the emitter is wired**: reverting the loop in `outputPublishedODataServiceMDL` left every `printPublishedMicroflowMDL` test green, so the DESCRIBE test goes through the real entry point. Also note the replay control does NOT reproduce a missing emitter, because `create or replace` preserves microflows when the statement supplies none — the defect is an incomplete description, not in-place loss. Tests `mdl/visitor/visitor_odata_action_test.go`, `mdl/executor/odata_auth_microflow_test.go`; example `mdl-examples/doctype-tests/10-odata-examples.mdl`. mxcli-formula1 §47.1 |
-| A service that correctly declares `TopSupported: No` cannot be consumed: `sql <alias> generate connector` / contract import produces an app whose external entity says `Supports $top = True`, and the **consumer** build fails **CE6630** "'Seasons' is marked supports $top=False in the OData service, but True in the app". The publisher is right, the contract is right, and only the generated consumer is wrong | Two layers, and the first hid the second. `applyCapabilityAnnotations` began with `if ann.Record == nil { continue }` — but `TopSupported`/`SkipSupported` are **standalone boolean terms** (`<Annotation Bool="false" Term="Org.OData.Capabilities.V1.TopSupported"/>`), not the record shape that `InsertRestrictions` and friends use, so the parser discarded them and `EdmEntitySet` had no field to hold them. `applyExternalEntityFields` then hardcoded `ent.SkipSupported = true; ent.TopSupported = true` — directly beside `Countable`, which *was* derived, and under a comment explaining the CE6630 mechanism the hardcode went on to trigger | `mdl/types/edmx.go` (`EdmEntitySet.TopSupported`/`SkipSupported`, `xmlCapabilitiesAnnotation.Bool`, standalone branch in `applyCapabilityAnnotations`), `mdl/executor/cmd_contract.go` (`applyExternalEntityFields`) | **The OData capabilities vocabulary has two annotation shapes, and a parser written against one silently drops the other.** Record terms (`InsertRestrictions`, `CountRestrictions`) wrap a `<Record>`; scalar terms (`TopSupported`, `SkipSupported`) carry `Bool` on the annotation element itself. The `Record == nil` guard read as "malformed, skip" when it actually meant "different, valid shape" — grep any capability parser for that guard before adding a term. **Absent must stay `true`, not `false`**: OData's own default is supported, so a tri-state `*bool` resolved as `p == nil || *p` is load-bearing — defaulting to false would invert CE6630 for every unannotated service, i.e. every service that worked before the fix. **This is the prerequisite for MDL-ODATA03's advice being followable**: the rule tells an author to declare `TopSupported: No` on a read-microflow resource, which was previously a trap that broke consumers. A fixture for this is worth capturing from a live `$metadata` rather than hand-written — the standalone shape is what made the bug, so a hand-built record-shaped fixture would have tested the wrong thing. Tests `mdl/types/edmx_test.go` (`TestParseEdmx_StandaloneTopAndSkipSupported`, plus a control proving record terms still parse), `mdl/executor/cmd_contract_capabilities_test.go`. mxcli-formula1 §42 |
-| `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 | 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* | `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` | **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 |
-| `mxcli run --local` refuses to boot — *"port 6643 is already in use — a previous 'mxcli run --local' … is likely still serving on it"* — and names a process the user already killed. The guard is right to refuse; the diagnosis is a guess, and the recovery it suggests is a three-command `pgrep` hunt whose own pattern (`pgrep -f 'mxcli run'`) matches the shell it is typed into | Two different situations printed one message. mxcli **does** reap its children on Ctrl-C/SIGTERM (`procgroup_unix.go` puts mxbuild's JVM, the runtime and the bundler each in their own process group and signals the group), so a held port after a graceful stop is a *foreign* listener. But `kill -9`, a crash, or a reaped container runs no handler at all, and then it really is the previous run's orphan. The guard could not tell them apart because it never asked who held the port | `cmd/mxcli/docker/portowner_linux.go` (`listenerOnPort`, `parseListeningInodes`, `pidForSocketInode`), `portowner_other.go` (non-Linux stub), `portguard.go` (`portCulpritAdvice`), wired into `checkTargetPortsFree` (`runlocal.go`) and `checkLocalAppPortsFree` (`localapp.go`) | **Resolve the port owner from `/proc`, never by shelling out to `lsof`/`ss`** — both are routinely absent from slim containers, and needing a subprocess to explain why a boot failed is its own failure mode. `/proc/net/tcp{,6}` gives the socket inode; scanning `/proc/<pid>/fd` for `socket:[<inode>]` gives the pid. **Read `tcp6` as well as `tcp`**: a JVM binding "localhost" lands on `[::1]` or dual-stack `[::]` as often as `127.0.0.1`, and its local_address is a 128-bit hex blob, not the 32-bit one. **Filter on state `0A` (TCP_LISTEN)** — an ESTABLISHED socket on that port is a *client*, and naming it would tell the user to kill their own browser. **Report the two cases differently**: a leftover of a previous run gets `kill <pid>`, a foreign listener gets "pick another port" and no kill suggestion, because offering to kill a stranger's process is worse advice than the vague message it replaced. Keep the guard **detection-only** — reaping someone else's process stays the user's call. **Three test traps hit in a row here.** (1) The live-IPv6 test only ever *skipped* (no IPv6 in the container), so the tcp6 parser was effectively untested — assert against captured kernel output instead. (2) A parser test calling `parseListeningInodes` directly does not prove `listeningInodes` *opens* both files: deleting `/proc/net/tcp6` from the list left every test green. (3) Making the list a `var` so a test can point it at fixtures then means the test no longer covers the **shipped** default either — assert the default's contents before overriding it. Only the third version of that control failed. The best test in the file is the cheapest: bind a port in the test process and demand `listenerOnPort` return `os.Getpid()` — it cannot pass by accident. Tests `cmd/mxcli/docker/portowner_linux_test.go`. mxcli-formula1 suggested issue 8 |
-| `create external entities from` a service where an entity set is wholly unfilterable/unsortable generates an app the contract contradicts: **28 × CE6630** on one service — "'message' is marked Sortable=False in the OData service, but True in the app". The publisher is right, the `$metadata` is right, only the generated consumer is wrong | `FilterRestrictions`/`SortRestrictions` have **two shapes**, and only one was read. `applyCapabilityAnnotations` pulled `NonFilterableProperties` out of the record and ignored the record's own `Bool` property value, so `Filterable: !nonFilterable[p.Name]` evaluated `true` for every property of a set that had declared nothing filterable. This is the §42 Top/Skip bug one layer along — same vocabulary, same two-shapes cause, different term | `mdl/types/edmx.go` (`EdmEntitySet.Filterable`/`Sortable`, the `Filterable`/`Sortable` cases in `applyCapabilityAnnotations`, and the `AttrFilterable`/`AttrSortable` accessors), `mdl/executor/cmd_contract.go` (`createExternalEntities` calls the accessors) | **Mendix picks the annotation shape by arithmetic, not preference.** It lists `NonFilterableProperties` when SOME attributes are filterable and emits a bare `<PropertyValue Bool="false" Property="Filterable"/>` when NONE are, because then there is no list to write — so both shapes appear in **one document** on different entity sets, and an entity exposing only a KEY reliably produces the whole-set form. A fixture with just the list shape tests the half that already worked. **After fixing one term in a vocabulary, sweep the siblings**: §42 fixed Top/Skip by teaching the parser about standalone booleans and stopped there; Filterable/Sortable had the same defect and were found only because a consumer app failed to build. Grep the whole `applyCapabilityAnnotations` switch for terms whose Bool is never read. **Put both shapes behind one accessor** (`AttrFilterable`) rather than two fields the caller must remember to AND together — the caller then cannot consult one and forget the other, which is exactly how this arose, and the nil-safe receiver deletes the `entitySet != nil` dance at the call site. Absent still means `true`: OData's default is allowed, and defaulting to false would invert CE6630 for every unannotated service. Tests `mdl/types/edmx_test.go` (`TestParseEdmx_WholeSetFilterAndSortRestrictions`, plus a control proving the list shape still parses); both controls reproduce (ignore the record Bool → the whole-set test fails with the CE6630 message; drop the check inside `AttrFilterable` → same). mxcli-formula1 §48 |
-| A project is generated with no documentation anywhere — Java actions, Java action parameters, entities, microflows — and nothing says so. `mxcli check` and the build both pass, because documentation is never load-bearing | `QUAL002` existed but reached only entities and microflows. Java actions were not reachable from Starlark **at all** (no `java_actions()` builtin), and a Java action's parameters were not reachable from anywhere: the catalog stored a parameter *count* and discarded each parameter's `Description` | `mdl/catalog/tables.go` (`java_action_parameters_data` + view, `CatalogSchemaVersion` bump), `mdl/catalog/catalog.go` (`Tables()` registry), `mdl/catalog/builder_modules.go` (insert parameters), `mdl/linter/context.go` (`JavaActions()` with parameters attached), `mdl/linter/starlark.go` (`java_actions()` builtin, `javaActionToStarlark`), `.claude/lint-rules/missing_documentation.star` | **Adding a catalog table has three obligations beyond the `CREATE TABLE`.** (1) Bump `CatalogSchemaVersion` — otherwise every existing `.mxcli/catalog.db` keeps its old schema, the new query fails, the error is swallowed, and the rule silently reports *zero* of the new findings. Silent under-reporting from a stale cache is indistinguishable from a clean project. (2) Register the view in `Tables()` — `catalog_test.go` enforces this and will fail with "add CATALOG.X so SHOW CATALOG TABLES includes it"; let that test tell you rather than discovering it from a user. (3) Exclude Marketplace/System modules in the iterator's `WHERE COALESCE(m.Source,'') = ''`, as every sibling iterator does — reporting undocumented Community Commons actions buries the findings the user can act on. **Attach children to their parent in the projection, not as a second iterator**: a rule reporting an undocumented parameter must name the action it belongs to, and pairing them in `JavaActions()` saves every rule from re-joining. **Load the shipped `.star` from disk in tests** — an inlined copy proves the builtin works and says nothing about whether the rule uses it. **Make each target switchable via `get_option`** before widening a rule: attribute-level checks are hundreds of findings on a real domain model, so `check_attributes` defaults off while the rest default on. Watch the whitespace when writing revert controls for Starlark: a `perl` pattern with `\t` silently matches nothing in a space-indented `.star`, so the control passes and proves nothing — it was the second attempt that failed correctly. Tests `mdl/linter/starlark_javaactions_test.go`; five controls reproduce. mxcli-formula1 (missing documentation) |
-| QUAL002 reports ~40 platform elements (`FileDocument`, `HttpRequest`, `System`) as undocumented, burying the handful of real findings; or a whole document type (pages, workflows, constants, REST services, mappings) is never reported at all no matter how undocumented it is | Two separate causes. (1) **Coverage**: QUAL002 only ever looked at entities and microflows — every other document type was unreachable from Starlark. (2) **The System leak**: `modules.Source` is `"Marketplace …"` for downloaded modules and **empty for System — exactly as it is for the user's own modules**, so the near-universal `WHERE COALESCE(m.Source,'') = ''` filter excludes Marketplace and lets all of System through | `mdl/linter/context.go` (`documentableSources`, `DocumentableElements()`, `notPlatformModule()`, `systemModuleID`), `mdl/linter/starlark.go` (`documentable_elements()` builtin), `.claude/lint-rules/missing_documentation.star` (`_DOC_KINDS`) | **Source alone does not exclude System** — only the sentinel Id `00000000-0000-0000-0000-000000000001` does (`modelsdk/meta.SystemModuleID`). Use `notPlatformModule(alias)` — **every** `LintContext` iterator now routes through it (Entities, Microflows, Pages, Enumerations, Constants, Snippets, Widgets, DatabaseConnections, JavaActions, DocumentableElements and all three `FindUnused` kinds), and `TestIterators_ExcludePlatformModules` fails if a new one is added without it. The leak was not confined to QUAL002: on a blank 9.24 project it inflated the whole run from 8 findings to 60 — CONV001 renaming System booleans, SEC001 demanding access rules on 38 System entities, DESIGN001 splitting `QueuedTask`, MPR003 splitting the System module itself. Adding the predicate can only ever narrow a result set, so the change cannot invent a finding; prove that by diffing full lint output before/after and asserting the ADDED set is empty. **One projection beats N builtins**: a rule that wants "every document" should get one `documentable_elements()` sweep driven by a table, so a new Mendix document type is two rows (one in `documentableSources`, one in `_DOC_KINDS`) rather than another builtin nobody remembers to call. **The documentation column is NOT uniform** — Mendix says `Documentation` for Java actions / REST / mappings / JSON structures and `Description` for everything else; assuming one spelling silently reports the other half as undocumented (a revert control confirmed 5 kinds go dark). **Test the catalog BUILDER, not just the query**: unit tests that INSERT rows directly cannot see that a builder never populates a column, which would flood the user with false positives — an end-to-end `exec` + `lint` on a real `.mpr` is what proved the constant/entity paths actually work. Three tables (`json_structures`, `import_mappings`, `export_mappings`) use `Id INTEGER PRIMARY KEY AUTOINCREMENT` while the rest use `Id TEXT PRIMARY KEY`, so a synthetic string id is a "datatype mismatch" on exactly those. Beware: MDL `COMMENT` and `DOCUMENTATION` are **different fields** on an entity — `CREATE ENTITY … COMMENT 'x'` does not set documentation, `ALTER ENTITY … SET DOCUMENTATION 'x'` does; a test using the wrong one looks exactly like a write-path bug. Tests `mdl/linter/starlark_javaactions_test.go`; controls reproduce for the sweep, each kind list, the doc-column split, Marketplace (both join shapes) and System |
-| A `LintContext` iterator suddenly yields nothing and the test says "expected ModA entities to be yielded" — no SQL error, no log line, just an empty result | The iterator's query failed (typically `no such column`) and the iterator swallows it: `rows, err := ctx.db.Query(...); if err != nil { return }`. A hand-rolled test double whose schema has drifted from the real catalog view produces exactly this. Hit when platform filtering started reading `modules.Id` and `context_test.go`'s minimal `modules` table had only `(Name, Source)` | `mdl/linter/context.go` (the `if err != nil { return }` in every iterator), `mdl/linter/context_test.go` (`setupModuleFilterDB`) | Read the failure as **"the query broke"**, not "the filter is too strict" — the two are indistinguishable from the assertion text, and the second reading sends you rewriting correct logic. Confirm by running the query by hand against the fixture DB. Test doubles that hand-roll a `CREATE TABLE` instead of using `catalog.NewFromFile` drift silently from the real schema; prefer the real schema builder for anything that joins. The swallowed error is the root problem — an iterator that cannot run its query is not the same as one with no results, and today nothing distinguishes them |
-| A lint run reports fewer findings than expected, or a rule that clearly should fire reports nothing — and there is no error, no warning, no log line | An iterator's catalog query failed and the failure was swallowed: `if err != nil { return }` inside an `iter.Seq[T]`, which has no error channel. The run looks successful because a linter's whole output is "here is what I found", and "found nothing" is what both a clean project and a dead query produce | `mdl/linter/context.go` (`QueryError`, `recordQueryError`, `QueryErrors`), `mdl/linter/linter.go` (`Linter.QueryErrors`), `cmd/mxcli/cmd_lint.go` (report + exit 1) | Iterators still degrade to "no rows" — one broken query must not take down the run — but they now **record** the failure, and `mxcli lint` prints it and exits 1, because silently passing CI on a run that could not read the model is the worst available outcome. All 34 sites are covered: `Query` + `return`, `Query` + `continue`, bare and inline `rows.Scan` forms, `return unused` (the non-bare return that a naive regex sweep misses — `TestQueryError_AllIteratorsReport` is what caught it), and the reader-backed `ListScheduledEvents`. **Dedupe on iterator+cause**: several rules iterate the same accessor, so one broken view is otherwise reported once per rule. Keying on the iterator alone instead hides a second, distinct failure in the same accessor. When adding an error message with a remedy, **run the remedy** — the first draft here suggested `mxcli lint --refresh`, a flag that does not exist; the shipped message names `.mxcli/catalog.db` and deleting it was verified to clear the error. Tests `mdl/linter/context_queryerror_test.go`; controls: no-op recorder (every iterator goes silent) and a single reverted iterator (only that one) |
-| Re-running `create external entities from` adds two more associations every time — `season_2`, `season_3`, then `season_4`, `season_5`, … unbounded. `mx check` is clean, every test passes, and the only symptom is duplicate links in Studio Pro's domain model | The re-import dedup matches an existing association by the OData **nav-property** name, but association names are unique per MODULE, so the second entity with a `season` nav property is stored as `season_2` — which can never match `season`. The nav-property index that would have matched it is keyed on `RemoteParentNavigationProperty`, and the **modelsdk reader never read the OData source back**, so that index was always empty under the default engine. The legacy reader did read it, which is why this only bit the default path | `mdl/backend/modelsdk/domainmodel.go` (`assocFromGen` now reads `*genRest.ODataRemoteAssociationSource`), `mdl/executor/cmd_contract.go` (`indexExistingAssociations`) | **A field that the write path sets and the read path drops survives exactly one save.** Grep both directions when a round-trip matters — `RemoteParentNavigationProperty` appeared in `domainmodel_write.go`, in gen, and in the legacy parser, and was missing only from the modelsdk read, which is invisible if you only grep for the identifier. **Do not "fix" this by stripping a trailing `_<n>` from names**: that heuristic also swallows a user's genuine `season_2`, and the model already records the true origin. Damage is cumulative and pre-existing: a project that ran the import N times carries 2N spurious associations, and they cannot simply be deleted — external-entity access rules reference them, so removing one leaves CE1613 "The selected association no longer exists". Tests `mdl/backend/modelsdk/association_odata_source_test.go` (round-trip, plus a control that a plain association is not stamped as external) and `mdl/executor/cmd_contract_reimport_test.go` (the index, incl. the assertion that the suffixed ones match via the nav index and NOT the name index — otherwise the guard passes for the wrong reason). mxcli-formula1 §50 |
-| DESCRIBE renders an activity as `-- Empty action` and its entire error branch is missing from the output — the MDL stays syntactically valid, nothing is printed to stderr, and a describe→edit→exec cycle deletes both | Two unrelated defects stacked. (a) The modelsdk reader — the DEFAULT engine — had no case for the action's `$Type`, so `ActionActivity.Action` was nil and `formatAction(nil)` returned the anonymous comment; 27 of 58 `MicroflowAction` types were in that state, 12 of them ones the legacy parser handles. (b) `emitActivityStatement` returned as soon as the statement started with `--`, *before* consulting `errorHandlerFlow`, so the branch was never traversed — for **every** unmapped action, not just the reported one | `mdl/backend/modelsdk/microflow.go` (nil → `UnsupportedAction` stand-in carrying `$Type` + `ErrorHandlingType`), `mdl/backend/modelsdk/microflow_read_actions.go` (`errorHandlingTypeOf` reads the field by property name), `mdl/executor/cmd_microflows_show_helpers.go` (`emitCommentedErrorHandler`), `mdl/executor/cmd_microflows_format_action.go` | **Count the gap before fixing the instance** — decoding each `$Type` through the real reader turned "SynchronizeAction is unsupported" into "27 types are, and `ExecuteDatabaseQueryAction` is a shipped feature you cannot describe back". **The early return is load-bearing**: annotations before a line comment make exec fail `no viable alternative at input '@position...'`, so keep it and emit the branch **commented-out** — emitting it live is worse than dropping it, since the next exec runs those activities unconditionally in the main flow instead of on failure. **Never take an enum from the UI wording**: Studio Pro says "Selected object(s)", the model stores `Specific` (Model SDK `SynchronizationType`, fetched via `npm pack mendixmodelsdk` — authoritative when `reference/` is not vendored). **A Mendix array's element 0 is a version marker, not data**: `property.EnumList.BSONValue()` returns a bare `[]string`, so a one-element list read back empty and mxbuild said CE2004 "No variables to synchronize have been selected." with the value plainly in the dump. Also CE0011 if a custom error handler has no outgoing error flow — call `finishCustomErrorHandler`. Tests `cmd_microflows_unsupported_action_test.go`, `microflow_synchronize_test.go`; example `mdl-examples/bug-tests/863-synchronize-and-unsupported-actions.mdl`. upstream #863 |
-| `execute database query` is written correctly and builds, but DESCRIBE renders it as `-- Empty action` (or, after #863, `-- Unsupported action: DatabaseConnector$ExecuteDatabaseQueryAction`) — a shipped feature you can author and never get back | The modelsdk reader (the DEFAULT engine) had no case for it. Both the MDL grammar and the DESCRIBE formatter were already there; only `actionFromGen` was missing, so `ActionActivity.Action` came back nil | `mdl/backend/modelsdk/microflow_read_actions.go` (`case *genDb.ExecuteDatabaseQueryAction`, plus `rawDocElements` for versioned arrays) | **The `$Type` is `DatabaseConnector$ExecuteDatabaseQueryAction`, not `Microflows$`** — several actions live in their own sub-metamodel, so a probe under the wrong prefix proves nothing either way and a `case \*genMf\.` grep under-counts what is mapped. **Read from raw against the keys the WRITER builds** (`Query` / `DynamicQuery` / `OutputVariableName` / the two mapping lists): the writer constructs the element directly rather than through gen setters, and gen exposes the named query as `QueryQualifiedName`, so pinning reader and writer to one key set is what makes the round trip mean anything. **Element 0 of a versioned array is the marker, not a mapping** — skip non-documents rather than slicing `[1:]`. **A text-stable round trip is not a valid model**: `describe→exec→describe` diffed clean while `mx check` died at load, because the fixture's `create database connection … username 'app'` wrote a literal into a ConstantIdentifier property (`StorageLoadException`, still-open defect, same class as #854) — always run the build, not just the diff. Tests `microflow_dbquery_test.go`, example `mdl-examples/bug-tests/863-execute-database-query-describe.mdl`. upstream #863 follow-up |
-| `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 | `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 | New `mdl/executor/validate_dbconnection.go` (`ValidateDatabaseConnection`, MDL058), wired into `cmd/mxcli/cmd_check.go` **and** `mdl/executor/cmd_dbconnection.go` | **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 |
-| `alter page … set DataSource = $Param` fails with "unsupported DataSource type for alter page set: parameter", while the same retype through `replace` works | 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 | `mdl/executor/cmd_alter_page.go` (`convertASTDataSource`), `mdl/backend/pagemutator/mutator.go` (`serializeDataSourceBson`, `SetWidgetDataSource`, `lookupParameter`) | **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 |
-| 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 | 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` | `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) | **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 |
-| 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 | `$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 | `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildSnippetCallParams`, `isContextArgument`) | **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 |
-| A project becomes unopenable after an mxcli write — Studio Pro / `mx check` fails with `System.Collections.Generic.KeyNotFoundException: The given key '<guid>' was not present in the dictionary` at `StreamingBsonUnitReader.ResolvePostponedProperties`. `mx check` on the *previous* revision is clean, and only some document types break (microflows/nanoflows yes, pages/navigation no) | An element's `$ID` was rewritten without rewriting the references that point at it. Mendix's loader defers reference resolution and then looks the target up by ID, so a pointer holding a discarded ID is a dangling reference. Hit by `element.PreserveIDs` (reverted in `f1371f71`), which recursed through `ChildProperty`/`ChildListProperty` and called `SetID`, but **pointers are not child properties** — `Microflows$SequenceFlow.OriginPointer`/`DestinationPointer` are primitive properties holding an `element.ID` (`modelsdk/gen/microflows/types.go` `InitFromRaw`), invisible to a child-walk | `modelsdk/element/preserve_ids.go` (reverted), `modelsdk/gen/*/types.go` (`InitFromRaw` shows which properties are ID-valued) | **Never rewrite an element ID without rewriting every reference to it in the same pass.** `ResolvePostponedProperties` in the stack trace means exactly this: a stored ID has no owner. The document types that survive are the ones with few internal cross-references (a page's widget tree is containment, a microflow's is a graph), so **"pages are fine" is not evidence the approach is safe**. Better than a fixup pass: seed the rebuild with the stored IDs so pointers are computed correctly from the start. **Verification lesson**: the local test project had entities, an association, an enumeration and constants but *no microflow*, so `mx check` reported 0 errors on a model that could not exercise the bug — a green `mx check` only covers the constructs the fixture actually contains. `make test-integration` (which needs mxbuild, ~20 min) caught it via `TestMxCheck_DoctypeScripts`; unit tests alone did not. Run it before claiming a write-path change is safe |
-| Re-running an MDL script against a project that is already in sync rewrites the `.mxunit` files anyway — `git status` is dirty, Studio Pro shows version-control changes, and three consecutive runs of one script give three different tree hashes across 143 documents while nothing semantic moves | No write path compared against what was stored. `create or replace` rebuilds the document from the MDL and overwrites unconditionally, and every sub-element in that rebuild is a new object whose `$ID` comes from `GenerateID()` — a random UUID. The output was a function of the script **and a random source**, so byte stability was unreachable by any amount of care in the builders | `modelsdk/canon/` (`Digest`, `Equal`, `Reconcile`), wired at the two storage choke points: `modelsdk/mpr/writer_core.go` (`reconcileWithStored`, covering `updateUnit` and `WriteTransaction.WriteUnit`) and `sdk/mpr/writer_units.go` (`updateUnit`) | **Compare a canonical form, not bytes** — the rebuilt bytes always differ, so a byte comparison skips nothing. Canonicalisation replaces every element `$ID` with its index in a deterministic containment walk; you do **not** need to know which properties hold references, because the set of element IDs comes from the walk and any occurrence of one of those IDs anywhere is a reference by definition. **Bias every failure path toward writing**: a false "different" costs a redundant write (yesterday's behaviour), a false "equal" silently discards the user's intent. **Skipping is safer than writing, not just cheaper** — the stored IDs are the ones every pointer inside that unit already agrees with, which is precisely what PR #125 broke by rewriting them. **Wire every choke point, both engines**: `codec.Store.SaveUnit`/`FlushUnits` reach storage through `WriteTransaction.WriteUnit`, not `UpdateRawUnit`, and which engine ran is an `--engine` flag users must not be able to see in a diff. **A control is mandatory**: assert that with `MXCLI_ALWAYS_WRITE=1` the same write *does* churn, or the test passes against a build that never had the fix. Tests `mdl/backend/modelsdk/microflow_idempotence_test.go`, `sdk/mpr/writer_elision_test.go`, `modelsdk/canon/canon_test.go`. ADR-0008 |
-| A microflow's `StableId` is a different GUID after every mxcli write, so a microflow always differs from itself and no amount of no-op elision can settle it. Downstream: every `callMicroflow` entry in `deployment/model/operations.json` gets a new `operationId` on each build | `microflow_write.go` registered `StableId` as a `codec` `FreshGUIDField`, minting a fresh GUID per write. It is the one field on a microflow whose *stated purpose* is not to change: Mendix declares it `ModelPropertyAttribute("StableId", RetentionType.DesignTime)` with `IsIdentifier = true`, seeds it once via the one-time `MicroflowStableIdConversion`, and transplants it across a marketplace module update in `PackageUtils.RescueStableIDs` | `modelsdk/canon/identity.go` (`identityFields`, `CarryIdentity`) — the stored value is carried onto the rebuilt document before the comparison, so an otherwise-unchanged microflow compares equal and is elided | **Establish that a property is an identity before adding a row to `identityFields`** — do not assume it from the name. The method that settled this one: strict-boundary `strings` scan of every runtime jar (a substring match gives false positives — `newPersistableIds` contains `stableId`); `monodis` the modeler assembly and read the `ModelPropertyAttribute` blob; look for an `IOneTimeConversion` named after the field; search the packaging assembly for a get→set pair; then build with `mxbuild --target=deploy` and reproduce the derivation against `deployment/`. That last step is what proved the value escapes the model: `operationId == base64(uuid5(projectId, StableId).bytes_le)`, 10 of 10 exact. **Carry only a key both documents already have** — never invent one, and dispatch on the stored `$Type` (CLAUDE.md, overlay writes). **Identity preservation is not gated by `MXCLI_ALWAYS_WRITE`**: that flag turns off eliding a write, not preserving what the document is. Tests `modelsdk/canon/identity_test.go`, `sdk/mpr/writer_elision_test.go`. ADR-0008 |
-| `call workflow`, `get workflow data/workflows/activity records`, `open`/`lock`/`unlock workflow` and `workflow operation` all DESCRIBE as a placeholder, so a describe→edit→exec cycle deletes them — while authoring and building them works fine | The modelsdk reader (the DEFAULT engine) had no case for any of the eight; each read back with a nil Action. The formatters and grammar were already there, so only `actionFromGen` was missing | New `mdl/backend/modelsdk/microflow_workflow_read.go` (+ dispatch in `microflow_read_actions.go`), `mdl/grammar/domains/MDLMicroflow.g4` + `mdl/visitor/visitor_microflow_workflow.go` (positional `call workflow` form), `mdl/executor/cmd_microflows_builder_workflow.go` (abort reason) | **Read against the WRITER's keys, not gen's** — gen binds every "get" action's result as `VariableName` while the model stores `OutputVariableName`, so an accessor-based reader silently drops the variable; round-trip tests (not reader-only tests on hand-written BSON) are what catch it. **`WorkflowSelection` has two variants and the object form uses `WorkflowDefinitionVariable`**, not `WorkflowVariable`; its ABSENCE is meaningful (the all-workflows case), so do not synthesise one. **Dispatch the operation on `$Type` before reading fields** — only Abort carries a Reason. **Finishing the reader exposes what could not be seen while nothing rendered**: `call workflow` described to a positional form the grammar rejected (the model never stores the parameter NAME, so DESCRIBE cannot emit the named form), and the abort reason stored the expression *including its quotes* into a StringTemplate Text, so Mendix rendered the quotes at runtime and every round trip doubled them. **Still open**: `lock/unlock workflow all` writes an activity mxbuild rejects with CE1825 — a lock always needs a specific definition, and supplying an empty selection does not satisfy it. Tests `microflow_workflow_read_test.go`, example `mdl-examples/bug-tests/workflow-actions-describe.mdl` |
-| `transform $In with Module.Transformer` reports "Created microflow" and the build then fails `[CE0008] "No action defined."` — the activity is in the model with no action inside it | The modelsdk writer (the DEFAULT engine) had no `TransformJsonAction` case, so it fell through to `default: return nil`. The grammar, builder, DESCRIBE formatter and the LEGACY writer all handled it, which is why it looked supported. The reader was missing too, so even a correctly written action described as a placeholder | `mdl/backend/modelsdk/microflow_write.go` (writer case), `mdl/backend/modelsdk/microflow_read_actions.go` (reader cases for `TransformJsonAction`, `CallExternalAction`, `RestOperationCallAction`) | **A missing WRITER case and a missing READER case present identically in a coverage audit** — grepping for reader cases found `transform` "authorable but unreadable" when it was actually unwritable, a strictly worse bug. Check both directions before sizing the work. **Mirror the legacy serializer for keys** (`InputVariableName`/`OutputVariableName`/`Transformation`); for the other two, note `CallExternalAction` stores its result under `VariableName` (not `ResultVariableName`) and REST's two mapping lists are NOT symmetric — the query list keys its name as `QueryParameter`. **Do not reconstruct `CallExternalAction.ResultDataType`**: it is resolved from the consumed service's cached `$metadata` at write time, so reading it back would let a stale value round-trip as if authored. **CE0008 turning into CE1613 is progress, not a new bug** — the action now exists and the build has moved on to validating its reference. Tests `microflow_integration_actions_test.go`, example `mdl-examples/bug-tests/transform-json-write-and-describe.mdl` |
-| `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 | 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% | `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) | 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 |
-| `describe import mapping M.X` / `describe export mapping M.X` reports "not found" for a mapping that exists and that `show` lists. `create or modify json structure` silently creates a duplicate instead of modifying the existing one. All of them work if the document happens to sit directly under the module rather than in a folder | `Backend.moduleNameFor` resolved a unit's module by reading its **direct** container (`GetModule(u.ContainerID)`). Studio Pro nests documents in folders — and folders in folders — so for any foldered document the container is a `Projects$Folder`, `GetModule` returns nil, the name resolves to `""`, and every `…ByQualifiedName` lookup built on it misses. In a stock marketplace project this is the *normal* case, not an edge case: 15 of 16 microflows, both JSON structures and both mappings were foldered, while all 8 domain models sat directly under their module — which is exactly why the three domain-model callers worked and hid the defect | `mdl/backend/modelsdk/domainmodel_write.go` (`moduleNameFor`); callers in `mapping_write.go`, `json_write.go`, `microflow.go`, `domainmodel_alter.go` | Walk the containment chain to the first enclosing module instead of reading one level. Build the parent map once (the old code re-scanned `ListUnits()` per call, inside a loop over every document — O(n²)), and **guard the walk against cycles**: the project root is its own container, so an unguarded loop hangs. Behaviour is unchanged for direct children, so the domain-model callers are unaffected. **Generalisable — the shape to look for**: a containment lookup that reads one level where the model allows arbitrary nesting. It works on every fixture built by `create module` + `create X` (nothing is foldered) and fails on every real project, so unit tests pass while users see "not found". **Diagnostic trap**: `describeImportMapping` wraps any error containing "not found" in `mdlerrors.NewNotFound`, so the surfaced message is identical whichever layer failed and cannot be used to identify the engine — call the reader and the backend directly to tell them apart. The legacy `sdk/mpr` reader walks the chain correctly (`buildContainerModuleNameMap`), so **the two engines disagreed** and only the default (modelsdk) was broken. Test `mdl/backend/modelsdk/module_resolution_test.go` |
-| `mxcli marketplace versions <id>` shows exactly ten versions for every content item, and asking for an older version reports it as not published — `marketplace diff` then refuses a module that was installed from a version the API plainly has | `Client.Versions` made one unpaged request. `/v1/content/{id}/versions` returns **10** items when given no paging parameters and caps `limit` at **20**, so everything older fell off the end. Data Widgets has 131 published releases; mxcli could see 10 | `internal/marketplace/client.go` (`Versions`, `versionPageSize`, `maxVersionPages`) | Walk `offset` in `versionPageSize` steps until a page comes back short. **The cap is not the same as the `/v1/content` cap** (100), so reusing `pageSize` here silently truncates at 20 — probe the real endpoint rather than assuming one paging convention per API. **A count that is exactly a round number is the tell**: ten versions for every single item is a page size, not a release history. The mock in `TestVersions_WalksEveryPage` clamps `limit` the way the server does, so a client that asks once and trusts the answer fails it |
-| `show modules` reports a module as having pages it does not have (Atlas_Web_Content: 46), while `show pages in module <that module>` correctly reports 0. `describe <a page template>` emits `create or modify page` with an **empty body**, and anything comparing describe output judges every template unchanged | `listUnitsByType` matched on a type **prefix**, and Mendix storage names nest: `Forms$Page` is a prefix of `Forms$PageTemplate`, so `ListPages` swept in all 46 templates. The modelsdk backend then replicated it deliberately ("match legacy"), so both engines agreed on the wrong answer. The empty body is a second, hidden consequence: a template's widgets hang off `LayoutCall` and the page describe path reads `FormCall` | `sdk/mpr/reader_units.go` + `modelsdk/mpr/reader_units.go` (exact match), `mdl/backend/modelsdk/page.go` (`ListPages`/`ListPageTemplates`), `mdl/catalog/tables.go` + `builder.go` + `catalog.go` (the `page_templates` table, `objects` row, `Tables()` entry), `mdl/executor/describe_auto_test.go` (`notAutoDescribable`) | **A count that is exactly a round module's worth is a type-matching bug, not an off-by-one.** **Do not fix a conflation by deleting the type from the index** — 46 documents nothing can enumerate is worse than 46 filed wrong, because nothing reports their absence; give the type its own table and let it report *unknown*. **Adding a catalog type touches five registries, not four**: the `*_data` table, the `objects` view union, the builder call, the describe-kind map (or `notAutoDescribable`), and `Catalog.Tables()` — `TestTables_CoversAllViews` is what catches the fifth. **A cosmetic-looking miscount can hide a silent false negative**: this was filed as "wrong count in `show modules`" and was really "the marketplace differ clears 46 elements it never read". Tests `sdk/mpr/reader_units_type_test.go`, `mdl/backend/modelsdk/page_test.go`. Still open: no `DESCRIBE PAGE TEMPLATE` handler |
-| After `mxcli marketplace install <id> -p app.mpr`, the project's `mprcontents/` folder is gone, the `.mpr` has grown from tens of KB to tens of MB, and `mxcli diff-local` no longer works. Git shows hundreds of deleted `.mxunit` files and one enormous binary | `mx module-import` rewrites an MPR **v2** project as **v1** — silently, and one-way. Measured on a blank 11.12.1 app: 69,632-byte `.mpr` + 341 `.mxunit` → 14,295,040-byte `.mpr` + 0, with the `_Transaction` table dropped. Reproduced independently on 11.13.0, so it is not version-specific. mxcli's install command shells straight out to it against the **user's** project | `cmd/mxcli/cmd_marketplace_install.go` (`checkStorageFormatPreserved`, `isMPRv2`, `reportFormatChange`, `--allow-format-change`) | **Refuse, do not warn** — the conversion cannot be undone (`mx convert` targets Mendix versions, not storage formats) and it destroys the per-document layout `diff-local`, `.mxunit` merges and ADR-0008's observable idempotence all rest on. **Detect the format the way the readers do** (presence of `mprcontents/`), not with a second definition. **Check the guard's negative case**: a test that only asserts "v2 is refused" also passes a guard that refuses everything — assert a v1 project still imports. **Do not guard every `module-import` call site**: `marketplace diff` runs one against a throwaway reference project, where the format is irrelevant (and the resulting v1 reference still diffs exactly against a v2 project, because DESCRIBE output does not depend on storage). Related, same family: `mx module-import` also refuses any module whose `Projects$ModuleImpl → IsThemeModule` is `true` (exit 112), which is the sole gate — flipping that one boolean makes an otherwise identical package import cleanly. Tests `cmd/mxcli/cmd_marketplace_install_test.go`. Reported in mxcli-formula1 FINDINGS §53 |
-| A .mpr extracted from a `.mpk` (or copied anywhere beside an existing project) reads with the wrong unit contents: edits appear to succeed, `ListRawUnitsByType` returns plausible documents, and a write lands nowhere the file will carry. Downstream the operation fails exactly as if nothing had been attempted | The MPR format test is **adjacency, not content**: an `.mpr` is treated as v2 when an `mprcontents/` directory sits next to it (`sdk/mpr/reader.go` `OpenWithOptions`). A package's v1 `project.mpr` unpacked into a work directory that already holds a scratch v2 project is therefore read as v2, and every unit resolves against the *other* project's `.mxunit` files | `cmd/mxcli/marketplace/theme.go` (`makeImportable` unpacks into its own `os.MkdirTemp` subdirectory) | **Unpack any foreign .mpr into a directory of its own** — never beside a project, even a throwaway one. **The failure is silent in both directions**: the read returns real-looking documents (from the wrong model) and the write reports success, so nothing surfaces until a later step refuses. The tell is a fix that provably works in isolation (`mx module-import` accepted the hand-built package) but does nothing in situ — that gap is environment, not logic. Test `TestMakeImportable_UnpacksAwayFromTheScratchProject` asserts the unpack does not land in the work-directory root |
-| `show features` lists nothing for agents or MCP, so `create agent` / `create model` on a pre-11.9 project runs without complaint. Reported alongside it: "`CREATE MODEL` can only author one provider — the writer assigns `MxCloudGenAI` unconditionally" | Two different things, and only the first was real. **The version gap**: the `agent_documents` area did not exist in `sdk/versions/mendix-11.yaml`, so `checkFeature()` had nothing to consult. **The provider claim was wrong**: the writer's assignment is `if m.Provider == ""` — a default, not an override. `Provider: OpenAI` parses, writes and round-trips through `describe model`; so does `Provider: TotallyMadeUp` | `sdk/versions/mendix-11.yaml` (new `agent_documents` area), `mdl/executor/cmd_agenteditor_models.go` + `cmd_agenteditor_write.go` (four `checkFeature` gates), `.claude/skills/mendix/agents.md` + `version-awareness.md` | **Read the assignment's guard before believing "hardcoded"** — `if x == "" { x = default }` and `x = default` are one character apart in a grep and opposite in meaning; the round-trip test settles it in a minute. **Agent doctypes are the one version gate with no downstream safety net**: the documents are custom blobs, mxbuild contains no agent-editor strings at all, so an ungated project builds green and fails only when Studio Pro opens it. **Do not invent the provider allowlist** — the enum lives in a Studio Pro *extension*, not in `generated/metamodel` and not in mxbuild, so a guessed list would reject values Mendix accepts; document that nothing validates it instead. Test `TestAgentDocumentsAreGated`. Reported in mxcli-formula1 FINDINGS §53 |
-| A marketplace module update leaves the app running the OLD widget code: `show modules` reports the new version, pages reference new widget definitions, and the binaries in `widgets/` are unchanged. Symptoms are whatever the version gap causes at render time, with no build error naming the cause | The update moved only the **model**. A widget module's `.mpk` ships its widget binaries under `widgets/` inside the package, and copying units out of a reference project never touches them. Measured on DataWidgets 3.5.0 → 3.11.3: model updated cleanly, all 10 widget binaries still 3.5.0 (`Datagrid.mpk` project=216193 vs package=166933) | `cmd/mxcli/marketplace/update.go` (`InstallPackageWidgets`, called from `PerformUpdate`) | **Take the widget files from the `.mpk`, not from the reference project** — the reference is a blank app plus the module, so its `widgets/` also holds the template's widgets and copying those overwrites widgets the update has nothing to do with. **Skip zero-size directory entries** in the zip or you write a stray file (the 3.11.3 package has 10 `widgets/` entries and 9 real files). **A module with no widgets cannot expose this**: Administration updated end-to-end and looked completely correct, which is why the gap survived a full slice. Pick a second subject with a different shape before believing an update path works. Related but distinct: after any headless module install `mx update-widgets` is needed (CE0463); and a newer module can want a newer Atlas than the project has (29 × CE6083 on DataWidgets 3.11.3), which `rename-design-properties` does NOT fix — that is a dependency, not a resync |
-| After a marketplace module update, `mx check` reports `CE6083` "Design property X is not supported by your theme" on the updated module's own widgets, and it survives BOTH `mx update-widgets` and `mx rename-design-properties` (which renames 0) | The update copied only the model and `widgets/`. The design properties are declared in the module's **own** `themesource/<module>/web/design-properties.json`, which was still the old version's copy — so the model referenced properties the shipped theme file did not define | `cmd/mxcli/marketplace/update.go` (`InstallPackageFiles` replaces `InstallPackageWidgets`) | **Copy everything the package ships**, excluding only `project.mpr` and `package.xml` — enumerating the directories that seem to matter is what produced two bugs in a row (widgets, then themesource). **CE6083 surviving `rename-design-properties` is the tell**: that command renames properties between Atlas generations, so 0 renamed means the declaration is missing entirely rather than renamed. **Do not diagnose this as a cross-module Atlas dependency** — that was the wrong call here; the declaring module was the one being updated. Guard against `..` in package paths while copying. Measured: DataWidgets 3.5.0 → 3.11.3, 49 files replaced, 29 errors → 0 |
-| A project that was MPR v2 is v1 after a marketplace install or update: `mprcontents/` is empty or gone, the `.mpr` jumped to tens of MB, `mxcli diff-local` stops working. The user followed the command's own "Next:" hint, or the docs | The hint said to run bare `mx update-widgets <project.mpr>` to clear the CE0463 a headless install leaves behind. That command performs the resync **and** rewrites a v2 project as v1 — measured on 11.12.1: 369 `.mxunit` files → 0, a 69,632-byte index → 14,405,632 bytes. Same family as the `mx module-import` collapse, arriving through advice rather than through a call | `cmd/mxcli/cmd_marketplace_install.go` + `cmd_marketplace_update.go` (the "Next:" lines now name `mxcli docker check`), `docs-site/src/guides/marketplace.md`, `.claude/skills/mendix/download-marketplace-content.md` | **`mxcli docker check` is the v2-safe resync** — it runs the same `mx update-widgets` under a storage-format snapshot (`cmd/mxcli/docker/update_widgets.go`, #808), so the check sees the resynced model and the project keeps its format. Verified: 369 `.mxunit` / 69,632 bytes before and after. **The resync is then not persisted** — the stored model still holds the old widget definitions and a later `mx check` reports CE0463 again; Studio Pro's "Update all widgets" persists it in v2, and `mxcli widget sync` is the partial headless equivalent (7 of 40 on the reference fixture). Say that rather than implying the resync sticks. **A guard in the code does not cover a string in the help text**: #808 already protected every call site mxcli owns, and the collapse came back as a sentence telling the user to bypass it |
-| `mxcli marketplace install <id> -p app.mpr` fails with `mx module-import failed: exit status 117` — "The package could not be imported, because it was created with a newer version of Mendix Studio Pro" — after downloading the package and building a reference project, and the message is buried under the command's full flag list | The marketplace publishes new releases against the newest Studio Pro patch within days, and `install` with no `--version` resolves to the latest, so on any project not on the very newest patch the **default** version is the one that cannot be installed. Measured 2026-08-12 on an 11.12.1 project: the latest release of all six agent-stack modules required 11.12.2, published five days earlier. Every version the API returns already carries `minSupportedMendixVersion` — nothing consulted it | `cmd/mxcli/marketplace_compat.go` (`checkMendixCompatibility`, `newestCompatibleVersion`, `mendixVersionOf`), called from `cmd_marketplace_install.go` and `cmd_marketplace_update.go`; `SilenceUsage`/`SilenceErrors` on install/update/diff | **Check what the API already told you before spending a download and a reference build on it** — the refusal was always going to happen, three layers lower and in mxcli's voice rather than Mendix's. **Name the version to use, not just the problem**: `--version 4.1.0 (the newest release built for 11.12.1 or older)` is the whole fix. **Skip, do not refuse, when the check cannot evaluate** (no project version, no published minimum) — same rule as `checkFeature`. **`SilenceErrors` belongs with `SilenceUsage`**: `main()` already prints what `Execute` returns, so silencing only usage leaves every refusal printed twice. Tests `cmd/mxcli/marketplace_compat_test.go`, including the negative case — a check that refuses everything passes the refusal test |
-| After a headless module install, `mx check` reports project-level `CE6087` "Design properties have been renamed in your theme and need to be updated" with an empty location, and no mxcli command clears it — or the same for `CE0463`, which `mxcli docker check` makes pass without actually fixing | The module ships its own design properties; Mendix's fix is `mx rename-design-properties`, which mxcli never ran. Measured on 11.12.1: it does real work (149 design properties across 41 documents) **and** collapses MPR v2 — 1,865 `.mxunit` files to 0, a 249,856-byte index to 39,895,040 bytes. Third member of the family, after `mx module-import` and `mx update-widgets` | `cmd/mxcli/docker/harvest.go` (`RunToolPreservingFormat`), `cmd/mxcli/cmd_fix.go` (`mxcli fix design-properties` / `fix widgets`) | **The `update-widgets` snapshot trick does not transfer** — that one restores the pre-run storage because the resync only has to hold for the duration of the check, whereas these renames must **persist**, so restoring undoes the fix. **Harvest instead**: let the tool convert the project, read every unit back out of the converted file, restore the v2 storage, then write the changed units into it through the writer — which is also where `canon.Reconcile` elides the units the tool rewrote without changing (ADR-0008), so a second run writes 0. Safe for the same reason a module transplant is: no binary `$ID` crosses a unit boundary. **Restore on every failure path after the tool has run**, or a failed command leaves a half-converted v1 file. **Print the storage count before and after** — the collapse this prevents shows up there as a zero, and a success message without its own evidence is how it shipped the first time. **`mprcontents/` is not all units**: it also holds an `mprname` file, so a naive file count is one high and reads as a dropped unit. Measured: 203 errors (202 CE0463 + 1 CE6087) to 0 on a vanilla 11.12.1 app, MPR v2 intact at 1,868 units, reproduced from a restored pre-fix snapshot. Tests `cmd/mxcli/docker/harvest_test.go` — each verified to fail with the reported symptom when the fix is stubbed out |
-| `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` | 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 | `mdl/executor/validate.go` (`execEnforcedMicroflowRules`), `mdl/exprcheck/func_checker.go` (`funcTable`), `mdl/exprcheck/unknown_funcs.go` (`roundingFuncs`) | **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 |
-| 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\`` | 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 | `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) | **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 |
-| An association's line anchors — where the connector attaches to the entity boxes in the domain model editor — are absent from `DESCRIBE ASSOCIATION`, and manual adjustments made in Studio Pro do not survive an mxcli round trip | `DomainModels$Association.ParentConnection`/`ChildConnection` (the string `"x;y"`) were **hardcoded** to `"0;50"`/`"100;50"` in BOTH writers and never read by either parser. Because every association write rebuilds the whole element, this was not an omission but active destruction: a documentation-only `alter association … set comment` reset them | `sdk/domainmodel/connection.go` (new: `ParseConnectionPoint`/`FormatConnectionPoint`, `Default*Connection`), `sdk/domainmodel/domainmodel.go` (fields → `*model.Point`), `sdk/mpr/parser_domainmodel.go` + `sdk/mpr/writer_domainmodel.go`, `mdl/backend/modelsdk/domainmodel.go` + `domainmodel_write.go`, `mdl/executor/cmd_associations.go` (`describeConnectionPoints`) | **A feature request that says "X is not exposed" may be hiding "X is destroyed"** — check the write path before scoping the read path. The A/B that settled it: a blank 11.13 app's own `Administration.AccountPasswordData_Account` stores `0;54/100;54`, so a Studio-Pro-authored association is a free fixture for "did mxcli overwrite this?" — no Studio Pro needed. **Learn the value's constraints from the LOADER, not from the shape**: hand-patch and run `mx check` — `"0.5;50"` dies with `StorageLoadException` (integers required) while `"0;500"` and `"-20;50"` load with 0 errors (no range check), so out-of-range values must round-trip untouched. **A zero value is not an absent value** — `{0,0}` is a real anchor (top-left), which forces the field to be a POINTER; a plain `model.Point` cannot distinguish "unset" from "top-left" and would silently rewrite it. **Fix both engines**: they share the semantic model, and a fix in one is invisible to a user on the other. **Emit unauthorable data as a COMMENT** — DESCRIBE output must stay re-executable, and inventing syntax (`@anchor(parent: bottom-left, …)`) would bake in a vocabulary the storage does not have: the pair is CONTINUOUS, not 8 named anchors (observed x values 0 9 11 17 18 47 49 50 65 77 78 84 87 100). **The marketplace is the sample** when you need to know what Studio Pro actually writes: `mxcli marketplace download <id>` gives real Mendix-authored models, and a module .mpk holds either a raw BSON `project.mpr` or an MPR v1 SQLite one — 88 coordinate pairs from three modules turned "looks like percentages" into a measurement (all 0..100; 85 of 88 pin one coordinate to exactly 0 or 100). **Rule a unit out from the model, not the values**: pixels is impossible because `DomainModels$EntityImpl` stores only `Location` and NO size — the box is sized by the editor from the name and attribute list, so a pixel anchor would have nothing to measure against. Not applicable to `CrossAssociation`, which has no connection properties and crashes Studio Pro if given them (#50). Tests `sdk/domainmodel/connection_test.go`, `mdl/backend/modelsdk/association_connection_test.go`, `sdk/mpr/writer_domainmodel_test.go`, example `mdl-examples/bug-tests/872-association-line-anchors.mdl`. upstream #872 |
-| An association's line anchors can be preserved but not AUTHORED — a scripted domain model cannot lay out its own connector lines, so `@Position(x, y)` gets you boxes and nothing gets you the lines between them | Feature gap, not a defect. `DomainModels$Association.ParentConnection`/`ChildConnection` had no MDL surface | `mdl/grammar/domains/MDLDomainModel.g4` (`SET ANCHOR`/`anchorPoint` — the ONLY grammar change), `mdl/visitor/visitor_association.go` (`anchorAnnotation`, `annotationParenPoint`, `anchorCoord`), `mdl/ast/ast_association.go` (`FromAnchor`/`ToAnchor` on both create and alter), `mdl/executor/cmd_associations.go` (`applyAnchors`, `describeConnectionPoints`) | **Look for an existing annotation before inventing one** — `@anchor(from:, to:)` already existed for microflow sequence flows, asking the same question (where does the connector attach), and `annotationParamName` already admitted FROM and TO, and `(x, y)` was already `annotationParenValue`: CREATE needed **zero** grammar. The two forms cannot be confused because the microflow one names its inner params (`(from: right, to: left)`) while a coordinate pair is positional. **Let the storage pick the value type**: the measured pair is continuous (x takes 14 distinct values across 88 samples), so named anchors were never an option — see the preservation row above for how that was established. **Silence must mean "preserve", not "default"** — naming one end sets it and omitting one keeps what is stored, which is what stops a `create or modify association` about the delete behaviour from flattening a hand-tuned line; the AST carries POINTERS so "not mentioned" and "mentioned as (0, 0)" stay distinguishable. **Reject what the LOADER rejects, at check time**: a fractional coordinate must error, not be truncated to 0 — Mendix refuses to open such a project, and a silently-wrong value in a file that still loads is the worse failure. **Prove DESCRIBE round-trips by parsing its own output** — asserting on a string literal passes against a formatter emitting something nothing can read. Tests `mdl/visitor/visitor_association_anchor_test.go`, `mdl/executor/cmd_associations_anchor_test.go`, example `mdl-examples/bug-tests/872-association-line-anchors.mdl`. upstream #872 |
-| 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 | 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 | `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` | **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` |
-| Scheduled events are read-only in MDL — a project's cron cannot be scripted at all, so `mxcli new` + a script leaves you opening Studio Pro to add the one thing that makes a batch job run. Separately, `describe` of an existing one omits its schedule entirely | Two gaps behind one request. (1) No write path: `ScheduledEventBackend` had List/Get and nothing else, and there was no grammar/AST/visitor/executor. (2) The READ was lossy in both engines — the legacy `parseScheduledEvent` never looked at `Schedule`, and the modelsdk reader went through `modelsdk/gen`, whose generated types **disagree with what Studio Pro writes** on two properties | `mdl/scheduledevents/codec.go` (new, shared by both engines), `mdl/backend/modelsdk/scheduledevent_read.go` + `sdk/mpr/scheduledevents.go` + `sdk/mpr/parser_enumeration.go` (both engines through the one codec), `mdl/grammar/domains/MDLDomainModel.g4` + `MDLCatalog.g4` + `MDLParser.g4`, `mdl/ast/ast_scheduledevent.go`, `mdl/visitor/visitor_scheduledevent.go`, `mdl/executor/cmd_scheduledevents.go`, `mdl/executor/validate_scheduled_events.go` (MDL-SCHED01) | **The generated metamodel is not the storage's ground truth** — `modelsdk/gen` declares `Interval`/`HourOfDay`/… as **int32** where Studio Pro writes **int64**, and `StartDateTime` as a **string** where Studio Pro writes a **BSON datetime**. This is the same mismatch as #585 (a reader that asserted int32), so the pattern is now twice-confirmed: when gen and an observed document disagree about a numeric width or a date, the document is right. **A byte-level pin beats field assertions**: three whole documents are hex-embedded in `codec_test.go` and re-serialized element by element in ORDER, so key order, key SET and BSON TYPE are all covered — a field-by-field test passes happily while writing int32 and an empty enum. **`mxcli marketplace download` is the Studio Pro substitute**: Business Events and Community Commons have none, but Workflow Commons 4.11.0, OIDC SSO 4.6.0 and SAML 4.2.1 have four between them (only Day and Hour variants — the other six had to be metamodel-derived, then verified to load). **An empty string is not "unset" for an enum property**: the first draft wrote `IntervalType: ""` and `mx check` reported 0 errors, but the enumeration has no such member. **`Interval`/`IntervalType` are LEGACY siblings of `Schedule` that Studio Pro does not keep in sync** — Workflow Commons stores `0`/`Minute` beside a `DaySchedule` of 01:00 — so they are derived on CREATE and carried through untouched on MODIFY, never re-derived. **A polymorphic child must be dispatched on `$Type`, and its field sets never merged** (the ADR-0005 rule): the eight variants differ in arity, so the executor refuses a field belonging to another Repeat rather than dropping it. **Validate at check time, not only at exec** — the validation is decidable from the statement, so it runs in the no-project pass and `check` and `exec` call the SAME function. **Prove the describe round-trips by PARSING its own output** for every variant, not by asserting on strings. Idempotence came free (ADR-0008 canon elides the regenerated `Schedule` `$ID`) — verified with the `MXCLI_ALWAYS_WRITE=1` control, which changes 9 units where the normal run changes 0. Tests `mdl/scheduledevents/codec_test.go`, `mdl/executor/cmd_scheduledevents_test.go`, `mdl/visitor/visitor_scheduledevent_test.go`, `mdl/backend/modelsdk/scheduledevent_read_test.go`, example `mdl-examples/doctype-tests/scheduled-events.mdl` |
-| A microflow run only by a scheduled event is reported as unused from three directions at once: `show callers of Mod.SE_Cleanup` says `(no callers found)`, `CATALOG.GRAPH_DEAD_ASSETS` lists it, and `mxcli lint` emits `[QUAL004] Microflow 'SE_Cleanup' is not called from anywhere.` with the suggestion **"Remove if unused"** — on a microflow that runs nightly in production | The catalog had no scheduled-event table and, more importantly, **no `refs` edge** from an event to the microflow it runs. Every consumer of the reference graph therefore agreed the microflow was dead. Separately, the linter's `ScheduledEvents()` iterator computed `interval_seconds` from the stored `Interval`/`IntervalType` pair | `mdl/catalog/tables.go` + `catalog.go` (new `scheduled_events`/`queues` views, registered in `Tables()`), `mdl/catalog/builder_scheduling.go` (new), `mdl/catalog/builder_references.go` (`RefKindSchedule` + `extractScheduledEventRefs`), `mdl/catalog/builder_graph.go` (`graphRefKinds`), `mdl/executor/cmd_search.go` (`callerRefKinds`), `.claude/lint-rules/orphaned_elements.star`, `mdl/linter/context.go` (`scheduleSeconds`, `Queues()`), `mdl/linter/starlark.go` | **A missing edge is worse than a missing table** — the table is an absence a user notices, the edge is a *wrong answer* three tools state confidently, and one of them recommends deleting the file. When adding a document type that references another, add the `refs` row in the same change. **An entry point is not a caller but must count as one**: `schedule` had to go into `callerRefKinds`, `graphRefKinds` AND the QUAL004 rule — three independent consumers, none of which shares the other's list. **Derive from the live property, not its legacy twin**: `interval_seconds` came from `Interval`/`IntervalType`, which Studio Pro writes and does not keep in sync with `Schedule` (Workflow Commons stores 0/"Minute" beside a DaySchedule of 01:00), so a "fires too often" rule read a nightly job as every 0 seconds; the old tests pinned the wrong source and had to be rewritten, which is the tell. **Adding a plural keyword breaks `CATALOG.<KEYWORD>`**: `QUEUES` became a lexer token and `select * from CATALOG.QUEUES` then parsed to NOTHING — no error, no output, just silence — until `QUEUES` was added to `catalogTableName` (`COMMUNITIES` had been through this before). `SCHEDULED_EVENTS` escaped only because the underscore makes it one IDENTIFIER. **`cmd/mxcli/lint-rules/` is gitignored and regenerated** from `.claude/lint-rules/` by `make build`, exactly like `cmd/mxcli/skills/` — editing the embed dir silently reverts on the next build. **`TestTables_CoversAllViews` catches a view missing from `Tables()`**, so a new catalog table is invisible to `SHOW CATALOG TABLES` until registered. Tests `mdl/catalog/builder_scheduling_test.go`, `mdl/linter/starlark_scheduledevents_test.go`, `mdl/visitor/visitor_catalog_test.go` |
-| A project's regular expressions are invisible to mxcli — `show regular expressions` is a parse error, they are absent from `describe`, the catalog and the project tree, and there is no way to author one — so a validation pattern shared across a domain model can only be seen in Studio Pro | No support at any layer for `RegularExpressions$RegularExpression`. The `model.RegularExpression` type existed but was **dead code**: nothing read or wrote it | `mdl/regularexpressions/codec.go` (new, shared by both engines), `mdl/backend/modelsdk/regularexpression.go` + `sdk/mpr/regularexpressions.go`, `mdl/backend/infrastructure.go`, `mdl/grammar/MDLLexer.g4` (+`REGULAR`/`EXPRESSIONS`) + `domains/MDLDomainModel.g4` + `MDLCatalog.g4` + `MDLParser.g4`, `mdl/ast/ast_regularexpression.go`, `mdl/visitor/visitor_regularexpression.go`, `mdl/executor/cmd_regularexpressions.go`, `mdl/catalog/builder_regularexpressions.go` (+ the `validate` ref edge in `builder_references.go`) | **`modelsdk/gen` had the property key wrong — the third confirmed instance.** gen binds the pattern to BSON `RegEx`; all five Studio Pro documents store `Expression`, and `generated/metamodel`'s JSON tag (`expression`) agrees with the documents. A codec built on gen writes a property the type does not carry AND reads an empty pattern from every real document — the negative control (flip `PatternKey` to `RegEx`) fails all five parse tests. The rule is now thrice-proven: **when gen and an observed document disagree, the document wins**. **A regex is the worst case for string handling**, so test the pattern round trip specifically: backslashes (not escapes), a doubled `''`, alternation, `{2,}` braces, and a `|` — assert by RE-PARSING the describe output, not by string match. **Do not equate "Go cannot compile it" with "invalid"**: Mendix validates with .NET, and the Email Connector ships `.*(?<!/)$`, which RE2 rejects — so the check is advisory and DESCRIBE says "not verifiable". **Check the reference direction before assuming a dead-asset bug**: unlike the scheduled-event case, `GRAPH_DEAD_ASSETS` is restricted to ENTITY/MICROFLOW/NANOFLOW/PAGE/SNIPPET, so a regex was never reported dead — the `validate` edge earns its place by answering `show references to <regex>`, and the control run proved the dead-asset framing wrong before it reached a comment. **Adjacent defect found and NOT fixed**: `create validation rule …` (regex, required, range, unique) has a grammar rule but **no AST node, no visitor and no handler** — it parses and silently writes nothing, so a regex document still cannot be bound to an attribute from MDL. `sdk/domainmodel.RegexValidationRuleInfo` and `serializeRuleInfo`'s Required-fallback are dead code reachable only once that is built (an entity rewrite PRESERVES stored rules — verified by injection, so there is no live data-loss bug there). Tests `mdl/regularexpressions/codec_test.go`, `mdl/executor/cmd_regularexpressions_test.go`, `mdl/visitor/visitor_regularexpression_test.go`, example `mdl-examples/doctype-tests/regular-expressions.mdl` |
-| `alter entity … add attribute` on an entity that has a **RegEx or Range** validation rule silently turns that rule into a **Required** rule: the regex reference (or the min/max bounds) is gone, the field is merely mandatory, and `mx check` reports nothing — a Required rule is perfectly valid. Happens on BOTH engines | A matched pair of fallbacks. The modelsdk READER (`ruleTypeFromGen`) collapsed every RuleInfo except Unique to `"Required"`, and BOTH writers (`ruleInfoToGen`, `serializeRuleInfo`) fell back to `RequiredRuleInfo` for any type they did not recognise. ALTER ENTITY round-trips the whole entity through read→write, so the two defaults compose into a silent downgrade | `mdl/backend/modelsdk/domainmodel.go` (`ruleTypeFromGen` now derives the name from `$Type`), `mdl/backend/modelsdk/domainmodel_write.go` + `sdk/mpr/writer_domainmodel.go` (both rule-info serializers return **nil = refusal**, plus `reproducibleRuleType`/`validationRulesAreReproducible`), guards in both `UpdateEntity` implementations | **A read default and a write default are individually defensible and jointly destructive** — neither function looks wrong alone; the corruption only exists in the round trip. When auditing a rewrite path, check the reader's fallback and the writer's fallback TOGETHER. **`mx check` is not a safety net for a type substitution**: both rules are valid, so the build stays green and the only evidence is the stored `$Type`. **A fourth gen-vs-reality key mismatch**: `modelsdk/gen` binds `RegExRuleInfo`'s reference to BSON `RegularExpression`, while the Studio Pro document (Mendix Email Connector 6.4.2) stores `RegExIdentifier` — so RegEx rules cannot be written through gen at all today, which is *why* the fix is a refusal rather than a round trip. There is no `supplements.json` or `cmd/modelsdk-codegen` in this tree, so correcting gen is not currently available. **Injection fixtures need ORDERED BSON**: re-marshalling a unit through `bson.M` randomises key order and Mendix refuses to load it (`Expected '$ID' as the first property of a storage object`) — use `bson.D` throughout, or the fixture's own invalidity masks the thing you are testing. **Required/Unique rules were never affected**, and are authorable today via the `not null error '…'` / `unique error '…'` attribute constraints — only the standalone `create validation rule` statement is dead (grammar with no AST, visitor or handler). Tests `sdk/mpr/writer_validationrule_test.go`, `mdl/backend/modelsdk/validationrule_test.go` |
-| `mxcli new` into a deep output directory dies with `System.IO.PathTooLongException` and leaves the directory holding ~259 files and no `.mpr` — output that looks like a project until you try to open it | MxToolset refuses any full destination path over **259 characters** (its own Windows-compatibility limit, not the filesystem's) and aborts extraction PART WAY THROUGH. mxcli pointed `mx create-project` straight at the user's output directory, so the abort happened there | `cmd/mxcli/newproject_paths.go` (new: `stagedProjectDirs`, `longestRelativePath`, `warnIfPathTooLongForStudioPro`, `moveProject`), wired into `cmd/mxcli/cmd_new.go` step 2 | **Stage the work somewhere safe and move it in, rather than validating a path you could just avoid** — creating in a short temp dir and renaming makes ANY depth work (POSIX allows 4096) instead of merely failing politely, and the destination is never partially populated because nothing is written there until creation succeeded. Check the relocation is safe first: `grep -rl <abs path> <project>` returned **0 files**, so a fresh Mendix project embeds no absolute paths. **Bisect for the real threshold instead of trusting arithmetic** — 77 characters creates a project on 11.13.0, 78 fails leaving 259 files, which pins `len(dest) + 1 + longest ≤ 259` exactly. **Measure the template, don't hardcode it**: the longest relative path is 181 on 11.13.0 and 182 on 11.12.0, so walk the staged tree and use the real number, or the reported budget drifts a character per release. **Warn, don't refuse, when the finished path is over budget** — the project works on POSIX, so refusing would block a machine where it is fine; but Studio Pro on Windows would not open it, so silence would be worse. Cross-device staging needs an `os.CopyFS` fallback: `os.Rename` cannot cross filesystems. Tests `cmd/mxcli/newproject_paths_test.go`. upstream #825 |
-| `show callers of <microflow>` and `show references to <page>` report "(no callers found)" for a document reached only from a page action button — a false negative that reads as "safe to delete" | TWO independent defects behind one symptom. (1) `scanWidgetOwnRefs` collected `Entity`/`Microflow`/`Nanoflow` from a widget's raw BSON but not **`Form`**, the key a PAGE reference uses, so `widgets_data` had no page column and the refs projection had no page row. (2) `execShowCallers` filtered `RefKind = 'call'` — the kind a microflow CALL ACTIVITY produces — so the button→microflow row, which was already in the refs table, was hidden by the query | `mdl/catalog/builder_pages.go` (`scanWidgetOwnRefs` + `rawWidgetInfo.PageRef`), `mdl/catalog/tables.go` (`widgets_data.PageRef`), `mdl/catalog/builder_references.go` (projection row), `mdl/executor/cmd_search.go` (`callerRefKinds`) | **Find the live code path before fixing anything** — `builder_references.go` has an inviting `extractWidgetRefs` with a per-widget-type switch, and it is DEAD: its only caller is its own recursion. Extending it changes nothing. The live path is a SQL projection out of `widgets_data`, and the standing `NOTE: widget-level datasource/action refs still require a parsed widget tree` comment beside it is the tell. **Separate "the reference is missing" from "the query hides it"** by reading the refs table directly: the button→microflow row was present all along, so fixing only the scanner would have closed half the issue and left the reporter's second scenario broken. **`Form` is `Page`** — the same rename behind `ShowFormAction`/`CloseFormAction` (CLAUDE.md's storage-name table); grepping for `Page` in a BSON scanner finds nothing. **One action can carry two references**: `create object … then open page` holds an entity AND a page, so collecting the entity alone still leaves the page unreferenced. **Do not widen `callers` into `references`** — `datasource`/`parameter`/`generalize` are uses of a TYPE, not invocations, and including them makes the two commands synonyms; the test pins both the included and the excluded set. Tests `builder_pages_test.go` (`TestScanWidgetOwnRefs_PageReference`), `cmd_search_callers_test.go`. upstream #773 |
-| `ALTER PAGE` over `--mcp` fails against Studio Pro **11.13** with `pg_patch_page: … PROP_NOT_PRIMITIVE: Property 'widgets' is not a primitive property`. `CREATE PAGE` is fine; the page itself is left intact | 11.13 gave `pg_read_page` a **`depth` argument defaulting to 4**, replacing anything deeper with the literal string `"..."`. ALTER PAGE is read-modify-**replace-whole-page**, so the truncated read went straight back as the new page body. Measured live: `Administration.Account_Overview` read 32,594 bytes at full depth but **1,052 bytes** at the default, its entire tree reduced to `{"widgets":["...","..."]}`. Every ordinary page truncates — three of three PgTest pages did | `mdl/backend/mcp/page.go` (`pgReadPage`, `pgReadFullDepth`, `hasTruncationSentinel`), `mdl/backend/mcp/client.go` (`SupportsToolArg`) | Request the full depth, and **guard rather than trust it**: refuse a read still carrying the sentinel instead of letting a partial page reach a write (ADR-0005 guard-don't-drop). Two traps. (1) **Do not send `depth` unconditionally** — 11.11/11.12 declare `pg_read_page` `additionalProperties:false` without it, so the whole call fails; gate on a live `tools/list` probe of the tool's input schema, because `serverInfo.version` is frozen at `1.0.0` across 11.11/11.12/11.13 and cannot discriminate releases. (2) **Match the sentinel only as an array element** — a caption or title legitimately reading `"..."` is real content, and a naive substring scan rejects valid pages. The release notes announced none of this, exactly as 11.12 silently removed `pg_write_page` (#697): on any Studio Pro upgrade, re-probe `tools/list` and diff the input schemas, not just the tool names. Tests `mdl/backend/mcp/page_depth_test.go`; controls: stub the depth arg (full-depth test fails) and stub the guard (truncation test fails) |
-| Widgets silently go backwards: a project on DataWidgets 3.11.3 ends up running 3.4.0 widget code after updating an unrelated module (Atlas_Web_Content, FeedbackModule). `mx check` stays clean, `show modules` shows the new module version, and nothing mentions widgets | A module `.mpk` bundles a copy of every widget its pages use, pinned at its author's release time — and different modules pin different versions of the **same** widget. `InstallPackageFiles` copied everything the package shipped, so the last module installed decided the widget versions. Measured on the published packages: Atlas_Web_Content 4.3.0 ships 5 Data Widgets at 3.4.0 against DataWidgets 3.11.3's 3.11.3 | `cmd/mxcli/marketplace/widgetversion.go` (`widgetVersionInMpk`, `versionLess`, `unpackedTwinOf`), `update.go` (`InstallPackageFiles` returns `[]SkippedFile`), `cmd_marketplace_update.go` (`reportSkippedFiles`) | **Read `<clientModule version>`, not `<package version>`** — the root attribute is the manifest schema and is `1.0` on every widget ever published, so comparing it makes every version look equal, which is exactly as broken as not comparing. **An unparseable version must never count as "older"** — the default is to install, and a wrong "older" verdict silently withholds a file the package shipped. **Skipping must be reported**: a silent skip is the same class of bug as the silent overwrite it replaces. **Test the negative half** — a guard that skips every widget also passes "the newer one survived"; assert that a newer *and* an equal bundled widget still install. Same file handles FINDINGS §18: a package that ships a widget as both `.mpk` and unpacked tree (FeedbackModule 5.0.0, both 12.0.4) installs only the `.mpk`, but an unpacked widget with **no** packaged twin must still install. Verified against the real packages: 5 kept, 13 twin entries skipped. Reported in mxcli-chat FINDINGS §14/§18 |
-| `mxcli marketplace update`/`diff` fail with `version "6.0.0" not found` on a module the project actually has, and `--force` does not bypass it | Both download the **installed** version to build the local-edit baseline, and that version had been unpublished. A blank 11.13 app ships NanoflowCommons 6.0.0 while the 6.x line now starts at 6.1.1 — so the module most in need of updating is the one whose baseline cannot be built | `cmd/mxcli/cmd_marketplace_update.go` (`--no-baseline`, and the refusal now names it) | **`--force` was never going to work**: it overrides a *finding*, and here the comparison never ran, so there is no finding. Needing a second flag is the signal that these are two different decisions — "I accept losing edits I have been shown" vs "I accept not being shown". **Say what the flag costs in the flag's own message** — with no baseline, local edits go without being named, so the honest instruction is to commit first. Reported in mxcli-chat FINDINGS §15 |
-| A constant set with `alter settings constant 'M.C' value '…' in configuration 'Default'` has no effect on the running app. The statement succeeds, `describe settings` round-trips it, `mx check` is clean, and the app behaves as if the constant were still at its default | mxbuild writes `deployment/model/config.json` with each constant's **default** value, and that map is what `run --local` hands the standalone runtime as `MicroflowConstants` — the configuration's overrides are not in it, and nothing read them. An app ran for hours with an empty encryption key while the model said otherwise | `cmd/mxcli/runconstants.go` (`resolveConstantOverrides`, `reportConstantOverrides`), `cmd_run.go` (`--configuration`), `cmd/mxcli/docker/localboot.go` (`mergeConstantOverrides`) | **A silent no-op is the worst shape a bug can take** — every layer reported success. The fix therefore prints in *every* case, including "no overrides applied", so silence stops meaning "your value is in effect". **Merge, never replace**: `config.json` carries the defaults for constants the configuration is silent about, and replacing the map drops them (the app 530s on the first microflow that reads one) — which is exactly the shape `--runtime-setting MicroflowConstants={…}` has. **A private override has no value in the model at all** (a `Settings$PrivateValue` marker; the value lives on the workstation), so applying it would blank the constant — skip and name it. **Do not guess between configurations**: with several and no `Default`, applying one silently could push production's API key into a local run. Tests `cmd/mxcli/runconstants_test.go`, `cmd/mxcli/docker/localboot_constants_test.go`; verified live — the run now prints `Applying 1 constant value(s) from configuration "Default"`. Reported in mxcli-chat FINDINGS §33 |
-| `mxcli marketplace diff` reports local edits on a project nobody has edited — typically an Atlas snippet and a building block. `--save-edits` then writes MDL that would *destroy* the element if replayed (an empty `create or modify snippet X (Folder: 'Web') { }`) | The comparison is on DESCRIBE output, and `Describable()` only asked whether describe *errored*. Some types describe successfully into output that says nothing: an empty `{ }` body, or a building block under "Building blocks are read-only; they cannot be created via MDL". Two such renderings can still differ — one unresolved name is enough — and the difference was reported as a user edit | `cmd/mxcli/marketplace/snapshot.go` (`Element.Conclusive`, `declaredReadOnly`, `emptyBody`), `compare.go` (`classify`), `update.go` (`SaveEdits`) | **Check equality BEFORE conclusiveness** — identical text is solid evidence of "unchanged" whatever the type, and inverting the order marks every Atlas building block unknown and drains `verified` of meaning. **Judge the output, not the type**: a type list goes stale the moment a describe handler improves, while "this text contains nothing to compare" stays true by construction — match the handler's own read-only wording so the two stay in step. **A rescue file must never be a deletion**: the same rule gates `--save-edits`, including `OnlyInstalled` findings, which reach it without passing through `classify`. **Test that a real edit is still Modified** — a guard that returns unknown for everything passes every "not evidence" test. Tests `cmd/mxcli/marketplace/inconclusive_test.go`. Reported in mxcli-chat FINDINGS §16 |
-| `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 | 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`) | `mdl/executor/cmd_security_write.go` (`inheritedAssociations`, `domainModelHasEntity`) | **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.) |
-| A `call java action` whose parameter is a **microflow** (`MCPServer.AddTool`'s `ExecutingMicroflow`, and every other "register a callback" action) fails `mx check` with **CE0115** — the microflow's name is stored as a literal string | The modelsdk engine's java-action read had no case for the parameter type, so `codeActionBasicFromGen` fell through to its `default` and returned a `StringType`. The microflow builder's `microflowTypeParams` branch was therefore never taken and it authored `Microflows$BasicCodeActionParameterValue{Argument: "'M.MyFlow'"}` instead of `Microflows$MicroflowParameterValue{Microflow: "M.MyFlow"}` | `mdl/backend/modelsdk/java_read.go` (`codeActionBasicFromGen`), `java_write.go` (`codeActionParamTypeToGen`), `mdl/executor/cmd_javaactions.go` (`astDataTypeToJavaActionParamType`, `bareDataTypeName`) | **A `default:` that returns a plausible type is how a read path lies.** The legacy parser and the executor both handled this correctly for years; only the gen→semantic converter did not, and it degraded to String rather than erroring — so every layer downstream looked correct in isolation. **Fix read and write together**: without the write case an *update* of such an action rewrites the parameter as a String, which is worse than the read bug. **Watch what DESCRIBE starts printing** — the fix made it emit the honest `Microflow`, which then round-tripped into an entity type with an empty module (`.Microflow`) until `astDataTypeToJavaActionParamType` learned the bare word. Probe the stored `$Type` from the marketplace `.mpk` before theorising; MCP Server 5.1.0 stores `JavaActions$MicroflowJavaActionParameterType`. Tests `mdl/backend/modelsdk/java_read_test.go`, `mdl/executor/cmd_javaactions_test.go`, example `mdl-examples/bug-tests/javaaction-microflow-parameter.mdl`; verified 0 errors under `mx check` 11.12.1. Reported in mxcli-chat FINDINGS §36 |
-| `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 | `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 | `mdl/executor/validate.go` (`scriptContext.javaActions`/`javaScriptActions`, `collectDefinitions`, `collectSingle`, `allNames`, `has`, `validateFlowBodyReferences`) | **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 |
-| `GRANT <role> ON Module.Specialization (READ *, WRITE *)` writes a model Mendix rejects with **CE0066** "Entity access is out of date", while the same grant on the generalization checks clean. The executor passes 3 MemberAccess entries and storage holds 2 | `ReconcileMemberAccesses` — which runs after every program and after every `create association` — recomputes each rule's expected member set from the entity's **own** attributes and the module's **FROM-side** associations. An inherited association matched neither, so it was classed stale and deleted, one step after the GRANT that had just written it correctly | `mdl/backend/modelsdk/domainmodel_security_write.go` (`sameModuleAncestors`, `entitiesByName`, `assocRefBelongsTo`, `ownerIDs` in `ReconcileMemberAccesses`), `mdl/executor/cmd_associations.go` (reconcile after DROP) | **The write path was innocent** — `AddEntityAccessRule` stored all 3; the deletion happened in the reconcile that ran next. When a value is written and then absent, instrument the *later* pass before the writer. **Preserve what cannot be checked**, as the attribute branch already did (#758): an association is qualified by the module that DECLARES it, so an ancestor in another module (the reported `OpenAIDeployedModel extends GenAICommons.DeployedModel`) names a domain model that is not loaded here. **The counter-control is the whole test**: a walk that collected every association in the module passes both positive cases and puts an entry on the TO side of an `OWNER Default` association, which is *itself* CE0066 — so assert that the unrelated entity does **not** get one. **Reconcile must add as well as keep**, or a rule written before the ancestor gained the association never catches up. Verifying this surfaced a neighbouring bug: `drop association` never reconciled at all, leaving entries Mendix rejects with CE1613 — on the declaring entity too, so it predates inheritance support. Tests `mdl/backend/modelsdk/reconcile_inherited_assoc_test.go` (5 cases incl. both controls), `mdl/executor/cmd_associations_mock_test.go`; example `mdl-examples/bug-tests/grant-on-specialization.mdl`, measured 1 error → 0 on mxbuild 11.12.1. Reported in mxcli-chat FINDINGS §25 |
-| A `.test.mdl` asserting on something a **constant** feeds passes under `mxcli test --attach` and fails under `mxcli test --local` (or the reverse), with nothing in either output to explain the difference | `--local` boots an app of its own through `StartLocalApp`, whose options had no `ConstantOverrides` field — so it ran with each constant's **default** from `deployment/model/config.json`, while `--attach` runs against an app `run --local` booted, which applies the configuration's shared overrides. A constant resolving to the wrong value is not an error, so both runs reported success and only the assertion differed | `cmd/mxcli/docker/localapp.go` (`LocalAppOptions.ConstantOverrides`, `runtimeOptions`), `cmd/mxcli/testrunner/localapp_options.go` (new, shared by both `--local` runners), `runner.go` (`RunOptions.ConstantOverrides`), `cmd/mxcli/cmd_test_run.go` + `main.go` (`--configuration`) | **A boot path that takes options needs one mapping function, not an inline struct literal per caller** — the two `--local` runners each built their own `LocalAppOptions`, so a field added for one would not reach the other, and neither had the constants. Both now go through `localAppOptions`, and the `LocalAppOptions`→`LocalRuntimeOptions` step is `runtimeOptions()` so the forwarding is assertable without booting anything: a dropped field there is otherwise invisible until an app runs with the wrong configuration. **Resolve in one place**: `cmd/` decides precedence and the runner only carries the map, or "which configuration wins" gets two answers. **Only report what this run actually uses** — `--attach` inherits the constants of the app it attached to, so resolving and printing them there would be a confident lie. Verified at the layer the symptom lives in (`.claude/skills/verify-in-runtime.md`): the same suite, one project, `--local` and `--attach` must agree, with the reverted-wiring control run showing the constant's default. Unit tests `cmd/mxcli/testrunner/localapp_options_test.go`, `cmd/mxcli/docker/localboot_constants_test.go`. See `docs/11-proposals/PROPOSAL_constant_values.md` slice 1 |
-| A constant value that must not be committed has nowhere to live: a constant's default and a shared configuration override both go to git, and Mendix's own **private** configuration value — the correct slot — is encrypted per user account by Studio Pro from 10.9, so nothing headless can read or write it | Not a defect so much as an absent layer. mxcli mirrors the concept with a store it can actually reach: `<project>/.mxcli/constants.json`, mode 0600, gitignored, sitting between `--constant` and the configuration | `cmd/mxcli/constantstore/` (load/save), `cmd/mxcli/cmd_constant.go` (`constant set/unset/list`), `cmd/mxcli/constant_gitignore.go` (`ensureStoreIgnored`), `cmd/mxcli/constants_resolve.go` (`layerMachine`) | **The promise has to be made true, then checked — asserting it is not enough.** `mxcli init` writes a `.gitignore` only when the project has none, and a Mendix project usually already has one, so the entry the whole layer rests on could simply be absent. `constant set` appends it *and then asks git*, refusing to write the value on "not ignored": a store that leaks is worse than no store. **Which rule defeats an ignore entry is not guessable** — `!.mxcli/**` does NOT re-include anything (git cannot re-include a file whose parent directory is excluded), while `!.mxcli` does; the test was corrected against measured git behaviour rather than the assumed case. **A corrupt store is an error, a stale entry is not**: an unparseable file means values the author set are about to be silently absent (fatal), while an entry naming a constant the project dropped is the user's own file and is skipped-and-named, or every run fails until it is hand-edited. **An empty store is deleted, not written as `{}`** — a file that configures nothing should not exist. Tests `cmd/mxcli/constantstore/store_test.go`, `cmd/mxcli/constant_gitignore_test.go`; verified live that the value reaches a running app and that `git status` never sees the file. See `docs/11-proposals/PROPOSAL_constant_values.md` slice 3 |
-| A constant value changed on disk (machine store, or the project configuration) does not reach an app that is **already running** — a `mxcli run --local` keeps serving the old value until it is restarted | Constants are a boot-time layer: mxcli sends them once, in the `update_configuration` call at start. Changing them live needs the M2EE admin API, and needs BOTH of its calls | `cmd/mxcli/docker/localboot.go` (`ApplyConstants`, `LocalRuntime.BootConfig`), `cmd/mxcli/devloop_handshake.go`, `cmd/mxcli/cmd_constant.go` (`--apply`) | **`update_configuration` is STAGED, not applied** — measured on 11.12.1: the running app keeps its old values, and the call still answers `result:0`. Only the next `reload_model` applies them, so a version sending just the first call reports success and changes nothing. That is why the two calls live in one function rather than at the call site. **Re-send the WHOLE payload**: the admin action has no read-back (`get_configuration`, `get_current_configuration`, `runtime_config`, `get_current_runtime_status` are all "Action not found"), so anything not sent is simply gone from the configuration afterwards — which is why the dev loop publishes what it booted with rather than a second process guessing. **A handshake from a dead process is refused, not used**: its ports may since have been taken by something else, and pushing a configuration change into the wrong process is worse than reporting no dev loop. **Say plainly what cannot be confirmed** — with no read-back, two successful calls are the strongest evidence available, so the command names what would actually confirm it (a microflow that returns the constant) instead of claiming success. **Failure to apply is not failure to set**: the value is already on disk and the next boot uses it, so `--apply` reports and returns rather than exiting non-zero over a half-succeeded command. Tests `cmd/mxcli/docker/localboot_constants_test.go`, `cmd/mxcli/devloop_handshake_test.go`. See `docs/11-proposals/PROPOSAL_constant_values.md` slice 4 |
-| `mxcli check` on a script containing `log 'msg' with ()` **panics** — `runtime error: invalid memory address or nil pointer dereference` at `mdl/visitor.buildTemplateParams`. Any command that parses the file dies, so there is no diagnostic at all, only a stack trace | The grammar requires at least one `templateParam`, so `with ()` is a syntax error — but ANTLR error-recovers by handing the walker a `TemplateParamContext` with **no index token** rather than by skipping the rule. `buildTemplateParams` called `paramCtx.NUMBER_LITERAL().GetText()` on it | `mdl/visitor/visitor_microflow_actions.go` (`buildTemplateParams`) | **A visitor walks error-recovered trees, so grammar-guaranteed tokens are not guaranteed at the walker.** "The rule requires it" is a statement about valid input; recovery synthesises contexts that satisfy no rule. Guard at the dereference, not by tightening the grammar. The other 11 `NUMBER_LITERAL().GetText()` sites in `mdl/visitor/` were checked and all already nil-guard — this was the only bare one, so no sweep was needed. **The control test is the point**: a guard that `continue`s on nil passes the crash test while silently dropping every parameter, so assert a well-formed `with ({1} = …, {2} = …)` still yields both. Tests `mdl/visitor/parser_batch_findings_test.go` (`TestLogEmptyTemplateParamsIsAnErrorNotAPanic`, `TestLogTemplateParamsStillBuild`); the crash becomes `line 3:20 mismatched input ')' expecting '{'`. Reported in mxcli-chat FINDINGS §55 |
-| An import activity's Range — Studio Pro's **All / First / Custom** — is absent from `DESCRIBE MICROFLOW`, and a `limit`/`offset` set in Studio Pro does not survive an mxcli round trip | Worse than "undescribed". `Microflows$ImportMappingCall.Range` is polymorphic — `ConstantRange{SingleObject}` (All/First) or `CustomRange{LimitExpression, OffsetExpression}` (Custom) — and mxcli wrote only the first and read only `SingleObject`. So **Custom was unrepresentable**, a bounded import became unbounded on any rewrite, and all three settings described identically, so describe→edit→exec silently changed the activity | `mdl/grammar/domains/MDLMicroflow.g4` (`importMappingRange`) + `MDLLexer.g4` (`FIRST`) + `MDLSettings.g4` (keyword list), `mdl/visitor/visitor_import_export_mapping.go`, `mdl/ast/ast_microflow.go`, `sdk/microflows/microflows_actions.go` (`RangeSingleObject`, `RangeSingleObjectOf`), `mdl/executor/cmd_microflows_builder_calls.go` (`addImportFromMappingAction`), `mdl/executor/cmd_microflows_format_action.go` (`formatImportMappingRange`), `mdl/backend/modelsdk/microflow_write.go` (`importMappingRangeToGen`) + `microflow_read_actions.go`, `sdk/mpr/writer_microflow_actions.go` (`importMappingRange`) + `parser_microflow_actions.go` | **The Range and the result variable's CARDINALITY are separate axes** — the first fix folded them and every `all` wrote a `ListType` against an object-rooted mapping, which mxbuild rejects with **CE0243** ("the mapping used to return 'List of X' but now returns 'X'"). Mendix's own `FeedbackModule.SUB_Feedback_PostToAppInsights` settles it: `ConstantRange{SingleObject:false}` against an **ObjectType** variable. The stored `VariableType` is the authority on cardinality; the range is its own flag (hence `RangeSingleObject *bool`, nil = "not authored, fall back"). **Count the write sites before declaring a serialization fixed** — the `ImportMappingCall` is built at THREE places (`importXmlActionToGen`, the REST `ResultHandlingMapping` case, and the legacy writer), and patching two let a limit reach the model while a `ConstantRange` was still written; extract one helper. **DESCRIBE must emit one of the three, never nothing** — silence re-enters the builder's inference, and an object-rooted mapping set to All (Studio Pro's default) comes back as First. **`first` is not `limit 1`**: one binds an OBJECT, the other a one-element LIST, so they cannot share syntax. **A platform rule you cannot author a positive case for is documentation, not validation** — Mendix rejects `offset` on a non-list mapping with **CE6100** while accepting `limit`, and mxcli cannot currently author a list-rooted import mapping (array-root mappings emit CE5015), so the constraint is documented rather than guessed at in a checker. Tests `mdl/executor/cmd_microflows_import_range_test.go`, `mdl/backend/modelsdk/microflow_import_range_test.go`, `sdk/mpr/parser_microflow_import_range_test.go`, example `mdl-examples/bug-tests/881-import-mapping-range.mdl`. upstream #881 |
-| `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 |
-| `create validation rule …` parses and silently writes nothing, so a regex document cannot be bound to an attribute from MDL at all — every form (regex, range, required, unique, expression) reports success and leaves the model untouched | Three layers, one visible symptom. (1) The grammar rule existed with **no AST node, no visitor and no handler**. (2) Its shape was unimplementable: an `EXPRESSION` rule type Mendix does not have, an **inline** regex literal where Mendix stores a **reference to a document**, and strict `<`/`>` bounds Mendix cannot represent. (3) Underneath, `modelsdk/gen` bound `RegExRuleInfo`'s reference to BSON `RegularExpression` where Studio Pro stores `RegExIdentifier`, so the rule could not have been written even with the statement wired up | `modelsdk/gen/domainmodels/types.go` (`STORAGE-NAME OVERRIDE` on `initRegExRuleInfo` **and** `InitFromRaw`), `mdl/backend/modelsdk/domainmodel.go` (`ruleInfoFromGen`) + `domainmodel_write.go` (`ruleInfoToGen` now takes the whole rule), `sdk/domainmodel/domainmodel.go` (regex ref is a qualified NAME not an ID; Range gained the attribute-bound fields), `mdl/grammar/domains/MDLDomainModel.g4`, `mdl/ast/ast_validationrule.go`, `mdl/visitor/visitor_validationrule.go`, `mdl/executor/cmd_validationrules.go`, `mdl/executor/cmd_entities_describe.go` | **Correcting `modelsdk/gen` IS available** — this supersedes the previous row's "no `supplements.json` or `cmd/modelsdk-codegen` in this tree, so correcting gen is not currently available". Neither path has ever existed here (`git log --all` empty) and `/reference/` is gitignored, but four `STORAGE-NAME OVERRIDE` precedents already hand-patch `init<Type>`, and `TestGeneratedCodeIsFormatted` exists because gen gets hand-edited. **`generated/metamodel` is the arbiter**: `cmd/codegen` emits the storage name as the json tag (`json:"regExIdentifier"`) while gen kept the SDK name — an audit of all 570 cross-checkable types found **65 with at least one wrong key**, and the three with independent evidence (`RegularExpression.Expression`, `Attribute.GUID`, this one) were all flagged correctly. **Patch BOTH the encode and decode literal**: reverting only `init` gave a document that writes `RegularExpression` and reads `RegExIdentifier`, whose symptom is a confusing entity-rewrite refusal rather than a bad file. **The control is the proof**: same script, key reverted → `CE0135 "No regular expression specified"` on mxbuild 11.13; with the fix → 0 errors and `RegExIdentifier` on disk. **A rule type is not a rule** — `ruleInfoToGen(ruleType string)` could never rebuild a RegEx (its reference) or a Range (its bounds), so it was widened to the whole rule and the reader taught to carry the payload; a bare RuleInfo of the right `$Type` is a silent downgrade wearing the right name. **Check for a bound that is not a literal**: a Range may point at another ATTRIBUTE, which MDL cannot author and a literals-only reader would have dropped on the next rewrite. **Do not add a second spelling for something already authorable** — Required/Unique stay attribute constraints (`not null error '…'`), refused here with a pointer. **Fixing an unimplementable grammar is free when nothing could depend on it**: every old form parsed and did nothing, so the shape was replaced rather than preserved. Tests `modelsdk/gen/domainmodels/storagename_test.go`, `mdl/backend/modelsdk/validationrule_test.go`, `mdl/visitor/visitor_validationrule_test.go`, `mdl/executor/cmd_validationrules_test.go`, example `mdl-examples/doctype-tests/validation-rules.mdl` |
-| An `@annotation` mxcli does not implement — `@size(600, 300)` — parses and does nothing, and layout authored through annotations silently differs from what was written | The grammar accepts any `@name`, and `extractMicroflowAnnotations`' switch had **no default arm**, so an unrecognised name was dropped in silence. Benign for an unimplemented annotation; NOT benign for a typo of an implemented one — `@postion(10, 20)` passed `check` and discarded the position | `mdl/ast/ast_microflow.go` (`ActivityAnnotations.UnknownNames`), `mdl/ast/annotations.go` (new: `StatementAnnotations`), `mdl/visitor/visitor_microflow_statements.go` (the `default:` arm), `mdl/executor/validate_microflow.go` (`checkUnknownAnnotations`, `knownActivityAnnotations`, MDL059), `mdl/executor/validate.go` (exec-enforced) | **A silent no-op is worse than an unimplemented feature** — the reporter filed "`@size` is ignored", but the same missing arm meant a typo of the annotation their whole workflow depends on threw away the layout with a clean `check`. Fix the class, not the instance. **Read the annotations generically, not through a type switch**: 15 statement types carry `Annotations`, and a hand-written switch that skips the 16th reintroduces the silent drop one level up — `StatementAnnotations` reflects, and `TestEveryActivityAnnotationsFieldIsNamedAnnotations` parses the AST package's own source for every `*ActivityAnnotations` field and asserts it is named so the accessor reaches it. **Pin a restated list against its source**: `knownActivityAnnotations` duplicates the visitor's case labels, so `TestKnownAnnotationsMatchTheVisitor` parses those labels out of the visitor and compares both directions — a name in one and not the other either rejects a working annotation or accepts a dead one. **Check a new rejection against the real corpus before believing it**: `scripts/check-skill-mdl.sh` over `.claude/skills/mendix` and `docs-site/src` (405 blocks) proved no false positives. Tests `mdl/ast/annotations_test.go`, `mdl/executor/validate_annotations_test.go`. upstream #884 |
-| `mxcli lint` reports MPR008 "activities overlap" for two nodes that live on different canvases — one inside a loop, one outside — so generated layout is flagged for an overlap that cannot happen on screen | `collect` recursed into `LoopedActivity.ObjectCollection` and appended the children into the **same flat list** as the microflow's own canvas, then compared every pair. A LoopedActivity's children are positioned RELATIVE to the container; verified in the stored BSON — outer activity `200;230` (absolute) beside a loop child `141;130` (container-relative) | `mdl/linter/rules/mpr008_overlapping_activities.go` (`overlapPlanes`, one plane per canvas; the pair loop iterates per plane) | **A false positive on a layout rule is worse than silence** — the rule exists to be trusted about positions. **Extract the inline logic to make the fix testable**: the rule's own test file carried a note that the overlap logic "cannot be unit-tested without building a mock mpr.Reader", which is why the bug had no coverage; `overlapPlanes` is a pure function over the object tree and needs no reader. **Assert both directions** — the cross-canvas pair must stop being reported AND a genuine same-canvas pair at (300,200)/(310,210) must still be, or the fix trades a false positive for a false negative. **The reporter's own numbers did not reproduce**: (141,130) vs (134,230) is dy=100 against `activityBoxHeight = 60`, so that pair never fired; the mechanism was real but the quoted evidence was not, and a constructed pair was needed to demonstrate it. **A vanished fixture reads exactly like a fixed bug** — an intermediate "no violations" result was the scratch project having been reaped, not the fix working; the A/B was redone with a pre-fix binary against the same rebuilt project. Tests `mpr008_overlapping_activities_test.go`. upstream #884 |
-| A hand-curved sequence flow does not survive a rewrite — `DESCRIBE` output is identical before and after the curve is drawn in Studio Pro, and re-running unchanged MDL straightens the edge | Mendix stores NO waypoints. A flow's shape is two bezier control vectors on its `Microflows$BezierCurve` line (`OriginControlVector`/`DestinationControlVector`, `"x;y"`). Both writers already emitted them and the legacy parser already read them, but nothing could SET them, so they defaulted to `"0;0"` and every rebuild flattened the curve — measured by patching `"40;-90"` into the stored line and re-executing the same script, which returned `"0;0"` | `mdl/ast/ast_microflow.go` (`FlowCurve`, `ActivityAnnotations.Curve`/`InvalidCurves`), `mdl/visitor/visitor_microflow_statements.go` (`parseCurveAnnotation`, `annotationPointValue`), `mdl/executor/cmd_microflows_builder_annotations.go` (`curveByOrigin`, `applyFlowCurves`, and the `mergeStatementAnnotations` copy), `cmd_microflows_builder_graph.go` (the one call), `cmd_microflows_show_helpers.go` (`emitCurveAnnotation`), `mdl/backend/modelsdk/microflow.go` (read the Line back) | **Check what the storage can represent before designing the syntax** — the request asked for "edge waypoints", which do not exist; `SequenceFlow` has two control vectors, so `@curve(from: (x, y), to: (x, y))` is the only shape that maps. Same lesson as #872's anchors. **Look for an existing annotation shape before touching the grammar**: `name: (x, y)` is already `annotationParenValue`, so `@curve` needed ZERO grammar changes. **Record against the ACTIVITY and stamp flows in one pass** — threading a curve alongside the anchor would mean editing all seven sites that create a flow (`previousStmtAnchor`, `nextFlowAnchor`, branch and loop variants) and missing one silently straightens that edge; `applyPendingAnnotations` already runs at every activity, so there is exactly one place to get right. **A new field on `ActivityAnnotations` must be copied in `mergeStatementAnnotations`** — it is an explicit field-by-field copy, so the first cut parsed the curve and wrote nothing. **Unit tests that call the function directly do NOT prove the wiring**: deleting both call sites left `TestEmitCurveAnnotation` and `TestApplyFlowCurves…` green, which is the "a test that only passes against fixed code" trap in its purest form — `TestCurveReachesTheFlowThroughTheBuilder` (MDL text → real builder) and `TestCurveIsEmittedByTheAnnotationEmitter` (through `emitObjectAnnotations`) fail when unwired. **Still open**: a curve drawn in Studio Pro is preserved only once the script names it, since a rebuilt flow has no stable identity to match on; DESCRIBE now surfaces it so it can be captured. Tests `mdl/executor/cmd_microflows_curve_test.go`, example `mdl-examples/bug-tests/884-annotations-and-lint-planes.mdl`. upstream #884 |
-| `mxcli run --local --ensure-db` fails on a freshly built `mxcli init` dev container — there is no PostgreSQL service to start and no `postgres` superuser — even though `psql` is on PATH | The generated Dockerfile installed `postgresql-client` **only**. `EnsureDatabase` starts a local service (`service postgresql start`) and provisions the role + database through `sudo -u postgres psql`, both of which need the **server** package. `psql` being present makes the container look correctly provisioned | `cmd/mxcli/tool_templates.go` (`generateDockerfile`) | Install `postgresql` alongside `postgresql-client`. **Generalisable**: when a feature shells out to a service, assert the *server* package in the image template, not the client that happens to satisfy a `LookPath` check — the CI/web image having the server is what hid this (`/usr/lib/postgresql/16` is present there but not in the generated dev container). Guarded by `TestGenerateDockerfile_PostgresServer`, which asserts the server package for both the docker and podman variants |
-| The implicit merge that closes a split — the end-if join — is placed by the layout pass and cannot be moved; it routinely lands on top of a neighbouring activity, and `@position` does not address it | The statement's own `@position` belongs to the SPLIT, so the merge had no annotation of its own. Three split builders computed `mergeX/centerY` with no override (`addIfStatement`, `addEnumSplit`, `addStructuredInheritanceSplit`), and DESCRIBE emitted nothing for it, so even a hand-moved merge was recomputed on the next exec | `mdl/ast/ast_microflow.go` (`ActivityAnnotations.Merge`), `mdl/visitor/visitor_microflow_statements.go` (`case "merge"`), `mdl/executor/cmd_microflows_builder_annotations.go` (`mergePosition`, and the `mergeStatementAnnotations` copy), the three split builders, `cmd_microflows_show_helpers.go` (`emitMergeAnnotation`, `commonMergeAfter`) | **Authoring without the DESCRIBE half is not a fix** — the first attempt shipped `@merge` writing correctly and was REVERTED, because the describer drops it and the layout pass then recomputes the merge on the next exec; that is the same round-trip data loss as #872/#881/#882, introduced by the change meant to help. **Find the relationship from data already in scope rather than threading a map**: the describer's `splitMergeMap` is not available at `emitObjectAnnotations`, and threading it would mean editing ten-plus call sites (the multi-site trap); `commonMergeAfter` walks the split's branches to the nearest merge reachable from ALL of them, using the `flowsByOrigin` and `activityMap` already passed in. **Bound any walk over a flow graph** — a retry loop makes it cyclic, so the walk carries a per-branch visited set and a node cap, pinned by `TestCommonMergeAfterTerminatesOnACycle`. **One helper for every site that places the merge**, so the override cannot be honoured at one split type and ignored at another. **Test the WIRING, not the helper**: `mergePosition` and `emitMergeAnnotation` called directly pass with every call site removed — `TestMergeReachesTheCanvasThroughTheBuilder` (MDL text → real builder) and `TestMergeIsEmittedByTheAnnotationEmitter` (through `emitObjectAnnotations`) fail when unwired, verified by removing each. Tests `mdl/executor/cmd_microflows_merge_test.go`, example `mdl-examples/bug-tests/884-annotations-and-lint-planes.mdl`. upstream #884 |
-| `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 | 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 | `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`) | **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 |
-| `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 | 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 | `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`) | **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 |
-| Authoring a pluggable widget property that lives in a **conditionally shown group** writes a widget Mendix rejects with **CE0463**, while the same widget's other properties take non-default values happily. On ProgressCircle both `showLabel: true` and `labelType: 'percentage'` do it; `showLabel: false` and General-group properties are clean. No DESCRIBE involved | Two gaps on the same axis. **Serialization**: #574 nulls the TextTemplate of a HIDDEN conditional property, but left a VISIBLE one null — and Mendix stores an empty `Forms$ClientTemplate` there. Null and empty are each invalid in the other's state, so nulling hidden ones was only half the rule. **Extraction**: the editorConfig reader did not understand a ternary's ELSE branch (`cond ? (…) : hidePropertiesIn([…])`), so the `showLabel` gate was never seen and `labelText` read as visible whenever `labelType` was `"text"` — its default | `mdl/backend/widgetobj/builder.go` (`ApplyVisibilityRules`, `bsonFieldIsNil`), `mdl/executor/editorconfig_extract.go` (`parseGuard` `:` case, `ternaryCondition`, `trailingExpr`) | **Fixing one gap alone inverts the bug rather than closing it** — filling visible templates without the missing gate made `showLabel: false` fail where `true` had, because mxcli still thought labelText was visible. Measured both ways round before and after; a fix that moves which case fails is not a fix. **Let Mendix say what the shape should be**: `mx update-widgets` on a COPY of the failing project reconciles the widget, and diffing that against mxcli's output named the single meaningful path (`Object/Properties[N]/Value/TextTemplate` null vs `Forms$ClientTemplate`) out of 969. **The good/bad control does the isolation for free**: authoring the same widget with the boolean both ways gave two documents differing in exactly ONE path, so no other candidate needed testing. **Only CONDITIONAL properties are filled** — Studio Pro's convention for an unset TextTemplate is not uniform (a DataGrid custom-content column stores null for `tooltip` and an empty template for `exportValue`, per `emptyClientTemplateRules`), so filling every unset one would trade this bug for its mirror image. **The extractor's preamble matters**: the ternary is preceded by a whole `switch`, and walking back past the `?` to the function start yields a fragment with an unbalanced `}` that parses to nothing and looks like "unsupported shape" — hence `trailingExpr`. Regression signal: the widgetdemo showcase applies with **0 CE0463** (its 4 CE1613 are a pre-existing attribute reference). Tests `mdl/backend/widgetobj/widget_visibility_test.go`, `mdl/executor/editorconfig_extract_test.go`; example `mdl-examples/bug-tests/pluggable-describe-roundtrip.mdl` now exercises the group. Reported in mxcli-ledger FINDINGS #104 follow-on |
-| `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]` | 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 | `mdl/executor/cmd_folders.go` (`execDropFolder`, `folderContentSummary`), `mdl/executor/cmd_list_folders.go` (`documentsByContainer`) | 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 |
-| `ALTER PAGE` **`REPLACE <col>`** or **`INSERT AFTER <col>`** naming a DataGrid2 column with a BARE name reports "Altered page", but the column vanishes (REPLACE) or nothing changes (INSERT) — and Studio Pro / `mx check` then cannot **LOAD** the project: `System.InvalidCastException: Unable to cast object of type '…LayoutWidgets.DivContainers.DivContainer' to type '…CustomWidgets.WidgetObject'` | `ast.WidgetRef` treats only a **dotted** name as a column, so a bare `NextRunAt` gives `Widget="NextRunAt"`, `Column=""`, `IsColumn()==false`. The op skipped the `InsertColumns`/`ReplaceColumn` paths — which work correctly — and fell through to the generic widget path, which built the `COLUMN` as a **layout container** and wrote it into the grid's column list. Nothing refused because `findBsonWidget` **recurses into pluggable-widget internals**, so the bare name *did* resolve — to the column node. `DESCRIBE PAGE` then skipped the malformed node, which is what made REPLACE look like a clean deletion and INSERT like a harmless no-op | `mdl/backend/pagemutator/mutator.go` (`refuseObjectListItemTarget`, called from `InsertWidget` + `ReplaceWidget`) | Discriminate on the resolved node's **`$Type`**: an object-list item (DataGrid2 column, Accordion group, PopupMenu basicItem) is `CustomWidgets$WidgetObject`, a real widget is `Forms$*` / `CustomWidgets$CustomWidget`. Refuse the bare form and name the qualified `grid.column` in the message — do **not** auto-resolve, since guessing which grid was meant is what produced the invalid document. Do not discriminate by *counting* name matches: `columnMatchCount` already existed but only refused when `n > 1`, so the single-match case (the common one) sailed through, and a widget that merely shares a name with some column elsewhere would be a false positive. Guard belongs in the **mutator**, not the executor — `FindWidget` matches columns too, so an executor-level check on it only catches names that are absent entirely, which the mutator already refuses. Repro `mdl-examples/bug-tests/891-alter-page-bare-column-target.fail.mdl`. Issue #891 |
-| `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 | 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 | `mdl/executor/cmd_pages_describe_objectlist.go` (`rawObjectListItem.Children`, `extractObjectListItem`), `mdl/executor/cmd_pages_describe_output.go` (the object-list item loop) | 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 |
-| A microflow computes a **different number than the expression says**, while `mxcli check`, `mx check` and the build are all green. An additive chain comes back from `DESCRIBE MICROFLOW` with its `+` and `-` exchanged — `$A - $B + 1` stored as `$A + $B - 1`. All-plus and all-minus chains are fine, as is `-` against `*` | `buildAdditiveExpression` read `AllPLUS()` and `AllMINUS()` as two separate token lists and emitted **every plus before every minus**, discarding source order. The precise rule is "the chain is re-sorted, all `+` ahead of all `-`" — sharper than "a `-` followed by a `+` swaps", and it predicts which cases survive | `mdl/visitor/visitor_microflow_expression.go` (`buildAdditiveExpression`) | **The fix already existed 20 lines below**: `buildMultiplicativeExpression` walks `GetChildren()` in order and builds its operator list correctly, so the additive case is that pattern copied — no new mechanism. The corruption is in the **stored model**, not in DESCRIBE: `strings` on the `.mxunit` shows the swapped text, which is why the running app computes it. A rewritten expression is perfectly valid, so no validator can catch this class — the only test that works is round-trip equality, not "does it apply cleanly". **The control cases carry the weight**: `$A - $B - 1` and `$A + $B - 1` pass both before and after, so a test built only from failing cases would have passed against code that sorted all minuses first instead. Verified by reverting the fix and confirming exactly the four swapped cases fail. Test `mdl/visitor/visitor_additive_order_test.go`; example `mdl-examples/bug-tests/additive-operator-order.mdl`. Reported in mxcli-ledger FINDINGS #105 |
-| `mxcli test` reports **PASS for an assertion that must fail** — `@expect 1 = 2`, `@expect length($result) = 999`, `@expect find($result, 'Z') >= 0` with the needle absent. Nothing in the output distinguishes a real assertion from a vacuous one, so a suite certifies work as verified while asserting only that the microflow did not throw. Mutation testing is what exposes it: mutants that return an obviously wrong value survive the suite | The `@expect` annotation was matched with a regex for one shape — `@expect $var (=|<>) <value>` — and `FindStringSubmatch` returning nil produced **no assertion at all** rather than an error. A test with zero assertions passes if its body completes. So the narrow support was not the defect; the silence was | `cmd/mxcli/testrunner/parser.go` (`expectPattern`, `parseAnnotations`), `cmd/mxcli/testrunner/expect.go` (new — `ParseExpect`, the validating parser), `cmd/mxcli/testrunner/generator_endpoint.go` + `generator.go` (emit the condition, not a rebuilt equality), `cmd/mxcli/testrunner/results.go` (`expectErrorResult`) | Capture the **whole** annotation body and hand it to a validating parser; anything it cannot compile becomes an `ExpectErrors` entry, the test is not generated at all, and the runner reports `StatusError` (which `FailCount` counts, so the exit code is non-zero). The parser is a strict recursive-descent pass over `exprcheck.Lex` — **not** `mdl/exprcheck`'s own parser, which recovers and emits hints, exactly the wrong behaviour here. Two measurements pinned the emitted expression against mxbuild 11.6.6: `<>` really is CE0117 (so the rewrite to `!=` is load-bearing, not cosmetic) and a wrong-typed comparison really is caught (`$result = 3` → CE0117), which is what makes the 0-error run on the 11 generated shapes mean something. **Generalisable**: when a pattern-matching parser can match *less* than its input, the non-match branch is a silent-failure path — audit every `if m := re.FindStringSubmatch(...); m != nil` whose else-branch does nothing. Repro `mdl-examples/bug-tests/expect-vacuous-assertions.mdl`. mxcli-sudoku FINDINGS #46 |
-| A test suite's green is unreadable: a test that asserts **nothing** prints the same `PASS` as one with six assertions, and `@verify` — documented as an OQL post-condition — is parsed and evaluated by nothing at all. After @expect started failing closed, the cheapest way back to green is to delete the assertion, and the output cannot tell that apart from a repair | Two silent-absence paths rather than the silent-drop path fixed in the row above. `TestResult` carried no assertion count, so nothing downstream could report one; and `TestCase.Verify` was populated by `parseAnnotations` and read by nothing but `--list` — `grep -n '\.Verify' cmd/mxcli/testrunner/*.go` returns the parser and the lister, no runner | `cmd/mxcli/testrunner/results.go` (`TestResult.Assertions`/`SourceFile`, `newResult`, `vacuousResult`, `resultNote`, `VacuousCount`), `cmd/mxcli/testrunner/parser.go` (`AssertionCount`, `AssertionErrors`, the @verify rejection), `cmd/mxcli/testrunner/junit.go` (`junitClassName`, assertions property), `cmd/mxcli/main.go` + `cmd_test_run.go` (`--require-assertions`) | Count assertions on the test case and carry them onto every result through **one** constructor (`newResult`) — the previous code built `TestResult` literals at five sites, which is exactly how a new field gets populated in one path and silently missing in another. Report the count on the ordinary result line, not behind `--verbose`: the whole lesson of #46 is that the *default* output must distinguish a test that asserted from one that did not. Vacuous tests warn by default and error under `--require-assertions`, because a smoke test is legitimate but an indistinguishable one is not. **Generalisable**: when auditing an annotation/config field for dead ends, grep for *readers*, not writers — a field with a parser and no consumer is a feature the docs promise and the code does not deliver, and it fails silently by construction. mxcli-sudoku FINDINGS #46 (follow-up) |
-| `@verify` cannot fail. No OQL — well-formed or not, true or not, against a real entity or an invented one — makes a test fail: `@verify select count(*) as n from Mod.Game = 999999` reports PASS on a table with one row, and so does `this is not a query` | The annotation was parsed into `TestCase.Verify` and read by nothing but `--list`. Same silent-absence class as the dropped `@expect`, in the annotation covering the *harder* half of Mendix testing: most microflows are side effects, so asserting on rows written is the only way to test them | `cmd/mxcli/testrunner/verify.go` (new — `ParseVerify`, `scalarOf`, `compare`, `runVerifies`), `cmd/mxcli/testrunner/parser.go` (`checkVerifyCleanup`), `runner_endpoint.go` + `runner_attach.go` + `watch.go` (`adminOptions` on `testTarget`), `runner.go` (`rejectVerifyOnLegacyRunner`) | Run the OQL over the admin API after the microflow returns, compare against a literal, and keep three outcomes apart: holds → unchanged, does not hold → FAIL with the observed value, cannot be evaluated → ERROR. Three things are enforced rather than left to trip you up, each learned by running it: **`@cleanup rollback` is refused** (the default undoes the writes before the query could see them, so it would assert against the pre-test state); **the result must be one row × one column** (picking a cell out of a table is a guess); and the **legacy after-startup runner refuses the whole suite**, since its tests run during boot with no seam to query at. Split the expected value off at the **last** comparison operator outside quotes and parens, then require the RHS to be a literal — without that check the split silently eats a `where x = 1` and sends a truncated query. **Generalisable**: unit tests with a stubbed endpoint proved the logic and would have shipped it broken — the first real run against a booted app found the OQL endpoint unreachable on that Mendix and the alias requirement, neither of which any stub could show. mxcli-sudoku FINDINGS #48 |
-| Running `mxcli test` dirties the project: `git status` reports the `.mpr` modified after a run that changed nothing, so a "run the tests, assert the tree is clean" CI step fails and a pull request carries a meaningless diff. `mprcontents/` is byte-identical; only the `.mpr` differs, and a `.mpr` diff is opaque | The runner injects an `MxTest` module and takes it back out. Cleanup restores the model, but every unit write stamps a fresh UUID into the `.mpr`'s `_Transaction.LastTransactionID` (`updateTransactionID`, in both engines' writers) **and** the insert/delete cycle relays SQLite's pages. Restoring the row alone is measurably insufficient: three consecutive runs then hold the id stable and still produce a different file hash each time | `cmd/mxcli/testrunner/snapshot.go` (new — `projectSnapshot`, `documentTreeDigest`), `cmd/mxcli/testrunner/runner.go` (`captureProjectState`, `restoreProjectFile` at all three cleanup sites), `cmd/mxcli/testrunner/host.go` (`HostedEndpoint.Remove`) | Snapshot the whole `.mpr` before injecting and write it back after a successful cleanup — byte-exact by construction rather than by enumerating what might have changed. Two refusals are load-bearing: **cleanup failed** and **the `mprcontents/` tree moved**. In either case the project is not in the state the snapshot describes, and restoring would turn a visible harmless discrepancy into an invisible misleading one — a tree that reads as clean while the model is not. Write through a temp file + rename so an interrupted restore cannot truncate the `.mpr`. **Generalisable**: a tool that mutates a project to do its work owes a restore that is byte-exact, not semantically equivalent — every consumer downstream of it compares bytes. And when the obvious cause is a single row, measure the file hash before concluding it is the only one. Verified with the reporter's own harness: 3 runs, `.mpr` and `mprcontents` hashes unchanged throughout. mxcli-sudoku FINDINGS #47 |
-| `run --local --watch` deploys a **half-applied model** when an `mxcli exec` is running, and there is no way to recover: re-running the script writes nothing (it is byte-idempotent), so nothing re-triggers the watcher and the stale build stands | `watchAndApply` (`cmd/mxcli/docker/runlocal.go`) rebuilt on the **first** mtime bump. An exec rewrites the `.mpr` and many `mprcontents/*.mxunit` over seconds, so the build snapshots the tree mid-write. There was a settle for the web bundler and nothing for the model. Two behaviours each correct alone: idempotency removed a *recovery path* nobody had written down as one — "just run it again" was load-bearing | `cmd/mxcli/docker/runlocal.go` (`settleSource`, `sourceSettleWindow`, the `case <-ticker.C` branch) | Wait for the source mtime to stop advancing (two poll intervals of quiet) before building. The wait is unbounded on purpose — a long exec is the case it exists for, and building late beats building mid-write — but it still honours the interrupt channel so Ctrl-C is not swallowed. `touch` on the `.mpr` remains the force-rebuild hatch, now documented. **Generalisable, twice over**: (a) a change *signal* is not a change *event* — anything polling mtime must debounce or it samples a writer mid-flight; (b) when adding an optimisation that skips work, ask what informal recovery procedure depended on that work happening. **Test trap hit while fixing it**: the first version asserted the file count *after* `wg.Wait()`, which holds against a `settleSource` that returns immediately — the assertion has to read the writer's state at the moment it returned. mxcli-sudoku FINDINGS #45 |
-| An OQL `ORDER BY` on a **DateTime** looks ignored: `order by DealtAt desc limit 5` returns old rows while `order by Id desc` returns genuinely new ones, and the wrong answer is **stable across runs** — so it reads as a platform bug rather than a data problem, and the natural workaround becomes "order by Id for recency" | **Not an mxcli bug, and not a Mendix bug.** Mendix emits the ordering with no null placement, so the database default applies: on PostgreSQL `DESC` means **NULLS FIRST**, and rows whose attribute was never set head the result. Stability is what makes it convincing and wrong — a degenerate sort key is exactly as repeatable as a correct one, so "stable, therefore not a tie-break artifact" does not discriminate | Nothing to change in mxcli — `ExecuteOQL` passes the query verbatim and `parseOQLFeedback` preserves row order. Docs only: `docs-site/src/tools/oql.md`, `.claude/skills/mendix/write-oql-queries.md` | Measured on **Mendix 11.13.0** with PostgreSQL statement logging on, which is the method to reuse: `ALTER SYSTEM SET log_statement='all'`, run the query, read the SQL the runtime actually sent. With four distinct non-null timestamps the emitted SQL is `… ORDER BY "x"."dealtat" DESC LIMIT $1` and the result is correctly ordered — the ordering is **not** dropped. Adding two rows with an empty DealtAt reproduces the reported symptom exactly, and running Mendix's own emitted SQL by hand with `NULLS LAST` fixes it. **Generalisable**: when a query returns a wrong-but-stable answer, suspect a degenerate sort key before suspecting the engine; and when a bug report blames a layer, check whether that layer is even in the path — here the same finding also reported the column being *dropped from the projection*, whose known mechanism is a null in the first row, which was direct evidence for the real cause sitting unread in the report. mxcli-sudoku FINDINGS #39 (second half) |
-| `ALTER PAGE SET <prop> ON <grid>.<col>` fails with `column property "X" not found` for a property the very same tool writes happily inside `CREATE PAGE`. `check --references` passes the statement that `exec` rejects, so the disagreement only surfaces at write time | Two hand-written alias tables for one widget schema, drifted. The create path (`mdl/executor/widget_defs.go` `itemPropertyAliases`) aliased `DynamicCellClass` → `columnClass`; the ALTER path (`mdl/backend/pagemutator/mutator.go` `columnPropertyAliases`) kept its own copy and did not — the file contained zero occurrences of the string | `mdl/types/widget_item_aliases.go` (new — `ItemPropertyAliases` moved here), `mdl/executor/widget_defs.go` (now a reference), `mdl/backend/pagemutator/mutator.go` (`resolveColumnPropertyKey`, `settableColumnProperties`) | Delete the second table rather than adding the missing row: resolve the MDL name against the schema keys the **document itself declares** (case-insensitively), falling back to the one shared alias table for genuine renames. A property the create path can write is then one ALTER can write, by construction. Case-only differences (`Sortable`→`sortable`) need no entry at all, which keeps the shared table down to real aliases. The not-found error now lists the settable keys read off that grid, so it is right for the widget version installed rather than the one mxcli was built against. **Generalisable**: two tables describing one external schema will drift; the fix is one table or none, never a third. mendixlabs/mxcli#919 |
-| `ALTER PAGE SET DynamicCellClass` / `SET Visible` on a DataGrid 2 column reports success and changes nothing visible: the value does not come back from `describe page`, and `mx check` stays at 0 errors | `setColumnPropertyMut` wrote every value to `PrimitiveValue`. `columnClass` and `visible` are **Expression**-valued, and a `CustomWidgets$WidgetValue` carries *every* field at once — Expression, PrimitiveValue, TextTemplate, AttributeRef — with the unused ones empty, so key-presence cannot tell you which one to write and the always-primitive default looked plausible. The value landed in a field Mendix does not read | `mdl/backend/pagemutator/mutator.go` (`columnValueField`, `buildColumnPropKeyMap` now also returns kinds, `bsonWidgetResult.colPropKinds`) | Take the kind from the schema — the column's `PropertyTypes[].ValueType.Type` — and write Expression, PrimitiveValue or the TextTemplate path accordingly; refuse the structured kinds (Attribute, DataSource, Action, Widgets) rather than writing a string where a reference belongs. Verified on Mendix 11.13.0: before, the write was invisible to DESCRIBE and `mx check` said 0 errors; after, it round-trips and mxbuild **validates** it — a valid expression builds at 0 errors and a bare identifier is CE0117, matching what CREATE produces for the same input. **Generalisable**: when a container type carries every variant field at once, presence is not a discriminator — the schema is. A silent wrong write is worse than the loud failure it was hiding behind |
-| 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 | 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`) | `mdl/executor/validate_widgets.go` (`validateDataGrid2ColumnName`, `derivedDataGrid2ColumnName`) | 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 |
-| `mxcli check script.mdl -p app.mpr` prints an unqualified `Check passed!` having resolved **nothing** against the project — a misspelled icon, entity or page name sails through the command that was handed the model. Reported as "check does not validate icon names", which it does | `cmd_check.go` gated the whole reference pass on `--references`, so supplying `-p` alone ran only the model-free rules. `validate_icon_refs.go` already existed and works (it names the offending icon and the `describe icon collection` command); it returns early when `!ctx.Connected()`, so it simply never ran | `cmd/mxcli/cmd_check.go` (`checkRefs = checkRefs || projectPath != ""`, the qualified pass message, help text), `cmd/mxcli/main.go` (flag help) | Make `-p` imply reference resolution — someone who hands the command a project has said what they want — and keep `--references` accepted so existing invocations survive. A run *without* a project now qualifies its verdict by naming what was not resolved. **Generalisable, and the third instance this month**: a clean report that cannot distinguish *checked and clean* from *not checked* is the same defect as a vacuous test assertion. When a feature needs two flags to do its job, the second one is usually a bug. Before adding a validator, check whether one exists and is merely unreachable. mxcli-dbreplication F5 |
-| 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) | 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 | `mdl/executor/validate_role_and_url.go` (new — `ValidateUserRoleSystemModuleRole` MDL-SEC20, `ValidatePageURLParameters` MDL-PAGE20, `urlBindsParameter`), `mdl/executor/validate_program.go` (wiring) | 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 |
-| `mxcli marketplace search 'Database Replication'` returns **No results** for a module that is right there; `search replication` finds it | `filterItems` matched the packaged name (`DatabaseReplication`) and publisher verbatim. Packaged names have no spaces, and `Content` carries no display-name field, so the name as written everywhere matched nothing | `internal/marketplace/client.go` (`normalizeSearchTerm`) | Fold case and drop separators (space, hyphen, underscore, dot) on **both** sides before matching, so the written name and the packaged name meet in the middle. Adding a display-name field was not an option — the API does not return one. **Generalisable**: when a search matches an identifier that was mechanically derived from a human name, normalise to the derivation, or every user has to guess the derivation. mxcli-dbreplication F7 |
-| `MDL-WIDGET16` fires 44 times on one project, once per DataGrid 2 column, all saying the same thing | 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 | `mdl/executor/validate_widgets.go` (`validateDataGrid2ColumnNames`, now called per widget rather than per object-list item) | 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 |
-| `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 | `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 | `mdl/executor/validate_widgets.go` (`builtinPropertyMisuse`, `misusedBuiltinProperty`, rule MDL-WIDGET17) | 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 |
-| A skill pack mxcli ships teaches a guard that cannot fire: `references/patterns.md` shows a splice caller doing `IF $Q/Rejected THEN -- fail the request`, and a project wrote and then deleted a Java action for that branch | The pack's **own** `QueryObject.java` throws `IllegalArgumentException` when `r.rejected && rejectUnsupported` **before** `Core.instantiate`, so a caller that receives a Query at all always has `Rejected = false`. The code is right and the documentation is wrong — and two further places repeated the claim (`SKILL.md`'s field table said `both`, `failure-modes.md` said "Pass `true`: `Rejected` comes back set") | `.claude/skills/packs/mendix-odata-pushdown/references/patterns.md`, `SKILL.md`, `references/failure-modes.md` (embed under `cmd/mxcli/skillpacks/` is regenerated by `make build`) | Delete the dead branch from the pattern and say why it cannot run, quoting the throw; mark `Rejected` as a **bind**-caller field. **Generalisable**: when a doc and the code it documents disagree, grep the whole pack — the claim is rarely in one place, and the two secondary mentions were the ones that would have re-taught it. A documented safeguard that silently is not one is the same defect class as a vacuous assertion. mxcli-owid #30 |
-| A two-column card layout renders as one column and the CSS is provably correct — it is on the wrong element | Mendix wraps a repeating widget's children in an intermediate element (`ul` for a list view, `.mx-dataview-content` for a data view), so `display: grid` on the widget's own class has exactly **one** grid item | `.claude/skills/mendix/migrate-design-prototype.md` | Put the grid on the element that holds the repeated children (`.my-cards > ul`), and `min-width: 0` on the child so a wide table does not push the track. The skill already used `> ul > li` in one example but never stated the rule, which is why the same project hit it **twice in two different widgets**. **Generalisable**: an example that happens to be right teaches nothing — if a selector's shape is load-bearing, say why. mxcli-owid #15, #41 |
-| `mxcli oql` fails on every Mendix older than 11.11 with *"Action not found ... upgrade mxcli"*, and separately reports a **rejected query as `0 rows`** rather than as an error | Two independent misreadings of the runtime's replies. (1) The 11.11+ REST route `/dev/preview_execute_oql` does not exist on older runtimes, and the admin API does not 404 it — it dispatches the POST as an ordinary admin request, finds no `action` field, and answers **HTTP 200** with `{"result":1,"message":"Action not found"}`. The fallback to the legacy M2EE action keyed on the 404 alone, so the legacy action — which works fine there — was never tried. (2) That legacy action reports a bad query as `{"feedback":{"error":"..."},"result":0}` — inside the feedback, with a **success** result code — so `M2EEError()` (which keys off the result) says nothing and the error body parses as an empty result | `cmd/mxcli/docker/oql.go` (`legacyOQL`, `oqlDevErrorKind`, the `error` field in `parseOQLFeedback`'s envelope) | Fall back to the legacy action on *either* absence signal, and surface `feedback.error` regardless of the result code. Measured on 11.6.6: before, `mxcli oql` could not run any query; after, `select count(*) as n from Mod.E` returns a row, and a bad query is an error instead of `0 rows`. **Generalisable**: when a fallback is keyed on one specific failure signal, check what the *other* end actually sends — an HTTP-level 404 and an application-level "not found" are different wires, and a success code next to an error message is common enough to assume it happens. Found while wiring @verify (FINDINGS #48); related to #39 |
-| Windows Defender flags the mxcli **Windows** release binary as `Trojan:Script/Sabsik.EN.A!ml`; enterprise EDR (Defender for Endpoint, CrowdStrike, SentinelOne) blocks it harder. Not the generic unsigned-Go-binary false positive of #185 | The binary genuinely embedded **chisel**, a dual-use tunnelling/pivoting tool (SSH over WebSocket), on every platform — although the tunnel only ever runs inside a Linux container. `run --hub` linked `chisel/client`, `tunnel-hub` linked `chisel/server`, so windows/darwin carried 32 packages incl. the whole `x/crypto/ssh` stack for a feature they cannot use | `cmd/mxcli/docker/tunnel_linux.go` + `tunnel_other.go` (client seam), `cmd/mxcli/tunnelhub/control_linux.go` + `control_other.go` (server seam), `scripts/check-tunnel-deps.sh` (guard) | **Never obfuscate, pack or rename to dodge the scanner** — attacker tradecraft, and it makes the binary less trustworthy, not more. **Code signing does not fix this class**: a signed binary containing chisel is still flagged behaviourally; signing only addresses #185's generic false positive. The fix is to stop shipping the capability where it is unused: one interface per seam, `_linux.go` impl + `!linux` stub, commands still registered everywhere but failing with an actionable message. **Prove absence three ways, and know that `go tool nm` is not one of them** — release ldflags `-s -w` strip the symbol table, so nm reports "no symbols" whether or not the code is linked and would give a false pass; use `go list -deps`, `go version -m`, and `strings` (nm only on a deliberately unstripped build). **Guard against the transitive path, not the name**: match the module list (`x/crypto/ssh`, `gorilla/websocket`, `armon/go-socks5`, `jpillora/*`) so re-entry without the word "chisel" still trips it, and assert a **positive control** (chisel IS in the linux graph) so the check cannot pass vacuously. Verified by re-adding the import and watching the guard fail on all four windows/darwin targets. Result: -13.5 MB (-14.7%) on windows+darwin, linux unchanged. See ADR-0009 |
-| CE7375 "must be published and be the key when associations are exposed as an associated object id" on a service publishing no associations | `PublishAssociations` is the representation, not a yes/no — `No` selects "as an associated object id", which needs the system ID as key | `mdl/executor/validate_odata_service_shape.go` | Set `PublishAssociations: Yes` ("as a link", and the default when omitted). MDL-ODATA06 warns at check time |
-| `mx check` exits with `System.ArgumentOutOfRangeException: length ('-1')` and no error code | an OData service `Path` with no slash in it; mxbuild throws out of its own validator | `mdl/executor/validate_odata_service_shape.go` | Path must not start with `/` and must end with one (CE6550/CE6552). MDL-ODATA05 catches all three |
-| `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 | 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 | `mdl/executor/cmd_entities.go` (`ast.AlterEntityRenameAttribute`), `mdl/executor/alter_entity_rename_attribute_test.go` | 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) |
-| After a `rename attribute`, `mx check` reports **CE0161 "Error(s) in XPath constraint."** at every retrieve, widget data source or entity access rule whose constraint named the attribute — and, if the attribute had a `READ *` access rule, **CE0066 "Entity access is out of date"** on the domain model | Two different causes with the same trigger. (a) XPath names an attribute as a **bare step** (`[Status = 'Open']`), which the qualified-name reference scanner cannot see — and which a scan for the bare name must not touch, since the same three letters are a string literal here, a function name there, and another entity's attribute somewhere else. (b) `UpdateEntity` re-derives an access rule's members from the attributes it can match, so renaming the attribute in the model left the old member orphaned; the reference scan then renamed the orphan into a **duplicate** of the new member | `mdl/xpathrefs/` (new: `rewrite.go`, `scan.go`), `mdl/executor/xpath_rename_model.go`, `mdl/executor/xpath_rename.go`, `mdl/executor/rename_attribute_entity_rules.go`, `mdl/executor/cmd_entities.go` | (a) **XPath needs no type inference** — a constraint's target entity is known *structurally* (a retrieve names its `Entity`, a widget data source its `EntityRef.QualifiedName`, an access rule the entity it sits inside), and every further hop is an association or entity named in the path. Resolve each bare step to its owning entity, then **edit one identifier token textually**; do NOT re-render the parsed tree, which would churn spacing in constraints the rename has no business touching and would corrupt any constraint the parser and renderer disagree about. **The load-bearing safety check is a count invariant**: `visitor.ParseXPathConstraint` runs with ANTLR's error listeners removed, so it recovers and can return a tree that silently omits part of its input (`[LastName = 'L' FirstName]` parses; the trailing step is simply absent) — require the lexical occurrence count and the walked occurrence count to agree, or refuse. Unresolvable → report and leave alone, never guess: for a *mutating* consumer the checking world's "unresolved → assume nothing → catch less" inverts into "unresolved → change nothing". (b) Fix the entity's own by-name references (`MemberAccess.AttributeName`, `ValidationRule.AttributeID`, range `Min/MaxAttributeQualifiedName`) **in the model before `UpdateEntity`**, not by leaving them to the scan afterwards. **Trap that cost an hour**: the stored `$Type` of a domain model entity node is `DomainModels$EntityImpl`, not `DomainModels$Entity` (that is the metamodel's name for a *reference target*) — checking the latter matched nothing and made every access rule look like a cautious refusal instead of a bug. Controls on Mendix 11.13.0 with `mdl-examples/bug-tests/910-rename-attribute-xpath-constraints.mdl`: same script without the rename = 0 errors, with the rename pre-fix = 3× CE0161 then 1× CE0066, post-fix = 0. mendixlabs/mxcli#910 (problem 2, XPath half) |
-| Authoring a pluggable widget with an **object list** (Accordion group, Pop-up menu item, chart series) raises **CE0463** "the definition of this widget has changed" on the widget itself, on a widget created seconds ago against the current package | An object-list item's **required TextTemplate** that the author left unset was serialized as `null`. `emptyClientTemplateRules` in `widgetobj/builder.go` is a hardcoded per-widget table covering only DataGrid columns, so every other object-list widget fell through it. Required-ness is genuinely absent from the widget XML for these properties — and the widget schema **defaults `required` to true** — so the Accordion's `headerText` is mandatory even though nothing says so | `mdl/backend/widgetobj/builder.go` (`isUnsetRequiredTextTemplate`, `buildDefaultTextClientTemplateProperty`), plus the entry plumbing in `mdl/types/widget_property_type.go`, `modelsdk/widgets/loader.go`, `sdk/pages/pages_widgets_advanced.go`, `mdl/backend/modelsdk/widget_pluggable_write.go` (`convertPropTypeIDs`) | Serialize a required unset TextTemplate with the widget's **shipped `<translations>`**, read off the template ValueType's `Translations` beside the `Required` flag. **Both weaker forms were measured and fail**: `null` is CE0463, and an *empty* `Forms$ClientTemplate` is **CE4899** "Property 'Groups/1/Text' is required" — so the intuitive "emit an empty template" fix only moves the error. Populating is what `mx update-widgets` itself writes (verified: mxcli and the reference now emit the same `'Header'`/`'Koptekst'`). Scope it to **required** properties: filling every TextTemplate is the documented way to take CE0463 from 33 to 127. Note `PropertyTypeIDEntry` exists in THREE places (`mdl/types` — canonical and aliased by `modelsdk/widgets`; `sdk/pages` — what the builder consumes; `sdk/widgets` — the legacy engine's own), so a field added for this must be carried through `convertPropTypeIDs` or it silently never arrives. Repro `mdl-examples/bug-tests/891-accordion-group-nested-widgets.mdl`. Issue #891 |
-| `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` | `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 | `mdl/executor/attribute_type_ref.go` (new), `mdl/executor/cmd_entities.go` (`AlterEntityModifyAttribute` case) | 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 |
-| 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 | 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 | `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` | 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 |
-| A skill claims a construct is unsupported that the grammar accepts (and documents the working form elsewhere in the same file) — an agent writes valid MDL, hits the contradicting claim, and undoes it. Seen for `case … end case` in `write-microflows.md` (supported at §CASE Statements, "not supported" under UNSUPPORTED Syntax), with `check-syntax.md`, `MDL_QUICK_REFERENCE.md`, three `docs-site` pages and the generated project CLAUDE.md (a third shape, `CASE $Var/Attr AS x WHEN Enum.Value`) all disagreeing | Nothing validates prose claims against the grammar. `scripts/check-skill-mdl.sh` extracts fenced blocks but deliberately **skips microflow bodies** (fragment-heavy), so every syntax claim about microflow statements is unguarded. The wrong "WRONG:" example also used string-literal case values, which fail for their own reason — making the claim look confirmed | Docs only: `.claude/skills/mendix/write-microflows.md` + `check-syntax.md`, `docs/01-project/MDL_QUICK_REFERENCE.md`, `docs-site/src/language/control-flow.md` + `appendixes/{quick-reference,common-mistakes}.md`, `cmd/mxcli/init_claudemd.go` (the generated table) | Settle it against the binary before editing, one variant per claim (`bin/mxcli check` on the documented form, the quoted form, the qualified form, the `AS` form, the `else` form) — a "WRONG" example that fails for an unrelated reason is not evidence. Then fix **every** surface: grep `end case\|END CASE` across `.claude/`, `docs/`, `docs-site/` and `cmd/mxcli/*.go`, not just the file in the report (7 surfaces, the issue named 3). Pin both directions in `mdl-examples/bug-tests/` — `907-case-enum-split-is-supported.mdl` (must pass) and `907-case-enum-split-invalid-forms.fail.mdl` (must fail) — so `make check-mdl` catches drift back. Issue #907 |
-| Docs disagree on whether an enumeration may be written as a string literal — the skills say "NEVER use a string literal", docs-site uses `Status = 'Draft'` in a dozen CREATE/CHANGE examples and calls it "plain strings when the context is unambiguous". Following either one wholesale is wrong, and `mxcli check` passes **both** the good and the bad form, so the build is where you find out | It is context-dependent and nobody had measured it. A string is accepted wherever the slot is **already enum-typed**; in an **expression** it is a String compared to an Enumeration | Docs only: `.claude/skills/mendix/write-microflows.md` (Enumeration Comparisons), `docs-site/src/language/{control-flow,expressions}.md`, `docs-site/src/reference/microflow/create-microflow.md` | Measure per context on a real project before touching a single example — one microflow per construct, `mxcli docker check` read per construct (`mxcli new EP --version 11.13.0 --skip-build`, then `exec` + `docker check`). Verified on 11.13.0: **CE0117** for `if $O/Status = 'Draft'` and for `'x' + $O/Status`; **clean** for `change`/`create` member values, attribute `DEFAULT 'Draft'`, XPath `[Status = 'Draft']`, and `getCaption()`/`toString()` in a concat. So fix **only** comparisons and concatenations — a sweep-and-replace over every `Status = '…'` would have "corrected" ~10 of 12 sites that are fine. No `.fail.mdl` is possible (check passes the failing form; the type checker is still a proposal — `docs/11-proposals/PROPOSAL_expression_type_checking.md`), so the verdicts live in `mdl-examples/bug-tests/enum-string-literal-contexts.mdl`, which pins the ACCEPTED forms and builds clean (control: adding it to a probe project left the error count unchanged at the 2 deliberate failures) |
-| `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 | `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 | `mdl/executor/validate_program.go` (the shared list), `cmd/mxcli/cmd_exec.go` (the gate), `cmd/mxcli/cmd_check.go` | `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 |
-| The expression type checker reports nothing, ever. `mdl/exprcheck` is a complete checker — parser, type lattice, function table, hints registry, slot resolver, and a `Context` with two tiers — and a suite of semantic rules (E001 enum-vs-string-literal, E009 slot-type mismatch, …) that never fire on any real project. `mxcli check --references` is green on a script with obvious type errors | Three silent absences, each of which alone reduces the whole thing to a no-op. (a) **Nothing implemented `exprcheck.CatalogReader`** — `grep -rn "exprcheck.CatalogReader"` outside the package returned zero hits — so every invocation ran with a nil `Catalog` and `Context.IsSemanticEnabled()` was false. (b) Three of the five lookups had **no data in the catalog**: `attributes_data.DataType` is the bare kind (`"Enumeration"`, losing which one), `enumerations_data` stored `ValueCount` but not the values, `microflows_data` stored `ParameterCount` but not the parameters. (c) The adapter's `exprSource` read **only `ast.SourceExpr`**, and the visitor attaches one to some slots and not others — measured on a fixture, neither a CREATE's nor a CHANGE's enum value carried one, so the walk had nothing to parse | `mdl/exprcatalog/` (new), `mdl/catalog/tables.go` + `builder_modules.go` + `builder_microflows.go` (schema 10), `mdl/exprcheck/adapters/check.go` (`WithSourceFunc`, trim, `CheckNanoflow`), `mdl/executor/typecheck.go` (new), `cmd/mxcli/cmd_check.go` | Implement the seam as a **memoized index loaded once** (four queries), not SQL per lookup. **Bump `CatalogSchemaVersion`** when adding a column the checker reads: without it a cached catalog answers "unknown" for every lookup, which the checker reads as "cannot tell" and skips — a green run that checked nothing, i.e. the original bug wearing a fresh cache. Keep the **E0xx codes** rather than remapping: the code in the message must be the code you can look up. **Generalisable, and the reason this sat undetected**: a seam with zero implementations is invisible to the compiler and to tests that mock it — when auditing an interface, grep for *implementations* (`var _ Iface = `, or the interface name outside its own package), not for callers; and when a checker's failure mode is "unknown → skip", every missing input looks exactly like a clean project. **Verify against a real project, never a mock** — all three defects survive a mocked test. Controls: nil reader → 0 violations, default source func → 0 violations, fixed → 2 (CREATE and CHANGE). False-positive probe: all 21 microflows of a 11.13.0 app described back to MDL and re-checked → 0 findings. **Known depth limit**: `AttributePathExpr` still infers `KindUnknown`, so `if $obj/Status = 'Open'` is NOT caught — only slot-qualified positions (create/change members) are. That is the proposal's open Tier-2 item, not a regression |
-| A `show`/`list` command **exits 0, prints nothing, and does nothing** — `mxcli -c "show page Mod.Home"` looks like a page with no content, `show connections` looks like no connections are open. No error, no parse failure, no output. Indistinguishable from a legitimately empty result, which is why it survives: the answer is plausible | The grammar alternative exists (`showOrList PAGE qualifiedName`, `showOrList CONNECTIONS`, `showOrList NOTEBOOKS`) but `ExitShowStatement` has **no `else if` branch for it**, so the visitor appends no statement and the program runs zero statements. Not a handler bug — the AST node is never created. `create notebook … begin end` is the same shape (grammar with no AST/visitor/executor anywhere) | `mdl/visitor/visitor_query.go` (`ExitShowStatement`), `mdl/grammar/domains/MDLCatalog.g4`, `mdl/ast/ast_query.go`, `mdl/executor/executor_query.go` | Either wire a visitor branch or delete the grammar alternative — an unimplemented command must fail loudly. `SHOW PAGE X` became an alias for `DESCRIBE PAGE` (matching `SHOW ENTITY`), `SHOW CONNECTIONS` wired to `sql.Manager.List()`, `SHOW NOTEBOOKS` removed. **A structural grep cannot find these**: `ctx.PAGE()` *does* appear in `ExitShowStatement` — for the unrelated `SHOW ACCESS ON PAGE` branch — so a token search reports the broken alternative as covered. The guard (`TestEveryShowAlternativeProducesAStatement`) instead synthesizes a probe from each grammar alternative and asserts a statement comes out. **Ordering trap when adding a branch**: `SHOW DATABASE CONNECTIONS` also matches `CONNECTIONS()`, so a new `CONNECTIONS` branch placed first swallows it and answers a stored-document query with live session state — guard with `ctx.DATABASE() == nil`. Found while auditing mxcli against Studio Pro's document-type list. **Follow-up**: the notebook grammar (`createNotebookStatement`, `notebookOptions`, `notebookPage`, `alterNotebookAction`, the `SHOW NOTEBOOKS` alternative, and the `NOTEBOOK`/`NOTEBOOKS` lexer tokens) was removed outright — all four of `create`/`alter`/`drop`/`show notebook` were silent no-ops with no Go code behind any of them. Dead grammar is not inert: it *accepts input and discards it*. Removing the tokens also frees `notebook` as an ordinary identifier. **Control for a broad grammar change**: sweep every `mdl-examples/**/*.mdl` through `mxcli check` before and after and diff the failure sets — 15 scripts fail either way, so the raw count proves nothing and only the set difference does |
-| `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 | 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 | `mdl/executor/validate_microflow.go` (Check 5 in `microflowValidator.validate`) | 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 |
-| 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 |
-| 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 | 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 | `mdl/executor/layout.go` (`containerBounds`, `fitContainerSize`), called from `addLoopStatement` / `addWhileStatement` in `cmd_microflows_builder_control.go` | 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 |
-| 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 | 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 | `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) | 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 |
-| A `CREATE DATABASE CONNECTION` whose query uses a `$$…$$` dollar-quoted SQL **and** a `parameter … default '…'` stores the **parameter's default as the query body**. `describe` shows `sql 'sales'` where the SELECT should be, the SQL text is absent from the BSON entirely, and `mx check` reports 0 errors on both engines | `buildDatabaseConnection` took `STRING_LITERAL(0)` as the SQL before falling back to `DOLLAR_STRING`. When the SQL is a dollar string, `STRING_LITERAL(0)` is the first parameter's DEFAULT — so the query body was overwritten by it. The parameter-index logic ten lines below already compensates (`if qc.DOLLAR_STRING() != nil { slIdx = defaultIdx }`); the SQL extraction did not | `mdl/visitor/visitor_dbconnection.go` | Check `DOLLAR_STRING()` FIRST, then fall back to `STRING_LITERAL(0)`. **Isolate by bisecting the clause combination**, not by reading: `parameter d: String` alone kept the SQL, `parameter d: String default 'x'` destroyed it — that one-clause difference names the cause immediately. When two sites in one function index the same token stream, they must agree about the offsets; a comment on one is not enough |
-| `describe database connection` omits `returns` / `map (…)` / `parameter` on the **default (modelsdk) engine** while the legacy engine renders them, so a describe → exec round trip drops the return entity, the column mapping and every query parameter | The modelsdk reader populated neither `TableMappings` nor `Parameters`, so the DESCRIBE renderer (which does handle them) only ever saw empty slices — dead code on that engine. The round-trip test existed but was pinned to the legacy backend via `setupTestEnv`, so it passed while the default engine was lossy | `mdl/backend/modelsdk/integration_read.go` (`tableMappingsFromGen`, `queryParametersFromGen`); test `mdl/executor/roundtrip_dbconnection_test.go` | Mirror the legacy reader field for field, and run the round-trip test over `gateEngines` rather than the default backend. **The cross-engine DESCRIBE matrix is the check that finds these**: write with engine A, read with engine B, all four combinations — a gap on one engine is invisible from inside that engine. Fixing one field (TableMappings) and not its sibling (Parameters) is the characteristic mistake; enumerate every child collection of the document before calling it done |
-| `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 | 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" | `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 | 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 |
-| Lint CONV010 flags **every** `ACT_` microflow that shows a page, closes one, or calls a sub-microflow — 11 false positives out of 13 findings, burying the real ones | The rule's `ALLOWED_ACTIONS` held the Mendix **storage** names (`ShowFormAction`, `CloseFormAction`); the catalog labels an action with its **SDK** name, derived from the parsed Go type in `getMicroflowActionType` (`ShowPageAction`, `ClosePageAction`, `MicroflowCallAction`). The allowlist matched nothing | `.claude/lint-rules/conv010_act_microflow_content.star`, `mdl/catalog/builder_microflows.go` | List the SDK names (both spellings is cheap insurance). The storage-name split is the same one in CLAUDE.md's `$Type` table — it bites rule authors because the catalog deliberately does **not** use storage names. `mdl/catalog/lint_rule_vocabulary_test.go` pins the allowlist to what `getMicroflowActionType` actually returns, so the rule cannot drift from the labeller again. Copy the rule into the target project's `.claude/lint-rules/` when testing: `mxcli lint -p <proj>` prefers the **project's** copy over the embedded one, so editing the repo's copy alone changes nothing |
-| Lint QUAL004 reports a live microflow as "not called from anywhere" (page datasource, widget button, calculated attribute), or a navigation-only page as orphaned | The rule counted only the `call` and `schedule` reference kinds. The builder emits `datasource`, `action` and `calculate` for microflows, and `home_page` / `login_page` / `menu_item` for pages — all ignored. The page half was masked by `ENTRY_PAGE_PATTERNS`, which happens to cover the pages most likely to be navigation targets | `.claude/lint-rules/orphaned_elements.star`, `mdl/catalog/builder_references.go` | Count every kind that means "this runs" / "this opens", via the `MICROFLOW_ENTRY_KINDS` / `PAGE_ENTRY_KINDS` lists. `TestQUAL004CountsEveryEntryPointKind` fails when one goes missing and `TestQUAL004EntryKindsAreRealRefKinds` when one is misspelled. Adding a new `RefKind` that means reachability means adding it to the right list |
-| `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 …` | 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) | `mdl/executor/validate_microflow_ce_gaps.go` (MDL061/062/063), wired from `validate_microflow.go`; fixtures `mdl-examples/bug-tests/893-check-gaps-*.mdl` | 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 |
-| `calculated by Module.Microflow` on an attribute is accepted by `check` and by exec ("Added attribute"), but the stored document holds a plain `DomainModels$StoredValue` with no calculation link — the microflow name appears nowhere in the domain model unit, `mx check` reports **0 errors**, and the attribute is simply empty at runtime. Both the CREATE (inline) and ALTER (`ADD`/`MODIFY ATTRIBUTE`) paths. A microflow whose signature cannot work is accepted too, masked by the same drop | `attributeToGen` in the **modelsdk** writer had arms for OqlViewValue / ODataMappedValue / ODataMappedPrimitiveCollectionValue and a `default:` that emits StoredValue — no `CalculatedValue` arm — so the binding the executor had already resolved fell through and was discarded. The **legacy** writer had the arm all along (`sdk/mpr/writer_domainmodel.go`), which is why the feature read as implemented; modelsdk is the default engine (`--engine`), so everyone hit the broken path. The reader had no `CalculatedValue` case either, so an unrelated ALTER on the same entity destroyed a binding made in Studio Pro | `mdl/backend/modelsdk/domainmodel_write.go` (`attributeToGen`) + `domainmodel.go` (`attributeFromGen`) + `mdl/executor/calculated_attributes.go` (`resolveCalculatedValue`, called from the three sites in `cmd_entities.go`) | Add the write arm (`genDm.NewCalculatedValue`, `SetMicroflowQualifiedName` → the `Microflow` ByNameRef key, `SetPassEntity`) **and** the read arm — a write-only fix leaves the read-modify-write data loss in place, which is the worse half. Derive `PassEntity` from the signature rather than hardcoding it (legacy hardcoded `microflowRef != ""`): measured on 11.13.0, an entity-parameter microflow (`PassEntity=true`) and a parameterless one (`PassEntity=false`) BOTH build at 0 errors, so refusing the parameterless form would have been wrong. Signature rules are refused at exec (the #833 placement), and each was checked against mxbuild rather than assumed — wrong entity parameter and wrong return type are both **CE7247**, but the return-type message is *"should be Integer/Long"*, so **Integer and Long are one family** and a strict equality check refuses valid MDL (caught only by reading the CE text). To ask mxbuild about a binding mxcli now refuses, stub the check and rebuild — `--engine legacy` does NOT bypass it, because the validation lives in the engine-independent executor. Tests `TestAttributeToGen_CalculatedValue`, `TestAttributeFromGen_CalculatedValue`, `TestResolveCalculatedValue_*` (the backend three fail with `value is *domainmodels.StoredValue` when reverted); fixture `mdl-examples/bug-tests/917-calculated-attribute-binding.mdl`. Issue #917 |
-| `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 |
-| `mxcli check -p app.mpr` passes a microflow containing `if $obj/Status = 'Open'` — comparing an enumeration attribute to a string literal, the first example in the type-checking proposal and the shape people actually write. The same mistake written as a create or change member *is* caught, which makes the gap look arbitrary | Two causes, both invisible. (a) **`inferKind` returned `KindUnknown` for every `AttributePathExpr`**, so `$obj/Attr` typed to nothing and every rule downstream of it stayed quiet. `exprcheck.Scope` is `Lookup(name) (TypeKind, bool)` — it can say "$P is an Object" but not *which* entity, so there was nowhere to put the answer; the adapter computed a variable→entity map (`buildVarEntityScope`) and used it only to label a slot path, never passing it to the checker, and it covered body-introduced variables but **not parameters** — the ordinary case. (b) Even resolved, nothing fired: **E001 keys off the SLOT** (`CreateItem.Value:Entity.Attr`), which exists for an assignment and not for a comparison | `mdl/exprcheck/interfaces.go` (`EntityScope`, `Context.Entities`), `mdl/exprcheck/parser.go` (`attributePathKind`, `pathTargetEntity`, `checkEnumComparedToString`), `mdl/exprcheck/adapters/` (`walkFlow`, `addParamEntities`, `entityScope`), `mdl/exprcatalog/` (`AssociationTarget`) | Put the object side in its **own seam** (`EntityScope`: `VariableEntity` + `AssociationTarget`) beside `Scope` rather than widening either it or `CatalogReader` — `CatalogReader`'s shape is what stays re-syncable from the upstream fork. **A multi-hop expression path is not an XPath path**: XPath spells the intermediate entity (`[Assoc/Entity/Attr]`) so a walk can read it off, while an expression does not (`$O/Mod.Assoc/Attr`), so every hop must resolve through the association index. For (b), emit the **same code and message** from the comparison as from the slot — one defect should not have two names depending on where it was spotted. **Generalisable**: when a checker is silent, separate "did the input resolve" from "is there a rule for this shape" before touching either — here resolution and detection were both missing, and fixing only one would have looked like the fix failed. Verify with a **probe corpus that actually exercises the construct**: 21 microflows described back to MDL contained 40 attribute-path lines including an association hop, and were clean before and after, which is what makes "no false positives" mean something. Controls: path→`KindUnknown` restored, `Entities` dropped from the Context, and `addParamEntities` removed each fail a distinct test. **Still open**: a *terminal* association step (`$Order/Mod.Order_Lines`) types to unknown — Object vs List depends on the association's kind and direction, and guessing costs false positives |
-| `describe microflow` renders a REST call's result as `returns String` when the activity actually stores the response in a **file document**, and the describe → exec round trip then writes String back — retyping the activity with `mx check` reporting nothing either way. On the legacy engine the `$var =` output variable disappears too | MDL had no syntax for the case, `sdk/microflows` had no FileDocument variant, and both readers fell through to String: the legacy `parseResultHandling` had no `FileDocument` case (so the whole handling read back nil, taking the output-variable fallback with it), while modelsdk's `restResultHandlingFromRaw` read `VariableType.Entity` and then discarded it, matching only the literal `System.HttpResponse`. Mendix stores all five variants as ONE `Microflows$ResultHandling` carrying a `VariableType`, discriminated by the `ResultHandlingType` enum | `mdl/grammar/domains/MDLMicroflow.g4` (`restCallReturnsClause`), `mdl/ast/ast_microflow.go`, `mdl/visitor/visitor_microflow_actions.go`, `sdk/microflows/microflows_actions.go`, `sdk/mpr/parser_microflow_actions.go` + `writer_microflow_actions.go`, `mdl/backend/modelsdk/microflow_read_actions.go` + `microflow_write.go`, `mdl/executor/cmd_microflows_builder_calls.go` + `cmd_microflows_format_action.go`, rule in `validate_microflow_rest.go` (MDL064) | Add `returns Module.Entity` as the LAST alternative so the keyword forms still win, and read Mendix's own `ResultHandlingType` discriminator rather than inferring from `VariableType` (keep the inference as a fallback — the property is `omitempty`). **Delete the silent `String` fallbacks**: an unreconstructable result handling must describe as something the parser REJECTS, or a reader gap becomes a model rewrite (ADR-0005). Mendix constraints worth knowing before designing syntax here: the BASE `System.FileDocument` is rejected as a return type (**CE0362**) so a specialization is mandatory, and HttpResponse **cannot** be specialized (**CE1540** allows only User, FileDocument, Image, Paging) — which is why `returns response` needed no change and the reporter's suggested "HttpResponse specialization" does not exist. Cross-engine round trip (`gateEngines`) is what proves it: the two readers failed differently and each looked fine from inside itself. Issue #922 |
-| `describe import mapping` prints only the LAST segment of a value element's JsonPath, so a mapping that binds a nested leaf onto a parent entity describes as `Attr = name` when the model says `(Object)\|customer\|name` — and re-executing mxcli's own output fails with `"name" is not a member of the JSON structure at (Object)`. Authoring that shape was impossible too (`extraneous input '/'`) | Studio Pro can bind a leaf several levels below the object element it belongs to, with no entity for the levels in between, stored as ONE multi-segment JsonPath. `mappingMemberName` took `LastIndex(path, "\|")`, assuming a value element is always a direct child, and the grammar's value alternative took a single `identifierOrKeyword` | grammar `mdl/grammar/domains/MDLDomainModel.g4` (`jsonMemberPath`), `mdl/visitor/visitor_import_export_mapping.go`, `mdl/executor/cmd_import_mappings.go` (`resolvePath`, `mappingMemberName`) + `cmd_export_mappings.go`; fixtures `mdl-examples/bug-tests/927-mapping-nested-member-path*.mdl` | Render the member RELATIVE to the enclosing object element (thread the parent's JsonPath through the printers) and resolve a `/`-separated member one segment at a time so each step keeps the raw-key/exposed-name tolerance from #882. **Use the parent path verbatim** — for an array the object element's own JsonPath is already the ITEM path, and trimming `\|(Object)` off it makes a child of that item render as `(Object)/sku`. Two shapes must be REFUSED, both measured rather than assumed: an EXPORT mapping cannot collapse levels (**CE5015** — it has to produce the intermediate node; three-way control: same member in an import is 0 errors, same export with only top-level members is 0 errors), and an import member cannot cross a `0..*` element (**CE0256** "a schema element with wrong occurrence"). Measure by patching the JsonPath into a stored mapping and running `mx check` — and assert the patch landed before trusting a 0, since an mxcli parse error leaves the baseline project untouched. Issue #927 |
-| The nightly fails on ONE Mendix matrix version only, in `TestMxCheck_DoctypeScripts`, with `Execution error: this project does not store the model setting <X>` — while the same script passes on every newer version | The example script set a model setting that version does not have. Measured: a blank 10.24 stores 11 model settings and a blank 11.6.6 stores 12, `DecimalScale` being the only difference. mxcli's refusal is CORRECT — Studio Pro will not open a model carrying a property its version does not define, and mxbuild does not catch it — so the bug is the ungated example, not the guard. The refusal covers the WHOLE statement, so one version-specific setting takes every portable setting in the same `alter` down with it | `mdl-examples/doctype-tests/14-project-settings-examples.mdl`; guard in `mdl/executor/doctype_version_gating_test.go` | Split the version-specific setting into its own statement inside a `-- @version: N.N+` section, closed with `-- @version: any`. **Put the `/** */` doc comment INSIDE the gated section**: a block comment is a documentation comment bound to the statement after it, so gating the statement while leaving the comment outside orphans it and the script dies with `no viable alternative at input '/**...'` — reported at the NEXT statement, tens of lines away, which reads like an unrelated syntax error. `--` line comments are free-standing and safe either side. Isolate which setting is at fault by exec'ing them one at a time against a blank project of that version (`mx create-project` in a SHORT path — a long one dies with PathTooLongException). `TestDoctypeScriptsParseAfterVersionFiltering` now parses every doctype script under each nightly matrix version without needing mxbuild, so a mis-gated script fails in seconds on push instead of hours later in one nightly job |
-| 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 | 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 | `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) | 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 |
-| `run --local` / `test --local` on macOS (or Windows) die with a raw `fork/exec ~/.mxcli/mxbuild/<v>/modeler/mxbuild: exec format error`, while `setup mxbuild` and `docker build` correctly use Studio Pro's binary. `--mxbuild-path` does not help | `MxBuildCDNURL` branches on **GOARCH only, never GOOS** — both URLs are Linux tarballs (Mendix ships macOS mxbuild inside Studio Pro, not on the CDN), so an arm64 Mac caches a Linux *aarch64* ELF: the arch matches, so nothing notices until exec. `docker build` resolves via `resolveMxBuild` (PATH → Studio Pro → known locations → cache) and `setup mxbuild` via `NativeMxBuildForSetup`, but the local loop called `DownloadMxBuild` directly at `runlocal.go` and `StartServe` looked only at the cache. `LocalRunOptions.MxBuildPath` was documented as an override and never read for the serve binary, so there was no workaround either | `cmd/mxcli/docker/mxbuild_platform.go` (new: `ResolveMxBuildForLocal`, `binaryOS`, `verifyRunsHere`) + `runlocal.go` (the `DownloadMxBuild` call) + `mxserve.go` (`StartServe`) | Reuse the rule the codebase already had rather than inventing one: `NativeMxBuildForSetup(goos, version)` returns Studio Pro's path, or "" meaning "Linux, download is fine", or an error plus guidance. Order: explicit path → (non-Linux) Studio Pro → cache/CDN. **Do not stop the download on Windows** — the cache holds a Linux binary there deliberately, for Docker builds; the fix belongs at resolve/exec time. Guard exec with a magic-byte check (ELF / Mach-O incl. fat / PE) and let an unrecognised format through, since a shell wrapper has no magic and refusing on a guess would block a working setup. **Inject `goos` into the helpers** (`resolveMxBuildForLocalOn`, `verifyRunsOn`): the whole bug is platform-specific and is otherwise untestable from a Linux runner. Repro without a Mac: plant a Mach-O magic at the cache path and call `StartServe` — reproduces the reporter's message verbatim. Tests `TestBinaryOS`, `TestVerifyRunsOn_LinuxBinaryOnMac`, `TestResolveMxBuildForLocal_*`; reverting makes `ExplicitPathWins` fail **by downloading from the CDN for 34s**, which is the ignored override made visible. **Unverified:** no macOS host was available, so the Studio Pro discovery path itself (`resolveStudioProDirMacOS`) is exercised only by its own existing tests. Issue #916 |
-| Windows: `run --local` behaves as though Java were undetected, and a local run can fail looking for Gradle | Two separate things. (a) **The `.exe` suffix**: `isJDK21` appended it, every CONSUMER did not — `--java-exe-path` handed to mxbuild and the path `exec.Command` runs to boot the runtime were both `<jh>\bin\java`, so a correctly-detected JDK was passed on in a form that need not resolve. Five sites built it by hand. (b) **Gradle is not mxcli's**: it ships inside the mxbuild bundle (`modeler/tools/gradle`, 8.5) and mxbuild invokes it — mxcli never calls gradle, so "Gradle missing" indicates a foreign/incomplete mxbuild bundle, usually #916 | `cmd/mxcli/docker/javaexe.go` (new `JavaExePath`) used from `mxserve.go`, `build.go`, `settle.go`, `localboot.go`, `detect.go`; `jdkSearchPathsFor` in `detect.go` | One helper, not five hand-built joins — the sixth call site would have repeated the bug. **Check the platform's own docs before adding a search path**: "add Studio Pro's JDK" turned out to be a non-task, because Mendix's install guide says Studio Pro installs **Eclipse Temurin 21** rather than bundling a JDK, so the existing Adoptium glob already IS Studio Pro's JDK; what was genuinely missing was the per-user `%LOCALAPPDATA%\Programs` install location. Inventing a `Mendix\<version>\jdk` path would have been dead code. Make the not-found error list what was searched — "JDK 21 not found" alone sends a user reading mxcli's source. Inject `goos` (`jdkSearchPathsFor`, `javaExeName`): the only Windows CI job is the tunnel seam, scoped with `-run`, so it compiles Windows code and executes almost none of it — which is exactly how a missing `.exe` survives. **Unverified**: no Windows host; the fix is code-level with OS-injected tests. Reported via a user relay, not an issue |
-| Studio Pro's version-control view shows an **entire** nanoflow/microflow as changed after editing one activity argument; `git diff` on `mprcontents/` is unreadable. A change and its revert leave a semantically identical document that shares no element IDs with the original. Separately, re-running an already-applied script prints `Modified …`/`Replaced …` for files it did not touch | Two independent things. (a) `create or replace` rebuilds the document and every sub-element gets a freshly random `$ID`; elision (ADR-0008) only covers the case where *nothing* changed, so a real change wrote a whole new identity set — measured 36 of 37 on a nanoflow, 21 of 22 on a microflow. (b) The `Modified …` lines are printed by the handler right after `ctx.Backend.Update*`, which returns nil whether or not storage elided the write | `modelsdk/canon/transplant.go` (`TransplantIDs`, called from `Reconcile` in `identity.go`); `mdl/executor/report_mutation.go` + `mdl/backend/writestats.go` | Match the incoming document against the stored one and reuse its `$ID`s: `$Type` + shape one level down (`Action=Microflows$LogMessageAction`) + `Name` as the LCS match key, positional fill in the gaps, then substitute **in place over every 16-byte binary** — a pointer is a primitive property a containment walk never sees, and any occurrence of one of the document's element IDs *is* a reference (the same insight `canon` rests on). **The correctness bar is lower than it looks**: a wrong match only makes a diff bigger, since every reference moves with the element; the one real failure is two elements sharing an `$ID`, so guard it explicitly (`dropCollisions`, run to a fixed point) and verify the resulting id set by read-back. **Do not touch `GUID`** — that is the database's identity and was already preserved (measured 8 of 8 through `ALTER ENTITY ADD ATTRIBUTE`). **A key built from content is the trap**: it stops an element matching itself the moment someone edits it, which is the case being fixed — key on shape and name only. **Watch for the control you invalidate**: `MXCLI_ALWAYS_WRITE=1` no longer changes the written bytes (identities are carried), so `TestWriteMicroflowTwice_ControlChurnsWhenElisionOff` became unprovable and had to move down a layer to the raw codec output (`TestRebuildChurnsSubElementIDs`); from the shell, control on mtimes rather than hashes. For the reporting half, downgrade the verb only on **positive** evidence (unit writes offered since the last report, none landed) so a mutation that never reaches unit storage — a theme file, a mock backend — reads exactly as before. Measured on the reporter's own project: 37/37 identities kept, diff down to the one changed line, insert/delete mints only the genuinely new elements, `mx check` unchanged at its 1 pre-existing error, both engines |
-| `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" | **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 | `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` | **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 |
-| `ALTER PAGE` at a **dotted** DataGrid2 column target (`insert after grid1.Col { container … }` / `replace grid1.Col with { container … }`) reports "Altered page", and `mx check` then aborts before checking anything: `System.InvalidCastException: Unable to cast object of type '…DivContainers.DivContainer' to type '…CustomWidgets.WidgetObject'`. Separately: a widget **inserted into a customContent cell** binds nothing — `ContentParams` naming an association path stores the raw path as the attribute name (**CE1613**) and `describe page` shows the path with its first hop silently gone | Two defects. (a) #891's guard covers only the BARE column form; the dotted form is legitimate and skips the guard entirely, so a **non-`column` body** still fell through to the generic widget path and was serialized into the grid's column list. The wrong thing is the *pairing* (widgets at an object-list target), not the target. (b) The entity-context walk descended into a pluggable widget's own widget properties but not into an object-list ITEM's — a column keeps its cell widgets one level deeper at `Objects[].Properties[content].Value.Widgets`, the same descent `findInWidgetChildren` gained in #834 — and never read a **pluggable** widget's datasource at all, so the grid's own entity was invisible too. Empty entity context ⇒ `resolveAssociationAttributePath` bails ⇒ the raw path is stored as the attribute name | `mdl/backend/pagemutator/mutator.go` (`refuseWidgetsAtColumnTarget` called from `InsertWidget`/`ReplaceWidget`; `findEntityContextInChildren`, `widgetOwnEntity`, `entityFromEntityRef`) | (a) Refuse when `columnRef != ""` — resolve the column FIRST so a mistyped name still reports not-found with the available names, then refuse and name both alternatives (`column …` body, or address the widget inside the cell by its own name, per #834). (b) Descend into `Value.Objects[].Properties[].Value.Widgets`, keyed on the BSON shape rather than the `columns` property key so Accordion groups and PopupMenu items are covered by the same code; resolve a pluggable datasource through the shared `entityFromEntityRef`, which also gives it the IndirectEntityRef (association) case the plain reader already had. **Note the guard cannot key on the target alone** the way #891's does, and a unit test on the mutator alone under-proves it: reverting only shows a nil-deref in the fixture. The honest control is the CLI + `mx check` — measured on Mendix 10.24.20.105674, exception before / 0 errors after, and CE1613 before / 0 after. Repros `mdl-examples/bug-tests/935-alter-page-widgets-at-column-target.mdl` and `935-customcontent-column-entity-context.mdl`. Issue #935 |
-| `GRANT <role> ON <entity> (READ (A))` **shrinks** an existing access rule instead of widening it: attributes granted by an earlier GRANT come back `None`, and `(CREATE, DELETE, READ *, WRITE *)` followed by a narrow re-grant loses create, delete and every write right. No error, no warning, no diff. Reported as WHERE-specific and as a "silent security regression" | Two defects. (a) The codec engine's upsert **cleared the matched rule's MemberAccesses and rebuilt them from the current statement alone**. The executor emits an entry for *every* member of the entity (unnamed ones at the rule's default, normally `None`), so each GRANT reset every member it did not mention; `AllowCreate`/`AllowDelete`/default rights were overwritten the same way. Legacy has merged additively since it shipped (`mergeAccessRule`), so this was an **engine regression**, not a longstanding gap — which is why the documented contract ("GRANT is additive … never removes permissions") held on one engine and not the default one. (b) **Both** engines matched a stored rule on its module-role set alone, ignoring `XPathConstraint`, collapsing two legitimate rules into one | `mdl/backend/modelsdk/domainmodel_security_write.go` (`AddEntityAccessRule`); `sdk/mpr/writer_security.go` (the upsert's match + `mergeAccessRule`); lattice shared via `mdl/types.AccessRightsLevel` / `HigherAccessRights` | **Measure the reported trigger before scoping the fix to it.** WHERE was a red herring — the same loss reproduced with no WHERE and with `READ *`, so a fix aimed at the constrained path would have passed the reporter's repro and left most of the bug. Equally, the report understated the damage: only attributes were mentioned, but structural rights went too, so re-derive the blast radius rather than inheriting it. **Run the other engine as the control** — `MXCLI_ENGINE=legacy` merging correctly is what turned "longstanding bug" into "regression" and handed over the reference semantics (OR create/delete, take the higher default, take the higher rights per member) instead of having to invent them. For (b), **check the platform's own docs before calling multi-rule a user error**: Mendix's refguide says "Rules are additive … all access rights of those rules are combined", so one role holding one rule per constraint is the normal way to write row-level security, and `mx check` confirms it at 0 errors. Put the constraint in the match key and treat the empty constraint as a *value*, not a wildcard, so an unconstrained and a constrained rule coexist and re-running a script stays idempotent (ADR-0008). **Fixing (b) breaks anything keyed on roles alone**: `formatAccessRuleResult` then echoed a *different* rule's rights back at the user, so it needed the constraint too (REVOKE passes `anyXPath`, since it narrows every matching rule). Rights merge on `None < ReadOnly < ReadWrite`, so a merge never narrows — that is what keeps GRANT and REVOKE inverses rather than two spellings of "set". Issue #936 |
-| `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 | 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 | `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` | **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 |
-| Binary upload is reported as impossible in MDL — "a consumed REST operation has no binary body, so use a Java action". A Studio Pro-authored binary POST also **describes with no body at all**, and re-executing that DESCRIBE produces a request that sends nothing | Right conclusion about the **wrong document**. Mendix models a binary request body on the microflow **REST CALL activity** as `Microflows$BinaryRequestHandling` + an action-level `RequestHandlingType: "Binary"` — a `Microflows$` type, which is why a metamodel grep for `Rest$*Body` finds only the three non-binary ones and "proves" it impossible. mxcli could **parse** it (`sdk/mpr/parser_microflow_actions.go`) and could neither write, read (modelsdk) nor describe it, so it survived a legacy read and vanished everywhere else | Grammar `mdl/grammar/domains/MDLMicroflow.g4` (`restCallBodyClause`); `mdl/ast/ast_microflow.go` (`RestBodyBinary`); `mdl/visitor/visitor_microflow_actions.go`; `mdl/executor/cmd_microflows_builder_calls.go`; writers `mdl/backend/modelsdk/microflow_write.go` + `sdk/mpr/writer_microflow_actions.go`; reader `mdl/backend/modelsdk/microflow_read_actions.go` (`restRequestHandlingFromRaw`); formatter `mdl/executor/cmd_microflows_format_action.go`; tests `mdl/executor/cmd_microflows_binary_body_test.go`; fixture `mdl-examples/bug-tests/rest-binary-post.mdl` | **"Not in the metamodel" needs the right namespace before it is a conclusion** — the search was for `Rest$…Body` and the answer lives under `Microflows$…RequestHandling`. Ask for a Studio Pro example instead of reasoning from an absence: one 4-KB unit settled in minutes what a metamodel grep had "disproved". **The discriminator and the sub-element must agree** — `RequestHandlingType` was hardcoded `"Custom"` in BOTH engines regardless of the handler; only the Binary case is derived here, because the others have no measured reference and work today (a latent mismatch worth a separate look). **The expression is the `Contents` MEMBER** (`$Doc/Contents`), not the document, and is stored as source text — quoting it sends the path as a string literal. **Verify a round trip by re-executing DESCRIBE and diffing the BSON against Studio Pro's**: mxcli's output reproduced the Studio Pro action exactly (same type, same discriminator, same expression) with mxbuild 0 errors, which is stronger than any assertion about what "should" be written. Beware the sibling trap: read support in one engine and not the other looks like a describe bug |
-| A REST call's `body mapping Mod.EMM from $var` is written with the variable under a key Mendix does not read, an empty `ContentType`, and an action-level `RequestHandlingType` of `Custom` that contradicts its own `Microflows$MappingRequestHandling` sub-element. A form-data body is dropped entirely by DESCRIBE, so describe → edit → exec silently produces a call that posts nothing | `generated/metamodel` is decisive: `MicroflowsMappingRequestHandling` owns exactly three properties — `contentType` (enum Json\|Xml), `mappingId`, `mappingVariableName`. mxcli wrote `ParameterVariable`, which the type does not own, and omitted `MappingVariableName`; its own READER had known the right key since #843 and the writer was never corrected. `RequestHandlingType` was hardcoded `"Custom"` in both engines regardless of handler. `FormDataRequestHandling` / `AdvancedRequestHandling` can be parsed and not written, so a rewrite dropped them | `mdl/backend/modelsdk/microflow_write.go` (`requestHandlingTypeOf`, the Mapping case) and `sdk/mpr/writer_microflow_actions.go` (`restRequestHandlingTypeOf`, same case); guard `mdl/executor/validate_rest_request_handling.go` wired from `cmd_microflows_create.go`; tests `mdl/backend/modelsdk/microflow_restbody_test.go`, `mdl/executor/validate_rest_request_handling_test.go` | **A reader that compensates for a writer hides the writer's bug** — the `MappingVariableName` fallback made DESCRIBE round-trip correctly while every document mxcli wrote carried the wrong key. When a reader has a "the real key is X" comment, check that the writer agrees. **An unknown property is worse than a wrong value**: mxbuild tolerates it and Studio Pro refuses to open the document, so a green build proves nothing (same rule as the overlay section in CLAUDE.md). **Ask for one Studio Pro example per variant** — four microflows covering Custom/Mapping/FormData/Binary settled the discriminator question that a single example had left as "unverified, so leave it alone"; guessing the other five enum values from one measured case would have been a coin flip. **Parse-but-cannot-write is a data-loss path, not a gap**: DESCRIBE omits what the writer cannot express, so the omission looks like faithful output — refuse the rewrite (ADR-0005), and make the guard's allow-list the writable set so it stops refusing the moment a type becomes expressible. Not fixed: the legacy engine encodes `MappingId` as binary where Studio Pro stores a qualified-name string |
-| `DESCRIBE MICROFLOW` emits MDL that is **not equivalent** to the microflow: a branch's activities are missing from the output, and re-executing the description builds a different flow. Reported as "roundtrip for @merge does not work" plus a separate complaint about the diagram coming back tangled | The graph is not **properly nested**. MDL's `IF/THEN/ELSE` is a single-entry/single-exit block; a Mendix microflow is an arbitrary graph, and when a branch re-enters a sibling branch's path there is no nesting that means the same thing. The describer walks it as a tree anyway. Measured on the reporter's graph: `log` ran on `¬c1 ∨ c2` and was described as `c1 ∧ c2` — with their actual expressions (`not(true)` on both decisions) the original **always** logs and the description **never** does, i.e. the exact inverse, not a near-miss. The tangled diagram is the *same* cause: `findSplitMergePointsForGraph` and `commonMergeAfter` are two independent merge-finders that agree on every nested graph and disagree here (merge2 vs merge1), so the emitted `@merge(x,y)` places the merge before an activity that structurally follows it | `mdl/microflowgraph/structure.go` (`Analyze` — post-dominators + branch-body overlap); `mdl/linter/rules/flow_irreducible_graph.go` (MDL-FLOW01); `irreducibleGraphWarnings` in `mdl/executor/cmd_microflows_show.go` | **Reconstruct the reporter's graph from the coordinates in their own output** before touching code — `@position`/`@merge` values pin the shape exactly, and `commonMergeAfter` reproducing their `@merge(-200,173)`/`@merge(100,173)` byte-for-byte is what confirmed the reconstruction was right rather than merely plausible. **Do not reuse the describer's join search in the detector**: there are already two implementations and they disagree on exactly the graphs being detected, so a detector built on either inherits whichever is wrong. Post-dominance is self-contained (`pdom(n) = {n} ∪ ⋂ pdom(succ)`, universe-initialised so it converges on the cyclic graphs retry loops create) and makes a describer/detector disagreement a *signal*. Classification: overlap with **one** entry point is a shared suffix (recombinable — the guards fold, `¬c1 ∨ c2`), **two or more** is genuine crossing (interleaved — needs activity duplication or a synthetic boolean per Böhm-Jacopini, so it is refused). **The false positive is worse than the bug** — flagging ordinary nesting would warn on nearly every microflow — so pin the shapes most likely to trip it: `if` with no `else`, an inner split whose join *is* the outer's, branches that both return, and error-handler flows (excluded, or every activity with one gets flagged). **A rule that never runs and a rule that finds nothing look identical**: prove the wiring with a forced-fire control (temporarily append a finding per microflow, lint a real project, confirm the count, revert) — `mxcli lint` reporting "No issues found" on a blank app is also just marketplace modules being excluded. Rendering it faithfully needs a label form; Mendix gives no field to hang one on (`Microflows$ExclusiveMerge` stores only `RelativeMiddlePoint` and `Size` — confirmed against `generated/metamodel`, `modelsdk/gen` and real 11.13 documents), but labels only need to be deterministic, not stored. Issue #923; design in `docs/11-proposals/PROPOSAL_structured_microflow_description.md` |
-| A CLI flag is accepted but does nothing: `mxcli test tests/ -p app.mpr --require-assertions` exits 0 on a suite where every test asserts nothing. `--help` lists the flag, it parses, and the summary line even prints "1 test(s) asserted nothing" — so the run looks like it noticed and chose to pass | The flag was consulted in exactly one of the two result-assembly loops. `vacuousResult` had a single caller, in the endpoint runner's loop (`--local`, `--attach`); the after-startup runner (Docker default, and `--local --legacy-runner`) assembles results in `ParseLogResults(logReader, suite)`, whose signature had no parameter the flag could arrive through — it could not honour it even in principle | `cmd/mxcli/testrunner/results.go` (`ParseLogResults`, `preRunResult`), `cmd/mxcli/testrunner/runner_endpoint.go` (`runSuite`), `cmd/mxcli/testrunner/runner.go` (the `ParseLogResults` call in `runAfterStartup`) | Give the pre-run verdicts — the ones decided by the *parsed test case* rather than by the run — **one** function (`preRunResult`) and route both loops through it, then pin that it is their only caller (`TestPreRunVerdictsHaveOneCallSite`). Same lesson as the `newResult` constructor two rows up: a decision reachable from one path and not the other is the defect, and a single call site is what prevents the next one. **Do not reach for the refusal precedent without checking it applies**: `rejectVerifyOnLegacyRunner` refuses `@verify` on this runner because it genuinely cannot evaluate it (its tests run during boot, there is no seam to query the app at). `AssertionCount()` is a static property of the parsed test case, known before any runner starts — refusing there would have denied a capability the runner has. **Generalisable**: when auditing a flag for dead ends, grep for its *consumers* and count them against the number of code paths that should honour it; a unit test on the helper (`TestRequireAssertionsMakesVacuousTestsErrors` called `vacuousResult` directly) proves the helper works and says nothing about whether any runner calls it. Issue #926 |
-| 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 |
-| `ALTER STYLING … SET '<design property>' = '<value>'` prints `Updated styling on widget "x"` and writes **nothing**. The same statement works on a Studio Pro-authored widget, and the inline `DesignProperties: [...]` form works everywhere | Two defects composing into a silent no-op. `bsonnav.DSet` takes a `bson.D` **by value**, so it can only overwrite an existing key — it returns `false` and does nothing when the key is absent, and `DSetArray` ignored that result. And the key WAS absent: the codec omits an empty, never-appended `PartList`, so `Forms$Appearance` on an mxcli-authored widget carried no `DesignProperties` at all (Studio Pro writes the empty marker `[3]` on all 16 pages of a blank app) | `mdl/backend/bsonnav/bsonnav.go` (`DSetArray` now returns bool + refuses a markerless write, new `DSetArrayIn`); `mdl/backend/pagemutator/mutator.go` (`writeDesignProperties`); `mdl/backend/modelsdk/widget_write.go` (`Forms$Appearance` MandatoryLists, `CustomWidgets$CustomWidget` LabelTemplate) | **Fixing the append without fixing the marker turns a silent no-op into an unopenable project.** A Mendix array's first entry is its typed-array marker; measured on 11.13, a `DesignProperties` array written bare fails to LOAD (`Type OptionDesignPropertyValue does not contain a constructor with a parameter of type Appearance`) and `create-module-package` dies with "Unknown export error", while a doubled marker throws `StorageLoadException`. So `DSetArray` refuses rather than guessing, and the marker is passed explicitly at the one call site that creates the property. **Diff against `mx update-widgets`' own output** to find missing keys: handing an mxcli-authored page to Mendix's tool and diffing the unit it writes back (pointer identity preserved, key order intact) surfaced `DesignProperties`, `LabelTemplate` and a set of int32/int64 width mismatches in one pass. Not changed: `Forms$Page.AllowedModuleRoles` is marker 3 where Studio Pro writes 1 — `NewByNameRefListV3` documents CE0557 as the reason, and nothing currently misbehaves. Issue mendixlabs/mxcli#931 |
-| `mx create-module-package` aborts on a module mxcli created with **`Exception occurred: Unable to cast object of type 'Newtonsoft.Json.Linq.JValue' to type 'Newtonsoft.Json.Linq.JObject'`** at `MprProperty.Init` → `MprUnit.get_Contents` → `MprDocumentHasher.Write`, while `mx check` reports **0 errors**. Removing the widget the reporter blamed changes nothing | `Forms$Page.AllowedModuleRoles` was written with typed-array marker **3** by the modelsdk (default) engine. The marker tells Mendix's reader what the entries ARE, and the entries are qualified-name **strings** — so a NON-EMPTY list under marker 3 is a JValue where the reader wants a JObject. The empty list never crashed (nothing to mis-cast), which is why only a module whose page carries a role hit it: `create module` auto-creates a `User` role and grants it. The legacy engine (`sdk/mpr/writer_security.go`) has always written 1 | `modelsdk/gen/pages/types.go` (`initPage`, the `allowedRoles` line — LIST-MARKER OVERRIDE next to the existing STORAGE-NAME OVERRIDE); `modelsdk/property/reference.go` (`NewByNameRefListV3`, whose comment asserted the opposite) | **Minimise before believing the reporter's attribution.** #931 blamed an Accordion; `create module MMin; create page MMin.P { DYNAMICTEXT }` reproduces the identical exception with no pluggable widget in the project — and the same crash appears on a binary built from `origin/main`, which is the control that proves it pre-existing rather than introduced by the fix in the same branch. **`mx check` is not a safety net for storage shape**: it read this project fine at all three security levels while the exporter could not. **Check the comment's premise before honouring it** — this marker was deliberately 3 because a comment said 1 caused CE0557 "even when roles are set"; measured at Off, Prototype and Production, marker 1 is 0 errors and exports, marker 3 is 0 errors and crashes. Note the repair is not retroactive: idempotent writes leave an existing page alone, so a project keeps the bad marker until each page is rewritten. Issue mendixlabs/mxcli#931 |
-| 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` | 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 | `mdl/executor/cmd_microflows_builder_actions.go` (the `addBranch("", s.ElseBody)` call and its CE0089/CE0090 comment) | 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) |
-| `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 | 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 | `mdl/executor/cmd_microflows_show_helpers.go` (`emitEnumSplitStatement`, `emitInheritanceSplitStatement`) **and** `mdl/executor/cmd_diff_mdl.go` (`microflowStatementToMDL`) | 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) |
-| A type split spelled `split type $x case Mod.E … else …` warns **MDL065**, or a script using `when Mod.E then` is rejected by an older mxcli | The type split moved onto the enum split's branch syntax (#913): `case` used to introduce a BRANCH here while introducing the SUBJECT in `case $x when V then` and in expressions, so the word meant two things. Both spellings build the identical flow and both still parse | `mdl/grammar/domains/MDLMicroflow.g4` (`inheritanceSplitCase`, `inheritanceSplitElse`), `mdl/visitor/visitor_microflow_statements.go` (`buildInheritanceSplitStatement`), `mdl/executor/validate_microflow.go` (`checkInheritanceSplitSpelling`) | Write `when Module.Entity then` and `when (empty) then`. **Never promote MDL065 to an error** — `TestMDL065_DoesNotBlockExecution` pins that, because `exec`'s pre-flight gate halts on errors and would refuse every script using the old form. When adding a spelling alias, pin the equivalence (`TestInheritanceSplit_BothSpellingsProduceTheSameAST`) rather than assuming it: the deprecation message promises "both build the identical flow", and that promise needs a test. Fixtures `mdl-examples/bug-tests/913-split-type-{unified,legacy}-syntax.mdl` |
-| `SHOW ACCESS ON ENTITY Mod.E` is a parse error — `extraneous input '.' expecting the start of a statement` — while `SHOW ACCESS ON MICROFLOW\|PAGE Mod.Name` parse. The generated project CLAUDE.md documents all three. Separately, and found by the same sweep: `SHOW ACCESS ON PAGE` **parses and answers the wrong question**, printing the page's whole widget tree instead of its allowed module roles | Two ordering defects, one at each layer. (a) There was no `ACCESS ON ENTITY` grammar alternative, and `ENTITY` is in the `keyword` rule, so `showOrList ACCESS ON qualifiedName` matched the word ENTITY as the *whole* name; the statement ended there and the real name was extraneous. The command itself always existed — the bare `SHOW ACCESS ON Mod.E` is the same AST node and the same handler. (b) `ExitShowStatement` is a long if/else chain: the singular `SHOW PAGE`→DESCRIBE alias branch (added when four show alternatives had no visitor branch) sits ~200 lines BEFORE the `ACCESS` branch and matches on `ctx.PAGE() != nil` alone, so it swallowed `SHOW ACCESS ON PAGE`. The `ENTITY` branch would have swallowed the new alternative the same way | `mdl/grammar/domains/MDLCatalog.g4` (`showStatement`), `mdl/visitor/visitor_query.go` (`ExitShowStatement` — the `ENTITY` and `PAGE` branches) | Add the alternative, then guard **every earlier branch that matches a bare token the new alternative also contains** with `ctx.ACCESS() == nil`. **Generalisable — the shape to look for**: a token accessor (`ctx.PAGE()`) is true for several alternatives, so in an if/else visitor the first branch wins and the later one is dead. `TestEveryShowAlternativeProducesAStatement` cannot catch it: a statement IS produced, just the wrong one — so a new alternative needs a test asserting the ObjectType, not merely that something came out. Grep `ctx\.[A-Z]*()` in the chain for a token that appears in more than one alternative before adding one. **The `-c` parse-error column is offset** by the `CONNECT LOCAL '<path>'; ` prefix `-p` prepends, which is why the report shows 1:60 for a 40-character command — do not chase the position, reproduce with `mxcli check <file>`. Three controls, each reverted separately: no grammar alternative ⇒ the original parse error; no ENTITY guard ⇒ `ObjectType = ENTITY`; no PAGE guard ⇒ `*ast.DescribeStmt`. Verified end-to-end on a real 10.24 project (access rules / allowed roles reported, `show entity` and `show page` still describing). Tests `mdl/visitor/visitor_show_access_test.go`, repro `mdl-examples/bug-tests/925-show-access-on-entity.mdl`. Issue #925 |
-| `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 | 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** | `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` | 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 |
-| `MOVE IMPORT MAPPING …` / `MOVE JSON STRUCTURE …` is a parse error, and neither mapping type takes a `FOLDER` clause on create — so those documents can never leave the module root from MDL. The documented doctype list ("PAGE \| MICROFLOW \| NANOFLOW \| SNIPPET \| ENUMERATION \| CONSTANT") is itself stale, omitting three doctypes MOVE already supported | `moveStatement` listed nine doctypes and nothing else; the other twenty-two were never unimplemented, just unlisted. `MoveImportMapping` and `MoveExportMapping` were fully wired — interface, both engines, mock — and **called from nowhere**. Same shape as mxcli-formula1 #32, one layer wider | grammar `mdl/grammar/MDLParser.g4` (new `moveDocumentType` rule), registry `mdl/ast/ast.go` (`MoveDocumentTypeByKeyword`, `IsMoveDocumentType`), visitor `mdl/visitor/visitor_entity.go`, executor `mdl/executor/cmd_move_document.go` (generic path) + `cmd_move.go` (default case), backend `FindDocumentUnit` / `ListDocumentUnits` in `mdl/backend/placement.go` | **Make the doctype list a grammar RULE, not an inline alternation.** `MOVE FOLDER` is told from a document move by the *absence* of a doctype, and that discriminator was a hand-written negation of every doctype keyword — with twenty-two more keywords it would never have stayed in step. As a sub-rule it is one `ctx.MoveDocumentType() == nil` check that cannot go stale. **Resolve the document through the unit table, not a per-kind list**: one `FindDocumentUnit(module, name)` covers every doctype including ones added later, where twenty-two `List<Kind>()` scans would each be a place to forget a kind. **Do not build a doctype → `$Type` table to validate against** — two such tables already exist in this repo and disagree with each other and with a real project (`mdl/types/unit_types.go` says `JavaActions$JavaScriptAction`; the writer inserts and Studio Pro stores `JavaScriptActions$JavaScriptAction`). Derive the kind from the stored `$Type` instead (`types.DocumentKind`) and refuse only when the derived kind is *itself* a doctype MOVE can spell, so a derivation you cannot vouch for defers to the name lookup rather than blocking a legitimate move. **Report the kind you found, not the kind the statement named** — the lookup is by name, so the two can differ, and echoing the user's word would be a confident-sounding lie. Same reasoning fixed `LIST FOLDERS`, whose hand-maintained `documentsByContainer` still hid layouts, menus, JavaScript actions and building blocks after #892 added five kinds to it: it now fills gaps from `ListDocumentUnits()` (measured 78 → 259 documents listed on a 7-module project). Tests `mdl/visitor/visitor_move_alldoctypes_test.go` (drives the registry, so a doctype added to it without grammar support fails), `mdl/executor/cmd_move_document_test.go`; example in `mdl-examples/doctype-tests/18-folder-examples.mdl`. Issue #932 |
-| Import and export mappings (and a dozen other doctypes — queues, scheduled events, regular expressions, workflows, menus, image collections, Java/JavaScript actions, database connections, data transformers, the AI-agent documents) have **no `FOLDER` clause on `create` at all**, so they can only ever be created at the module root. `DESCRIBE` on one that Studio Pro filed away emits no folder either, so a describe → re-exec round trip recreates it unfiled | The clause was simply never added to those grammar rules; `CreateImportMappingStmt` had no `Folder` field and the executor hardcoded `containerID := module.ID` | grammar: 16 create rules across `MDLParser.g4`, `MDLDomainModel.g4`, `MDLMicroflow.g4`, `MDLService.g4`, `MDLWorkflow.g4`, `MDLAgent.g4`; AST `Folder` field on each `Create*Stmt`; visitors; executors (`containerForDocument` + `applyDocumentFolder`); DESCRIBE emitters via `describeFolderClause` | Put the clause in **one place per statement — straight after the qualified name** — rather than matching each rule's local style. Pages/snippets (`Folder: 'path'` property) and microflows (`folder 'path'` before `begin`) already disagree, and a third convention per doctype would make the syntax unlearnable. **Watch for rules that already contain a direct `STRING_LITERAL`**: `createWorkflowStatement` read DISPLAY / DESCRIPTION / DUE DATE by *counting* `AllSTRING_LITERAL()` in order, so a folder path — now the rule's first string — silently became the display name and shifted every later clause by one. Fix by **labelling the tokens in the grammar** (`display=STRING_LITERAL`) and reading `ctx.GetDisplay()`, not by placing the new clause last: positional counting is wrong for *any* combination of optional clauses, not just this one. Same for `createDataTransformerStatement`, whose source path was `ctx.STRING_LITERAL()`. Control: revert the workflow visitor to positional and `TestWorkflowHeaderClausesAreReadByLabel` reports `DisplayName = "Private/Filed"`. The executor side is uniform — `containerForDocument(ctx, moduleID, s.Folder, existingContainer)` encodes the precedence (named folder → current placement → module root) once, so no handler decides it again. Verify the round trip by replaying a DESCRIBE **into a module where the document does not exist** — replaying over the original says "Unchanged" whether or not the clause survived. Tests `mdl/visitor/visitor_folder_clause_test.go` (all 16 doctypes); repro `mdl-examples/bug-tests/932-folder-on-modify.mdl`. Issue #932 |
-| `SHOW REFERENCES TO <entity>` reports **0 pages, 0 widgets** for an entity that is demonstrably used on a page, and `SEARCH` cannot find content that is in the model. The entity is used inside a **List View specialization template** (one template per specialization of the list view's generalization — Studio Pro only; MDL has no surface for it) | `Templates` was not a recognised widget-container key. `extractWidgetsRecursive` knew `Widgets`, `Rows`/`Columns`, `FooterWidgets`, `TabPages`, pluggable `Object.Properties[].Value.Widgets` and NavigationList `Items[].Widgets` — not `Templates` — so nothing inside a template reached the widgets table, and the refs projection is built from that table. `Templates` was also missing from `widgetChildKeys`, so the **same omission had a second, opposite effect**: the list view's own ref scan descended into its templates and, returning the lexicographically smallest candidate, recorded a template's specialization as the list view's datasource entity | `mdl/catalog/builder_pages.go` (`extractWidgetsRecursive`, `widgetChildKeys`) | Walk each template as a container in its own right — `extractWidgetsRecursive(tplMap)` — so its row carries the specialization it renders and its children are indexed like any other nested widgets, **and** add the key to `widgetChildKeys` so the parent stops absorbing them. **Both halves or neither**: recursion alone leaves the wrong-entity displacement in place, and the key alone hides the contents without indexing them. `widgetChildKeys` and the recursion are two sides of one contract — a key in one and not the other is a bug in a specific direction, so audit them as a pair. (`Items` is correctly asymmetric and must stay that way: a nav item's own `Form`/`Entity` belongs to the NavigationList because items are not emitted as rows, and the walk already stops at the item's `Widgets`.) **Generalisable**: two omissions of the same key in complementary walkers partly mask each other — a stray ref still leaks through — which is why this reads as intermittent rather than absent. mendixlabs/mxcli#940 |
-| `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** | `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` | `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` | 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 |
-| `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 | 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** | 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 | **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 |
-| `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 | 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` | `mdl/executor/cmd_pages_describe_datasource.go` (`xpathConstraintClause`) | **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 |
-| 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 | 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 | `mdl/executor/cmd_pages_describe_datasource.go` (`flowSourceArgs`, and the `case "microflow", "nanoflow"` renderer) | 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)` |
-| `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 | 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 | `mdl/executor/cmd_pages_builder_v3.go` (`isDataSourceWidget`, and the `DataSourceOverride` branch) | 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` |
-| A microflow that reads `if Module.SomeRule(param = $x) then` is written with **no Condition at all** — `mx check` reports **CE0080** "The 'Condition' property is required." naming the Decision, whose caption still shows the call. `DESCRIBE` renders it as `if true then`, so the round trip looks like valid MDL, and re-applying an identical `CREATE OR MODIFY` over a Studio Pro-authored microflow turns a clean project into a broken one | Two defects, one behind the other. (a) `splitConditionToGen` handled only `ExpressionSplitCondition` and fell through to `default: return nil`; the caller then skipped `SetSplitCondition` entirely. The READ side had been implemented for #723, and that asymmetry is what made it silent. (b) `modelsdk/gen` binds `Microflows$RuleCall.Rule` to BSON key `Rule`, where Mendix stores **`Microflow`** (rules share the microflow namespace) — so fixing (a) alone writes a reference Mendix never reads and produces the same CE0080 for a different reason | `mdl/backend/modelsdk/microflow_write.go` (`splitConditionToGen`, new `ruleCallToGen`, the `Microflows$RuleCall` marker registration); `modelsdk/gen/microflows/types.go` (`initRuleCall` + `RuleCall.InitFromRaw` — STORAGE-NAME OVERRIDE on both sides); strike the row off `modelsdk/gen/keyaudit_test.go`; tests `mdl/backend/modelsdk/microflow_rule_split_write_test.go`; repro `mdl-examples/bug-tests/939-rule-split-condition.mdl` | **"Works on Mendix 10, fails on 11" was an ENGINE difference, not a version one** — same script, same project, `MXCLI_ENGINE=legacy` is 0 errors and the default (modelsdk) is CE0080. The microflow write path branches only on `major >= 10` / `<= 9`, so 10.24 and 11.12 take identical code; check the engine before believing a version story. **A round-trip test cannot see a wrong storage key** — it passes whichever key is used as long as both sides agree, which is exactly the shape of (b) — so assert the KEY on the encoded document, in a separate test with its own control. **Reconstruct the missing document type when the fixture does not exist**: MDL cannot author rules and no module in a blank Mendix 11 app ships one, so the repro rewrote an mxcli-created microflow's unit as `Microflows$Rule` (keeping only the ten properties `initRule` declares) — `mx check` 0 errors on the synthetic rule is the control that it is a valid stand-in. Verify the fix against the legacy engine's BSON, not just against a green build: the two documents are identical modulo key order. Issue mendixlabs/mxcli#939 |
-| `mxcli check -p` reports **"Unexpected token after expression — … possible missing space between keywords"** with an EMPTY location and a hint about glued keywords like `emptyor`, on a script that parses fine without `-p` and executes correctly. Related: `declare $b Boolean = Mod.Rule(...)` passes check and is **CE0117** "Error(s) in expression" on mxbuild, and `show callers of` a rule finds nothing | Three separate gaps around the one construct MDL spells as `Module.Name(...)`. (a) `mdl/exprcheck` does not model a qualified call, so the trailing `(` was left on the stream and reported as leftover — it fired on the VALID decision form as much as the invalid ones, so it carried no signal and named a typo that was not there. (b) A Mendix expression has no user-callable functions at all — its library is built-in and unqualified — so a qualified call in a VALUE position is CE0117 whether it names a rule, a microflow or a Java action, and both engines wrote the literal text. (c) A rule is not an activity: Mendix evaluates one only as a decision's condition, and the reference extractor walked only action activities, so a rule called from a decision had no callers | `mdl/exprcheck/parser.go` (`parseQualifiedCall`, reached from `parseIdentLed`) + `ast.go` (`CallExpr.Qualified`) + `unknown_funcs.go` (skip qualified); `mdl/executor/validate_qualified_call.go` (MDL066) wired from `validate_microflow.go`; `mdl/executor/cmd_microflows_builder.go` (`buildSplitCondition` refuses a non-rule); `mdl/catalog/builder_references.go` (`collectRuleCalls`); tests `mdl/exprcheck/qualified_call_test.go`, `mdl/executor/validate_qualified_call_test.go`, `mdl/catalog/builder_rule_refs_test.go` | **A diagnostic that fires on the correct form too is worse than none** — it trains the author to ignore the checker, and here it also masked the real defect in the same script. **Exempt only the position that is actually legal**: the decision condition is the single place a bare qualified call is valid MDL (mxcli stores it as a `RuleSplitCondition`), so MDL066 skips `if` and nothing else — a `while` condition has no rule-split form and is flagged. **Split the check by what it needs**: whether a qualified call is illegal *here* is project-less (no built-in Mendix expression function has a dot in its name), while whether the name in a decision is a RULE needs the backend — so the first is a linter rule and the second is a flow-builder refusal, each with its own control. **Do not let the new node reach the unknown-function checker**: `UnknownFunctionCalls` feeds MDL044's did-you-mean, and a qualified name has no near built-in, so it would emit nonsense on the legal form; `CallExpr.Qualified` marks it and the walker skips it. Not fixed: rules are still not catalog OBJECTS, so a microflow called only from inside a rule's body is reported dead by QUAL004 / GRAPH_DEAD_ASSETS — adding the object type without also indexing rule bodies would report every rule itself as dead, so it needs both halves at once. Issue mendixlabs/mxcli#939 |
-| `mxcli test`: (a) a `.test.mdl` file whose first test is preceded by a **file-level `/** … */` header** reports one test fewer — the first one vanishes with no pass, no fail and no error, and every later test renumbers over it; the workaround (a `--` header) re-triggers it the moment that header's **prose spells out `/**` and `*/`**. (b) `@expect count($Var) = N` on a bare `retrieve` block reported **PASS unconditionally** on v0.18.0, for any N, against an empty table | Two independent "substring instead of structure" defects in `cmd/mxcli/testrunner`. (a) `extractDocAndBody` took the FIRST `/**`…`*/` in a `/`-separated chunk as the test's doc comment. A header is not separated from the test below it by a `/`, so both are one chunk: the header became the doc, carried no `@test`, and the chunk — real test included — was skipped. The delimiters were found by `strings.Index` with no notion of comment or string state, which is why writing them inside a `--` comment recreated the fusion. Test IDs were numbered by **chunk index**, so a skipped chunk left a gap (`test_2` as a file's only test) and the line number came from searching the whole file for the chunk's first 20 bytes (wrong chunk when two start alike; **panics** on a chunk shorter than that). (b) `count()` is not a Mendix expression *function* — counting a list is an Aggregate list **activity** — so `ParseExpect` could not compile it. Pre-0bf9382 that dropped the annotation, and a test with no assertions passes as long as its body does not throw | `cmd/mxcli/testrunner/parser.go` (`splitTestBlocks`, `extractDocAndBody`, `scanDocComments`, `skipMDLString`), `expect.go` (`expectAggregate`, `parseAggregate`, `collectAggregates`), `generator_endpoint.go` (`writeExpectAggregates`), `generator.go` (`renameExpect`) | Scan the chunk (whitespace / `--` / `/* */` / `'…'`) instead of searching it: the doc is the **last** comment of the leading run, the body starts after it, and the line travels with the chunk from `splitTestBlocks`. Number tests, not chunks. **Two `@test` docs in one chunk is refused**, not resolved — either resolution runs one and drops the other, which is the bug. For (b), hoist the aggregate into the activity the author would write (`$mxtest_count_X = COUNT($X);`) ahead of the decision, and refuse `sum`/`average`/`minimum`/`maximum` (they need an attribute an assertion cannot supply) with the helper-microflow workaround named. In the monolithic runner the generated variable must be renamed per test like the body's own, or two tests counting same-named lists declare it twice. **Verify (b) at the Mendix layer, not the parser's**: `mxcli check` accepts plenty that mxbuild rejects — the generated flows were exec'd into a real 11.13.0 project and `mx check` run with a pristine-copy baseline (1 pre-existing error either side). **Controls**: pre-fix binary on the repro file finds 2 of 4 tests; stubbing `isListAggregate` to false restores "count() is not a Mendix expression function". Repro `mdl-examples/bug-tests/927-test-mdl-leading-comment-and-count.test.mdl`. Issue #927 |
-| A `.test.mdl` test gains an assertion, a cleanup strategy or an expected error **nobody wrote**, because a sentence in its doc comment quotes the annotation — writing "`@expect $x = 1` in a sentence" gives the test that assertion, and "@cleanup none would apply here" changes its cleanup strategy. The invented assertion usually fails to compile, so the test reports an ERROR whose message quotes prose | The annotation patterns in `parseAnnotations` were unanchored (`@expect\s+(.+)`), so they matched anywhere in a line rather than at its start. An annotation is a javadoc **tag**, and a tag opens its line | `cmd/mxcli/testrunner/parser.go` (the six patterns in the `var (…)` block) | Anchor every pattern with `^`. The leading `*` and its indentation are already stripped before they run, so the real spellings — at any javadoc indentation, and the one-line `/** @test x */` form — are unaffected; keep a control asserting that, or a fix that simply stops reading annotations passes. Found while writing the #927 repro file: its header explained the bug, and explaining it created an assertion that then errored against a test nobody had written. **Generalisable**: the sibling of #927's own root cause — a delimiter means nothing outside the structure it delimits, whether that structure is a comment or a line |
-| A test carrying both `@throws` and `@expect` reports making two assertions and makes one: the `@expect` is never evaluated, silently. It cannot fail, whatever it claims | `@throws` selects a different generated shape in **both** generators (`writeThrowsFlowBody` / `writeThrowsTestBlock`, where the verdict starts as a failure and only the error handler clears it) and neither emits the `@expect` checks — but `AssertionCount` still counted them. Same silent-absence class as the dropped `@expect` and the unimplemented `@verify`, in the one combination where the assertion cannot be made to work at all: the body was expected not to produce a result to assert on | `cmd/mxcli/testrunner/parser.go` (`checkThrowsExpect`, called from `parseAnnotations` beside `checkVerifyCleanup`) | Move the expects to `AssertionErrors` and clear them, so the test is an ERROR and gets no microflow — the annotation pipeline's fail-closed rule. Keep the `@throws` itself: it is the assertion that still stands. **Prove it end to end, not on the struct**: the visible symptom is `AssertionCount` and the generated MDL, so the test parses a file, checks the count, and greps the generated flow for the microflow's absence. Sibling of the `@verify`-under-rollback refusal, which is the precedent for the message shape (name the annotation, name the one-line change) |
-| `ALTER WORKFLOW` over `--mcp` inserts a `CALL MICROFLOW` and Studio Pro shows **CE0495 "Duplicate name"** on the workflow, while `mxcli`'s own read-back looks fine and the statement reported success | A `CALL MICROFLOW` activity is named after its target microflow (`buildCallMicroflowTask`: `task.Name = n.Microflow.Name`), so two calls to the same microflow collide before anything inspects them. The file backends deduplicate in `wfmutator`; the MCP backend had no equivalent and sent the derived name verbatim. Two separate gaps, both needed: PED **accepts** the duplicate with `SUCCESS` and does **not** auto-rename (measured live), and `mcpWorkflowMutator.Save()` early-returned when only activity ops had run, so `ped_check_errors` — the only thing that sees a consistency error — was never called. `CREATE`/`CREATE OR REPLACE` are **not** affected: the executor dedups at `cmd_workflows_write.go` for every backend | `mdl/backend/wfnames/` (shared policy); `mdl/backend/mcp/workflow.go` (`resolve`/`searchActivities` collect names on the walk, `Save`/`checkSettled`); `mdl/backend/wfmutator/mutator.go` (`serializeAndDedup`, `buildSubFlowBson`) | Deduplicate **before the add** — PED refuses `set` on an activity's `/name` (`Element type does not support renaming`), so there is no repair after the fact. Collect the taken-set on the walk `resolve` already does, or the fix costs a PED round-trip per level. **Use a taken-set, not a seen-count**: counting re-collides the moment the workflow already contains the suffixed name (`A, A, A_2` counts its way to `A, A_2, A_2`). Uniqueness is workflow-**wide**, so recurse into the inserted activity's own outcome and boundary-event sub-flows. **`ped_update_document` reporting `SUCCESS` proves nothing about consistency** — it reports op-level failures only; `ped_check_errors` is the only signal, and it reads Studio Pro's **background** error list, which lags the write in BOTH directions (26 samples at a 20ms poll interval: error becomes visible 77-115ms after the write, stops being shown 75-128ms after the fix; one symmetric debounce, no growth under load). Asked too early it answers "No errors found." for a document just broken **and** still reports an error a just-applied op has already cleared — measured against an immediate check as the control, 6 trials each: immediate missed the real error 6/6 and falsely failed on a cleared transient 6/6, settled 0/6 on both. `Backend.pedCheckDocument` owns the pacing for every call site (delay, then re-ask while clean) so a new write path cannot forget it. **Poll at a fine interval when measuring a debounce** — a first pass at 50-100ms reported 170-350ms and "grows under load", both pure granularity artifacts. Issue #945 |
-| 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 | 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)}`) | `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` | **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` |
-| A workflow write is never elided: re-running an unchanged `ALTER WORKFLOW` (or any workflow rewrite) produces a different `.mpr` every time, so Studio Pro shows a version-control change on every run even though nothing was edited | Every `Workflows$*` element — activities, outcomes, boundary events, and the workflow root — carries a `PersistentId`, and **both** engines mint a fresh GUID for it on every write (`addFreshPersistentID` in modelsdk, a literal `idToBsonBinary(generateUUID())` in legacy) while **neither** reads the stored value back. A rebuilt document therefore never equals the stored one, so `canon.Reconcile`'s no-op elision could not fire for a workflow | `modelsdk/canon/persistentid.go` (`CarryPersistentIDs`, wired into `Reconcile` in `identity.go`); tests `modelsdk/canon/persistentid_test.go`; blind-spot note in `mdl/backend/modelsdk/identity_drift_test.go` | Carry it in **canon**, not in the writers: one place covers both engines and every nested type, and the writers keep minting fresh for genuinely new elements (which is correct — the carry only applies where a stored counterpart exists). `canon.identityFields`/`CarryIdentity` are **not** the right home — they only reach **top-level** properties of the document root, and `PersistentId` sits on elements arbitrarily deep in the flow tree; reuse `TransplantIDs`' structural pairing instead, and keep the traversal identical to `pairer`'s or one element's `$ID` and `PersistentId` could come from two different stored elements. **`TestFreshGUIDFieldsHaveAnIdentityDecision` does not catch this class**: it sees only properties registered via the codec's `FreshGUIDFields`, and a writer that mints a GUID by hand is invisible to it. Verify by **byte-comparing the `.mpr` across repeated no-op runs on both engines** (`MXCLI_ENGINE=legacy`), not by reading the code — and keep a control that a real edit still writes, or the carry has become a way of losing writes. Issue #949 |
-| `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)` | **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 | `mdl/executor/cmd_entities.go` (`AlterEntityDropAttribute` cleanup) and `mdl/backend/modelsdk/domainmodel_alter.go` (`UpdateEntity`, the emptied-child-list loop) | 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 |
-| `ALTER WORKFLOW … REPLACE ACTIVITY X WITH <activity named X>` silently renames it to `X_2`, and re-running the same script compounds it — `X_2_2`, `X_2_2_2`, … A no-op replace (nothing changed) renames too. Invisible to `mxcli check`, `exec` output, and — for `CALL MICROFLOW` steps, whose DESCRIBE renders only the target microflow — to `DESCRIBE` as well | The dedup helper was written for INSERT and reused by REPLACE. `collectAllActivityNames()` walks the still-unmodified tree, so the activity about to be spliced out is still in the name pool when the replacement's name is checked against it — a same-name replace therefore always "collides" with itself. The MCP backend had the same shape, propagated deliberately in PR #204 on a **guess** that the file backends' choice was intentional | `mdl/backend/wfmutator/mutator.go` (`serializeAndDedup` gains `freeName`, `ReplaceActivity` passes the outgoing name); `mdl/backend/mcp/workflow.go` (`activityRefMatch.name` / `wfLocation.name`, `delete(loc.taken, loc.name)`); tests `mdl/backend/wfmutator/replace_samename_test.go`, `mdl/backend/mcp/workflow_dedup_test.go` | Free **only the outgoing activity's name**, and read it off the **resolved element** — the reference may be a caption, not the name, so using `activityRef` frees the wrong key (or none). Keep a control proving a replacement colliding with a *surviving* activity still dedupes, or the fix over-corrects into CE0495. **Check the severity claim before believing it**: the report argued renames detach in-flight `System.WorkflowUserTask` records, but Mendix's [workflow-versioning docs](https://docs.mendix.com/refguide/workflow-versioning/) list "changing names, captions, and titles" as explicitly **non-conflicting** — the engine matches structurally, not by name. The real harm is unbounded accretion and the ADR-0008 idempotence break. **The fix only half-closes that**: a no-op replace still rewrites the `.mpr` because `addFreshPersistentID` re-mints `PersistentId` on every activity write in both engines and neither reads it back (measured: untouched siblings keep theirs, the replaced one does not). Issue #944 |
-| `SHOW PROJECT SECURITY` prints no **Guest User Role** on the default engine while `MXCLI_ENGINE=legacy` prints it for the same project — and the documented Starlark fields `anonymous_user_role` / `role.is_anonymous` resolve to `""` / never, so a lint rule asking "what can anonymous visitors read" matches nothing | `modelsdk/gen` bound `Security$ProjectSecurity.GuestUserRoleName`; every Studio Pro document stores **`GuestUserRole`** (likewise `AdminUserRoleName` → `AdminUserRole`). Both were on the known-mismatch ledger, unfixed. The legacy parser reads the right key, which is why the engines disagreed | `modelsdk/gen/security/types.go` (`initProjectSecurity`), ledger rows struck from `modelsdk/gen/keyaudit_test.go` | **A `property.Primitive` decodes AND encodes under one bound name** (`Get()` passes `p.name` to the decode func; the encoder reads the same), so unlike the pages precedents this needs **one** literal, not two — check the property kind before hunting for a second site in `InitFromRaw`. **The read bug was the quiet half; the write bug was fatal.** gen preserved the stored `GuestUserRole` as an unknown-key passthrough, so existing writes lost nothing — but calling `SetGuestUserRoleName` would have added a *second* key beside it, which Studio Pro refuses to open (`Sequence contains no matching element` at `MprProperty.cs`) while mxbuild tolerates it. Measure the encode side before concluding a passthrough makes the key safe. Control for the whole fix: rewrite the stored role under the pre-fix key and `mx check` reports **CE0133** (6 errors vs 5) — i.e. without the override the guest-access feature would have shipped writing a project that cannot build. Tests `modelsdk/gen/security/storagename_projectsecurity_test.go`. Issue #924 |
-| An app needing **anonymous access** cannot be built unattended: `SHOW PROJECT SECURITY` reads `Guest Access` but no MDL statement writes it, so every headless run ends with a manual step in Studio Pro | `ALTER PROJECT SECURITY` had exactly two forms (`LEVEL`, `DEMO USERS`). Nothing was missing underneath — `SetEnableGuestAccess` already existed in gen — it had simply never been wired through grammar → AST → visitor → executor → backend | `mdl/grammar/domains/MDLSecurity.g4`, `mdl/ast/ast_security.go`, `mdl/visitor/visitor_security.go`, `mdl/executor/cmd_security_write.go` (`applyGuestAccess`), `mdl/backend/security.go` + both engines | **`DEMO USERS ON\|OFF` is the whole template** for any project-security flag: same AST node, same unit, same write choke point. Copy it rather than designing. **What mxbuild does and does not enforce decides the syntax, and only measurement tells you which:** guest access on with an empty role is **CE0133** (measured 6 errors vs 5), so `ROLE` cannot be optional in effect — but guest access on with a role that **does not exist** builds with the *same* count as a valid one, so mxcli must validate the reference itself or a typo yields a silently broken public site. That asymmetry is why `ROLE` is optional in the *grammar* (a stored role satisfies CE0133, so re-enabling need not retype it) and required by the *executor*. **`OFF` keeps the stored role** — guest-off-with-role is valid Mendix, and clearing it would lose the operator's choice on a toggle. **No check-time (no-project) rule is possible for the bare `ON` case**: whether it is legal depends on what the project stores, which `mxcli check` cannot see — so unlike most refusals this one has no `validate_security.go` counterpart, deliberately. Example `mdl-examples/doctype-tests/30-guest-access.mdl`; tests `mdl/executor/cmd_security_guest_access_test.go`. Issue #924 |
-| `DELETE_BEHAVIOR PREVENT` (or `DELETE_IF_NO_REFERENCES`, or `DELETE_AND_REFERENCES`) reports `Modified association` and stores `DeleteMeButKeepReferences`, destroying whatever the association had — and `DESCRIBE ASSOCIATION` emits `delete_behavior DELETE_CASCADE`, which the parser then rejects | `buildDeleteBehavior` read only `db.CASCADE()`; the other four of the rule's five tokens fell through to the zero value `ast.DeleteKeepReferences`. A **legal** behaviour, so nothing below could tell it had been substituted. Underneath it, `ALTER ASSOCIATION SET` built the stored value as `DeleteBehaviorType(s.DeleteBehavior.String())`, and `String()` spells prevent `"DeleteIfNoReferences"` where Mendix writes `"DeleteMeIfNoReferences"` — so fixing the visitor alone put an **out-of-domain enum** on disk | `mdl/visitor/visitor_helpers.go` (`buildDeleteBehavior`), then `mdl/executor/cmd_associations.go` (`storageDeleteBehavior`) | Read **every** token the grammar rule admits — a `default:` arm returning a plausible value turns a parse gap into silent data loss. Route all storage conversions through one function; a `String()` returning storage-ish names is a trap, not an encoder. Emit from DESCRIBE only spellings the lexer has (`DELETE_AND_REFERENCES`, not `DELETE_CASCADE`) and prove it by feeding the output back through `visitor.Build`. **`mx check` is not the oracle here**: measured on mxbuild 11.6.6, a project carrying `DeleteIfNoReferences` builds with 0 errors exactly like a correct one — only Studio Pro refuses it, so assert the stored value is one of Mendix's three, not merely the one you asked for (upstream #901) |
-| `CREATE OR REPLACE WORKFLOW` silently deletes a boundary event (timer + its whole handler flow) or an event sub-process that the script does not restate — `exec` reports "Created workflow" and exit 0, and `mx check` afterwards reports 0 errors because the result is a valid workflow that simply no longer does what it did. `DESCRIBE WORKFLOW` does not show the construct either, so nothing reveals the loss | Two separate defects. (1) The **default (modelsdk) engine's workflow reader had no boundary-event support at all** — `grep BoundaryEvent mdl/backend/modelsdk/workflow_read.go` → 0, while `sdk/mpr/parser_workflow.go` → 17. Both engines *write* them, so a boundary event mxcli itself had just written read back as absent. (2) A rewrite rebuilds from the statement, so anything unstated is dropped, and no guard existed — unlike the queued-call and validation-rule paths | `mdl/backend/modelsdk/workflow_read.go` (`boundaryEventsFromGen`, wired into the 6 gen types with `BoundaryEventsItems`); `mdl/executor/validate_workflow_rewrite.go` (`checkNoDroppedWorkflowConstructs`, called from `cmd_workflows_write.go`); `mdl/executor/cmd_workflows.go` (clause order) | **Read the stored side from the RAW unit, not the semantic model** — the reader is what was blind, and a guard sharing its blind spot cannot see what it protects; `GetRawUnit` also covers constructs no engine models yet (event sub-processes exist in `modelsdk/gen` but have no semantic type, reader or writer anywhere). Match the `$Type` by **substring** so all three timer variants and any later one are caught. Authorable constructs get the queue treatment (restate them and the rewrite proceeds); unauthorable ones refuse outright. **Fixing a reader can expose a describer bug**: with boundary events finally readable, `describe → exec` stopped parsing, because the call-microflow describer emitted `boundary event` BEFORE `outcomes` and the grammar requires the reverse — pre-existing on legacy, invisible while the default engine emitted neither. Always re-run a describe→re-exec round trip after widening a reader. Issue #948 |
-| 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 | `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` | `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` | **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 |
-| `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 | 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 | `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` | **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 |
-| 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 | 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 | `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) | 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 |
-| `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 | 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 | `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` | **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 |
-| A bundled skill renders with a stray `---` fence and a duplicated `name:` at the top of its body, and `mxcli init` ships it that way. `TestEmbeddedSkillsCarryAgentSkillsFrontmatter` passes — the frontmatter it checks is valid | The #906 migration **prepended** a `name`/`description` block to every skill, including the one file that already had one (`custom-widgets`, under its pre-rename name `mendix-custom-widgets`). Everything after the FIRST `---` block is body, so the old block became visible text. The test's `frontmatter.FindSubmatch` matches the first block and validates it correctly, which is precisely why it is blind to a second one | `.claude/skills/mendix/custom-widgets/SKILL.md` (two blocks merged into one, keeping the old block's trigger words — child slots, `.def.json`, engine internals); guard added to `cmd/mxcli/init_skills_standard_test.go` | **A first-block check cannot see a rename-and-prepend**, and that is the exact shape of a migration that renames things — so a bulk frontmatter edit needs a guard against a SECOND block, not a better check of the first. **Measure the pre-state before a bulk prepend**: 1 of 68 files already had frontmatter, which was known and written down, and the migration script still did not branch on it. **Do not attribute a defect to the change you are looking at** — this was reported against PR #222, whose diff touches only the `description:` inside the first block and shows the stray `---` as unchanged context; `git log -S 'name: mendix-custom-widgets'` settles it in one command. Two adjacent traps from the same report: `make test` did not depend on `sync-all` while `make build` did, so a bare `go build` left the generated `cmd/mxcli/skills` stale and six tests failed — and the failure message named the `go:embed` directive, which was fine, instead of the missing build step. A **differential across refs is only as sound as the procedure both sides share**: the same stale build made main fail 4 and the branch fail 6, which looked like a regression and was a test-count difference. mxcli-formula1 finding 68 |
-| `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") | `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 | `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` | 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 |
-| `GRANT … ON Module.Entity` over `--mcp` fails with `failed to read module security for X: GetModuleSecurity: not supported by the MCP backend` — `--mcp-verbose` prints **no PED tool call at all**, and `mxcli mcp capabilities` reports entity access rules as available in the same session. `SHOW MODULE ROLES` / `SHOW USER ROLES` / `SHOW PROJECT SECURITY` fail the same way | The MCP backend embeds `unsupportedBackend` and overrides only what it supports; `gen_unsupported.go`'s own header says it delegates "the reads those [writes] need" — i.e. a read is added **reactively, per write method**. `AddEntityAccessRule` (#704) shipped and was unit-tested, but the executor calls `validateModuleRole` → `GetModuleSecurity` **before** it, and a pre-check made outside the backend package is invisible from inside it. Three reads were missing, not one | `mdl/backend/mcp/security.go` (`GetModuleSecurity`, `ListModuleSecurity`, `GetProjectSecurity` → `b.reader`); tests `mdl/backend/mcp/grant_executor_test.go` | **Test the statement, not the backend method** — a unit test on the method passes against a completely unreachable feature, which is exactly how this shipped; drive real MDL through `executor.New` + `SetBackendFactory` against `newFakePED` and assert a `ped_update_document` actually happened. **Probe the whole class**: the reported symptom was GRANT, but the same three-line omission had broken every security `SHOW`, none of which writes anything. **The capability report is a hand-written YAML declaration, not a verified claim** — `capabilities.go` says report and behaviour "cannot drift", and that holds only for the four *method-gated* keys; `entity_access_rules` is a display-only row, so it can and did contradict the very next command. Routing a read to the local `.mpr` is safe **only when PED is not a writer of that document**: roles are by-name references Studio Pro resolves on apply, so a stale file yields "module role not found", never a wrong write — unlike the domain model, which needs the dirty-set router. A module created over PED this session has no security document on disk at all, so answer that case explicitly rather than letting the reader say "not found for module mcp~module~X". Issue #900 |
-| A batch write through `codec.Store.SaveUnit` / `FlushUnits` reports success while a unit's `.mxunit` on disk still holds the old bytes — the `Unit` row's `ContentsHash` describes contents nobody can read. On Windows the trigger is a file held open without `FILE_SHARE_DELETE` (an editor, an indexer, a sync client), which makes `os.Rename` fail with "Access is denied"; the CLI's own `ALTER`/`CREATE` paths are unaffected because they go through `Writer.updateUnit`, which has always failed hard | `WriteTransaction.Commit` committed the SQLite transaction FIRST and then renamed the temp files, logging a warning and continuing when a rename failed — so the database moved on and the disk did not, and `nil` told every caller the write had landed. #954 | `modelsdk/mpr/writer_core.go` (`Commit`), mirrored in `sdk/mpr/writer_core.go` | Rename the files into place BEFORE committing the transaction, moving each replaced file aside as `<unit>.mxunit.bak` so a later failure can put it back; on any failure undo the renames, drop the temps and roll the transaction back. Test it by removing a pending temp file between `WriteUnit` and `Commit` — a portable stand-in for the lock — and assert BOTH that `Commit` errors and that the DB hash still matches the file, since an error alone passes against a version that reports the failure and still leaves the DB ahead |
-| 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"* | 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 | `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`) | 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 |
-| 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` | `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 | `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`) | 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 |
-| 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 | **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 | `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` | **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 |
-| `DESCRIBE PAGE` emits MDL that does not parse — `line N:M mismatched input 'custombutton' expecting '}'` — so a page holding that widget cannot round-trip, and the object list's items cannot be authored at all | The `.def.json` generator DERIVES the container keyword from the object-list property key (`customButtons` → `CUSTOMBUTTON`, via `deriveObjectListKeyword`), while the grammar's `widgetTypeV3` carries a HAND-MAINTAINED list of them. Nothing checked the two agree, so any widget whose object list had no keyword described back as unparseable MDL | `mdl/grammar/MDLLexer.g4` + `mdl/grammar/domains/MDLPage.g4` (`CUSTOMBUTTON`, `ALLOWEDFILEFORMAT`); guard test `mdl/executor/widget_container_keyword_test.go` | **Add the guard, not just the keyword** — the list is derived on one side and hand-written on the other, so the next marketplace widget re-opens it; the test reads the accepted keywords straight out of `MDLPage.g4` so it cannot drift from the grammar, and fails with the fix instructions in the message. **Check the lexer before adding one**: measured across 43 widget defs, 5 derived keywords were missing and 3 of them (`ATTRIBUTE`, `ATTR`, `EVENT`) COLLIDE with existing tokens — `ATTRIBUTE` is the `Attribute:` property keyword — so they cannot simply be appended and are recorded in `knownUnsupportedContainers` with the reason rather than left to fail silently. The symptom is a parse error, so it is loud — but the thing it hides is not: an unparseable DESCRIBE means `describe → exec` **aborts**, and a round-trip test that only diffs the two describes passes, because a re-describe after a failed exec is trivially identical. Always confirm the exec applied (`Replaced …`) first. Issue #956 |
-| 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** | `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 | `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` | **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 |
-| 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 | 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 | `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` | **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 |
-| `COMMIT $Obj;` writes **"With events = No"** — Studio Pro's default is Yes, so every mxcli-authored commit silently skips its before/after commit event handlers. Detection is nil across the board: `mxcli check` ✓, `mxcli lint` 0 errors, Studio Pro's consistency check ✓, `mxbuild --write-errors` BUILD SUCCEEDED. The reporter found it in production — 1,800 rows written, no handler run. Sibling symptom: a Studio Pro **DELETE** or **CREATE** activity with `Refresh in client = Yes` loses the flag on describe → exec | Two layers, and only the first is the reported bug. **MDL**: the grammar had no `WITHOUT EVENTS` on `commitStatement`, so an absent modifier meant `false` — while MDL's own convention (stated in `commitClause`'s grammar comment) is that absent means *Mendix's* default. **Engine**: `modelsdk/gen`'s `initCommitAction` carries `// TODO: applyDefaults(o) — populate mandatory fields from reflection-data` (~900 such TODOs across gen), so nothing downstream corrects a wrong MDL default — though it is not the proximate cause here, since the writer sets the value explicitly either way. The refresh half is `#407` half-fixed: that issue added `REFRESH` to `change` and stopped, leaving `delete` and `create` with no grammar, no describer output, and (for create) no field in the semantic model at all | `mdl/grammar/domains/MDLMicroflow.g4` (`commitStatement`, `deleteObjectStatement`, `createObjectStatement`) + `mdl/executor/cmd_microflows_format_action.go` | Invert the AST flag to `MfCommitStmt.WithoutEvents` so the **zero value is the language default** — a `WithEvents bool` defaults to the one value Studio Pro never writes, and that trap is what caused the bug. Keep `WITH EVENTS` parsing (it means the default) so pre-fix scripts still run. DESCRIBE must render the *deviation*, not the flag: `without events` when false, nothing when true — render it the other way and a Studio Pro default commit describes into its opposite. Share one `refreshModifier()` across all five activities; five inline conditionals is exactly how delete and create drifted. **Measure against a real Studio Pro document, not the refguide**: `CommitActivity.DefaultCommit` in ako/TestApp stores `WithEvents=true`, and its sibling stores `false`, so Studio Pro writes both spellings and neither is an omission Mendix fills in. **Prove the drop before fixing it**: flip `RefreshInClient` on a stored Delete through the backend, describe (renders `delete $Obj;`), re-exec → `Replaced` and the flag is gone; the commit probe under the same round trip reports `Unchanged`, which is the control that says the drop is delete-specific and not round-trip noise. `mx check` is worthless here — 0 errors before and after — so the fixpoint test is `Unchanged microflow:` from exec. MDL067 (info, once per microflow) names the documents whose behaviour changes. Tests `TestFormatAction_CommitObjects`, `TestFormatAction_RefreshInClient_AllActivities`, `TestCommitWithoutEvents`; repro `mdl-examples/bug-tests/895-commit-events-and-refresh-defaults.mdl`. Issue #895 |
-| 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 | 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 | `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` | **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 |
-| `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 | 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 | `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`) | **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 |
-| 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 |
-| `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 | 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 | `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` | **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 |
-| `mxcli check`/`exec` reports **MDL041** "assigning a Decimal expression to Integer variable" on arithmetic that mxbuild builds at **0 errors** — `round(floor($a div 3)) * 3` is refused while the same expression without the `* 3` is accepted. Since `exec` refuses to write when any rule errors, the model's own `describe` output cannot be fed back to `exec`, and anything built on that round trip (mutation harnesses, generators) silently applies nothing | `round`/`floor`/`ceil` were declared `ret: KindDecimal` in `funcTable` and exempted from the check only when the call was the WHOLE right-hand side. As soon as the rounded value became an operand, the inner `div`'s Decimal taint propagated back out through the very function that exists to stop it. The same root-only shortcut let the genuinely Decimal two-argument `round($a div $b, 2)` through, and `abs`/`max`/`min` — which preserve their operands' kind — were false positives on every Integer argument | `mdl/exprcheck/func_checker.go` (`funcSig.retByArity`/`retFromArgs`/`retFor`, the Math table), `mdl/exprcheck/parser.go` (`inferKind` CallExpr arm, `callArgsResult`), `mdl/exprcheck/unknown_funcs.go` (`SourceRejectedForIntegerTarget`; `roundingFuncs` deleted); test `mdl/exprcheck/round_returns_integer_test.go`; repro `mdl-examples/bug-tests/sudoku-49-mdl041-rounding-arithmetic.mdl` | Give the function table a return kind that is right at **every** call site instead of exempting a name at the root: arity-dependent for `round` (1 arg Integer, 2 args Decimal), Integer for `floor`/`ceil`, operand-derived for `abs`/`max`/`min`. Then the rule just asks `inferKind`, and `arithResult` propagates it through the surrounding arithmetic for free. **Measure the table against mxbuild, one row at a time** — `mxcli exec --no-check` writes the expression, `mx check` judges it — and include the bare `$a div 3` control, or a table of "0 errors" proves only that the validator never fires. Cheaper alternative deliberately NOT taken: downgrading MDL041 to a warning so it cannot block `exec`. **The generalisable trap: making a checker authoritative (refuse-before-write) turns every false positive from an annoyance into a blocked workflow** — the rules behind such a gate have to be at least as accurate as the tool they are protecting you from, and this one was measurably less accurate than `mx check` on 10 of 18 probes. Sudoku finding #49 |
-| `index "Idx" on (A, B)` written inside `create entity`'s attribute parentheses fails to parse with `missing ':' at '"Idx"'` plus an unrelated "unescaped apostrophe" hint — reading as though indexes were unsupported there. Separately, the standalone `create index Idx on Mod.Entity (A);` reports `Syntax OK (0 statements)` and `exec` writes nothing, silently, even when the entity does not exist | Two halves of one gap. The index syntax exists but belongs AFTER the closing paren (`entityBody: LPAREN attributeDefinitionList? RPAREN entityOptions?`), so inside it the index name parses as an attribute missing its type, and the short leftover tokens then trip the apostrophe heuristic. The standalone `createIndexStatement` rule had been in the grammar since indexes were added **with no listener behind it** — `grep -rn CreateIndexStatement mdl/visitor/ mdl/ast/ mdl/executor/` returned nothing | `mdl/visitor/visitor.go` (`misplacedIndexRe`, the hint branch, `errorListener.deduplicateHint`), `mdl/visitor/visitor_entity.go` (`ExitCreateIndexStatement`), `mdl/visitor/visitor_helpers.go` (`buildIndexColumns` extracted from `buildIndex`); tests `mdl/visitor/misplaced_index_hint_test.go` | Key the hint off the **source line**, not the ANTLR message — the token error lands on the index name, so the message never mentions `index` (the `bareNotRe` precedent). Discriminate against the valid standalone form by what sits between `ON` and `(`: the misplaced form has the paren directly there, the standalone one names the entity. **Lower the standalone statement to the ALTER one** rather than growing a second write path — it means exactly `alter entity … add index`, and the index name is discarded in both, because a Mendix index is identified by its columns (`ast.Index` has no Name field). **A cascade repeats a hint under every error it caused** — one misplaced index yields four errors on one line — so suppress a hint already shown for that line; per line, not globally, or the same mistake made twice in a file is explained once. **A grammar rule with no listener is worse than a missing one**: it answers "Syntax OK" and does nothing. Sudoku finding #4 |
-| A domain script cannot be re-run. `alter entity … add index` is the silent one: a second run reports "Added index" and appends a duplicate, and the project then fails the build with **CE0072 "Duplicate indexes"** — mxcli said nothing was wrong. `drop index` is addressable only by an invented positional name ("idx1") that appears in no output, and the documented `drop index (Col)` does not parse. `create entity`/`create association` offer only `create or modify`, which replaces the whole definition and drops omitted attributes (finding #24) | Three gaps in one surface. The `IF NOT EXISTS`/`IF EXISTS` family had been added for ATTRIBUTE and EVENT HANDLER only, so INDEX had no guard AND no duplicate check — the two omissions compose into a silent corruption rather than an error. DROP INDEX matched `fmt.Sprintf("idx%d", i+1)` against a user-supplied name, which is a position, not an identity | `mdl/grammar/domains/MDLDomainModel.g4` (`ifNotExists?` on ADD INDEX / createEntityStatement / createAssociationStatement, `ifExists?` + `indexDefinition` on DROP INDEX), `mdl/executor/cmd_entities.go` (`findIndexByColumns`, `indexMatchesColumns`, `indexColumnLabel`, both index arms, the create-entity arm), `mdl/executor/cmd_associations.go` (`associationExists`), `mdl/executor/cmd_enumerations.go` (`validateIdempotencyGuard`, MDL067); tests `mdl/executor/alter_entity_index_idempotent_test.go`, `mdl/visitor/idempotency_guards_test.go`, `mdl/executor/validate_idempotency_guard_test.go`; repro `mdl-examples/bug-tests/sudoku-10-rerunnable-domain-script.mdl` | **An index's identity is its columns, in order, with their directions** — Mendix builds a composite database index, so (Row, Col) is not (Col, Row) and ascending is not descending; a matcher looser than that makes ADD refuse a distinct index and DROP remove the wrong one. **A guard and a duplicate check are separate omissions**: adding `IF NOT EXISTS` alone would have left the unguarded form still corrupting, so the bare form must ERROR — and its message names CE0072 and the guarded spelling, because the author cannot otherwise connect a build failure to the statement that caused it. **`IF NOT EXISTS` is not `OR MODIFY`**: one leaves the stored element untouched, the other rebuilds it from the statement, so they are opposite answers for a partial statement and writing both is refused (MDL067) rather than silently resolved. **Check the docs against the parser**: four forms in `MDL_QUICK_REFERENCE.md` did not parse (`add (a, b)`, `drop (a)`, `rename X to Y`, `drop index (Col)`) — the exact drift class `scripts/check-skill-mdl.sh` names in its own header, which had never been pointed at that file. It is now wired into `make check-skill-mdl`. Verify with a THREE-run control: run 1 does the work, run 2 is nothing but skips, run 3 leaves `mprcontents` byte-identical and `mx check` at 0 errors. Sudoku finding #10 |
-| Rewriting a document **deletes every language but one**: a `describe page` → `exec` round-trip drops a page's Dutch title from the entire project, and `show languages` counts fall. `mx check` reports 0 errors before and after | A Mendix text is a `Texts$Text` holding one `Texts$Translation` child per language, and MDL carries **one string** — `Title: 'My Account'` — so a rebuilt document has exactly one child and the rest are gone. The legacy reader compounds it: `extractTextFromBson` returns the first non-empty text and ignores `LanguageCode` entirely | `modelsdk/canon/translations.go` (`CarryTranslations`), `modelsdk/canon/identity.go` (`Reconcile`'s carry chain) | Carry the stored translations onto the rebuild, in the same chain as the other things a rebuild would lose (identity, element `$ID`s, `PersistentId`) — so **both engines get it from one place** (`sdk/mpr/writer_units.go` and `modelsdk/mpr/writer_core.go` both call `canon.Reconcile`). Pair texts **by containment path when the two documents hold texts at exactly the same paths** (exact, and the only way to carry a text whose source the statement CHANGED), else **by source string**. A mis-pair here is NOT benign the way `TransplantIDs`' is — that rewrites every reference with the id, whereas copying a translation onto the wrong text injects a translation of a different string — so positional pairing is abandoned entirely if one path differs rather than applied where it fits. **Append the stored `Texts$Translation` sub-document verbatim**, not a freshly built one: without its `$ID` the canonical form differs and no-op elision can never fire. Ambiguous source (two stored texts share a source, disagree on the translation) → carry nothing. **`mx check` is not the oracle** — a model missing a translation is valid; count `Texts$Translation` elements or use `show languages`. Controls: remove the call from `Reconcile` → nl_NL 335 → 328 on one page, and `TestReconcile_TranslatedDocumentRoundTripsUnchanged` fails. Repro `mdl-examples/bug-tests/translations-preserved-on-rewrite.mdl`. PROPOSAL_translations.md slice 1 |
-| `search '<text>'` finds nothing that lives only in a **nanoflow, rule, JSON structure or mapping**, even right after `refresh catalog source`; `CATALOG.SOURCE` holds only ENTITY / ENUMERATION / MICROFLOW / SNIPPET / PAGE | Two lists maintained in different packages drifted. `buildSource` (catalog) already collected nanoflows, rules and workflows, but `captureDescribeParallel`'s dispatch (executor) had no `rule` case and routed `"nanoflow"` to `describeMicroflow`, which searches `ListMicroflows()` only and so returns NotFound for every nanoflow. The worker loop then discarded both errors — `if err == nil && text != "" { ... }` — so the types produced zero rows and reported nothing. Measured: 114 collected, 100 inserted, the 14 dropped being exactly the 13 nanoflows + 1 rule | `mdl/catalog/builder_source.go` (`buildSource`, `runDescribes`), `mdl/executor/cmd_catalog.go` (`describeDispatch`) | Keep the type names as constants in `catalog.SourceObjectTypes` and make the executor's dispatch a table asserted against that list, so a collector added without a dispatch case fails a test instead of silently indexing nothing. **Pin each mapping by function identity** (`runtime.FuncForPC`) — a presence-only check passes the nanoflow bug, because the wrong function is still a function. Return describe failures instead of dropping them and report them grouped by type: a whole type failing is a wiring bug, one document failing is a property of that document. Verify at the catalog layer, not via `mxcli check` — the defect needs a project, so a `.fail.mdl` cannot express it (see the Makefile's `check-mdl` note). Repro `mdl-examples/bug-tests/912-catalog-source-all-doctypes.mdl`. Issue #912 |
-| A `create or replace translations` run reports removing N translations and they are all **still there** afterwards | `canon.Reconcile` carries the stored translations onto every write (PROPOSAL_translations slice 1), which is right for a REBUILD — MDL carries one string per text and the other languages were never expressible — and exactly wrong for a targeted PATCH, where a missing translation was removed on purpose. The two are indistinguishable from the bytes | `modelsdk/canon/identity.go` (`Reconcile`'s `ContentsOwnTranslations` option), `modelsdk/mpr/writer_core.go` (`UpdateRawUnitOwningTranslations`), `mdl/translations/project.go` | Only the CALLER knows which case it is, so the write declares it. A path that patches stored bytes uses `UpdateRawUnitOwningTranslations`; a rebuild uses the ordinary write and keeps the carry. Threaded as a **variadic** `canon.Option` so every existing caller is untouched. The test must show the default DOES carry before showing the option suppressing it, or it proves nothing. Related: a new `Texts$Translation` needs a real 16-byte `$ID` as its **first** property — Mendix fails the build with *"Expected '$ID' as the first property of a storage object, but got '$Type'"*, which no assertion about the translation's value catches; it took `mx check` on a patched project to find. Repro `mdl-examples/doctype-tests/translations.mdl`. PROPOSAL_translations slices 2-4 |
-| A pluggable widget's text-template property is authored and **silently dropped** — the document keeps the enumeration that says the text exists but no text, so `tooltipType: 'customText', tooltip: '…'` builds as *"'Tooltip' cannot be empty when 'Custom' type is chosen"*. The tell that makes it findable: `tooltip: 'Value {Score}'` WORKS while `tooltip: 'Plain text'` does not | `setTextTemplateValue` only ever **updated an existing** TextTemplate and returned the element untouched when it was nil. A CONDITIONAL template is stored nil while its condition hides it (#574), and the Slider's tooltip is hidden under its own default `tooltipType: "value"` — so a statement that turns the condition on and writes the text in one go finds nothing to edit. `ApplyVisibilityRules` then fills the now-visible property with an EMPTY template, which is what reaches disk. The `{AttrName}` spelling escapes it only because `SetTextTemplateWithParams` **replaces** the whole template instead of editing it | `mdl/backend/widgetobj/builder.go` (`setTextTemplateValue`); the params gap it exposed is `mdl/executor/widget_engine.go` (`applyOperation` "texttemplate" + `resolveMapping` "TextTemplate", `BuildContext.ClientParams`) | Build the envelope when the slot is nil (`updateTemplateText(BuildEmptyClientTemplate(), text)`) rather than special-casing visibility — `ApplyVisibilityRules` still runs afterwards and re-nulls a genuinely pruned property, so authored text can never survive into a slot the editor hides. **Studio Pro is the tool that localises this**: `pg_read_page` shows the stored template as a well-formed, EMPTY `Pages$ClientTemplate`, which distinguishes "no text was written" from "the template is malformed" — the BSON cannot. Two traps. Fixing the drop makes the **`{1}` spelling reachable**, and the MAPPING pass ignored `contentparams:` where the explicit-property pass has routed it since #928, so the newly-landing text hit CE0720 until both passes agreed. And **DESCRIBE still does not emit any text-template property for a pluggable widget** (`extractExplicitProperties` reads AttributeRef and PrimitiveValue only), so a tooltip survives a write and is lost on the next describe→exec — measured on the Timeline control too, i.e. every widget, tracked separately. Repro `mdl-examples/bug-tests/254-slider-custom-tooltip.mdl`. Issue #254 |
-| 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 | 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 | `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`) | 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` |
-| **CE0463 on every page carrying a File Uploader**, whatever is on it — an action-free one with nothing but its `datasource:` fails identically. The widget the #956 action-slot work was *about*, and the one it never exercised | **Two independent causes, and each alone still fails.** (A) The widget XML's `defaultType` — the KIND of a default, `defaultType="CallNanoflow"` on the create* actions, `defaultType="Association"` on the datasources — was never parsed, so all six landed as `DefaultType: "None"`. It is part of the widget DEFINITION, exactly like the stale `onChange` of #716. (B) `uploadMode`'s declared default never reached the visibility evaluator, because a primitive mapping carries the XML default in `PropertyMapping.Value` while `widgetValueMap` read only `.Default` (populated for selections alone). With the condition unknown, `hiddenUnnamedProperties` correctly refuses to guess — so `associatedImages` was not pruned, the one `datasource:` clause fanned out into BOTH datasource properties, and the pruned one carried a value. File Uploader is the only widget in a stock 11.13.0 app that declares any `defaultType` (6 properties; every other bundled widget declares 0), which is why one widget was unwritable while the rest were fine | (A) `modelsdk/widgets/mpk/mpk.go` + `sdk/widgets/mpk/mpk.go` (`PropertyDef.DefaultType`, `xml:"defaultType,attr"`), `modelsdk/widgets/augment.go` + `sdk/widgets/augment.go` (`defaultTypeOf`); (B) `mdl/executor/validate_widgets.go` (`widgetValueMap`) | **`mx update-widgets` on a COPY is the oracle when there is no Studio Pro** — and when one IS reachable, `ped_check_errors` over the written documents is the real verdict, with the same page written by the pre-fix binary as the control (it reports the CE0463 text and a `/layoutCall/arguments/0/widgets/0/widgets/0` location; the fixed 17 documents report "No errors found."). `pg_read_page` then shows the editor's own view — on the pre-fix page it lists BOTH `associatedFiles` and `associatedImages` under `uploadMode: "files"`, which is the fanout, and on the fixed one only the active half. It is Studio Pro's own normalizer: run it, confirm it clears the error, then diff its output against yours — a 2,650-path document diff whose *only* differences are the cause. Diff by property NAME, never by index: the two dumps order top-level keys differently and a positional flatten reports ~60 spurious differences that hide the 6 real ones. Widget properties are keyed by `TypePointer` into `Type.ObjectType.PropertyTypes`, so resolve the pointer to its `PropertyKey` first or the diff is unreadable. Two more findings from the same measurement, both still open: mxcli writes widget-action `ParameterMappings` with list marker **3** where Studio Pro writes **2** (and omits the sibling `Variable`/`OutputMappings` keys) — accepted by both mxbuild 11.13 **and Studio Pro**, which resolves every mapping to the right parameter (checked live over PED), so it is a diff-churn item rather than a correctness one; and the visibility extractor misses a `hidePropertiesIn` call inside a **ternary branch** (`cond ? hide([…]) : hide([…])`), as opposed to the ternary *array element* #233 fixed — so `createImageAction` carries no uploadMode rule, MDL-WIDGET10 cannot warn, and wiring it in files mode is a CE0463 the script author gets no help with. Repro `mdl-examples/bug-tests/956-fileuploader-six-action-slots.mdl`. Issue #956 |
-| Nothing visibly wrong: `create translations` writes a translation that builds at 0 errors and describes back correctly, but the `Texts$Translation` elements it minted carry `$ID`s of a shape Studio Pro never produces | `mdl/translations` minted its own id — 16 raw bytes from `crypto/rand` — instead of going through `types.GenerateID`/`types.UUIDToBlob` like every other element mxcli writes. Mendix stores an element id as a **.NET Guid**: mixed-endian, so the RFC-4122 version nibble lands at byte **7** and the variant bits at byte **8**. Raw bytes satisfy that 1 time in 64. Measured on a stock 11.13.0 app: **44,002 of 44,002** element ids are well-formed on that reading (version 4 or 5, variant `10b`), including all **1,650** translation ids the marketplace modules ship; after `mxcli exec translations.mdl`, **1 of 27** written ids was. `mx check` is silent — a Guid parses any 16 bytes — and so is DESCRIBE, because the id is never shown | `mdl/translations/text.go` (`newElementID`), against `mdl/types/id.go` (`GenerateIDErr`, `UUIDToBlob` — which is where the byte swap lives) | Mint through `types.GenerateIDErr` + `types.UUIDToBlob`. Assert the **form**, not the presence: draw ~200 ids and require version nibble 4 at byte 7 and variant `10b` at byte 8, so a raw-random implementation cannot pass by luck (`TestNewElementID_IsAUUIDInMendixByteOrder`). Note the two measurement traps: decoding with `bson.M` (or any Go map) **loses key order**, so "is `$ID` first" cannot be asked that way — use `bson.D`/`bson.Raw`, or Python, whose dicts preserve insertion order; and read the version nibble at byte **7**, not 6 — at byte 6 Mendix's own ids look like uniform noise, which reads as "Mendix does not care" and inverts the conclusion. The paired control is the whole project: 100% conforming before the run and after the fix, 3.7% for the new ids in between. Repro `mdl-examples/bug-tests/translation-id-form.mdl` |
-| `mxcli run --ensure-db` fails to start PostgreSQL when no service manager becomes ready (e.g. Arch): `exec: "pg_ctlcluster": executable file not found in $PATH`, though `initdb`/`pg_ctl`/`psql` are present | `startLocalPostgres` only knew the `service`/`pg_ctlcluster` helpers (the latter a placeholder that could never run), and role/database provisioning assumed `sudo -u postgres`, which a user-owned cluster does not need | `cmd/mxcli/docker/ensuredb.go` (`startLocalPostgres`, `startUserCluster`, `resolveSuperuser`) | Fall back to a user-owned `initdb`/`pg_ctl` cluster under `~/.mxcli/postgres`, but never initialize a competitor when the requested TCP port is already owned by a service-started server that is still recovering. Enforce the passwordless-superuser boundary instead of assuming it: explicitly tighten an existing socket directory to `0700`, set the socket itself to `0700`, and persist `listen_addresses`/`port`/`unix_socket_directories` in `postgresql.conf` so a plain later `pg_ctl start` stays safe. Refuse, with a cleanup path, a cluster made by the earlier development revision if its host authentication is still `trust`. Reuse a running cluster only when both the port and socket directory in `postmaster.pid` match. Keep `sudo -u postgres` for system clusters, but make both sudo and psql non-interactive, retain peer authentication over the system Unix socket at the exact requested port, and force SCRAM password storage for pre-14 defaults. Normalize the endpoint once and return it to the runtime; parse the bracketed form before any last-colon IPv6 compatibility fallback. Tests stub every external tool and exercise slow service startup, legacy-cluster refusal, permissions, persisted settings, endpoint propagation, sudo arguments, and repeated/running cases. Issue #823 |
-| `mxcli test` **panics** — `slice bounds out of range [:-1]` in `extractDocAndBody` — on a `.test.mdl` saved with **CRLF** line endings; the identical file with LF works. Separately, **one unparseable file aborts the whole directory**: `mxcli test tests/` (and `--list`) reports the bad file and runs none of the others | Two independent defects behind one report. (1) The line-number estimate searched the **raw file bytes** for the first 20 characters of a block that had already been rebuilt by joining scanner lines with `"\n"` — under CRLF the needle can never match, `strings.Index` returns -1, and `content[:-1]` panics. Fixed as a side effect of #927's block/line pairing (`testBlock` carries its own `Line`), which left it **untested**. (2) `ParseTestDir`/`parseTestFiles` returned on the first file that failed to parse, so an unrelated malformed file cost every other test in the directory | `cmd/mxcli/testrunner/parser.go` (`TestSuite.FileErrors`, `FileError`, `ParseTestDir`), `cmd/mxcli/testrunner/runner.go` (`parseTestFiles`, `Run`, `dispatchRun`, `reportFileErrors`, `suiteFileErrorResults`), `cmd/mxcli/testrunner/watch.go`; tests `cmd/mxcli/testrunner/parser_crlf_test.go`, `cmd/mxcli/testrunner/parser_file_isolation_test.go` | **Never search reconstructed text inside the original bytes** — normalising line endings on the way in and then indexing the raw content is the whole bug, and it is silent on LF machines. **A CRLF test must write the bytes at runtime** (`os.WriteFile`), not live in a checked-in fixture: git's line-ending handling would normalise it and the test would pass vacuously. **Assert on line NUMBERS, not just "does not panic"** — the defect lived in a line estimate, so a smoke test would not have detected a wrong answer; the LF file is the control. For (2), the fail-closed rule this package is built around is **ERROR, not abort**: an uncompilable `@expect` becomes a `StatusError` result counted with the failures, and an unparseable file now gets the same treatment — red exit code, file named, other tests still run |
-| A language cannot be enabled or disabled from MDL — `alter settings LANGUAGE` carries `DefaultLanguageCode` only, so the answer to "translate this app" was always "go to Studio Pro". Worse, `show languages` looks like the answer and is not: it lists languages that have TRANSLATIONS (from the catalog `strings` table), so a stock blank app reports **8** while **1** is enabled | The enabled list (`Settings$LanguageSettings.Languages`) was read into the semantic model and never written: the settings overlay wrote `DefaultLanguageCode` and carried `Languages` through from the stored document. A handler could therefore report `Enabled language: ar_SD` and land **nothing** — the executor mutated `ps` and the writer dropped it on the floor | `mdl/grammar/domains/MDLSettings.g4` (`ADD`/`REMOVE` alternatives, `languageOptions`), `mdl/visitor/visitor_settings.go`, `mdl/executor/cmd_settings_languages.go`, and the write that makes it real: `mdl/settingsoverlay/settingsoverlay.go` (`Languages`, `Language`, `newLanguage`) wired from `mdl/backend/modelsdk/settings_write.go` | Pin the element against a Studio Pro-authored reference before writing it — four things a guess gets wrong: the type is **`Texts$Language`** (not `Settings$…`) though it lives under `Settings$LanguageSettings`; there is **no `Description`** (Studio Pro derives "Arabic, Sudan" from `ar_SD`, so the code is the whole stored identity); Studio Pro **appends** rather than sorting; and **`CheckCompleteness` is stored `false` even for the default language**, whose Languages-table row reads "Yes" — the dialog says why ("the default language is always checked"), so that Yes is computed and writing `true` to match the UI produces a document Studio Pro never writes. Follow `settingsoverlay.ServerConfiguration`: match stored elements by their natural key, keep each one's document (so its `$ID` and any unmodelled property survive), derive a NEW element's shape from a sibling so no key is invented. **The refusal that was wrong:** removing a language does NOT delete its translations — the enabled list and the translation data are independent, which a stock app proves by enabling one language while storing translations in eight — so refusing on that basis would make the operation impossible on any project with a marketplace module and would assert something false about Mendix. Report the count instead. Verify by diffing the written element against the Studio Pro one field by field (identical here, `$ID` aside) and by checking the stored `$ID` of an untouched language survives. Example `mdl-examples/doctype-tests/languages.mdl` |
-| A language cannot be enabled or disabled from MDL — `alter settings LANGUAGE` carries `DefaultLanguageCode` only, so the answer to "translate this app" was always "go to Studio Pro". Worse, `show languages` looks like the answer and is not: it lists languages that have TRANSLATIONS (from the catalog `strings` table), so a stock blank app reports **8** while **1** is enabled | The enabled list (`Settings$LanguageSettings.Languages`) was read into the semantic model and never written: the settings overlay wrote `DefaultLanguageCode` and carried `Languages` through from the stored document. A handler could therefore report `Enabled language: ar_SD` and land **nothing** — the executor mutated `ps` and the writer dropped it on the floor | `mdl/grammar/domains/MDLSettings.g4` (`ADD`/`REMOVE` alternatives, `languageOptions`), `mdl/visitor/visitor_settings.go`, `mdl/executor/cmd_settings_languages.go`, and the write that makes it real: `mdl/settingsoverlay/settingsoverlay.go` (`Languages`, `Language`, `newLanguage`) wired from `mdl/backend/modelsdk/settings_write.go` | Pin the element against a Studio Pro-authored reference before writing it — four things a guess gets wrong: the type is **`Texts$Language`** (not `Settings$…`) though it lives under `Settings$LanguageSettings`; there is **no `Description`** (Studio Pro derives "Arabic, Sudan" from `ar_SD`, so the code is the whole stored identity); Studio Pro **appends** rather than sorting; and **`CheckCompleteness` starts `false`** on a newly added language. That flag is a REAL setting, not display sugar — ticking it makes Mendix report errors and warnings for texts with no translation in that language, instead of letting them fall back to the default silently — so it must be authorable (`add … (CheckCompleteness: true)`) and changeable (`modify`), never forced. The subtlety is only the DEFAULT language: a stock project stores `false` for `en_US` while its Languages-table row reads "Yes", because Mendix always checks the default whatever the flag says, so a run that sets it there should say the value is stored and inert until another language becomes the default. Follow `settingsoverlay.ServerConfiguration`: match stored elements by their natural key, keep each one's document (so its `$ID` and any unmodelled property survive), derive a NEW element's shape from a sibling so no key is invented. **The refusal that was wrong:** removing a language does NOT delete its translations — the enabled list and the translation data are independent, which a stock app proves by enabling one language while storing translations in eight — so refusing on that basis would make the operation impossible on any project with a marketplace module and would assert something false about Mendix. Report the count instead. Verify by diffing the written element against the Studio Pro one field by field (identical here, `$ID` aside) and by checking the stored `$ID` of an untouched language survives. Example `mdl-examples/doctype-tests/languages.mdl` |
-| A language cannot be enabled or disabled from MDL — `alter settings LANGUAGE` carries `DefaultLanguageCode` only, so the answer to "translate this app" was always "go to Studio Pro". Worse, `show languages` looks like the answer and is not: it lists languages that have TRANSLATIONS (from the catalog `strings` table), so a stock blank app reports **8** while **1** is enabled | The enabled list (`Settings$LanguageSettings.Languages`) was read into the semantic model and never written: the settings overlay wrote `DefaultLanguageCode` and carried `Languages` through from the stored document. A handler could therefore report `Enabled language: ar_SD` and land **nothing** — the executor mutated `ps` and the writer dropped it on the floor | `mdl/grammar/domains/MDLSettings.g4` (`ADD`/`REMOVE` alternatives, `languageOptions`), `mdl/visitor/visitor_settings.go`, `mdl/executor/cmd_settings_languages.go`, and the write that makes it real: `mdl/settingsoverlay/settingsoverlay.go` (`Languages`, `Language`, `newLanguage`) wired from `mdl/backend/modelsdk/settings_write.go` | Pin the element against a Studio Pro-authored reference before writing it — four things a guess gets wrong: the type is **`Texts$Language`** (not `Settings$…`) though it lives under `Settings$LanguageSettings`; there is **no `Description`** (Studio Pro derives "Arabic, Sudan" from `ar_SD`, so the code is the whole stored identity); Studio Pro **appends** rather than sorting; and **`CheckCompleteness` starts `false`** on a newly added language. That flag is a REAL setting, not display sugar — ticking it makes Mendix report errors and warnings for texts with no translation in that language, instead of letting them fall back to the default silently — so it must be authorable (`add … (CheckCompleteness: true)`) and changeable (`modify`), never forced. The subtlety is only the DEFAULT language: a stock project stores `false` for `en_US` while its Languages-table row reads "Yes", because Mendix always checks the default whatever the flag says, so a run that sets it there should say the value is stored and inert until another language becomes the default. Follow `settingsoverlay.ServerConfiguration`: match stored elements by their natural key, keep each one's document (so its `$ID` and any unmodelled property survive), derive a NEW element's shape from a sibling so no key is invented. **The refusal that was wrong:** removing a language does NOT delete its translations — the enabled list and the translation data are independent, which a stock app proves by enabling one language while storing translations in eight — so refusing on that basis would make the operation impossible on any project with a marketplace module and would assert something false about Mendix. Report the count instead. Verify by diffing the written element against the Studio Pro one field by field (identical here, `$ID` aside) and by checking the stored `$ID` of an untouched language survives. **DESCRIBE has to emit statements, not a comment**, or the settings do not round-trip — and the emitting is where the design work is: plain `add` refuses an already-enabled language, so a described project could not be replayed onto itself, which is why `ADD OR MODIFY` exists (the same upsert reasoning as `CREATE OR MODIFY`); `DefaultLanguageCode` is validated against the enabled list, so it must be emitted **after** the languages or the output fails on a project that lacks that language; and **every** option must be named, because MODIFY touches only what it names and an omitted `CustomDateFormat` would leave whatever the target already had. Measured both directions: replaying onto the same project leaves the unit byte-identical and reports `Unchanged language` per language (the verb is downgraded on positive evidence, as with `Unchanged nanoflow`), and replaying onto a BLANK project reproduces the language settings exactly. Example `mdl-examples/doctype-tests/languages.mdl` |
-| `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` |
-| 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 | `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 | `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` | **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 |
-| The documented way to remove a language's translations — `create or replace translations for <lang> ( );` — is a **parse error**, so there is no way to do it at all. The advice appears in the removal path's own error message, in the skill and in the docs | `createTranslationsStatement` required at least one entry: `LPAREN translationEntry (COMMA translationEntry)* COMMA? RPAREN`. An empty list is the OR REPLACE semantics taken to the limit (the file names nothing, so everything in scope goes), and nothing else expresses it | `mdl/grammar/domains/MDLSettings.g4` (`createTranslationsStatement`), tested in `mdl/visitor/visitor_translations_test.go` | Make the list optional — `LPAREN (translationEntry (COMMA translationEntry)* COMMA?)? RPAREN` — and nothing else: `ModeReplace` with an empty dictionary already removed everything and already named what it deleted. **The lesson is about the docs, not the grammar**: this was found by running the statements quoted in a skill through `mxcli check` rather than by reading them, and the same wrong advice had already shipped inside an error message telling users how to recover. Quote-then-check every statement a message or a skill recommends; `make check-skill-mdl` covers fenced blocks it recognises but not prose inside a Go string |
-| `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 | 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 | `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` | 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 |
-| `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 | 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 | `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` | 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 |
-| Lint reports a clean project under rules that never ran: `--list-rules` omits the bundled Starlark rules, `-r <id>` prints `No issues found.` for a rule that did not load (or never existed), and `mxcli report` scores high. Typically when `.claude/` sits at the repo root and the `.mpr` is in a subfolder | Three separate silences. (a) Discovery was `filepath.Dir(<the .mpr>) + /.claude/lint-rules`, so rules were found only beside the .mpr — one `.claude/` at the repo root loaded **zero** Starlark rules (measured 19 vs 48). (b) `--rules` is an allowlist applied by disabling everything it does not name, and the ids were never validated, so an unmatched id disabled all rules and the run reported success. (c) Load failures went to stdout via `fmt.Printf` and were not returned, and the directory-level error was discarded by `if err == nil` | `mdl/linter/lintrules_discovery.go` (`FindLintRulesDir`, `UnknownRuleIDs`, `MatchesRuleID`), `mdl/linter/starlark.go` (`LoadStarlarkRulesFromDir`), `cmd/mxcli/cmd_lint.go`, `cmd/mxcli/cmd_report.go`, `mdl/executor/cmd_lint.go` | Walk up from the project for `.claude/lint-rules/`, stopping **at the repo root** — continuing to the filesystem root would let a stray `.claude/` in `$HOME` or `/tmp` supply rules to every project beneath it, which is worse than finding none because the run looks green under someone else's rules. Validate `-r` ids and exit non-zero naming the directory rules came from; match case-insensitively, since `-r conv009` previously disabled everything. Return load failures instead of printing them, and print to **stderr**. **Beware the miscount**: CONV011-CONV014 are Go built-ins, not bundle rules, so "4 of my 29 loaded" really means 0 of 29 and there is no stale-file bug to chase. Fix `cmd_report.go` in the same pass — it had the identical lookup and emits a score. Not expressible as a `.fail.mdl` (needs a directory layout and a project; `check-mdl` runs without one), so the guards are unit tests. Repro `mdl-examples/bug-tests/904-lint-rules-discovery.mdl`. Issue #904 |
-| `mxcli lint --format json \| jq .` fails with `Invalid numeric literal at line 1`; `--format sarif > results.sarif` writes a corrupt file. stdout begins `Connected to: …` / `Loading cached catalog…` / `✓ Catalog ready` before the payload | The executor is constructed with `executor.New(os.Stdout)` via `newLoggedExecutor`, so every progress line shares the stream the payload is written to. Independent of which formatter runs — the chatter is emitted during connect and catalog build, before the formatter is reached | `cmd/mxcli/output_stream.go` (`isMachineReadableFormat`, `progressSink`), `cmd/mxcli/main.go` (`newLoggedExecutorTo`), `cmd/mxcli/cmd_lint.go`, `cmd/mxcli/cmd_report.go` | Pick the executor's writer from the resolved format: stderr when stdout carries a machine-readable payload (json/sarif/html/markdown), stdout otherwise. Route to **stderr, not io.Discard** — the progress is wanted on a terminal and in CI logs, it was merely on the wrong stream. `mxcli report` needs the extra condition that `-o <file>` frees stdout, so progress goes back to stdout there. Text mode must be left alone; assert that, or the fix silently degrades interactive use. Two commands share this because both build a catalog before formatting; any future command that prints a payload to stdout needs `progressSink` too. Issue #904 (residue) |
-| A `create … comment 'text'` option reports success and sets **no documentation**. Affected `create entity`, `create enumeration`, `create module`, `create microflow`, `create nanoflow`, `create rule` and `create association` — the text appears nowhere in the written project, and `mx check` passes because a document with no documentation is valid | The visitor stored the option on `stmt.Comment`; the executor read `stmt.Documentation`. Two fields, never joined. `create module` was worse than unwired: `Projects$Module` has **no Documentation property**, so the option could never have done anything. The `/** … */` doc comment sets `Documentation` correctly on all of these except association, where **neither** spelling works (separate defect) | Grammar `mdl/grammar/domains/MDLMicroflow.g4` (`microflowOption`), `mdl/grammar/domains/MDLDomainModel.g4` (`entityOption`, `enumerationOption`, `moduleOption`); `mdl/visitor/visitor_microflow.go`, `visitor_entity.go`, `visitor_enumeration.go`; hint in `mdl/visitor/visitor.go` (`looksLikeRemovedCreateComment`); tests `mdl/visitor/create_comment_removed_test.go` | **Remove a dead option rather than wiring it** when a working spelling already exists — two spellings, one of which lies, is worse than one. **A removed option needs a parse-error hint**: "no viable alternative" sends the author hunting for a different spelling of something that no longer exists. **`COMMENT` is alive on constants, JSON structures, image collections, database connections, workflow activities and `ALTER … SET COMMENT`** — a blanket search-and-replace across the visitors silently broke the *constant* branch, which `TestCreateConstant` caught; the removal test therefore carries a positive control listing every surviving site. Grep for `stmt.X = …` in a visitor with no matching read in the executor to find more of these |
-| 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 | 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 | `mdl/executor/cmd_microflows_builder_control.go` (`addWhileStatement`, the `pendingCase` loop + trailing `addContinueEvent` block) | 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 |
-| Every **annotation on a domain model** — the note boxes Studio Pro draws on the canvas — disappears when anything rewrites that domain model on `--engine legacy`. Adding one entity to a blank app's MyFirstModule takes its annotation count from 1 to 0 and the caption vanishes from the project. `mx check` reports **0 errors**: an annotation is decorative, so nothing below Studio Pro can see the loss. The default (modelsdk) engine preserves them | Two defects. (1) `sdk/mpr/writer_domainmodel.go` hardcoded `{Key: "Annotations", Value: bson.A{int32(3)}}` — the bare empty typed array — regardless of what the domain model held, while the parser read them into `dm.Annotations` perfectly well. (2) `parseAnnotation` read `Location` only as a BSON sub-document, but Studio Pro stores it as the **string** `"60;240"`, the same convention an entity's Location uses — so even before the write threw them away, every position had already read back as (0,0), and `Width` was never read at all | `sdk/mpr/writer_domainmodel.go` (`serializeDomainModelAnnotation`, the `annotations` array), `sdk/mpr/parser_domainmodel.go` (`parseAnnotation`); tests `sdk/mpr/domainmodel_annotation_test.go` | **A collection the parser reads but the writer hardcodes is invisible to every round-trip test that only checks the parser.** Grep the writers for `bson.A{int32(3)}` written as a literal value rather than built from a slice — that shape is the bug. **A blank Mendix app is a free reference document**: MyFirstModule ships with a real Studio Pro-authored annotation, which is where the `"x;y"` string shape came from — no need to ask anyone to author one. There is **no colour property**: a domain model holds exactly four child collections (Annotations, Associations, CrossAssociations, Entities) and `DomainModels$Annotation` is Caption/ExportLevel/Location/Width, so a "coloured section box" is this element in Studio Pro's own styling, not stored state. A test fixture ID must be a **real UUID** — `idToBsonBinary` cannot round-trip a made-up string, which reads as an identity bug that isn't one |
-| `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 | `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 | `mdl/executor/cmd_microflows_show_helpers.go` (`isFlowNode`, and the `incomingCount` candidate loop in `emitLoopBody`) | **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 |
-| A brand palette hand-edited into `theme/web/custom-variables.scss` works once, and then `mxcli theme apply` reports the file as `skipped` and refuses to touch it — the project has silently taken the theme out of mxcli's hands to change one colour | The theme registry was embed-only: `List`/`Get` read `assetsFS` and nothing else, so there was nowhere to put a fourth theme and the generated block was the only place to put a palette | `cmd/mxcli/theme/source.go` (the two-source registry), `cmd/mxcli/theme/create.go` (`theme create`), `cmd/mxcli/theme/tokens.go` | **A digest fence that refuses an edit is a signal that the thing being edited should have been authorable.** Project-local themes live in `theme/mxcli-themes/` — committed (`.mxcli/` is gitignored by `mxcli init`) and not compiled (mxbuild's entry point is `theme/web/main.scss`; it does not glob `theme/`, verified against a real 11.13 build that nothing under it reaches `deployment/`). Scaffolding **must** rename the identifiers built from the theme name (`@mixin mxcli-<name>-<alt>`, the `@import`) — a plain copy collides the moment both themes exist. Verified end to end: seeded palette → `mxbuild --target=deploy` → measured `--brand-primary` in a real browser in both variants. Tests `cmd/mxcli/theme/create_test.go`, `cmd/mxcli/cmd_theme_test.go` |
-| A design-derived `--mxt-*` token is written into a theme, the theme applies with every file reporting `created`, and the app renders exactly as before — indistinguishable from the design never having been applied | Nothing reads an unrecognised custom property, so a typo (`--mxt-brand-color` for `--mxt-brand`) is a no-op with no error anywhere in the chain | `cmd/mxcli/theme/create.go` (`validateTokens`, `knownTokens`) | **Validate a token vocabulary at authoring time or the failure has no symptom.** `theme create --from` refuses a `--mxt-*` name the base theme does not declare and names it; `mxcli theme show <name>` prints the vocabulary. Related trap: seed only the *scoped* extras into the alt-palette mixin — a variant-independent token like `--mxt-radius` belongs in the palette, and copying it into both means retuning it twice |
-| A theme's SCSS fails to compile with `Error: Expected expression` pointing at a `$…-scope:` line, and every Go test is green — `mx check` says nothing either, because the failure is in mxbuild's Sass pass, before any model validation | A selector was assigned to a Sass variable bare (`$s: :root` or `$s: a, b`). Neither is a Sass expression; only a **quoted string** is, and `#{}` drops the quotes at the point of use | `cmd/mxcli/theme/theme.go` (`expand`, the `{{SCOPE}}` substitution quotes; `{{PALETTE_SCOPE}}` does not, because that file is plain CSS) | **An asset-driven feature whose correctness depends on a compiler the tests never run needs one real compile in the loop.** This shape passed every unit test and broke the build on the first `mxbuild --target=deploy` — the same class as recurring-finding #20. Two placeholders that look interchangeable are not: one lands in plain CSS, one in a Sass expression |
-| Applying several themes as a set is never idempotent — `mxcli-fonts/OFL.txt` reports `updated` on every run, forever — and the installed licence covers the wrong fonts | Every theme vendored a different font family and wrote its SIL OFL text to the *same* path. With one theme installed the last apply won and it settled; with a set, each theme overwrote the previous one on every pass | `cmd/mxcli/theme/assets/*/files/theme/web/mxcli-fonts/OFL-<theme>.txt` (renamed per theme) | **Two themes writing different content to one verbatim path is a licensing bug before it is a churn bug** — the churn is just the symptom that made it visible. `TestThemesDoNotClaimTheSameVerbatimPathWithDifferentContent` hashes every non-fenced file across every theme and fails on a collision; controlled by renaming them back, which reproduces the original failure |
-| A new `DROP <thing>` statement **parses, exits 0, and does nothing** — `mxcli check` passes, the CLI prints no output, and the model is untouched | `ExitDropStatement` in `mdl/visitor/visitor_entity.go` opens with `names := ctx.AllQualifiedName(); if len(names) == 0 { return }` — a silent early return for "most DROP statements have at least one". Any DROP form addressed by something OTHER than a qualified name (a string literal, a position, an index) is swallowed there before its branch is reached. `DROP CONFIGURATION` is handled above the guard for exactly this reason; a new one must be too | `mdl/visitor/visitor_entity.go` (`ExitDropStatement` — put the branch ABOVE the qualified-name guard and `return` from it); example `mdl-examples/doctype-tests/40-domain-model-annotations.mdl` | **Symptom is silence, not an error**, so a test that only checks "the script parses" passes. Exercise a new DROP end to end against a real project and assert the thing is GONE — `mxcli check` cannot see this class at all. The same guard shape (an early `return` keyed on the *usual* argument) is worth grepping for in any other Exit* dispatcher that grew a name-less alternative |
-| `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 | 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 | `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` | **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 |
-| `describe microflow` prints `range($List)` for a range that stores an offset and an amount — both expressions dropped, no warning, exit 0, and `mxcli check` clean on the truncated output, which re-executes as an *unpaged* range. Mirror-image on the write side: `range($L, $o, $a)` authored through mxcli builds as **CE6520** *"Amount and offset are not specified"*, and on `--engine legacy` the project will not **load** at all (*"Expected '$ID' as the first property of a storage object, but got 'NewOperation'"*) | Mendix nests the bounds one level below where mxcli looked: `Microflows$ListRange{ListName, CustomRange}` → `Microflows$CustomRange{LimitExpression, OffsetExpression}`. The modelsdk engine had them **flat on both sides** — `listOperationToGen` wrote them onto the ListRange and `listOperationFromRaw` read them from there — so mxcli round-tripped its own documents perfectly and only Mendix disagreed. The legacy engine had no `ListRangeOperation` case at all, fell through to `return nil`, and `serializeListOperationAction` appended that nil under `NewOperation`, writing an **empty sub-document** that Mendix's loader rejects outright | `mdl/backend/modelsdk/microflow_write.go` (`listOperationToGen`), `mdl/backend/modelsdk/microflow_read_actions.go` (`listOperationFromRaw`), `sdk/mpr/writer_microflow_actions.go` (`serializeListOperation` + the nil guard in `serializeListOperationAction`), `mdl/executor/validate_microflow.go` (`checkRangeHasABound`, MDL068); tests `mdl/backend/modelsdk/microflow_listrange_test.go`, `sdk/mpr/writer_listoperation_test.go`, `mdl/executor/validate_range_bounds_test.go`; repro `mdl-examples/bug-tests/list-range-custom-bounds.mdl` | **A clean round trip proves nothing when one engine wrote the document.** Both sides being wrong in the same direction is what hid this for a release: the reporter concluded "the authoring side works correctly" from exactly that evidence. Read a document Studio Pro wrote, or cross-read with the *other* engine — here the legacy PARSER had been right all along, so `--engine legacy` on a default-engine project was a free control. **`generated/metamodel` settles the nesting**: a `*Microflows$X` pointer field is a child element, a plain string is a property. When a writer's `default:` returns nil, check what the CALLER does with it — appending nil is how an unloadable file gets written, and omitting the key (CE0008, which names the activity) is always the better failure. The reader keeps a **flat fallback** so a project written by the broken writer still describes its bounds and repairs itself on the next `exec` — verified: CE6520 → describe → exec → 0 errors |
-| 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 |
-| 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 |
-| 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` | 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`) | `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 | **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 |
-| 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 | 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 | `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) | **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 |
-| 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 |
-| 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 |
-| An array of **primitives** — `"tags": ["a","b"]` — cannot be mapped, and `describe` leaks the storage markers (`= categories/(Wrapper)` with `Value = (Value)`), which does not parse | Mendix models it as a **Wrapper** element binding one entity per item, with the primitive on a value child at the `(Value)` marker; 34 of the 327 demo-app documents contain one. Two independent causes: mxcli's **JSON structure builder** wrote the wrong PATHS for a primitive array — wrapper at `…\|tags\|(Object)`, value at `…\|(Object)\|` with a trailing empty segment — so nothing could resolve against it; and the mapping builders stepped from an array to a hardcoded `\|(Object)` | `mdl/types/json_utils.go` (`buildElementFromRawArray`), `mdl/executor/mapping_customhandler.go` (`arrayItemOf`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`, and `elementTypeForKind` / `isMappingObjectKind` in all four writers | **No new syntax**: an array of primitives is written like any other array and the wrapper level is GENERATED, the same way the item level is (#248, #262). Step from an array to its **actual** child rather than a hardcoded marker — `\|(Object)` for objects, `\|(Wrapper)` for primitives — which is what `arrayItemOf` is for. **"Wrapper" is an OBJECT element kind**: both writers dispatched on `Kind == "Object" \|\| Kind == "Array"`, so it serialized as a Value with no attribute and mxbuild reported **CE5015** "Element '(Object)/tags/(Wrapper)' is not a Value element" — the same trap on the DESCRIBE side, where the export printer's object branch was missing both `Wrapper` AND `Array`, printing `texts = ` and dropping the subtree. Fix the structure builder FIRST: the mapping is unreachable until the markers exist, and the two look like one bug. `(Value)` is a marker, not a member name — DESCRIBE prints the element's ExposedName (`Value`), which is what re-executing resolves against. Repro `mdl-examples/bug-tests/268-primitive-array-wrapper.mdl`, tests `mdl/executor/mapping_wrapper_test.go`. Issue #268 |
-| A `find` mapping element always behaves as **find-or-create** whatever the document said, and `describe` cannot show the difference — a Studio Pro mapping that said "error out" comes back saying "create silently" | Mendix stores **two** properties on an object mapping element, not one: `ObjectHandling` {Parameter, Create, Find, Custom} and `ObjectHandlingBackup` {Create, Error, Ignore} (plus the bool `ObjectHandlingBackupAllowOverride`). mxcli only ever wrote the first and hardcoded the backup, so the runtime behaviour was mxcli's choice rather than the author's. Measured: rebuilding the shipped `Email_Connector.IMM_EmailTemplateMapping` flipped **7 elements from 'Error' to 'Create'**, with mxbuild reporting 0 errors on both — the documents are equally valid, they just do different things | `mdl/grammar/MDLLexer.g4` (`IGNORE`, `OVERRIDABLE`) + `mdl/grammar/domains/MDLDomainModel.g4` (`mappingHandlingBackup`) + `MDLSettings.g4` (keyword rule), `mdl/visitor/visitor_import_export_mapping.go` (`applyMappingHandlingBackup`), `mdl/executor/cmd_import_mappings.go` + `mapping_messagedefinition.go`, `mdl/backend/modelsdk/mapping_write.go` (`importBackupFor`) + `mapping_read.go`, `sdk/mpr/writer_import_mapping.go` + `parser_import_mapping.go`, `modelsdk/mpr/serialize_mappings.go` | `find M.E or create\|error\|ignore [overridable]`, with `find or create M.E` kept as the older spelling of the first. **A bare `find` is refused** — silently picking one of three runtime behaviours is the bug, so the executor names all three in the error rather than defaulting. Backups that are NOT the author's to choose: `create` and custom (`by`) handling keep 'Create', because "Custom" is not a member of the backup enum; **export** elements are always 'Error' (there is nothing to find), which is what Studio Pro writes. Two places the fix has to reach that a JSON-path test does not exercise: the **message-definition** builder (`mapping_messagedefinition.go`) has its own element construction, and it was the last 7 of the 8 fixture differences — a direct nested JSON test passed while the real document still regressed, so **diff the fixture, not a synthetic case**. The eighth was unrelated and adjacent: `xmlPrimitiveTypeName` fell through `Binary` to "String". Remember a `find` also needs a KEY (`Attr = member key`) or mxbuild reports **CE0250** "Object element must have a key defined if object handling is set to 'Search for an object'." — pre-existing, but every repro of this fix trips it. Repro `mdl-examples/bug-tests/261-object-handling-backup.mdl`. Issue #261 |
-| An import mapping cannot declare its INPUT OBJECT, so a custom handler's `Param: parameter` refers to something that cannot exist, and `describe` of a real one drops the declaration while still emitting the handler that uses it | Mendix stores it as `ParameterType`, a `DataTypes$ObjectType` naming the entity. Measured across the demo apps: 10 of 327 mappings declare one (GenAICommons.ChunkCollection in eight), 190 import mappings store the `DataTypes$UnknownType` marker, and an EXPORT mapping carries no `ParameterType` property at all (0 of 127) — its parameter IS its root object, so there is no export spelling. All three writers hardcoded the UnknownType variant | `mdl/grammar/domains/MDLDomainModel.g4` (`importMappingParameterClause`), `mdl/visitor/visitor_import_export_mapping.go`, `mdl/executor/mapping_customhandler.go` (`resolveMappingParameter`, `requireDeclaredParameter`) + `cmd_import_mappings.go`, `mdl/backend/modelsdk/mapping_write.go` + `mapping_read.go` (`parameterEntityFromRaw`), `sdk/mpr/writer_import_mapping.go` + `parser_import_mapping.go`, `modelsdk/mpr/serialize_mappings.go` | `parameter Module.Entity` on the header, after the schema source. gen models **no** `ParameterType` property at all, so the modelsdk read goes to raw BSON — the route `customHandlerFromRaw` takes. **The legacy parser unmarshals a unit into `map[string]any`, so a nested sub-document arrives as `map[string]any`, NOT `bson.D`**: asserting `bson.D` compiles, always fails, and leaves DESCRIBE silently dropping the clause on the legacy engine only — caught solely by running the same assertions on both backends, so write that test. Two refusals, each with the guard stubbed and measured on mxbuild 11.13: `Param: parameter` with nothing declared is **CE0279** "Parameter is used in object handling microflow while the mapping does not specify one", and an unknown entity is refused by name. **Deliberately NOT guarded**: a parameter whose entity does not match the microflow's parameter type — mxbuild reports **CE0282** naming both types, and duplicating it in mxcli would need a generalisation-aware walk that could refuse valid specialisations. Check the whole thing over the BUILT model in `finishImportMapping`, not the AST, so the JSON-structure and message-definition builders are covered at once. Repro `mdl-examples/bug-tests/265-mapping-input-parameter.mdl`, tests `mdl/executor/mapping_parameter_test.go`. Issue #265 |
-| 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 |
-| 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 |
-| 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` | 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`) | `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 | **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 |
-| 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 | 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 | `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) | **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 |
-| 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 |
-| 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 |
-| An array of **primitives** — `"tags": ["a","b"]` — cannot be mapped, and `describe` leaks the storage markers (`= categories/(Wrapper)` with `Value = (Value)`), which does not parse | Mendix models it as a **Wrapper** element binding one entity per item, with the primitive on a value child at the `(Value)` marker; 34 of the 327 demo-app documents contain one. Two independent causes: mxcli's **JSON structure builder** wrote the wrong PATHS for a primitive array — wrapper at `…\|tags\|(Object)`, value at `…\|(Object)\|` with a trailing empty segment — so nothing could resolve against it; and the mapping builders stepped from an array to a hardcoded `\|(Object)` | `mdl/types/json_utils.go` (`buildElementFromRawArray`), `mdl/executor/mapping_customhandler.go` (`arrayItemOf`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`, and `elementTypeForKind` / `isMappingObjectKind` in all four writers | **No new syntax**: an array of primitives is written like any other array and the wrapper level is GENERATED, the same way the item level is (#248, #262). Step from an array to its **actual** child rather than a hardcoded marker — `\|(Object)` for objects, `\|(Wrapper)` for primitives — which is what `arrayItemOf` is for. **"Wrapper" is an OBJECT element kind**: both writers dispatched on `Kind == "Object" \|\| Kind == "Array"`, so it serialized as a Value with no attribute and mxbuild reported **CE5015** "Element '(Object)/tags/(Wrapper)' is not a Value element" — the same trap on the DESCRIBE side, where the export printer's object branch was missing both `Wrapper` AND `Array`, printing `texts = ` and dropping the subtree. Fix the structure builder FIRST: the mapping is unreachable until the markers exist, and the two look like one bug. `(Value)` is a marker, not a member name — DESCRIBE prints the element's ExposedName (`Value`), which is what re-executing resolves against. Repro `mdl-examples/bug-tests/mapping-268-primitive-array-wrapper.mdl`, tests `mdl/executor/mapping_wrapper_test.go`. Issue ako/mxcli#268 |
-| A `find` mapping element always behaves as **find-or-create** whatever the document said, and `describe` cannot show the difference — a Studio Pro mapping that said "error out" comes back saying "create silently" | Mendix stores **two** properties on an object mapping element, not one: `ObjectHandling` {Parameter, Create, Find, Custom} and `ObjectHandlingBackup` {Create, Error, Ignore} (plus the bool `ObjectHandlingBackupAllowOverride`). mxcli only ever wrote the first and hardcoded the backup, so the runtime behaviour was mxcli's choice rather than the author's. Measured: rebuilding the shipped `Email_Connector.IMM_EmailTemplateMapping` flipped **7 elements from 'Error' to 'Create'**, with mxbuild reporting 0 errors on both — the documents are equally valid, they just do different things | `mdl/grammar/MDLLexer.g4` (`IGNORE`, `OVERRIDABLE`) + `mdl/grammar/domains/MDLDomainModel.g4` (`mappingHandlingBackup`) + `MDLSettings.g4` (keyword rule), `mdl/visitor/visitor_import_export_mapping.go` (`applyMappingHandlingBackup`), `mdl/executor/cmd_import_mappings.go` + `mapping_messagedefinition.go`, `mdl/backend/modelsdk/mapping_write.go` (`importBackupFor`) + `mapping_read.go`, `sdk/mpr/writer_import_mapping.go` + `parser_import_mapping.go`, `modelsdk/mpr/serialize_mappings.go` | `find M.E or create\|error\|ignore [overridable]`, with `find or create M.E` kept as the older spelling of the first. **A bare `find` is refused** — silently picking one of three runtime behaviours is the bug, so the executor names all three in the error rather than defaulting. Backups that are NOT the author's to choose: `create` and custom (`by`) handling keep 'Create', because "Custom" is not a member of the backup enum; **export** elements are always 'Error' (there is nothing to find), which is what Studio Pro writes. Two places the fix has to reach that a JSON-path test does not exercise: the **message-definition** builder (`mapping_messagedefinition.go`) has its own element construction, and it was the last 7 of the 8 fixture differences — a direct nested JSON test passed while the real document still regressed, so **diff the fixture, not a synthetic case**. The eighth was unrelated and adjacent: `xmlPrimitiveTypeName` fell through `Binary` to "String". Remember a `find` also needs a KEY (`Attr = member key`) or mxbuild reports **CE0250** "Object element must have a key defined if object handling is set to 'Search for an object'." — pre-existing, but every repro of this fix trips it. Repro `mdl-examples/bug-tests/mapping-261-object-handling-backup.mdl`. Issue ako/mxcli#261 |
-| An import mapping cannot declare its INPUT OBJECT, so a custom handler's `Param: parameter` refers to something that cannot exist, and `describe` of a real one drops the declaration while still emitting the handler that uses it | Mendix stores it as `ParameterType`, a `DataTypes$ObjectType` naming the entity. Measured across the demo apps: 10 of 327 mappings declare one (GenAICommons.ChunkCollection in eight), 190 import mappings store the `DataTypes$UnknownType` marker, and an EXPORT mapping carries no `ParameterType` property at all (0 of 127) — its parameter IS its root object, so there is no export spelling. All three writers hardcoded the UnknownType variant | `mdl/grammar/domains/MDLDomainModel.g4` (`importMappingParameterClause`), `mdl/visitor/visitor_import_export_mapping.go`, `mdl/executor/mapping_customhandler.go` (`resolveMappingParameter`, `requireDeclaredParameter`) + `cmd_import_mappings.go`, `mdl/backend/modelsdk/mapping_write.go` + `mapping_read.go` (`parameterEntityFromRaw`), `sdk/mpr/writer_import_mapping.go` + `parser_import_mapping.go`, `modelsdk/mpr/serialize_mappings.go` | `parameter Module.Entity` on the header, after the schema source. gen models **no** `ParameterType` property at all, so the modelsdk read goes to raw BSON — the route `customHandlerFromRaw` takes. **The legacy parser unmarshals a unit into `map[string]any`, so a nested sub-document arrives as `map[string]any`, NOT `bson.D`**: asserting `bson.D` compiles, always fails, and leaves DESCRIBE silently dropping the clause on the legacy engine only — caught solely by running the same assertions on both backends, so write that test. Two refusals, each with the guard stubbed and measured on mxbuild 11.13: `Param: parameter` with nothing declared is **CE0279** "Parameter is used in object handling microflow while the mapping does not specify one", and an unknown entity is refused by name. **Deliberately NOT guarded**: a parameter whose entity does not match the microflow's parameter type — mxbuild reports **CE0282** naming both types, and duplicating it in mxcli would need a generalisation-aware walk that could refuse valid specialisations. Check the whole thing over the BUILT model in `finishImportMapping`, not the AST, so the JSON-structure and message-definition builders are covered at once. Repro `mdl-examples/bug-tests/mapping-265-mapping-input-parameter.mdl`, tests `mdl/executor/mapping_parameter_test.go`. Issue ako/mxcli#265 |
-| 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 |
-| A multi-segment member in an **inline REST** mapping (`"Title" = "fields/Title"` inside `Response:`/`Body: MAPPING`) passes every gate — `mxcli check`, `exec`, `mx check`, `describe` — and the column is **empty at runtime** | The inline REST serializer is a SEPARATE code path from the mapping documents, and it appended the member text verbatim: `jsonPath + "\|" + m.ExposedName` stores `(Object)\|fields/Title`, one member whose NAME contains a slash, where Mendix stores `(Object)\|fields\|Title`. Nothing converted `/` to `\|` on this path. Confirmed against four Studio Pro-authored inline response mappings in the demo apps, which all store full pipe paths (`(Object)\|results\|bindings\|(Object)\|caseId\|value`) | `model/mapping_paths.go` (`InlineMappingPath`, `InlineMappingExposedName`), `sdk/mpr/writer_rest.go` (`serializeInlineMappingElement`), `mdl/backend/modelsdk/consumed_rest_write.go` (`restInlineMappingElementToGen`), `mdl/executor/cmd_rest_clients.go` (`inlineMemberName`) | **The document fixes do not reach this.** The mapping census (`PROPOSAL_mapping_coverage.md`) classifies mapping DOCUMENTS only and does not mention the inline form, so none of #248/#262–#268 improved it as a side effect — a reader who sees multi-segment paths documented as working will reasonably try one here. Store the pipe path and put the **last segment** in `ExposedName` (Studio Pro's own derivation uniquifies against siblings — `caseId\|value` becomes `CaseId_Value` but `graphData\|value` in the same document becomes plain `Value` — so it is not reproducible from the path and does not need to be; ExposedName is a label, JsonPath is what binds). **Fixing the path breaks DESCRIBE in the same motion**: the printer emitted `ExposedName`, which now holds only the last segment, so it produced `"Title" = "Title"` — output that parses, re-executes and binds the wrong member. Derive the member from the stored JsonPath relative to the enclosing element and drop the generated `(Object)`/`(Array)`/`(Wrapper)` markers. Both engines have their own copy of this serializer; patch both or they drift. Repro `mdl-examples/bug-tests/rest-inline-mapping-paths.mdl`, tests `sdk/mpr/writer_rest_inline_mapping_test.go`. mxcli-rest FINDINGS #36 |
-| A nested `Body: MAPPING` on a consumed REST operation makes the project **impossible to open** — mxbuild throws `System.AggregateException … (Export Object Mappings cannot have ObjectHandling set to 'Create')` instead of reporting an error | The inline serializer passed the literal `"Create"` for every nested child regardless of namespace, so an EXPORT object element got an illegal handling. This is not a check error: it is thrown while **loading** the model, before any check runs, so `mx check` cannot even reach the project — and `mxcli check` and `exec` both accept it | `sdk/mpr/writer_rest.go` + `mdl/backend/modelsdk/consumed_rest_write.go` (`nestedInlineHandling`, `nestedInlineBackup`) | Nested export elements are `Find` with backup `Error`, which is what Studio Pro stores on an export mapping DOCUMENT — there is no inline export body anywhere in the demo corpus to pin against (**0** `Rest$ImplicitMappingBody` across 9 packages), so the document form is the reference and mxbuild loading the project is the control. Keep a control test for the IMPORT direction in the same file: nested import elements legitimately stay `Create`, and a fix that flips both is wrong. Note the asymmetry when reproducing: a build error you can see is a *better* failure than this one — always confirm the project LOADS, not just that the check is green. Repro `mdl-examples/bug-tests/rest-inline-mapping-paths.mdl`, test `TestInlineExportBodyNestedHandling`. mxcli-rest FINDINGS #37 |
-| A microflow calling a consumed REST operation with a path parameter (`send rest request Mod.RC.Op with ($id = …)`) makes the project **impossible to open** — mxbuild aborts with `The type cache does not contain a type with qualified name Microflows$ParameterMapping` from `StreamingBsonUnitReader` | Both writers hardcoded `Microflows$ParameterMapping` as the `$Type` of each entry in `Microflows$RestOperationCallAction.ParameterMappings`. **No such Mendix type exists.** `generated/metamodel` is the arbiter — `MicroflowsRestOperationCallAction.ParameterMappings` is `[]*MicroflowsRestOperationParameterMapping` — so the storage name is `Microflows$RestOperationParameterMapping`. The sibling `QueryParameterMappings` was already correct, which is why only path parameters trip it | `sdk/mpr/writer_microflow_actions.go` (`serializeRestOperationCallAction`), `mdl/backend/modelsdk/microflow_rest_write.go` (`restOperationCallActionToGen` **and** its `codec.RegisterListMarker`) | A STORAGE-NAME OVERRIDE in the `$Type` sense, and the most dangerous shape of it: the failure is at **load**, before any check, so `mx check` never reaches the model and reports the exception instead of an error list — and `mxcli check` and `exec` both accept it happily. **Patch the list-marker registration as well as the `newElem`**, or the codec decodes under the old name. Found only by trying to BOOT an app (`run --local`), not by any static gate — the same lesson as the inline-mapping paths above: when a construct's symptom is "the runtime does the wrong thing", the runtime is the only honest test. Repro: any microflow with `send rest request … with (…)`; covered by `mdl-examples/bug-tests/rest-inline-mapping-paths.mdl`'s companion runtime probe. Reported indirectly via mxcli-rest FINDINGS #36's repro |
-| The nightly is green on recent Mendix versions and fails on older ones with `<mapping> now round-trips faithfully — remove it from knownLossy` | `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 | `mdl/executor/mapping_fixture_roundtrip_test.go` (`knownLossyFrom`, and the base-project log line in `loadMappingFixture`) | 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 |
-| A JavaScript action with a parameter throws `<Param> is not defined` the first time a user clicks it. `mx check` reports 0 errors, `mxcli check` says nothing, the build is clean, and the generated file cannot be patched — it is rewritten on every build | mxbuild **lowers the first letter** of a parameter when it generates the wrapper: `Skin: String` reaches the body as `skin`. A body written with the modelled spelling is a ReferenceError, and nothing between MDL and the click can see it — Mendix treats the body as opaque user code | `cmd/mxcli/theme/switcher.go` (both parameterised actions); the same rule applies to any `create javascript action` with parameters | **Model the parameter capitalised, read it lowercased.** Verified against a real 11.13 build (`export async function SetAppSkin(skin)`) and in a browser by importing the generated module and calling it — `ReferenceError: Skin is not defined` before, the correct return after. The guard walks *every* parameter of *every* generated action, so a new one cannot reintroduce it. Note the trap in writing that guard: a regex anchored on `javascript action` also matches `call javascript action` in the nanoflows, which made the first version run past a real declaration and pass against the very defect it was written for — anchor on `create or modify javascript action` and assert the match count. ako/mxcli-ledger #135 |
-| `mxcli theme create` lists `theme/web/custom-variables.scss` and `theme/web/main.scss` as `created`, on a project that has hand-written versions of both. Nothing was touched | The reported paths were relative to the scaffold, not to the project, so they collided exactly with the app paths — printed by the one command whose whole purpose is to write into `theme/` | `cmd/mxcli/theme/create.go` (`CreateResult.Files` carries scaffold-root-relative paths), `cmd/mxcli/cmd_theme.go` (prints them under the scaffold root) | **A path in output is a claim about a location.** Two files in different trees sharing a relative path means the output has to carry the root or it asserts the wrong one. `theme.json` sits at the scaffold root and everything else under `files/`, so the result carries that distinction rather than the printer re-deriving it. ako/mxcli-ledger #139 |
-| `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 | `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 | `mdl/executor/cmd_pages_describe.go` (`getLayoutWidgetsFromRaw`), `mdl/executor/cmd_pages_describe_parse.go` (`scrollContainerRegions`) | **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 |
-| Every layout reports `Layout Type: Responsive` — including the Phone, Tablet, ModalPopup and native ones, 19 of the 22 Atlas ships | Two faults compounding. `LayoutType` is **not on `Forms$Layout`**; it is on the content wrapper. `modelsdk/gen` nonetheless exposes `Layout.LayoutType()`, bound to a key the document does not carry, so it reads `""` — a phantom property, not a wrong key, which is why `keyaudit_test.go` does not list it. `DESCRIBE LAYOUT` then defaulted `""` to `"Responsive"`, rendering a failed read as a fact | `mdl/backend/modelsdk/page.go` (`layoutTypeOf` reads the wrapper), `mdl/executor/cmd_pages_describe.go` (no fallback) | **Never default a value every real document carries** — an empty one means the read failed, and a plausible default is what hides it. `generated/metamodel` was right about the location all along (property of `PagesWebLayoutContent`/`PagesNativeLayoutContent`), so the arbiter rule held; what no source got right was the *value set*, six values splitting by platform (web: Responsive/Phone/Tablet/ModalPopup, native: Default/Popup) against two declared in gen and in the metamodel enum. Measured across all 22 |
-| A layout mxcli wrote builds cleanly (`mx check`: 0 errors) but Studio Pro refuses to open the project: `System.InvalidOperationException: Sequence contains no matching element` at `MprProperty.cs` | The layout carried `MainPlaceholderName`. `modelsdk/gen` declares it on `Layout` so the setter compiles, and mxbuild tolerates unknown properties — but `generated/metamodel`'s `PagesLayout` declares only eight properties and none of the 22 layouts Atlas ships on 11.13.0 carries the key. Studio Pro resolves every stored property against the type's list | `mdl/backend/modelsdk/layout_write.go` (`layoutToGen`), `mdl/executor/cmd_pages_layout_v3.go` (the header refuses any property but `layouttype`) | **A `Forms$Layout` has exactly ten keys** — `$ID`, `$Type`, `Appearance`, `CanvasHeight`, `CanvasWidth`, `Content`, `Documentation`, `Excluded`, `ExportLevel`, `Name` — measured identical across all 22. Which placeholder is "main" is a *naming convention*: every Atlas layout names one `Main`, and a page binds to a placeholder by qualified name anyway, so the document has nothing to say. gen's whole placeholder family (`MainPlaceholder`, `AcceptButtonPlaceholder`, `UseMainPlaceholderForPopups`, …) is phantom here. `mx check` is not the control for this class — the key set is. Pinned by `TestLayoutToGen_WritesExactlyTheKeysStudioProWrites` |
-| `ALTER PAGE … SET Layout` / `ALTER LAYOUT` cannot find any widget in a layout — "widget X not found" for a widget DESCRIBE LAYOUT clearly shows | Two finder gaps compounding. `findBsonWidget` starts from the page's `FormCall`, which a `Forms$Layout` does not have (its tree hangs off `Content`), so every widget in every layout was unreachable; and `findInWidgetChildren` never descended into a `ScrollContainer`'s five named slots, so a layout's topbar (`Top`) and navigation (`Left`) were out of reach even once the root was found — as was anything inside a scroll container a *page* places | `mdl/backend/pagemutator/mutator.go` (`findBsonWidgetInLayout`, region descent in `findInWidgetChildren`), `mdl/backend/pagemutator/scrollregion.go` | **A region is addressed by slot, not by name** — it has no `Name`, so `INSERT INTO layoutContainer.top` reuses the dotted widgetRef that also serves DataGrid2 columns, and which one it means is decided by the named widget's `$Type`. Only `INSERT INTO` takes a region: BEFORE/AFTER position a widget among siblings, and silently treating them as INTO would put widgets somewhere the script did not ask for. The MDL slot name is `center`; the stored key is `CenterRegion`. Controlled by emptying the slot list and by respelling the centre key |
-| 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 | 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 | `mdl/executor/cmd_pages_repoint.go` (`checkRepointPlaceholdersAgainst`), `mdl/backend/layoutplaceholders.go`, `mdl/backend/pagemutator/mutator.go` (`BoundPlaceholders`) | **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 |
-| A layout mxcli wrote renders with **no topbar bar and no sidebar rail** — the widgets are all there and in the right regions, but unstyled. `mx check` is 0 errors and the BSON looks right | The layout's own `Forms$Appearance.Class` was empty. Atlas scopes **24** of its layout rules to `.layout-atlas` and its variants, and every Atlas layout with chrome carries one (`layout-atlas layout-atlas-responsive-topbar`, `…-responsive-default`; only `PopupLayout` is bare). `CREATE LAYOUT` had no `class:` property at all, so every layout it wrote was unstyled | `sdk/pages/pages.go` (`Layout.Class`/`Style`), `mdl/backend/modelsdk/layout_write.go`, `mdl/executor/cmd_pages_layout_v3.go` (header property), `mdl/backend/modelsdk/page.go` (`appearanceClassOf`, so DESCRIBE round-trips it) | **A CSS class on a layout is API, not decoration** — it is how the design system's rules find the layout at all. No check mxcli or mxbuild has can see this: the document is valid, the build is clean, and the difference is only visible in a browser next to the layout being replaced. That comparison *is* the test (`.claude/skills/verify-in-runtime.md`). The same reasoning applies to the flex design properties on `topbar-content`: Atlas sets the flex direction as a design property rather than in the class, so a container without them stacks its children in the corner |
-| A JSON payload with a member named `owner`, `class`, `int`, `changedDate` or any other Java keyword makes `create json structure` produce a project mxbuild REFUSES to build: **CE9524** "JSON element '(Object)/owner' has an invalid custom name 'Owner'. Custom name should start with a letter or underscore followed by either letters, digits or underscores." | `resolveExposedName` prefixes an underscore for names Mendix reserves — Studio Pro's own scheme, keeping the key's ORIGINAL case (`_id`, `_object` in OpenAI_API.JSON_OpenAI_Response) — but the list held only `{Id, Type}`. Every other reserved name went through capitalised and was rejected at build time, with nothing before that warning: `mxcli check` passes and `exec` succeeds | `mdl/types/json_utils.go` (`reservedExposedNames`, `resolveExposedName`) | **Do not trust the CE message to name its own rule** — 'Owner' matches the character pattern it quotes perfectly. Probe instead: one structure per candidate name, one `mx check`, read the rejected list off the output. Measured on mxbuild 11.13: **53 Java keywords and literals**, the four system attribute names (Owner/ChangedDate/CreatedDate/ChangedBy), plus CurrentUser and Guid. It is **not** the entity-member reserved list — `Type` and `Id` are ACCEPTED here (they stay in the map only because Studio Pro avoids them, which is why the list is "what Studio Pro avoids", a superset of "what mxbuild rejects"). Match **case-insensitively**: Mendix's check is, since `class` derives `Class`, which is not literally a keyword and is still rejected. The author cannot rename a member of an external payload, so deriving a valid name is the only fix — refusing at check time would make the construct unusable. A customNameMap entry still wins, so a structure read back from a project keeps the name it already carries. Repro: `create json structure X snippet '{"owner": "o"}'`, then `mx check`. Tests `mdl/types/json_exposed_name_test.go`. Issue ako/mxcli#300 |
-| A JSON payload with a member named `owner`, `changedDate`, `createdDate` or `changedBy` produces a project mxbuild refuses to build: **CE9524** "JSON element '(Object)/owner' has an invalid custom name 'Owner'. Custom name should start with a letter or underscore followed by either letters, digits or underscores." | `create json structure` derives an ExposedName for every element (Studio Pro does too — 0 of 211 fixture elements have an empty one), and the derivation capitalises the initial. For a member Mendix reserves as a system attribute the derived name collides and Mendix rejects it. **The message is a red herring**: 'Owner' matches the character pattern it quotes perfectly; the real rule is the system-name collision. Isolated with a three-structure probe — `owner` and `changedDate` fail, `holder` passes | the JSON structure builder in `mdl/types/json_utils.go`; the reserved list already exists as `mendixSystemAttributeNames` in `mdl/executor/cmd_enumerations.go` | `owner` is an ordinary member name in real REST payloads, so this is reachable from a plain `create json structure ... snippet`. Do not trust CE-message wording to name its own trigger — probe it: three one-line structures separated the system-name collision from the character pattern in one mx check. Found while building a runtime test app, not by any unit test. Filed separately |
-| A test written with a bare `@throws` fails on the very exception it was written to expect, reporting "exception during execution" and "no assertions" | `mxcli test` treats a test as a throws-test only when the annotation carries a NON-EMPTY message (`generator_endpoint.go`, `if tc.Throws != ""`), so a bare `@throws` is silently ignored and the exception propagates as a failure. The message itself is **never compared** — `@throws 'ZZZ-NOT-THE-REAL-MESSAGE'` passes against any error — so it documents intent rather than asserting it | `cmd/mxcli/testrunner/generator_endpoint.go` (`writeThrowsFlowBody`, `rewriteBodyForThrows`) | Write `@throws '<description>'` and give the test its meaning with a CONTROL — the same call with input that must NOT throw — because the annotation alone only proves something was raised, not what. Two separate defects to fix: a bare `@throws` should be a parse error rather than silently dropped, and the message should either be matched or documented as unmatched (the annotations reference shows `@throws 'validation failed'`, which reads as a match). Found while asserting #261's `or error` at run time |
-| 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 | 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 | `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)`) | **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 |
-| 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 | 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 | `mdl/executor/cmd_pages_create_v3.go` (`execCreateSnippetV3`); the correct pattern is 40 lines above it in `execCreatePageV3` | **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 |
-| `mxcli run --local` on a Mendix 11.14 app dies at `bundling web client: no rollup.config.mjs in …/deployment/web (run a serve Deploy build first)` — and a serve Deploy build HAS just run | 11.14 bundles the browser client itself. `BuildWebClient` exists to close a gap that 11.13 and earlier left (client source + a rollup config, but no bundler run), and its gate tested for the CONFIG, so it failed on the absence of a file whose purpose had been served. Measured on a blank app, same build target: 11.13 `rollup.config.mjs` PRESENT / `dist/index.js` ABSENT; 11.14 exactly inverted | `cmd/mxcli/docker/webclient.go` (`BuildWebClient`), called fatally at `runlocal.go:664` and `:1091` | **Gate a compatibility step on the GAP it closes, not on the shape one version happened to leave behind.** Skip when `WebClientBundled(deployDir)` is already true; keep requiring the config when it is not, because then rollup is the only thing that can produce a bundle. Do NOT make it an unconditional no-op when `dist/` exists — `runlocal.go:1091` re-bundles when the file is present but not SERVED, and a blanket skip would break that recovery. The doc comment called it "no-op-safe" and it was not; it is now. Affects EVERY 11.14 app, so a version-gated workaround is wrong — the condition is about the bundle, not the version. ako/mxcli-ledger #146 |
-| No export mapping mxcli writes matches its Studio Pro original, so every one stays in #260's silent-loss set even once its source kind is authorable | The export writers hardcoded three properties the IMPORT twin already read off the element: `MinOccurs 0` (a schema root has **1**), `MaxLength 0`, and `IsKey` not written at all. `MaxLength` is the one that cannot be a constant — Studio Pro stores **0 for a string element and -1 for a numeric one**, mirroring the bound schema element exactly as `MaxOccurs` already did | `mdl/backend/modelsdk/mapping_write.go` (`exportValueElementToGen`, `exportObjectElementToGen`) + `mapping_read.go`, `sdk/mpr/writer_export_mapping.go`, `modelsdk/mpr/serialize_mappings.go`, `mdl/executor/cmd_export_mappings.go`, `model.ExportMappingElement` | The export element model had **none** of these fields and the reader populated none of them, so this is four layers (model, reader, builder, three writers), not a writer patch — and a writer patch alone would have written zeros from an empty model. Clone them from the schema element where the builder already clones `MaxOccurs`. Check the import twin first when an export property looks wrong: this was a divergence between the two writers, not a considered decision, and the import side is the correct reference. Repro `mdl-examples/bug-tests/mapping-277-export-property-set.mdl`, tests `sdk/mpr/writer_export_mapping_properties_test.go`. Issue ako/mxcli#277 |
-| A rebuilt mapping drops `MessageDefinition2`, so a document written by Studio Pro 11.10+ never round-trips | The key is version-introduced — `modelsdk/gen/mappings/version.go` records `messageDefinition2` as `Introduced: "11.10.0"` — and gen generates **no accessor** for it, so nothing read or wrote it. A blank 11.13 app's own mappings carry it as `""`; none of the older pinned fixtures has it at all | `model.ImportMapping`/`ExportMapping` (`MessageDefinition2 *string`), `mdl/backend/modelsdk/mapping_read.go` (`messageDefinition2FromRaw`) + `mapping_write.go`, `sdk/mpr/parser_*_mapping.go` + `writer_*_mapping.go`, `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go` | **Carry it, do not derive it.** A pointer, because nil (absent) is NOT the same as present-and-empty — writing the key onto a pre-11.10 document is the overlay-rule mistake CLAUDE.md warns about, which mxbuild tolerates and Studio Pro refuses to open. The executor decides: carry `existing.MessageDefinition2` on an update, apply the version gate only on a CREATE where there is nothing to read it off. A plain version gate in the writer looks equivalent and is not — it re-adds the key to every older document a rewrite touches, which turned four previously-clean fixtures red. gen having no accessor means the read goes to raw BSON, the route `parameterEntityFromRaw` takes. **`MappingSourceReference` is the same family and deliberately NOT carried**: its gate (10.16) predates every project in the field, and the codec emits it through a package-level `TypeDefaults` registration, so making it conditional would touch every mapping write to preserve one pre-10.16 fixture. Issue ako/mxcli#279 |
-| `describe {import,export} mapping` emits MDL its own grammar rejects, or — worse — MDL that parses and rebuilds a DIFFERENT mapping (measured: 132 of 327 did not parse, 112 parsed and were unfaithful) | Four independent describer/grammar defects. (1) An OBJECT element could not take a nested member path (`= meta/pagination`); #927 gave that to VALUE elements only. (2) An Array or Wrapper printed as an EMPTY value binding with its whole subtree DROPPED, because the printer branched on `Kind == "Object"` alone — the export half was fixed under #268, the import half was not. (3) `create ./Entity = x` and `create . = x` for association-less and entity-less object elements, neither ever accepted. (4) Members MDL cannot spell bare — `$type` (43 occurrences), `research%3Aread`, `https%3A//…` — emitted raw | `mdl/grammar/domains/MDLDomainModel.g4` (`importMappingChild`, `exportMappingChild`), `mdl/visitor/visitor_import_export_mapping.go`, `mdl/executor/cmd_import_mappings.go` (`resolvePathKind`, `mappingMemberName`, `quoteMemberPath`, the two-level array branch) + `cmd_export_mappings.go` | **An object path may step THROUGH an array where a value may not**: one object per item is legal, while a value pulled through many items is CE0256 — so the occurrence guard is keyed on `def.Entity != ""`, not applied to everything. Intermediate `(Object)`/`(Wrapper)` markers are dropped when printing and stepped through when resolving; they are generated levels, never written. The **two-level import array** (container and item each carrying their own entity and association) is detected the same way #262 detects it on export — an array whose single child is an object element — and the item is built BY HAND, because putting it through the generic builder tries to resolve the marker as a member. Building it by hand means remembering everything the generic path does: the first attempt dropped the item's own custom handler and its CE0281 value elements. **Item 4 needed no grammar at all** — `identifierOrKeyword` already accepts a quoted identifier, so only the describer had to quote; check what the grammar already allows before extending it. The entity-less IMPORT container was deliberately NOT given syntax: 0 of 12 pinned documents have one in either direction, and inventing a spelling whose stored shape cannot be checked against a real document is how a mapping ends up valid to mxbuild and unopenable in Studio Pro — DESCRIBE emits a comment naming it instead. **Alternative ORDER matters in the export rule**: `group` is a keyword `qualifiedName` accepts, so the bare-entity alternative placed before `GROUP AS` swallows `group as x` and stores an entity called "Module.group" — caught by TestExportGroupElement, not by any parse error. Repro `mdl-examples/bug-tests/mapping-260-describe-roundtrip.mdl`. Issue ako/mxcli#260 |
-| `mxcli check -p app.mpr` reports `Unexpected token after expression — … (possible missing space between keywords)` with **no rule id, no file and no line**, on an expression containing a doubled apostrophe. Nothing is glued and no keyword is involved. `exec`, `DESCRIBE` and `mx check` all accept it | `''` is how the Mendix expression language escapes an apostrophe inside a string literal (CLAUDE.md states the rule), but exprcheck's lexer scanned to the next `'` with no notion of an escape — so `'a''b'` lexed as TWO strings, `parseOr` consumed the first, and the second was reported as a leftover token | `mdl/exprcheck/lexer.go` (the `case c == '\''` arm); the leftover report is `mdl/exprcheck/parser.go` | Consume a **doubled** quote as part of the literal; a single one ends it. Keep the unterminated case emitting `TokError` — a lexer that just swallows to end-of-input passes every escape test while accepting a broken literal, so assert that control at the lexer. **It only reproduces WITH `-p`**: exprcheck runs when a project is supplied and `make check-mdl` runs without one, which is why this repo's own MDL gate never saw it across six of the reporter's builds — an `mdl-examples/` script alone would NOT have caught it. The message is a red herring by construction: the leftover reporter cannot know why a token is left over, so any lexer gap surfaces as "glued keywords". ako/mxcli-ledger #131 |
-| A project made by `mxcli new --version 11.14` fails its very first build with `error: release version 25 not supported`, and installing a JDK 25 moves the failure to boot (`UnsupportedClassVersionError … class file version 69.0`) | Mendix 11.14's `mx create-project` writes `JavaVersion = 25`, but mxcli builds and launches the runtime on **JDK 21** and validates it (`resolveJDK21` refuses any other `JAVA_HOME`). Compiling for 25 and running on 21 cannot work in either direction — and 11.14's own runtime bundles are still Java 21 class files (major version 65) | `cmd/mxcli/cmd_new_java.go` (`alignJavaVersion`, `runtimeMaxJavaVersion`), called from `cmd_new.go` **before** the first build; the launcher side is `cmd/mxcli/docker/detect.go` (`resolveJDK21`) | **Lower the project, do not raise the JDK.** Set `JavaVersion` to what the runtime launcher actually uses, and only when the project asks for MORE — so it is a no-op on 11.13 and disappears by itself when the launcher becomes version-aware. Order matters: align BEFORE `SettleGeneratedSources`, or that build is the thing that fails. Mendix then warns "Java versions below 25 are deprecated", which is a deprecation on a project that builds rather than an error on one that does not. An unparseable version is left alone rather than overwritten. `runtimeMaxJavaVersion` and `resolveJDK21` must move together — there is a test asserting it. ako/mxcli-maintenance #1, #3 |
-| A JSON member with any character outside `[A-Za-z0-9_]` — `$type` (43 occurrences in the demo apps), `research%3Aread`, `https%3A//…` — makes `create json structure` produce a project mxbuild refuses to build (**CE9524**); and the structure root carries `MinOccurs 0` where Studio Pro writes `1` | `resolveExposedName` only CAPITALISED the member name, never sanitised it, so an invalid character reached the stored ExposedName. Separately `rootMinOccurs` was pinned to 0 with a documented reason: writing 1 used to make every mapping bound to the structure fail **CE5015** "Attribute 'MinOccurs' does not match schema element" because the mapping serializers hardcoded 0 | `mdl/types/json_utils.go` (`sanitizeExposedName`, `resolveExposedName`, `rootMinOccurs`) | **The MinOccurs blocker was removed by a different fix**: #277/#279 made every mapping element mirror the bound schema element, so both sides now agree and the root can carry the 1 — check whether a documented "cannot change this" still holds before accepting it, because the constraint may have been fixed elsewhere. Do not revert one without the other; they are cross-validated and CE5015 is what disagreement looks like. The sanitising rule is Studio Pro's, read off CRS_ModelSimulator: every character outside `[A-Za-z0-9_]` becomes `_`, then the initial is capitalised (`confidence(No)` → `Confidence_No_`, `first(Importance)_Payload (kg)` → `First_Importance__Payload__kg_`); a LEADING DIGIT is prefixed rather than replaced, since the name must start with a letter or underscore and `1st` → `_st` would lose a character. Unlike the reserved-name case (#300), CE9524's message is accurate here. **The array-item naming in the same issue was NOT reproduced, deliberately**: Studio Pro produces both real singularisation (`Data`→`Datum`, `Categories`→`Category`) and a flat `JsonObject`/`JsonObject_2` across the nine pinned structures, and it is not a collision fallback — nothing named `Embedding` exists in the structure whose item is `JsonObject`. There is no single rule to copy, so picking one would match some real documents and break others. Repro `mdl-examples/bug-tests/mapping-272-json-structure-metadata.mdl`, tests `mdl/types/json_exposed_name_test.go`. Issue ako/mxcli#272 |
-| A Mendix 11.14 project will not build (`error: release version 25 not supported`) or, if built elsewhere, will not boot (`UnsupportedClassVersionError … class file version 69.0`) | mxcli resolved a JDK **21 unconditionally** and refused any other `JAVA_HOME`. Studio Pro 11.14 supports Java 25 and its blank app asks for it, so the Java release is now a per-project variable (Settings > Model > JavaVersion) rather than a constant | `cmd/mxcli/docker/javaversion.go` (`ProjectJavaMajor`, `ParseJavaMajor`), `cmd/mxcli/docker/detect.go` (`resolveJDK`, `isJDK`, `jdkSearchPathsFor`); the four call sites are `build.go`, `settle.go`, `mxserve.go`, `localboot.go` | **Resolve the JDK from the project, not a constant** — and use the SAME major for the build and the runtime, because class files from a newer release cannot be loaded by an older JVM. Two traps. (1) The version glob is matched against `java -version` text, so the major must be followed by a dot, whitespace or the closing quote — a bare `21` also matches `210`; there is a test. (2) Zero must mean the default, or every options struct that forgets the field silently changes behaviour. The control worth running: boot a Java **21** project with `JAVA_HOME` pointing at a JDK **25** — it must ignore it and find the 21, and `ps` per-process is the only reliable way to check, since a stale JVM from an earlier run will fool `ps | head -1`. ako/mxcli-maintenance #1 |
-| 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 | 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} | `mdl/executor/mapping_customhandler.go` (`resolveJsonStructureSource`, `canonicalNullValueOption`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go` | **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 |
-| After ako/mxcli#260, ten of the 327 demo-app mappings still describe into MDL that does not parse — an export root printed as `. {`, and a custom-handler parameter printed as `Suggestion: (Value)` | Two leftovers of the same families. (1) `group as` covers a nested entity-less node (#262) but a ROOT has no member name, so it had no spelling at all. (2) `customHandlerParamText` rendered the stored value path raw, so an array-of-primitives parameter leaked Mendix's `(Wrapper)`/`(Value)` markers | `mdl/grammar/domains/MDLDomainModel.g4` (`exportMappingRootElement`), `mdl/executor/cmd_export_mappings.go` (the entity-less-root branch, and the association-less handling), `mdl/executor/mapping_customhandler.go` (`customHandlerParamText`, `buildCustomHandler`) | **Printing the member is only half of it**: emitting `Value` while the builder concatenates it back as `…|(Wrapper)|Value` gives a path that resolves to nothing, so resolve the parameter path THROUGH the schema index (`resolvePathKind(..., true)`) the way a member reference is resolved. Two things only a real build caught, both invisible to `mxcli check`: an entity-less root fell through to the VALUE branch and produced a project mxbuild cannot LOAD (*"Type ExportValueMappingElement does not contain a constructor with a parameter of type ExportMapping"*), because the builder decides object-vs-value on `def.Entity != ""`; and an element with NO association cannot be `Find` — **CE0224 "No association selected for obtaining objects."** — it is `Parameter`, which is what CapitalConnector.EM_AttachedDataRequest stores on both its elements. Took the corpus from 317/327 parsing to **327/327**. Repro `mdl-examples/bug-tests/mapping-260b-last-parse-failures.mdl` |
-| 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 | 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 | `mdl/executor/validate_offline_paths.go` (`MDL-OFFLINE01`), wired from `validate_program.go` | **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 |
-| `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** | `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 | `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) | **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 |
-| Adding an offline navigation profile makes a build fail with **CE6206** ("Attribute paths with multiple steps cannot be used on pages that are accessible through an offline-based navigation") in pages the statement never mentioned | An offline profile restricts every page it can REACH to at most one association hop. The pages were valid before; creating the profile is what invalidated them, and mxcli writes multi-step paths happily and said nothing | `mdl/offlinepaths/scan.go` (the stored-document scan), `mdl/executor/offline_profile_warning.go` (the report), `mdl/types/navigation_profile_kind.go` (`IsOfflineProfileKind`) | **The threshold is TWO hops, not "any indirect reference"** — one hop is explicitly allowed, pinned by a control inside one page where mxbuild flags column 2 of 2 and accepts column 1. Scan for the stored `DomainModels$AttributeRef` whose `EntityRef.Steps` holds ≥2 steps, keying on `$Type` and not on a table of widget property names — a DataGrid2 column's binding is nested several levels inside a `CustomWidgets$WidgetValue`, so a property-name scan reports a clean project for the widget people actually use. Do NOT match every `IndirectEntityRef`: a data source that navigates an association is a different element and CE6206 does not reject it. Report as a **warning**, never a refusal — reachability needs the whole page graph (home pages, menu items, and every page those open), which mxcli does not walk, and the end-to-end control shows mxbuild at 0 errors while the flagged page is unreachable and CE6206 the moment the profile's home page points at it. ako/mxcli-maintenance |
-| CI's `build-and-test` fails on every open PR with a **compile** error in a `_test.go` file — e.g. `undefined: resolveJDK21` — while `make build`, `make test` and `make lint` are all green locally, and the failing job burns ~30 minutes before reporting it | The file is behind `//go:build integration`. A bare `go vet ./...` and `go test ./...` do not compile it, so a rename can leave it uncompilable and the entire fast gate stays green. The break lands on **main** and every open PR inherits it, which makes it look like N separate PR failures | The stale call site (here `cmd/mxcli/docker/build_integration_test.go`), and the gate that missed it: `Makefile` (`vet`) | **Fix it on a branch off `main`, not in the PRs** — they all inherit it, and fixing it in one leaves the others red. Then close the gap: `make vet` now vets once per build-tag set (`""` and `integration`), which type-checks the tagged files in seconds without needing mx, a JDK or Docker. Grep for stale references with `go vet -tags integration ./...` before renaming anything an integration test touches. Where the renamed symbol became version-aware, do NOT just pass the old constant back in — `resolveJDK(21)` would reinstate exactly the assumption the rename removed; resolve from the project (`ProjectJavaMajor`), which for a skip guard means moving it after the fixture is scaffolded. |
-| A `mxcli test` case written with a bare `@throws` reports **FAIL … exception during execution** — it fails on the very error it was written to expect — and separately, `@throws 'ZZZ-NOT-THE-REAL-MESSAGE'` reports **PASS** | Both generators keyed a throws test on `tc.Throws != ""`, and a bare annotation leaves `Throws` empty — the same value an ABSENT annotation leaves, so the two states were indistinguishable and the bare form was dropped in silence. The message half was decorative: the generated `ON ERROR` handler cleared the pre-set failing verdict for **any** exception, so a stale or simply wrong expectation kept passing against a completely different error. The regexp required the quotes, so an unquoted message matched nothing and removed the `@throws` entirely | `cmd/mxcli/testrunner/parser.go` (`parseThrows`, `TestCase.ExpectsThrow`, `expectsThrow()`), `generator_endpoint.go` (`throwsHandler`), `generator.go` (`throwsFlagHandler`) | **`$latestError/Message` is available inside an `ON ERROR` handler and compiles** — measured at 0 errors on mxbuild 11.6.0 and 11.13.0, with `$noSuchThing/Message` as the control (**CE0109** "Undefined variable"). Match with `contains`, not equality: a real Mendix message carries an activity name or an object id the test cannot predict (`Could not find object of type 'RtMap.Person'`), so equality would make most expectations unwritable. Two fields can say "this is a throws test" and they must not disagree — read them through **one accessor** (`ExpectsThrow || Throws != ""`), or every existing construction site that sets only the message silently becomes a non-throws test. Prove it at RUNTIME, not on the generated MDL: the control (`if want == ""` → `if true`, rebuilt) reproduces both reported symptoms verbatim against `mdl-examples/bug-tests/mapping-runtime-proof.test.mdl` under `run --local --test-endpoint` + `test --attach`. That suite's own `@throws 'the object was not found'` was **wrong and passing** — a fixed matcher turns a wrong expectation red, so expect to correct existing tests. ako/mxcli#301 |
-| An attribute parses in `create entity` but the same name is rejected in a `grant … read (…) / write (…)` list, and mxcli's hint offers three RENAMES (`Title_`, `_Title`, `MyTitle`) — so a stored attribute gets renamed to work around a parser keyword | The hint never mentioned quoting, which is the actual remedy and is right there in the raw ANTLR message's expectation set (`{IDENTIFIER, QUOTED_IDENTIFIER}`). Renaming an attribute that already exists is a schema change; quoting is free and keeps the name | `mdl/visitor/visitor.go` (`reservedKeywordHint`, `hintedKeywordSet`), `mdl/types/reserved_words.go` (`IsPlatformReserved`) | **Two kinds of reserved word, and conflating them is expensive in both directions.** An MDL PARSER keyword is escaped by quoting and the model keeps the name. A name the PLATFORM reserves is not — the check strips the quotes and rejects the bare name (CE7247/MDL021), so advising quoting there produces something that parses and then fails the build. Branch on `types.IsPlatformReserved`. Measured when this was written: **38 of 41** hinted keywords are rescued by quoting, and exactly **3** (`Type`, `Default`, `Owner`) are not — the old blanket-rename advice was wrong for the 38 and right for the 3 by accident. The platform lists moved to `mdl/types` because the validator (`mdl/executor`) and the hinting (`mdl/visitor`) both need them and neither may import the other. Any test asserting the hint recommends quoting needs a **control that the quoted form actually parses**, or it passes against advice that does not work. ako/mxcli-maintenance §5 |
-| `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 | 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 | `mdl/executor/cmd_security_write.go` (`refuseSystemEntityGrant`, called right after `findModule`) | **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 |
-| `mxcli test <dir>` prints `Found 0 test(s) in 1 file(s)` then `no tests found in the provided files`, for a directory that visibly contains a `.mdl` test | Discovery matches on the file NAME (`*.test.mdl` / `*.test.md`), and nothing said so. The `1 file(s)` was the DIRECTORY counted as a path, so it read as though a file had been opened and found wanting | `cmd/mxcli/testrunner/runner.go` (`emptySuiteError`, `parseTestFiles`), `cmd/mxcli/testrunner/parser.go` (`TestSuite.FilesRead`, `ParseTestDir`) | **Count files read, not paths given** — one directory is one path and zero-to-many files. When the suite is empty, name the `.mdl`/`.md` files that were skipped for their name: a `.mdl` in a test directory is almost always the intended test misnamed, so listing it turns a dead end into a rename. Do NOT list unrelated extensions (`.txt`), and on a genuinely empty directory do NOT claim files were skipped — describe the format instead. Both branches have tests, and `FilesRead` has a positive control so it cannot pass by never being incremented. ako/mxcli-maintenance §5 |
-| 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" | 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 | `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 | **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 |
-| `GRANT` on an entity that extends **System.Image** fails the build with **CE1613** "The selected association 'System.Thumbnail_Image' no longer exists" at the access rule — and `describe entity` renders that rule without any broken member, so nothing inside mxcli shows it | The virtual System module carries entities that exist only in the **runtime's** metamodel, not in the System module Studio Pro shows. They arrived with the block marked "extracted from MDP (Phase 3)". `Thumbnail_Image` is owned by BOTH ends, so System.Image counted as an owner through the CHILD side and every specialization inherited an access-rule member for it | `modelsdk/meta/system_module.go` (`RuntimeOnly`, `ModelerSystemEntities`, `ModelerSystemAssociations`), consumed by `mdl/backend/modelsdk/system_module_read.go`; the inheritance walk that reads it is `mdl/executor/cmd_security_write.go` (`inheritedAssociations`) | **The legacy engine is a free control here**: its System list (`sdk/mpr/system_module.go`) never had the MDP block, so the same script under `--engine legacy` writes a clean rule — which pins the defect to the data rather than to the GRANT path reading it. Establish what the modeler actually has by MEASURING, not by reasoning about names: one microflow per candidate retrieving from `System.<Name>`, then one `mx check`. All eleven MDP rows came back CE1613 while the controls (Image, FileDocument, Session) came back clean, so the probe discriminates. Flag rather than delete — the runtime rows were harvested deliberately and a storage backend speaking to the runtime metamodel wants them — and DERIVE the association filter from the entity flag (an association is runtime-only exactly when one of its ends is), because two hand-kept lists drift and the one that falls behind writes a dangling by-name reference. Unrelated pre-existing gap found alongside: `extends <anything>` is never reference-validated, for System or for a same-module name. |
-| `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 | 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 | `mdl/executor/validate_generalization.go` (`validateEntityGeneralization`, `checkGeneralizationQualified`, MDL069), wired from `validate.go` (`CreateEntityStmt` case), `cmd_enumerations.go` (`ValidateEntity`) and `cmd_entities.go` (`execCreateEntity`) | **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. |
-| `DROP ENUMERATION Mod.Name` reports "enumeration not found" for one that `SHOW ENUMERATIONS`, `DESCRIBE ENUMERATION` and `ALTER ENUMERATION` all resolve in the same session | 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 | `mdl/executor/cmd_enumerations.go` (`execDropEnumeration`); the trap was `mdl/executor/helpers.go` (`findModuleByID`, now removed — DROP was its only caller) | 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. |
-| 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 | 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 | `mdl/executor/cmd_microflows_builder_calls.go` (`addValidationFeedbackAction`, `declaringMemberRef`), walking via `mdl/executor/entity_hierarchy.go` (`DeclaringMemberRef`) | 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. |
-| 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 | `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" | `mdl/executor/cmd_pages_builder_v3.go` (`resolveAssociationDestination`, `isSpecializationOf`, `generalizationOf`) | **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". |
-| 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 | 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"` | `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 | **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. |
-| A mapping's `with xml schema Module.NoSuchThing` is accepted by `mxcli check`, by `check --references` AND by `exec`, and the build fails with **CE1613** "The selected XML schema 'X' no longer exists" at the import/export mapping. The JSON twin's fix (ako/mxcli#259 first half) left the same hole at `check -p` | The reference was written to BSON verbatim; nothing listed XML schemas, so nothing could resolve it. The JSON half refused only in the executor's create path, which `check` never reaches — `check --references` runs `validateWithContext`, a different switch | `sdk/mpr/reader_types.go` (`ListXmlSchemas`), `mdl/backend/mapping.go` + `mpr`/`modelsdk`/`mock` impls, `mdl/executor/mapping_customhandler.go` (`resolveXmlSchemaSource`, exec tier), `mdl/executor/validate_mapping_sources.go` (check tier, covers BOTH schema kinds) | **There is no reference document to measure against — 0 of the 9 demo apps in the corpus contains an XML schema, and MDL cannot create one.** PLANT a synthetic unit instead and let mxbuild identify it: a temporary `_test.go` in `sdk/mpr` calling `AddRawUnit(id, moduleID, "Documents", "XmlSchemas$XmlSchema", …)` with `{Name, Documentation, Excluded, ExportLevel, Entries, FilePath}` moved the mapping's error from CE1613 "no longer exists" to **CE0292 "Please import an XSD file." at XML schema 'XGap.Probe_Xsd'** — mxbuild naming, by module and name, the document it had just found. That is the whole proof of both the `$Type` string and the `Name` key, and it agrees with `modelsdk/gen/xmlschemas`'s codec registration and `gen/mappings/refs.go`'s `Target`. **FAIL OPEN on an empty list**: with no `create xml schema` and none in any demo app, an empty list is the ordinary case, so refusing on it would break every XML mapping to catch nothing — and a wrong `$Type` would then degrade to today's behaviour rather than a regression. Match on the **qualified** name; a bare-name match accepts `A.Foo` because `B.Foo` exists, which is the dangling reference all over again. Fix the check tier by adding a validator beside `validateIconRefs` (same class: "MxBuild otherwise reports the typo as CE1613") rather than a `scriptContext` field — a script that creates a structure then maps over it is the commonest shape and must not be flagged. ako/mxcli#259 |
-| Under `run --local --watch`, after roughly ten hot-applies a page dies with the runtime's generic error dialog and `runtime.log` fills with `404 - file not found for file: dist%2Fchunks%2F<hash>.js`. The model is clean, `mx check` is clean, and a plain restart fixes it with no model change | The browser bundle is internally inconsistent: `index.js` imports a content-hashed chunk that is not on disk. `ensureClientServed` probes **only `/dist/index.js`**, which is served with a 200 in this state — so the apply is reported as successful and the fault reads as an application bug | `cmd/mxcli/docker/webclient_chunks.go` (`danglingClientChunks`), called first from `ensureClientServed` in `runlocal.go` | **Walk the import graph from `index.js`, and follow only chunks that EXIST.** An orphan left by an earlier bundle references old hashes, so scanning every file in `chunks/` reports a healthy bundle as broken. One level is not enough either — a real rollup bundle has `index.js` importing a single chunk with the rest hanging off it, so a one-level check misses almost every real breakage. The safety control matters more than the detection here, because this gates an automatic re-bundle: run it against several REAL built bundles and require zero findings, then delete one referenced chunk from a copy and require detection. ako/mxcli-maintenance-2 |
-| 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 | `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 | `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` | 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 |
-| 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 | 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`) | `mdl/executor/cmd_microflows_builder_workflow.go` (`addCallWorkflowAction`) | **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 |
-| 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 | 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` | `mdl/executor/validate_datasource_args.go` (`validateDataSourceArguments`, `dataSourceArgErrors`, `buildFlowParameterNames`), wired from `mdl/executor/validate.go` for both pages and snippets; `scriptContext.flowParams` | **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 |
-| `editable: Never` on a widget in `CREATE PAGE` has no effect — the field is editable in the browser, while `mxcli check`, `mxcli exec` and `mx check` are all clean, and `describe page` shows nothing either way | The property was parsed and validated but nothing carried it to the writers, which hardcoded `SetEditable("Always")` for TextBox, TextArea, CheckBox, DatePicker and RadioButtons. The semantic model had no field for it at all | `sdk/pages/pages_widgets.go` (`BaseWidget.Editable`, `CanonicalEditability`, `WidgetEditability`), `mdl/executor/cmd_pages_builder_v3.go` (`applyConditionalSettings`), `mdl/backend/modelsdk/widget_write.go`, `sdk/mpr/writer_widgets.go`, `mdl/executor/cmd_pages_describe_{parse,output}.go` | **The isolating control is ALTER**: `ALTER PAGE … SET Editable = Never ON w` always wrote it correctly, which proves the value is representable and only the CREATE path loses it — run that before touching the writers. Put the field on `BaseWidget`, not on each input widget: one field covers all twelve editable types and MDL-WIDGET20 already refuses the property on the rest. `EDITABLE IF` must WIN over a plain `editable:` — the conditional settings element is what makes the enum `Conditional`, so honouring both writes an enum contradicting the element beside it. **`describe` must emit it too**, or a describe/diff compares equal while the document is wrong; it lived in the CheckBox case alone, so hoist it to `appendAppearanceProps`. **Pluggable widgets are NOT fixed by this** — no `.def.json` maps `editable` and the stored `CustomWidgets$CustomWidget` has no `Editable` key, so a combobox is reported (MDL-WIDGET21) rather than dropped; do not "fix" it by calling `SetEditable` on the gen CustomWidget, which is an inert sink. ako/mxcli-maintenance-2 |
-| A documented `~/.mxcli/mxbuild/*/modeler/mx check app.mpr` fails with `Verb '/root/.mxcli/mxbuild/<other>/modeler/mx' is not recognized`, and it looks like a broken mxbuild install | The shell expands the `*` to every cached version and `mx` reads the second path as an argument. Both binaries are fine; it is purely the command line, and the failure mode is misleading enough that an earlier report recorded the wrong binary as broken | `cmd/mxcli/init_claudemd.go` (the generated project docs), plus ~15 `.md` files including three SYNCED skills (`manage-security`, `custom-widgets`, `alter-page`) | **Document `mxcli docker check -p <app>.mpr` first** — it resolves the version from the project, which is the whole problem. Where `mx` must be called directly, name a version (`<version>`), never glob. Note the split: `filepath.Glob` in Go (`cmd/mxcli/docker/detect.go`) is CORRECT and must not be "fixed" — it globs then picks, whereas a shell passes all matches through. This reaches every user, since anyone who has used two Mendix versions has two cached. ako/mxcli-maintenance-2 |
-| `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 | 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" | `mdl/executor/cmd_security_write.go` (the `NewAlreadyExists` site) | **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 |
-| `ContentParams: [{1} = $PageVar]` comes back from DESCRIBE as `<unbound>` | 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 | `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) | **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. |
-| 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 | 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 | `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` | 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. |
-| `describe page` emits MDL that mxcli's OWN `check --references` rejects — `duplicate widget name 'row1' … (CE0495)` — on stock pages nobody edited | 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 | `mdl/executor/validate_page_context.go` (`checkDuplicateWidgetNames`, `widgetKindsWithoutStoredNames`) | **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". |
-| A JSON structure's ARRAY ITEM element gets a derived name (`LinesItem`, `JsonObject`) that no MDL can change, and every mapping over the structure carries it — `describe` of a Studio Pro mapping then diffs on `ExposedName`. The obvious workaround, `custom name map ('lines\|(Object)' as 'OrderLine')`, parses, executes and does **nothing** | An array's item is the anonymous `[…]` entry, so it has no JSON key; `customNameMap` is keyed on JSON keys, so the item was unreachable by construction. And an entry matching no key was applied to nothing and reported nothing, so the failed workaround was indistinguishable from success | grammar `mdl/grammar/domains/MDLDomainModel.g4` (`customNameMapping` gains `ITEM OF`), `mdl/ast/ast_jsonstructure.go` (`CustomItemNameMap`), `mdl/visitor/visitor_jsonstructure.go`, `mdl/types/json_utils.go` (`snippetBuilder.itemName`, `SnippetKeys`), `mdl/executor/cmd_jsonstructures.go` (`collectCustomItemNames`, DESCRIBE), `mdl/executor/validate_json_structure_names.go` (`MDL-JSON01`/`MDL-JSON02`) | **Do NOT infer Studio Pro's generation rule from stored documents — they are hand-edited.** Measured across 621 array elements in nine apps: 61% are the generator's `JsonObject`/`Wrapper`[+counter], 35% are a word someone chose, 4% are `<Name>Item`. The fingerprint that settles it is `JSON_AutoConfigResponse`, whose eight arrays read *in document order* `Scope, Wrapper_2..Wrapper_6, Claim, CodeChallengeMethods` — a counter with **gaps where a human renamed**; and `JSON_SensorData`'s `Array → SensorData`, a name with no relation to the array's. A version story fitted to a 9-structure sample ("10.24 singularises, 11.4 does not") evaporated at corpus scale. So the fix is **expressiveness, not default-matching**: no default can match a corpus that is a third hand-written, and changing the default would rewrite every stored structure's item names plus every mapping bound to one (ExposedName is a resolution key, #882). Design notes: `item of 'key' as 'Name'` rather than folding it into the existing entry, so naming an item does not require restating the array's name and adding one is a one-line diff; the same clause names a primitive array's **Wrapper**, because that wrapper IS the item; `item of 'Root'` for a root array, which has no key. DESCRIBE needs its own collector — an item's path segment is the marker `(Object)`/`(Wrapper)`, so the existing one skips it, and without it a named item was written on CREATE and silently renamed back by describe → exec. ako/mxcli#272 |
-| `mx check` fails with **`InvalidOperationException: … Duplicate Guid in unit page 'M.P'. Object types: Translation, Translation`** and the project will not LOAD at all — and every later edit of that page reports the same thing | Two elements in one unit share an `$ID`. "Guid" in Mendix's message is the element `$ID`, not a `GUID` property — a `Texts$Translation` stores exactly four keys (`$ID`, `$Type`, `LanguageCode`, `Text`) and has no GUID of its own | `modelsdk/canon/duplicates.go` (`DuplicateElementIDs`, `DuplicateElementIDError`), wired at all four write choke points: `modelsdk/mpr/writer_core.go` (`insertUnit`, `updateUnit`) and `sdk/mpr/writer_units.go` (same two) | **A guard is worth shipping without a root cause.** The reporter lost ~1h to one of these, proposed two causes, tested both, and withdrew both (ako/mxcli-captrack #2) — the trigger is still unknown. Refusing at the write turns an unopenable project into one message, and breaks the thing that made it expensive: the corruption is **STICKY**, so once a unit carries duplicate ids every later edit inherits them and each subsequent write looks like the culprit. Restore before re-testing, or the second experiment measures the first one's damage. Check BEFORE `canon.Reconcile`, not after — an elided write is not a safe one, only one that did not happen this time. Two controls are mandatory and both are cheap: **pointers are not duplicates** (an element's id is referenced by primitive properties like `ParentPointer` all over a normal document — counting those refuses every write), and a **normal translated page** with two translations differing only in id must still be accepted. False-positive control run at scale: **0 flagged out of 33,645 units across 90 projects**. Do NOT "repair" by deduplicating — an `$ID` is a pointer target, so choosing which element keeps its identity silently re-points references (ADR-0008). |
-| 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 |
-| `rename entity` / `rename module` reports success but prints no "Updated N reference(s)" line, and the next `mx check` fails **CE0174** "Cannot resolve object name 'MyFirstModule.Period'" on a view entity | A view's OQL is the ONE place a qualified name is stored **embedded in a sentence** rather than as a property of its own. Both engines' rename walkers match a string that *equals* the old name or *begins with* it — correct for a BY_NAME property, and blind to `from MyFirstModule.Period as p` mid-query | `mdl/types/oql_rename.go` (`RewriteOQLQualifiedName`), wired at the `Oql` key in `mdl/backend/modelsdk/infrastructure_write.go` (`replaceQNInDocCounted`) and `sdk/mpr/writer_rename.go` (`replaceStringsInDoc`) | **Ask where each reference is STORED, not just which documents reference it** — a scan built for whole-string properties silently covers 0 of the embedded ones, and reports 0, which reads like "nothing referenced it". Scope the rewrite to the `Oql` key: a blanket substring replace across every string reaches documentation and expressions, where a similar-looking name is not a reference. Three name-shaped ways it goes wrong, all covered by tests: a **longer name starting with the old one** (`M.PeriodDetail`) must not move, a **quoted** reference must stay quoted (bare is CE0174 — quoting is how a view names an entity called after an OQL reserved word), and a **module rename arrives as a prefix pair** (`"Old." -> "New."`) with no entity half to split, so it needs its own path or module rename stays broken while entity rename looks fixed. Where a query-local alias is spelled exactly like the module, the rewrite **declines** rather than guessing — 0 references reported is a visible non-event, a corrupted query is not. Both engines, one shared rewrite. ako/mxcli-captrack |
-| 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") | 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) | `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) | **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 |
-| `mxcli check` passes and `exec` prints `Created association`, then the project no longer OPENS — `KeyNotFoundException … at StreamingBsonUnitReader.ResolvePostponedProperties()`, a stack trace naming no document | 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 | `mdl/executor/validate_association_module.go` (`ValidateAssociationModules`, MDL070), wired in `mdl/executor/validate_program.go` | **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 |
-| A test fails only on CI and never locally — e.g. `TestWatcherDebounce`: `expected 1 debounced message, got 2` | The test ASSUMED a timing premise instead of checking it. A debounce test needs the whole burst of writes to land inside the debounce window; each write resets the timer, so a gap larger than the window splits the burst and it debounces as two. On a loaded runner one gap between five `os.WriteFile` calls exceeded 500ms | `cmd/mxcli/tui/watcher.go` (`newWatcherDebounced`, the window is a field not a constant), `cmd/mxcli/tui/watcher_test.go` | **Get the observed value out of the CI log before theorising** — `gh run view <id> --log \| grep <test>`. I guessed "count 0, event delivery too slow" and built two controls for it; both passed, because the log said `got 2` and the real mechanism was the opposite one. Three fixes, each aimed at the measured failure: a window far longer than production (2s vs 500ms) so headroom is orders of magnitude rather than 2×; the premise **measured and skipped on** (`if burst >= debounce { t.Skip }`) so a machine too slow to emit a burst reports its own limitation instead of a product defect; and the message **polled for, not slept for**, so delivery latency cannot decide the outcome. The grace after the first message must be a FULL window — a split's second timer fires one window after the last write, so a shorter wait stops looking before the evidence arrives. Control the mechanism deterministically (100ms window, 150ms gaps → count 5) rather than trying to reproduce load, and verify the skip path actually fires (temporarily set the window to 1ns). This is the checklist item "tests don't rely on `time.Sleep` for synchronization" — the original even named the hazard in a comment without removing it. |
-| CodeQL `go/incorrect-integer-conversion` (high) on `strconv.ParseUint(…, 16, 32)` narrowed to `int` | The parse width was chosen from the *field's* width in the file, not the *type's*. A TCP port is 16 bits and the kernel writes it `%04X`, so a 32-bit parse accepts values the caller then compares as if they were ports; where `int` is 32 bits the conversion wraps (`FFFFFFFF` → `-1`, `ok=true`) | `cmd/mxcli/docker/portowner_linux.go` (`hexPort`) | **Parse at the target type's real width and let the parser do the range check** — that is the whole fix, and it turns an unchecked narrowing into a rejection at the boundary. Establish reachability before rating it: the input here is `/proc/net/tcp`, written by the kernel, so no hostile value reaches it and the consequence of the wrap is a *missed* port match (the diagnostic falls back to its generic message), not memory unsafety. Two things make it worth fixing anyway — a range check that lives in the parser cannot be forgotten by the next caller, and the alert otherwise stays open forever. Measure the wrap rather than asserting it: a `GOARCH=386` binary **runs on an amd64 host**, so the 32-bit behaviour is directly observable, and the same run showed the repo does not currently build for 386 at all (`mdl/settingsoverlay` has `9007199254740992` as an untyped int constant) — worth knowing before claiming a 32-bit impact. A test written at 64 bits still catches it: at width 32 `hexPort` returns `4294967295, true` where it should refuse. Keep a 32-bit-safe test literal (`int(^uint32(0))`, not `4294967295`, which is not a valid `int` constant on 386). |
-| CodeQL `go/unsafe-unzip-symlink` on a tar extractor that already checks the joined path and the symlink target — looks like a false positive | It is not. A **chain of two symlinks** escapes: the guard resolves each link against its **lexical** parent while the OS resolves it against its **real** one. `sub/up -> ..` genuinely is the root (allowed, correctly); `sub/up/w -> ..` therefore really is `root/w`, pointing at the root's **parent**, and lexically looks like `root/sub`. Then `sub/up/w/pwned` contains no `..` and passes every check | `cmd/mxcli/docker/download.go` — one `extractTarGzInto` on `*os.Root` behind both `extractTarGz` and `extractTarGzStrip1`, plus `tarEntryPath` / `symlinkStaysInside` / `pathWithin` | **Try to break it before rating it, and keep trying after the first six attempts fail.** Six single-step archives (absolute link, `../..` link, absolute name, link-to-root, …) were all correctly refused, which is exactly what makes "false positive" tempting; the seventh — two chained up-links — wrote a file into the extraction root's parent, and an eighth reached any sibling directory. The fix is `os.OpenRoot` + `Root.OpenFile`/`MkdirAll`/`Symlink` (Go 1.24/1.25), which hands containment to the kernel (`openat2` `RESOLVE_BENEATH`) instead of to string comparison — the failure is then `path escapes from parent` from the OS. Keep a **link-target** check as well and resolve its parent with `EvalSymlinks`: `os.Root` stops *mxcli* following an outward link, not mxbuild or the JVM that read the tree afterwards. Two things the rewrite fixed for free: `strings.Contains(name, "..")` silently dropped legitimate files (`foo..bar` never appeared, no error) — `filepath.IsLocal` is the right test, on path *elements* — and a `HasPrefix` containment test with no separator puts `/cache/runtime-evil` inside `/cache/runtime`. Settle "would refusing break real downloads?" by measurement, not caution: the 11.13.0 CDN tarballs are 3,646+279 (runtime) and 33,188+5,036 (mxbuild) entries with **zero symlinks**, listed with `curl \| tar -tzv` without saving the archive. Control both directions — the ordinary-archive test must pass, and against the old extractor the chained cases must actually write outside (they do, in both the stripping and non-stripping variants). |
-| `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. |
-| `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. |
-| `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` |
-| `create or modify translations in <Module> for <lang>` reports success ("Set 212 nl_NL translation(s) across 20 document(s)") and the app's pages switch language while the **menu does not** | `mdl/translations/outofscope.go` (new), `mdl/executor/cmd_translations.go`, `cmd/mxcli/syntax/features_misc.go` | The **navigation is a project-level document**, not a module one, so `in <Module>` never reaches it. Measured on the reporting project: 151 strings scoped against 546 unscoped, and re-running the same file unscoped landed 65 more across 22 further documents. Nothing warned — the document count was the only tell, and only if you knew what number to expect. A scoped run now names **the file's own entries** it did not reach (`translations.OutOfScope`), not "the project has other strings", which is true of every scoped run and would warn forever — the per-module workflow is exactly what the scoping exists to support. Second, load-bearing half: those entries were previously swept into the **drift** warning, whose premise ("no text has this as its source") is *false* about them — they matched, out of scope. They are subtracted from it, so "the text may have been deleted" is only said where it is true. Controls: an unscoped run of the same file reports nothing new and lands the strings; a key matching nothing anywhere is still reported as drift. Reported as ledger #137 |
-| `mxcli run --local`/`--hub` sits at several hundred percent CPU for hours while the app is gone; `ps -o stat` shows the runtime JVM as `Z` (zombie) under it, `curl localhost:<app-port>` returns `000`, and the hub preview URL still answers | `cmd/mxcli/docker/localboot.go` (`watchExit`, `alive`, `stopProcess`), `cmd/mxcli/docker/runlocal.go` (`waitForInterruptOrExit`, `runtimeStoppedError`) | Two mechanisms. (1) **Nothing ever called `Wait()`** on the runtime process, so an exited JVM stayed an unreaped zombie — and `alive()` asked `Signal(0)`, which **succeeds on a zombie**. Measured (Linux 6.18, go1.26): proc state `Z`, `Signal(0)` → nil; after `Wait()` → "process already finished". So the liveness check reported a runtime that had terminated itself hours earlier as alive. `Signal(0)` is only a correct liveness test *because* something reaps — removing `watchExit` silently breaks that line, which is why the control is on the reaper, not on `alive()`. (2) **After boot, `run` waited on a signal and nothing else**, so a correct answer had no one asking; it now waits on the signal OR `rt.Exited()` and returns a **non-zero** error, because returning 0 after the app has gone is what let a supervisor conclude all was well. **Why it happens at all**: the local standalone runtime uses a development licence with a maximum run time and terminates *itself* (measured lifetimes 3h52m and 5h07m — not a fixed number, and shorter than a working session); `runtimeExitReason` lifts that from the runtime's own log, and reports nothing rather than guessing when it cannot tell. **Two waiters on one process deadlock**, so `stopProcess` consults the reaper's channel instead of taking its own `Wait`. The CPU spin itself was NOT reproduced and is not claimed fixed by name — it lived in the tunnel client, under a supervisor blind to its dead child; what is fixed is the state it occurred in, since mxcli now exits and takes the tunnel with it. **Generalisable**: a 200 from a tunnelled URL is not evidence the app is alive — the tunnel outlives the runtime. Reported as mxcli-formula1 FINDINGS §60 |
-| After `mxcli test … --local`, an app another `mxcli run --local` is serving goes blank while still answering HTTP 200 (~1.7 KB, the Mendix SPA shell); the runtime log shows `Connector: 404 - file not found for file: dist%2Findex.js` and `deployment/web/dist` is gone | `cmd/mxcli/testrunner/localapp_options.go`, `cmd/mxcli/testrunner/runner_local.go` (`localTestDeployDir`), `cmd/mxcli/testrunner/runner.go` (`checkScratchDeploymentExists`) | A local test run already used its own ports and its own `<project>_test` database — the code comment says why, verbatim — but shared the **deployment directory**, which is the one the *browser* reads. A headless test boot does not bundle the web client, so its build left the running app serving the shell over a 404: tests pass, run keeps running, app is blank, nothing reported at either end. **Detection was not the fix**: the two processes use different ports by design, so no port check can see it, and a lock file would only turn a silent blanking into a refusal. The test boot now builds into `<project>/.mxcli/deployment-test/` — gitignored, already where the test runtime log lives — which makes the collision impossible. Note booting a runtime against the shared directory damages it even **without** a rebuild (the packaging step removes the bundle — FINDINGS §35, `ReportLostWebClientBundle`), so "reuse the dev loop's tree read-only" is not an alternative. Consequence to wire: `--skip-build` used to mean "reuse deployment/" and now has nothing until tests have run once, so it is refused with the reason rather than failing inside the runtime boot against a path the user never chose. Reported as mxcli-formula1 FINDINGS §62 |
-| A widget keyword the grammar accepts is absent from `mxcli syntax page widgets`, so it is concluded not to exist and worked around at length (reported for `tabcontainer`, which cost two days and five hand-rolled pages) | `cmd/mxcli/syntax/features_page.go`, `cmd/mxcli/syntax/widget_keywords_drift_test.go` | The lesson the reporter drew — "absence from the documentation is not absence from the grammar" — is true and is a bad thing for the docs to require. `TestEveryWidgetKeywordIsInAPageSyntaxTopic` makes it false instead: it reads the `widgetTypeV3` rule out of the **committed** `.g4` (only the *generated parser* is uncommitted, and the grammar is the authority the reporter was told to consult) and fails when a keyword appears in no `page.*` topic. It found **18**, not one. Exemptions go in `documentedElsewhere` **with the topic that owns them** — layout constructs (`scrollcontainer`, `region`, `navigationtree`, `menubar`, `placeholder`) and pluggable-widget object-list keywords (`group`, `series`, `marker`, …) are not page widgets; an entry with no home is the same defect. The guard carries its own vacuity control: a keyword that does not exist must not match, and one that does must. **Do not document a keyword without running it** — probing all 18 on 11.13 found four the parser accepts and the *default engine refuses* (`statictext`, `staticimage`, `dynamicimage`, `dropdown` → "widget *pages.X not yet supported by the modelsdk engine"), two refused on both engines (`referenceselector`, `legacydatagrid`), and one whose bare form emits **CE0463** (`image`). Reported as mxcli-formula1 FINDINGS §69 |
-| Every open PR goes red at once on `build-and-test` with a failure in a package none of them touched — `--- FAIL: TestSessionLog_PersistAndPrune`, "after reload+prune: 0 records, want 1" — and the same test fails on a clean checkout of `main` | A **time bomb in the test**, not a regression: the fixture pinned `base := time.Date(2026, 8, 1, ...)` against a 30-day retention window, and `NewSessionLogFile` prunes inside `load()` — *before* the test can assign `log2.now`, so the reload prune runs on the real `time.Now()` whatever clock is injected afterwards. It passed for 30 days and then failed permanently, on every branch simultaneously | `cmd/mxcli/tunnelhub/sessions_test.go` (`TestSessionLog_PersistAndPrune`), `cmd/mxcli/tunnelhub/sessions.go` (`load` → `pruneLocked` → `clock`) | **First establish it is not yours**: run the failing test on a clean `origin/main`. Several PRs failing on one unrelated test is the signature. Then make the fixture relative — `base := time.Now().UTC()` — so the record ages, not the calendar, decide the outcome; the other tests in the file keep their fixed base legitimately, because they use `NewSessionLog` and inject the clock before recording. **A date fixture is only safe where no code path reads the real clock**; the moment a constructor prunes, expires or compares against `time.Now()` before the seam is in place, an absolute date has a fuse on it. Control the repair: stub `pruneLocked` to a no-op and confirm the test still fails (2 records, want 1), or the fix is just a test that stopped testing |
-| Every page menu item in an **mxcli-authored navigation profile** loses the page's own title, and `mx check` reports one **CW0263 "Empty template"** warning per item while errors stay at 0 (16 of them on a real 11.12.3 app) | `Forms$FormSettings.TitleOverride` written as an **empty** `Microflows$TextTemplate` instead of `null` — the #812 defect above, in the three writers #812 did not touch. An empty template is an override to `""`, not the absence of one. Unlike the ShowPage/button paths there is nothing to preserve: `types.NavMenuItemSpec` has no title field, so MDL cannot author a navigation title override and the value is unconditionally null | `sdk/mpr/writer_navigation.go` (`buildFormSettingsBson`), `mdl/backend/modelsdk/navigation_write.go` (`navFormSettingsBson`), `modelsdk/mpr/nav_patch.go` (`navpBuildFormSettingsBson`) | Emit `{Key: "TitleOverride", Value: nil}` in all three. **Grep the builder's callers before concluding a navigation fix is menu-only** — each of the three is also the profile's **login page** builder (`writer_navigation.go:116`, `navigation_write.go:127`, `nav_patch.go:122`, plus `navigation_profile_add.go:108`), so one edit per engine covers both `Forms$FormAction` and `LoginPageSettings`, and a fix aimed only at menu items would have missed half the emitters. Verify against a **Studio Pro document already in the project**, not against the warning count: a blank app's own navigation unit stores `TitleOverride = null` on both the login settings and the home menu item. Read it with `f=$(grep -ral NavigationDocument app/mprcontents \| head -1)` — `grep -a` is required, a `.mxunit` is raw BSON and plain `grep -rl` skips it as binary — then `strings -a "$f" \| grep -c TextTemplate`: **4 before (3 page items + login page), 0 after**, with `grep -c TitleOverride` staying at 4 so the key is still written. Measured on 11.12.0 on both engines. These three paths are raw `bson.D` → `bson.Marshal` → `UpdateRawUnit`, so #812's second trap (a `codec.RegisterTypeDefaults` `NullFields` entry clobbered by another registration for the same `$Type`) cannot apply — which also means a shape assertion on the builder is the only unit-level guard there is. Repro `mdl-examples/bug-tests/989-navigation-title-override.mdl`. PR #989 |
-| `DESCRIBE NAVIGATION` prints `home page` and the menu but **silently omits `login page` and `not found page`**, so pasting its output back (the documented copy workflow) deletes both from the profile. The clauses are on disk and `MXCLI_ENGINE=legacy` prints them | The **reader**, not the writer: `mdl/backend/modelsdk/navigation_read.go` type-asserted only the `$Type`s `modelsdk/gen` declares for those two slots, and neither is what the documents carry — `LoginPageSettings` is stored as `Forms$FormSettings` with the page under `Form` (gen expects `Navigation$NavigationProfileLoginFormSettings` / `LoginPage`), and `NotFoundHomepage` as `Navigation$HomePage` (gen and `generated/metamodel` both expect `Navigation$NotFoundHomePage`). A failed type assertion leaves the field empty, so the loss is silent | `mdl/backend/modelsdk/navigation_read.go` (`navLoginPageOf`, `navNotFoundPageOf`), cross-check `generated/metamodel/types.go` `NavigationNavigationProfile` | **The other engine is the control.** Legacy read the same bytes correctly throughout, which is what identifies a reader bug: `describe navigation X` on both engines must agree, and a disagreement localises the defect to the one that reads through gen. Accept the `$Type` the documents actually carry and keep gen's as a fallback branch. Note the two slots fail in **opposite directions** and want opposite fixes: for the login page a real Studio Pro document and `generated/metamodel` agree with the writers, so **gen** is wrong; for the not-found page — Studio Pro's **"Fallback page"** — metamodel and gen agree with each other and the three mxcli **writers** are the odd one out, emitting `Navigation$HomePage` where Studio Pro stores `Navigation$NotFoundHomePage`. Only a reference document could tell those apart, since mxbuild accepts either; ako/TestApp supplied it. Keep reading both `$Type`s regardless: documents written before the writer fix carry the `HomePage` spelling and must keep round-tripping. Repro `mdl-examples/bug-tests/navigation-describe-profile-pages.mdl` |
-| A document mxcli writes carries a different **typed-array marker** (the leading `int32` of a Mendix array) than the equivalent Studio Pro document — e.g. every list in a `CREATE OR REPLACE NAVIGATION` profile was `1` where Studio Pro writes `2` or `3`. No error, no warning, no build failure: it renders and opens | The writers hand-build `bson.A{int32(1)}` per list. The marker is a **per-field constant**, not a function of the list's contents (`Forms$FormSettings.ParameterMappings` is `2` in 816 empty and 306 non-empty documents alike), so it cannot be derived — it has to be read off real documents | `sdk/mpr/writer_navigation.go` + `mdl/backend/modelsdk/navigation_write.go` + `modelsdk/mpr/nav_patch.go` (`navMarker*` / `navpMarker*` constants), `mdl/backend/modelsdk/navigation_profile_add.go`, `modelsdk/codec/defaults.go` (`RegisterListMarker`) for the codec paths | **Census, don't reason.** Walk every `.mxunit` on the machine, tabulate `(parent $Type, field, marker, empty?)`, and take the value the Studio Pro documents carry — 19,078 files across 54 projects settled five of six navigation fields outright. **`int32(1)` is NOT invalid**, whatever `debug-bson.md` used to say: a Marketplace `.mpk` mxcli has never touched uses it for `CustomWidgets$WidgetValueType.AllowedTypes` (212k occurrences) and `Forms$Page.AllowedModuleRoles`. Believing otherwise turns a per-field mismatch into a phantom corruption bug and sends the fix in the wrong direction. Where the census has no observation, **find a document that has one** rather than picking: `HomeItems` was `2` in all 51 stored profiles but every one was empty, and `navigation_profile_add.go` wrote `3` from a PED session that could not be re-run. ako/TestApp settled it — a Studio Pro-authored profile whose `HomeItems` holds two `Navigation$RoleBasedHomePage` elements at marker **2**, the non-empty case the census could not reach. One project with the feature actually configured beats any amount of reasoning about empty lists. Verify by dumping the written document and the project's own pristine reference and diffing the marker column, not by `mx check`, which is silent on all of it |
diff --git a/.claude/skills/fix-issue/findings/README.md b/.claude/skills/fix-issue/findings/README.md
new file mode 100644
index 0000000000..1cdcc482e3
--- /dev/null
+++ b/.claude/skills/fix-issue/findings/README.md
@@ -0,0 +1,59 @@
+# Findings
+
+One JSON object per line, sharded by area. 630 records, extracted from the
+symptom table that used to live inside `fix-issue.md` — see that file for how to
+search them and how to add one.
+
+## Why JSONL, and why sharded
+
+The table had grown to 1.05 MB. That is past a context window, past what
+GitHub's web editor will open, and past what the wiki's own `wiki-sync` can
+consume (its Phase 2 requires reading a source in full) — so the digest step that
+turns findings into `docs-wiki/bug-patterns/` pages had been blocked since the
+day it was created.
+
+Line-oriented records fix all three at once. A shard is small enough to open and
+grep; `merge=union` is *correct* on a file of independent records, where on the
+old mixed prose-and-table file it was a hazard; and a query can pull one area at
+a time instead of the whole corpus.
+
+Nine shards rather than one file per finding: 630 files would trade a
+too-large file for a directory nobody can scan, and the conflicts that motivated
+sharding only happen between fixes touching the *same* area.
+
+## Fields
+
+| field | |
+|---|---|
+| `area` | package the fix landed in, e.g. `mdl/executor`. Decides the shard |
+| `date` | when the finding was last touched, `YYYY-MM-DD`. Backfilled by `git blame` over the table this came from, so it is *last touched*, not *first written* — a row that was later corrected carries the correction's date. Used by `make digest-status` to measure how far the wiki digest has fallen behind |
+| `symptom` | what the user saw — the thing you match against |
+| `cause` | the mechanism |
+| `file` | where to look first |
+| `insight` | what would have made it cheaper to find; the part worth reading |
+| `refs`, `ce`, `rules` | issue/PR refs, Mendix `CE####` codes, MDL rule ids — extracted from the text, present only where the text carried them |
+| `raw` | the original table row, for the 68 records whose row could not be split into four columns (an unescaped `\|` in the text, or a row that never had four cells). `symptom`/`cause`/`file`/`insight` are absent on these |
+
+A record has **either** the four structured fields **or** `raw`. Queries that
+must cover everything need to account for both.
+
+## Guard
+
+`make check-findings` (`scripts/check-findings.sh`) validates every line: one
+JSON object, an `area`, a `date`, and either the four fields or `raw`. It prints
+one line saying how far `docs-wiki/bug-patterns/` has fallen behind these
+findings — see `make digest-status` for the breakdown.
+
+It runs in CI as of the change that added this sentence. It did not before,
+for the two weeks this file claimed it did — which is the same shape as every
+other finding here, so it is recorded rather than quietly corrected.
+
+The extraction was verified lossless by regenerating every table row from the
+records and diffing against the original 630 — byte-identical as a multiset.
+Order carries no meaning: these are looked up by matching a symptom.
+
+## On DuckDB
+
+The files are newline-delimited JSON, which DuckDB reads in place over a glob —
+no import, no schema, no build step. It is not vendored and not required: `grep`
+plus `jq` covers the common lookup, and the guard above only needs `python3`.
diff --git a/.claude/skills/fix-issue/findings/cmd-mxcli.jsonl b/.claude/skills/fix-issue/findings/cmd-mxcli.jsonl
new file mode 100644
index 0000000000..ab26e0d61c
--- /dev/null
+++ b/.claude/skills/fix-issue/findings/cmd-mxcli.jsonl
@@ -0,0 +1,97 @@
+{"area": "cmd/mxcli", "date": "2026-07-30", "symptom": "`mxcli test` leaves the project mutated: Security Level changed, after-startup pointing at the deleted `MxTest.TestRunner`, and only a `Warning:` line about it. Or: an empty `MxTest` module accumulates after every run", "cause": "Three defects in one teardown. (a) `getAfterStartup` trimmed quotes *before* trailing punctuation, so a DESCRIBE SETTINGS line ending in `,` yielded `Module.Flow',` and the restore statement was unparseable; (b) cleanup dropped only the microflow, not the module it created; (c) the Security Level was forced OFF and restored to a hardcoded PRODUCTION", "file": "`cmd/mxcli/testrunner/runner.go` (`parseSettingValue`, `quoteMDLString`, `projectState`, `setupCommands`, `cleanupCommands`)", "insight": "Strip trailing `,;` before unquoting; re-emit via `quoteMDLString` (doubling embedded quotes, never backslashes); capture a `projectState` before the first mutation and restore from it; drop the module only when the run created it (a pre-existing `MxTest` is the user's); leave Security Level alone entirely; return cleanup errors instead of printing warnings, and fail the run when they occur. Command lists are pure functions so the restore is testable without a project or Docker. Issues #802/#803/#804", "refs": ["#802", "#803", "#804"]}
+{"area": "cmd/mxcli", "date": "2026-07-31", "symptom": "`mxcli oql -p app.mpr \"…\"` fails against a `mxcli run --local` app — first `admin password required`, then (with the password) `OQL error: Action not found.` and 0 rows — even though the same query works under `mxcli docker up`", "cause": "Two-part gap. (a) The local runtime booted the JVM with no system properties, so `/dev/preview_execute_oql` was never mounted (docker mode passes `-Dmendix.live-preview=enabled -Dmendix.running.locally.by.studiopro=true` via docker-compose; the local boot did not). (b) `run --local` never printed or wrote the admin password, and `mxcli oql` errored instead of defaulting to it", "file": "`cmd/mxcli/docker/localboot.go` (`LocalRuntimeOptions.jvmArgs` — new) + `cmd/mxcli/docker/m2ee.go` (`resolveM2EEDefaults` token fallback) + `cmd/mxcli/docker/oql.go` (Action-not-found hint) + `cmd/mxcli/docker/runlocal.go` (banner)", "insight": "Always pass the two live-preview `-D` flags in `jvmArgs` (run --local is always DTAPMode=D, matching docker); default the oql admin token to `defaultLocalAdminPass` when nothing else supplies it (admin API is loopback-only); branch the \"Action not found\" hint to cover the `--local` case; print a `Query data: mxcli oql …` line in the run banner. Tests `TestJVMArgs`, `TestResolveM2EEDefaults_Defaults`. traceops #36", "refs": ["#36"]}
+{"area": "cmd/mxcli", "date": "2026-07-08", "symptom": "CE0463 on an MDL-created **Combobox** (or other platform widget) at `mxcli docker build/check` time — but the SAME widget passes `mx check` on a project whose installed `.mpk` matches mxcli's embedded template (Mendix 11.6 / combobox 2.5.0). NOT the old incomplete-template bug (#112, fixed — a matching-version combobox is clean)", "cause": "Widget-VERSION mismatch: mxcli emits the embedded 2.5.0-shaped PropertyTypes, but the project has a NEWER combobox (e.g. 2.8.1) that reorders/regroups properties. `augmentFromMPK` patches presence + enum values but can't restructure the baseline; `GenerateFromMPK` is less faithful still (fails even on a matching version). The designed remediation is `mx update-widgets` (docker build/check runs it before `mx check`)", "file": "`cmd/mxcli/docker/check.go` + `build.go` (`updateWidgetsPathArg`) — the update-widgets *invocation*, not the widget emission", "insight": "The real trap was that `mx update-widgets <bare-app.mpr>` **crashed** (`AddProjectDirAsAllowedPath` → `Path.GetDirectoryName(\"app.mpr\")` = \"\" → `System.ArgumentNullException`) and some mx builds exit 0 after printing it, so the migration silently no-op'd and CE0463 survived. Pass an **absolute** path to update-widgets (always has a directory component). `mx check` is unaffected. Diagnosis: run the bundled `mx update-widgets <bare.mpr>` yourself — if it throws ArgumentNullException on AddProjectDirAsAllowedPath, the path lacks a dir. Faithful multi-version widget emission is the larger fix (#529). Issue #112; repro `mdl-examples/bug-tests/112-combobox-enum-ce0463-widget-version.mdl`", "refs": ["#112", "#529"], "ce": ["CE0463"]}
+{"area": "cmd/mxcli", "date": "2026-07-31", "symptom": "`mxcli docker check`/`build` (or a bare `mx update-widgets`) **silently deletes `mprcontents/`** and rewrites an MPRv2 project into single-file v1 — `check` reports **0 errors** and looks successful, but the git working tree diverges from tracked files, a running `mxcli run --local` loop breaks (it watches `mprcontents/`), and Studio Pro may crash on open (`LibGit2RepositoryProvider.WriteBaseFile`). Triggered by following the CE0463 remediation on a `mxcli new` (always v2) project", "cause": "The pre-check `mx update-widgets` step (run to suppress false CE0463) **performs the conversion**: it inlines every unit into the `.mpr` (`Unit.Contents` column) and deletes `mprcontents/`. The `check` itself is read-only; `update-widgets` is the mutator. docker check/build invoked it with no storage-format protection", "file": "`cmd/mxcli/docker/update_widgets.go` (`runUpdateWidgets` / `snapshotStorageFormat`) — call sites in `check.go` and `build.go`", "insight": "Snapshot `.mpr` + `mprcontents/` to a temp dir before `update-widgets`, `defer restore()` after the check (restore removes the post-conversion single-file `.mpr` residue and puts the v2 tree back); MPRv1 projects need no protection. The check still runs against the widget-normalized model, so CE0463 stays suppressed — only the on-disk format is preserved. **Never tell an agent to run bare `mx update-widgets` on a v2 project** — the synced skills (`create-page.md`, `custom-widgets.md`, `migrate-design-prototype.md`, `download-marketplace-content.md`) + dev `debug-bson.md` route to `mxcli docker check`/`build` (v2-safe) instead. **Fix the operation, not the call site**: PR #764 wrapped the invocation inside `Check` only, and `Build` had a second bare copy — so `docker build`/`run`/`reload` kept converting projects for another 40 issues, until #808. The snapshot now lives in `runUpdateWidgets`, which is the only place that may exec `update-widgets`; grep for `\"update-widgets\"` should return exactly one hit. When a mutating external step is guarded, put the guard in a function that also *performs* the step, so a new caller cannot get it wrong. Issues #763 / PR #764, #808", "refs": ["#763", "#764", "#808"], "ce": ["CE0463"]}
+{"area": "cmd/mxcli", "date": "2026-06-06", "symptom": "`mxcli <cmd> -p \"C:\\\\path\\\\App.mpr\"` (Windows backslash path) fails with `unable to open database file (14)` and the echoed path is mangled (`C:\\temp` → `C:<TAB>emp`, backslashes dropped); forward slashes (`-p C:/path/App.mpr`) work", "cause": "The CLI fabricates `CONNECT LOCAL '<path>'` MDL from the flag value and re-parses it, so the lexer's `unquoteString` interprets `\\t`/`\\n`/`\\r` and escape backslashes in the path. The positional `.mdl` arg is a raw path, so it's unaffected", "file": "every `cmd/mxcli/*.go` `fmt.Sprintf(\"CONNECT LOCAL '%s'...\", projectPath)` site + `mdl/visitor/visitor_helpers.go`", "insight": "Never interpolate a raw filesystem path into MDL source. Wrap it in `visitor.QuoteString(projectPath)` (escapes `\\`→`\\\\`, `'`→`''` — the exact inverse of `unquoteString`) at every CONNECT-string site. Round-trip test in `mdl/visitor/visitor_connection_test.go`. Issue #644", "refs": ["#644"]}
+{"area": "cmd/mxcli", "date": "2026-07-01", "symptom": "`mxcli oql` against a docker-deployed app returns **0 rows** for tables that clearly have data (false negative — tester concluded \"saving is broken\")", "cause": "NOT a database-config problem (that's a red herring — proven: aligning the runtime to Postgres with data still returned 0). The OQL preview servlet (`/dev/preview_execute_oql`) is registered by `com.mendix.basis.livepreview.LivePreviewRegistry` → `AppContainer.addDevelopmentServlet`, which **only mounts the servlet when the JVM system property `mendix.running.locally.by.studiopro=true` is set** (Studio Pro sets it; a deployed `bin/start` PAD doesn't). Without it the endpoint returns HTTP 200 `{\"result\":-5,\"message\":\"Action not found\"}`, which mxcli silently parsed as empty data. (Found by decompiling `com.mendix.mxruntime.jar` / `com.mendix.appcontainer.jar`.)", "file": "`cmd/mxcli/docker/templates/docker-compose.yml` (the `command`) + `cmd/mxcli/docker/oql.go` (`oqlDevError`)", "insight": "Add `-J -Dmendix.running.locally.by.studiopro=true` to the start command (each JVM opt needs its own `-J`), next to the existing `-Dmendix.live-preview=enabled` — this mounts the dev servlets and `mxcli oql` returns live data (verified end-to-end; DTAP mode is NOT required, DB config is irrelevant — the preview runs in-process against the runtime DataStore). Separately, make `oqlDevError` surface `{\"result\":<0,\"message\":…}` (not just `{\"error\":…}`) so the failure isn't swallowed as 0 rows. **Related startup bug found:** the generated `etc/Default` inherits the project's ports, which are `0` when unset → the runtime rejects port 0 and won't start; `patchRuntimePorts` (patch.go) forces `runtime.http { port = 8080 }` / `admin { port = 8090 }`. Verified with a full docker build/run/seed cycle"}
+{"area": "cmd/mxcli", "date": "2026-07-25", "symptom": "`mxcli run` warm-loop ergonomics from Sudoku findings: (a #17) a **relative** `-p` fails with MxBuild's raw \"should be an absolute path\" + a Windows JSON sample; (b #15/#23) a **build failure in the watch loop** (incl. a SCSS compile error like `Expected expression. _x.scss 180:35`) printed only the generic `build failed: <message>`, swallowing the real detail", "cause": "(a) `cmd_run.go` passed `-p` straight through without `filepath.Abs`; (b) the watch path at `runlocal.go` printed only `build.Message` while `build.Raw` (the full serve `/build` body, which the cold-build path already prints) held the compiler/model detail", "file": "`cmd/mxcli/cmd_run.go` + `cmd/mxcli/docker/runlocal.go` (watch build-failed branch)", "insight": "(a) `projectPath, _ = filepath.Abs(projectPath)` after reading the flag; (b) also print `strings.TrimSpace(string(build.Raw))` (indented) when it differs from `build.Message`, matching the cold path. **Diagnosis pattern**: when a dev-loop error is unhelpfully generic, check whether a `Raw`/full-body field is already captured and just not printed on that code path", "refs": ["#15", "#17", "#23"]}
+{"area": "cmd/mxcli", "date": "2026-07-22", "symptom": "Editing `themesource/**/main.scss` (or `theme/web/main.scss`) while `mxcli run --local` serves on `:8080` keeps showing **old styles** — reads exactly like a stale compiled-CSS cache. `rm -rf theme-cache/ .mendix-cache/ deployment/` \"fixes\" it only because a restart came with it", "cause": "THREE distinct causes, none a CSS cache: (1) **no `--watch` = no watcher at all** — `mxbuild --serve` only rebuilds on a `/build` request (startup, or a watch tick), so a save changes nothing; (2) **stale process silently adopted** — a leftover serve/runtime on the ports answers the startup readiness probes (`waitReady`/`waitAdminReady` only check \"port answers\"), so a new run attaches to the OLD process and its own child is torn down by `defer`; a backgrounded `run --local` whose wrapping shell exited non-zero dies while its serve+runtime keep serving; (3) the theme source was **watched by nothing** — the `--watch` signal was model-only (`.mpr`+`mprcontents/`). The incremental theme step itself is FINE: one `/build` after an scss **content** edit does rewrite `theme-cache/web/theme.compiled.css` (verified), so there is no cache to clear", "file": "`cmd/mxcli/docker/runlocal.go` — `checkTargetPortsFree` (guard), `themeSourceMTime`/`sourceMTime` (watch signal), `watchAndApply` (generation log)", "insight": "(2) Refuse to boot when `:8080/:8090/:6543` already answer, with an actionable message (never auto-kill — user's call). (3) Add `theme/`+`themesource/` scss/css/js to the `--watch` mtime-poll signal (`sourceMTime` = max(model, theme)); poll-based so it's container-safe (unlike the rollup chokidar/inotify web-client watcher). Log a build-generation counter (`build #2`) so \"did it take?\" is answerable. Docs: `docs-site/src/tools/run-local.md` + skill `run-local.md` — \"SCSS needs a rebuild (`--watch` or clean restart), never a cache-clear; kill the old serve/runtime first\". Tests `TestThemeSourceMTime_WatchesThemeAndThemesource`, `TestCheckTargetPortsFree`", "refs": ["#2"]}
+{"area": "cmd/mxcli", "date": "2026-07-26", "symptom": "`mxcli run --local`: when a page action throws, the browser shows the generic Mendix error dialog and there is nothing to correlate it against — the runtime's own stdout/stderr (server stack trace, microflow `LOG` output) is swallowed, so a server-side bug can't be told apart from a client one", "cause": "The runtime JVM was spawned with `cmd.Stdout=log; cmd.Stderr=log` where `log` is an in-memory `syncBuffer` surfaced only on a *startup* failure; during normal operation it goes nowhere on disk", "file": "`cmd/mxcli/docker/localboot.go` (`spawnAndConfigure`, `openRuntimeLog`, `LocalRuntime.logFile`, `LocalRuntimeOptions.RuntimeLogPath`) + `cmd/mxcli/docker/runlocal.go` (default `<projectDir>/.mxcli/runtime.log`) + `cmd/mxcli/cmd_run.go` (`--runtime-log`)", "insight": "Tee the JVM's stdout+stderr to `<projectDir>/.mxcli/runtime.log` via `io.MultiWriter(log, file)` (the in-memory buffer still backs startup-error reporting). Append across restarts with a `=== runtime start … ===` marker; close the handle on Stop/reopen. Default on; `--runtime-log <path>` relocates, `-` disables. Print the path at boot. Test `TestOpenRuntimeLog`. Findings #25", "refs": ["#25"]}
+{"area": "cmd/mxcli", "date": "2026-07-26", "symptom": "Follow-up to the above (#25 re-test): `run --local` writes `runtime.log` but it stays **nearly empty** — the JVM tee captures startup/JVM output only; **application** logs (microflow `LOG`, server-side exception stack traces) never reach stdout, so a page-action error still can't be diagnosed", "cause": "A standalone runtime (launched via `runtimelauncher.jar`) attaches **no log subscriber** by default — unlike a Studio Pro / m2ee run, which calls `create_log_subscriber` **after** start. Mendix application logs flow to log *subscribers*, not stdout, so with none attached they go nowhere", "file": "`cmd/mxcli/docker/runtime_controller.go` (`RuntimeController.LogSubscriberFile`/`Stdout`, `attachFileLogSubscriber`, called at the end of `Start`) + `cmd/mxcli/docker/localboot.go` (`StartLocalRuntime` sets `ctrl.LogSubscriberFile` to the abs runtime-log path)", "insight": "After a successful `start` (and on every restart's `Start`, since each fresh JVM has no subscriber), call the `create_log_subscriber` admin action with `{type:\"file\", name:\"mxcli-run-local\", autosubscribe:\"INFO\", filename:<abs runtime.log>, max_size:1GiB, max_rotate:0}`. **`max_rotate:0` is load-bearing**: the JVM stdout tee holds an fd on the same file, and a rotate-rename would detach it. Best-effort (a logging failure must not fail an up runtime — warn to Stdout instead). Pass an **absolute** path (the runtime's cwd is `<install>/runtime`, not mxcli's). Tests `TestStart_AttachesLogSubscriber`, `TestStart_NoLogSubscriberWhenUnset`, `TestStart_LogSubscriberFailureNonFatal`. Findings #25 (round 2)", "refs": ["#25"]}
+{"area": "cmd/mxcli", "date": "2026-07-26", "symptom": "Follow-up to round 2 (#25 re-test): the subscriber is registered but `runtime.log` **still** holds only the 4 JVM-banner lines — a probe microflow's `log info/warning/error` and a forced runtime exception produce **zero** lines. Isolation test: boot+subscriber → 0 probe lines; then call `start_logging` → 6 lines", "cause": "A standalone runtime boots with logging **not started**, so a registered subscriber sits **inert** — nothing is delivered until the logging subsystem is activated. `create_log_subscriber` alone is necessary but not sufficient", "file": "`cmd/mxcli/docker/runtime_controller.go` (`configureRuntimeLogging` — renamed from `attachFileLogSubscriber`; now also calls `start_logging`)", "insight": "After `create_log_subscriber`, call `CallM2EE(c.opts, \"start_logging\", nil)` in the same step (order: create subscriber → start_logging). Treat an \"already started\" response as success (`start` re-runs on the DB-update retry / restart paths on a still-running JVM). Still best-effort (warn to Stdout, never fail an up runtime). Test `TestStart_StartLoggingAlreadyStartedIsSuccess`; `TestStart_AttachesLogSubscriber` now asserts the `[start, create_log_subscriber, start_logging]` sequence. **Diagnosis pattern**: when a registered sink receives nothing, check whether the subsystem that feeds it is even *running* — registration ≠ activation. Findings #25 (round 3)", "refs": ["#25"]}
+{"area": "cmd/mxcli", "date": "2026-08-01", "symptom": "`mxcli new --version X` prints \"Resolving MxBuild X...\" and then produces a project at a **different** Mendix version — silently. Every later step (init, mxbuild, runtime, `run --local`) follows the wrong version", "cause": "`ResolveMxForNewProject` delegated to `ResolveMxForVersion`, whose last resort is `AnyCachedMxPath()` — *any* cached mx, of any version. That fallback is fine when the project already exists and its version is a preference; for `new` the requested version **is** the output, because `mx create-project` stamps the project with the version of the binary that ran it", "file": "`cmd/mxcli/docker/check.go` (`localMxForVersion`, `ResolveMxForNewProject`) + `cmd/mxcli/cmd_new.go` (postcondition)", "insight": "Resolve **exactly** the requested version for `new` (exact Studio Pro install → exact versioned install path → exact download cache; **not** PATH, which carries no version guarantee), and download otherwise. Then check the postcondition: reopen the created `.mpr`, compare `ProductVersion` to `--version`, and fail loudly on a mismatch — resolution bugs are invisible without it. **Generalisable**: when a flag names the version/identity of the artifact being produced, a \"close enough\" local substitute is never valid, and the produced artifact should be verified against the request rather than the resolution trusted. Found while reproducing #812 in a browser — cost a full project rebuild before it was noticed", "refs": ["#812"]}
+{"area": "cmd/mxcli", "date": "2026-08-11", "symptom": "`mxcli syntax <topic>` teaches MDL that does not parse — `Binds:` (removed in favour of `Attribute:`, and hard-rejected by the parser), workflow decision outcomes without the `->` arrow, `ALTER WORKFLOW … SET DUE DATE = '…'` (no `=`), `INSERT <activity> AFTER <name>` (operands reversed), `IMAGE 'name'` (identifier, not string), a `BEFORE` that does not exist. Nothing failed, because nothing checked", "cause": "The registry (`cmd/mxcli/syntax/features_*.go`) is hand-maintained while the grammar moves underneath it, and every existing test checked *structure* — fields populated, aliases resolve, see-also targets exist — never whether the documented MDL is real. 26 of 120 entries had a non-parsing example", "file": "`cmd/mxcli/syntax/example_parses_test.go` (new guard), plus corrections across `features_page.go`, `features_workflow.go`, `features_integration.go`, `features_microflow.go`, `features_misc.go`", "insight": "Parse every `Example` and fail the build if it does not. Examples come in several legitimate shapes, so each blank-line-separated **block** is tried as a statement, a microflow activity, a page widget, a workflow activity, and a retrieve clause — a failure means it parses as none of them. Only `Example` is checked; `Syntax` carries metasyntax (`[OR MODIFY]`, `<statements>`) by design. **Generalisable — the shape to look for**: documentation that is *data in the binary* can be executed against the real parser, which turns \"the docs drifted\" from a review problem into a test failure. The same trick applies to any embedded example corpus (skills, `--help` text, README snippets extracted at build time). **Why it matters more than it looks**: the registry is the first surface an agent consults, so a gap there does not read as \"undocumented\", it reads as \"unsupported\" — a contact-management app built with mxcli worked around three features that already existed, including replacing a `SAVE_CHANGES CLOSE_PAGE` button with a bespoke microflow because only the two halves were listed separately. **Close the opt-out** — a guard that skips empty input is a guard you can silence by emptying the field; `TestFeatureFieldsPopulated` already rejects a blank `Example`, and the new guard additionally fails an example that is all comments"}
+{"area": "cmd/mxcli", "date": "2026-08-06", "symptom": "SCSS written to **`themesource/<name>/web/main.scss` never reaches the app** — no error, no warning, the build succeeds and the rules are simply absent from `theme-cache/web/theme.compiled.css`. Looks exactly like an SCSS cache problem, so the usual reflex (`rm -rf theme-cache/`) wastes the session", "cause": "A theme source folder is only compiled when `<name>` matches a **real module in the model**. mxbuild walks the model's modules and pulls each one's `themesource/<lowercased module name>/web/main.scss`; it never globs the `themesource/` directory, so an invented folder (`themesource/my_theme/`) is silently skipped. Verified on 11.13: a probe rule in `themesource/myfirstmodule/` compiled, the identical rule in `themesource/mxcli_theme/` did not", "file": "`cmd/mxcli/theme/theme.go` (package doc records the compile order); the target paths live in `cmd/mxcli/theme/assets/<theme>/files/`", "insight": "Put app-level styling in **`theme/web/`**, not in an invented theme source folder: `theme/web/main.scss` is compiled **last** — after Atlas Core *and* after every module theme source — so a partial imported from it overrides any Atlas rule without `!important`. Use a module's theme source only when the styling genuinely belongs to that module (it exports with the `.mpk`). **Generalisable — the shape to look for**: when CSS \"doesn't apply\", first prove the file is *compiled at all* (grep a unique probe selector in `theme-cache/web/theme.compiled.css`) before debugging specificity or caches — absent and overridden look identical in the browser. Note also that `theme/web/custom-variables.scss` is imported once **per module**, so it must hold declarations only; a rule there is emitted N times"}
+{"area": "cmd/mxcli", "date": "2026-08-06", "symptom": "Text painted by an **Atlas topbar widget is invisible in a dark theme** — the language selector measures ~1.13:1 contrast, glyph pixels spanning 4 luminance values out of 255. A theme override exists and *names the right element*, so it looks handled", "cause": "Two separate mistakes stacked. (1) **Specificity**: Atlas's own rule is `.navbar-brand .widget-language-selector .current-language-text` at (0,3,0); a bare `.current-language-text` at (0,1,0) never wins, and only appears to on layouts that do not nest the selector under `.navbar-brand`. (2) **Wrong value**: `color: inherit` inherits *body ink*, which is dark, while the rail is dark in both palettes — so even at the winning specificity it measures 1.00:1. Atlas paints from `--bg-color-secondary` with a `#fff` fallback because it assumes a dark rail", "file": "`cmd/mxcli/theme/assets/*/files/theme/web/_mxcli-atlas-map.scss` (the \"Atlas fixups\" block)", "insight": "Re-declare **Atlas's own selector shape** so the weights match and source order decides, and resolve the colour through the rail token (`var(--mxt-rail-ink-active, var(--mxt-rail-ink))`) rather than `inherit`. List the bare and the `.navbar-brand`-nested selectors together — each is matched at its own specificity, so one rule covers both layouts. **Generalisable — the shape to look for**: a guard that names the right element is not evidence it applies. Read the *winning* declaration (`CSS.getMatchedStylesForNode` in DevTools, or the computed value) instead of the one you wrote. **Measure contrast, not colour**: reading `getComputedStyle(el).color` once and seeing a plausible value proves nothing — compute the WCAG ratio against the first non-transparent ancestor background, which is what turns \"looks fine\" into 1.13 vs 19.47. Reported from the RssReader test build; tests in `cmd/mxcli/theme/theme_test.go`, verified in a browser at 17.79:1 light / 19.47:1 dark"}
+{"area": "cmd/mxcli", "date": "2026-08-08", "symptom": "A themed app is on-palette everywhere except a few widget details — the **Data Grid 2 pager caption is invisible** (1.02:1 on a dark ground), row-select checkboxes stay stock Mendix blue, popovers cast light-mode shadows. Re-pointing tokens changes nothing, and the same widget's other parts (the pager *buttons*) are fine", "cause": "The theme source shipped by the **widget modules** (`themesource/datawidgets`, `atlas_web_content`) styles some things with Sass variables and literals — `datawidgets/web/variables.scss:18` is `$pagination-caption-color: #0a1325`. Sass resolves those at compile time, before any custom property exists, so the value is baked into `theme.compiled.css` and no `--mxt-*` can reach it. The parts that *do* work resolve `var(--gray-darker, …)` through Atlas: same bar, two mechanisms", "file": "`cmd/mxcli/theme/assets/*/files/theme/web/_mxcli-widgets.scss` (the shared widget layer, imported after the theme partial)", "insight": "Add a CSS rule per baked declaration, resolving through a token so both palettes follow. **The obvious fix does not work**: each module's `main.scss` imports `theme/web/custom-variables` before its own `!default` vars, so `$pagination-caption-color: var(--mxt-ink-muted)` there *would* win — but (1) the names collide with Atlas Core's, which feeds them to Sass colour functions (`atlas_core/web/_variables.scss:20` computes `mix($brand-primary, #e7e7e9, 10%)`; handing `mix()` a `var()` is a compile error) and (2) the worst offenders are not behind a variable at all — `_three-state-checkbox.scss` writes `#264ae5` and `rgba(#264ae5, 0.4)` directly. **Generalisable — the shape to look for**: read the **compiled CSS, not the SCSS**, when deciding what to override. The sources are full of `var(--token, #fallback)` declarations that already resolve correctly; in one measured app `#264ae5` appeared in 46 declarations and **24 were harmless fallbacks**, so grepping the source would have produced twice the rules for no benefit. Reported from the Formula1 test build (§33); verified in a browser: pager caption 1.02:1 → 6.99:1 console dark, 6.39:1 light, 6.78/5.93 on signal", "refs": ["#0", "#264"]}
+{"area": "cmd/mxcli", "date": "2026-08-06", "symptom": "`mxcli oql` silently omits a whole column: a `select A, B …` renders only `A`, and the JSON output has no `B` key at all — no error, no empty column. Reproduces whenever the value of `B` is **null in the first row**", "cause": "The runtime omits a null-valued column from a row's JSON object entirely, and `parseOQLFeedback` took the column list from `extractColumnOrder(rows[0])` — one row, chosen for its key *order*. Every later row was then projected onto that short list, so the column vanished from the result rather than showing NULLs", "file": "`cmd/mxcli/docker/oql.go` (`parseOQLFeedback`, `mergeColumnOrder`, `hasOnlyKnownKeys`)", "insight": "Union the keys of **all** rows, inserting each new key directly after the last key already known rather than appending — merging `[A, C]` with `[A, B, C]` must give `[A, B, C]`, not `[A, C, B]`, or a column that is null early in the result set jumps to the end of the table. The per-row re-scan is skipped when a row carries no unseen key, so the uniform case still costs one length check. **Generalisable**: any \"take the shape from the first element\" over a sparse encoding is a silent-wrong-answer bug, not a formatting bug — the output looks complete. Tests `TestParseOQLFeedback_ColumnUnionAcrossRows`, `TestMergeColumnOrder`; proven by stubbing the union back to first-row-only and watching the reported symptom return. sudoku #39, first half", "refs": ["#39"]}
+{"area": "cmd/mxcli", "date": "2026-08-06", "symptom": "`mxcli test` cannot run at all in a container without a Docker daemon — parsing, runner generation, model injection and the **entire mxbuild build** succeed natively, then `docker up` fails with \"failed to connect to the docker API at unix:///var/run/docker.sock\". So microflow tests are unavailable in exactly the environment mxcli targets (Claude Code web containers ship `/usr/bin/docker` with no daemon)", "cause": "Only one step of the run was containerised — start the runtime and read its log — but it was wired directly to `docker compose`, with no seam for another way to run the app. `run --local` had all three pieces already (boot a standalone runtime, tee its log, restore)", "file": "`cmd/mxcli/docker/localapp.go` (new `StartLocalApp`), `cmd/mxcli/testrunner/runner_local.go` (new), `cmd/mxcli/testrunner/runner.go` (docker path extracted to `runDockerAndCapture`), `cmd/mxcli/cmd_test_run.go` + `main.go` (`--local`)", "insight": "Give the run a seam — `runLocalAndCapture` / `runDockerAndCapture` — so both modes share parse/inject/parse-results/cleanup and differ only in how the app is started. **Two traps, both found by running it rather than reasoning about it.** (a) The runner reports via an **after-startup** microflow, so its LOG output happens DURING the start action, before the runtime's log subscriber attaches; registering the subscriber early is not possible (the runtime answers `LoggingException` pre-start). What actually carries the output is the JVM console tee, live from spawn — verified by A/B running with the early attach removed. (b) A **failing** test makes the runner return false, which makes the after-startup action fail, which makes `start` return an error — the first version reported that as a broken run and dumped a stack trace instead of the test report. A failed boot whose log shows a verdict is a normal outcome. Local runs use their own ports (8081/8091) and a `<project>_test` database so a `run --local` dev loop can keep serving. Verified end-to-end in a daemon-less container: 2 passed; then 1 passed / 1 failed with exit 1, project restored. sudoku #41", "refs": ["#41"]}
+{"area": "cmd/mxcli", "date": "2026-08-07", "symptom": "A solution's apps are served on one host with different ports, so they share a cookie jar (cookies key on host name and **ignore the port**) — logging into one silently replaces the other's `XASSESSIONID`. Giving each app a host name in **App Settings -> Configurations -> Application root URL** appears to do nothing under `run --local`", "cause": "`runtimeConfigParams` builds the entire boot `update_configuration` payload from `LocalRuntimeOptions`, and `ApplicationRootUrl` was only ever populated from a `--hub` registration. The model's own value had no path into the payload — and since the admin action REPLACES rather than merges, nothing else could supply it either", "file": "`cmd/mxcli/docker/runlocal.go` (`configuredApplicationRootURL`, `applicationRootURLFrom`, `customHostRootURL`)", "insight": "Read the setting off the project at boot and use it when no hub URL was assigned (hub wins — that URL is the one actually serving the app). **The trap is that a blank Mendix app already ships `ApplicationRootUrl = http://localhost:8080/`**, so \"is set\" does not mean \"was chosen\": honouring every value would change behaviour for every existing project and, under `--app-port`, advertise a port the app is not serving on. Only a **non-loopback host** is passed through, and a port that disagrees with `--app-port` warns. Serving under the host name needs no flag at all — the runtime accepts any `Host` and the client uses relative URLs (verified: 200 via `/etc/hosts`, nip.io and localtest.me); the setting matters only for the **absolute** URLs Mendix generates. **Generalisable**: before defaulting from a model setting, check what a blank project already has in it — a non-empty default makes \"fall back to the model\" a behaviour change, not a no-op. Verified end-to-end on 11.12.1: with `backend.local` configured, boot prints `Application root URL from configuration \"Default\"` and the app answers 200 on both the host name and the listen address. Tests `TestApplicationRootURLFrom`, `TestCustomHostRootURL`"}
+{"area": "cmd/mxcli", "date": "2026-08-07", "raw": "| The SessionStart hook `mxcli init` writes cannot survive an idle reap: it is guarded on `test -x ./mxcli`, and `.gitignore` excludes that binary (~85 MB) on purpose. The container is reclaimed, the repo re-cloned without it, the guard fails and the hook no-ops through `\\|\\| true` — the next session has no mxcli, no MxBuild cache, no database, and no message saying so | The hook inlined the whole bring-up in one shell line, so \"binary missing\" could only be expressed as \"skip\". A hook line cannot reasonably do OS/arch detection and a download; something committed has to | `cmd/mxcli/init_hook.go` (`bootstrapScriptTemplate`, `writeBootstrapScript`, `sessionStartHookCommand`, `sessionStartHookMarkers`) | Emit a committed `.claude/bootstrap-mxcli.sh` that resolves OS/arch, fetches the binary when absent (`MXCLI_TAG` to pin), then runs the setup; the hook becomes `sh .claude/bootstrap-mxcli.sh \\|\\| true`. **Changing the hook command breaks dedupe**, which matched on the old command string — so `addSessionStartHook` now recognises *any* known marker and **rewrites the entry in place**, migrating an old project instead of leaving it with two hooks that both run. **Generalisable**: a guard whose condition is something you deliberately do not commit is a silent no-op waiting for a fresh clone — make the guard able to satisfy itself. Verified by reproducing the reap: moved `./mxcli` out of the project, ran the hook command verbatim, watched it re-download (88 MB, new mtime) and finish with \"Setup complete … database ready\". Tests `TestAddSessionStartHook_MigratesLegacyCommand`, `TestEnsureSessionStartHook_WritesFile`. mxcli-todo #2 |", "refs": ["#2"]}
+{"area": "cmd/mxcli", "date": "2026-08-07", "symptom": "`mxcli exec -p app.mpr - <<'EOF' … EOF` fails with `Error reading file: open -: no such file or directory` — `-` is taken literally as a filename, so MDL cannot be piped or written as a heredoc and every ad-hoc script needs a temp file first", "cause": "`exec` (and `check`) called `os.ReadFile(path)` directly, with no case for the conventional stdin spelling", "file": "`cmd/mxcli/mdlsource.go` (new `readMDLSource`, `mdlSourceLabel`), `cmd/mxcli/cmd_exec.go`, `cmd/mxcli/cmd_check.go`", "insight": "One helper both commands share, so `check` gained the same spelling rather than only the reported one; `check` reports the source as `<stdin>` instead of a bare `-`. Verified live: a heredoc through `exec` and a pipe through `check` both run. Tests `cmd/mxcli/mdlsource_test.go`. mxcli-todo #5", "refs": ["#5"]}
+{"area": "cmd/mxcli", "date": "2026-08-07", "symptom": "`mxcli syntax` documents spellings the parser rejects, so an agent following the reference writes MDL that fails — `TEXTBOX … (Binds: Attr)` (\"'Binds:' is no longer supported, use 'Attribute:' instead\") and `DataSource: MICROFLOW Module.MF()` (a zero-arg microflow datasource takes NO parens, unlike RETRIEVE/CALL)", "cause": "Nothing checks the `syntax` corpus against the parser. `make check-skill-mdl` validates MDL blocks in the skills and the docs site, but the `Syntax`/`Example` strings in `cmd/mxcli/syntax/*.go` are not covered, so a retired spelling can sit there indefinitely", "file": "`cmd/mxcli/syntax/features_page.go` (10 × `Binds:` → `Attribute:`, the datasource parens), `cmd/mxcli/syntax/retired_spellings_test.go` (new guard)", "insight": "Fix the text **and** pin it: a table-driven test fails if a retired spelling reappears in any topic's Syntax or Example. It is a spelling guard rather than a parse — the snippets are fragments (a DATAVIEW body, a property line) that do not stand alone as statements, so they cannot just be fed to the parser. Proven by reintroducing `Binds:` and watching the test name the topic and field. **A third claim in the same report did not reproduce**: `CONTAINER (OnClick: SHOW_PAGE M.P(Param: $currentObject))` parses fine on current main, so only the two verified ones were changed. mxcli-todo #8", "refs": ["#8"]}
+{"area": "cmd/mxcli", "date": "2026-08-07", "symptom": "`mxcli test … --local` (or any other `StartLocalApp` caller) fails with MxBuild's `the project file path should be an absolute path`, followed by a page of Windows sample requests, whenever `-p` is given a **relative** path", "cause": "`ServeServer.Build` forwarded `ProjectFilePath` verbatim. `mxcli run` had learned to absolutize at the CLI layer (findings #17), but that fix lived in `cmd_run.go`, not in the code that talks to MxBuild — so the next caller re-hit it", "file": "`cmd/mxcli/docker/mxserve.go` (`ServeServer.Build`)", "insight": "Absolutize `req.ProjectFilePath` in `Build` itself, the single place that talks to MxBuild, so no future caller can miss it; also resolve `LocalAppOptions.ProjectPath` in `applyDefaults` so `DeployDir` and the runtime log path are not derived from a relative value. Test by pointing a `ServeServer` at an `httptest` fake and asserting on the request body — the CLI-layer fix cannot be tested that way, which is part of why it did not generalise", "refs": ["#17"]}
+{"area": "cmd/mxcli", "date": "2026-08-07", "symptom": "`mxcli test --attach` fails with `reload_model failed: Authentication failed.` — after the test microflows have already been injected into the project", "cause": "The M2EE admin API and the test endpoint are **different secrets**. `attach` built its `RuntimeController` with `M2EEOptions{Token: hs.Token}` — the endpoint token — instead of the runtime's admin password", "file": "`cmd/mxcli/testrunner/runner_attach.go` (`attach`), `cmd/mxcli/testrunner/handshake.go` (`Handshake`)", "insight": "Carry `AdminPass` in the handshake alongside `Token` and pass that to `M2EEOptions`. The hosting `run --local` publishes it via `docker.LocalAppInfo` (the resolved value, not the package default, so a `--admin-pass` override still works). Whenever one process drives another's M2EE API, check which credential is being passed — `defaultLocalAdminPass` and any app-level token are unrelated"}
+{"area": "cmd/mxcli", "date": "2026-08-07", "symptom": "\"Contrast is low and not everything uses the dark theme\" — and switching theme does not help, because `signal`, `ledger` and `console` all render the same defects. The worst of it is the **login page**: Atlas's stock photograph fills half the viewport on a dark app, and the Sign in button is green while the app's primary button is the brand colour", "cause": "The login page is served from `theme/web/login.html`, which loads the SAME compiled theme CSS (`{{themecss}}`) — so it IS themeable, but nothing themed it. Two Atlas rules do the damage: `.loginpage-image` layers a brand-tinted gradient over `url(\"./resources/work-do-more.jpeg\")`, and the submit button is `.btn-success`, so it follows the **success** colour rather than the brand. Separately, `--link-color` was mapped straight to the brand, and console's light-variant teal is 3.74:1 on white — under AA for body text", "file": "`cmd/mxcli/theme/assets/*/files/theme/web/_mxcli-atlas-map.scss` (login block + `--mxt-link` indirection, all three copies stay byte-identical), `cmd/mxcli/theme/assets/console/.../_mxcli-console.scss` (light `--mxt-link`)", "insight": "Replace the photo with a token-built gradient and point the login button at the brand; give link TEXT its own `--mxt-link` token defaulting to the brand, because a link needs 4.5:1 as text while a brand used as a button FILL only needs 3:1 plus contrast against its own ink — darkening the brand everywhere would have been the wrong lever. Console light gets `#0f766e` (5.47 / 5.10 / 4.92 against surface / ground / surface-alt). **The project's own `theme/web/logo.png` is deliberately left alone** — it is the app's asset to replace, and hiding it would strip a real logo from apps that have one. **Verification boundary, stated plainly**: verified at the compiled-CSS layer (the overriding `.loginpage-image` is last and carries no photo; the button and link declarations resolve), NOT in a browser — raising the scratch project's security level to serve a login page surfaced pre-existing model errors there that block deploy. The `#999` empty-state label could not be reproduced: every `#999` in the compiled CSS is a Bootstrap default (popover arrows, modal border, print styles), so that one needs the reporter's app. mxcli-todo #19", "refs": ["#0", "#19", "#999"]}
+{"area": "cmd/mxcli", "date": "2026-08-07", "symptom": "A login that is known to be correct starts failing on `run --local` — the page says only **\"Sign in failed\"**, as if the password were wrong. `--screenshot-user` silently produces screenshots of the login page instead of the requested page", "cause": "The local runtime is unlicensed, and an unlicensed runtime caps concurrent sessions. Past the cap it refuses the sign-in and logs `Maximum number of sessions exceeded! (You are currently using a trial license)` to `.mxcli/runtime.log` only; the page reports the refusal identically to a bad password. mxcli's own login helper never noticed either — it filled the form, waited, and saved whatever session it had", "file": "`cmd/mxcli/docker/screenshot_login.go` (`loginScript` failure detection, `loginFailureHint`, `readLogTail`), `cmd/mxcli/docker/runlocal.go` (passes `RuntimeLogPath`), `.claude/skills/mendix/run-local.md`", "insight": "Not an mxcli defect in the model layer — but mxcli held both halves and joined neither. Mendix answers a rejected sign-in by re-rendering the same form, so **the username field still being present after the click is the signal** that login did not complete; on that signal read the tail of the runtime log and name the cap. **Generalisable**: when a browser-driven helper \"succeeds\" with a degraded result, look for a server-side log that already says why — the page is often the least informative witness. Sessions are released by restarting `run --local`; a browser-driving script should sign out at the end, or the fifth or sixth run is the one that fails and it looks like a regression. Tests `TestLoginFailureHint`, `TestReadLogTail`. mxcli-todo #16", "refs": ["#16"]}
+{"area": "cmd/mxcli", "date": "2026-08-07", "symptom": "A fresh clone of a project created by `mxcli new` goes dirty the first time anyone builds it: ~50 **tracked** files modified that nobody edited — every `javascriptsource/*/actions/*.js` gains a banner, `import { Big } from \"big.js\"` and `export async function`, plus the matching `javasource` stubs. In a cloud session with a stop-hook git check it reads as \"uncommitted changes\" at the end of clean work", "cause": "The template ships the generated action stubs in a slightly older shape and MxBuild rewrites them all on the first build. `mx check` does **not** — only a build does — so nothing before the first `run --local` could reveal it, which is after the user has already committed", "file": "`cmd/mxcli/docker/settle.go` (`SettleGeneratedSources`), `cmd/mxcli/cmd_new.go` (step 5/6, `--skip-build`), `cmd/mxcli/init.go` (`/theme-cache/` in the generated ignore list)", "insight": "Fix the *timing*, not the content: run the build while the project is still being created, so the settled form lands in the first commit. Do **not** reimplement the rewrite — it is mxbuild's generator and version-specific; run the real thing. Best-effort by contract (no JDK, no mxbuild, failed build → warning, never a failed creation), because a settled tree is a nicety and a usable project is the deliverable. The other half is gitignore: `theme-cache/` is a cache and says so. A/B on 11.12.1, both git-init'd then built: `--skip-build` → 50 dirty files, default → **0**. Tests `cmd/mxcli/docker/settle_test.go`. mxcli-todo #7", "refs": ["#7"]}
+{"area": "cmd/mxcli", "date": "2026-08-07", "symptom": "`mxcli init` run from a solution root (several app folders, no `.mpr` at the root) reports success and writes tooling that points at `project.mpr` — a file that does not exist. Nobody is told which project it picked, because it did not pick one", "cause": "`findMprFile` looks only in the target directory; an empty result fell through to a hardcoded `\"project.mpr\"` default and initialisation continued as if that were a real project", "file": "`cmd/mxcli/init.go` (`findMprFilesInSubdirs` + the three-way branch on the candidate count)", "insight": "Look one level down, then branch on the **count**: 0 → warn that generated paths will be placeholders; 1 → announce the project and initialise **that** directory; 2+ → refuse, list them, and print the exact command naming one. One level only — a Mendix app keeps its `.mpr` at its own root, and walking deeper starts finding deployment copies and backups. Candidates are sorted so the refusal and its suggested command are stable rather than directory-order dependent. **Generalisable**: a \"sensible default\" that names a file which does not exist is not a default, it is a silent wrong answer — count the candidates and let the count choose the behaviour. Tests `cmd/mxcli/init_discover_test.go`. mxcli-formula1 #3", "refs": ["#3"]}
+{"area": "cmd/mxcli", "date": "2026-08-07", "raw": "| `ALTER MODULE X ADD JAR DEPENDENCY (…)` succeeds, `list jar dependencies` reports it, the build is **green** — and the runtime throws `SQLException: No JDBC driver found in app for URL`. `deployment/build.gradle` has no dependencies block and `find deployment -iname '*<artifact>*'` returns nothing | Not a bad write. Declaring and resolving are **separate steps**: the model records the coordinate, and `mx sync-java-dependencies <project.mpr>` is what downloads it into `vendorlib/`. Studio Pro runs that when you edit Module Settings; nothing headless was running it. Confirmed on 11.12.1 — a full `mxbuild --target=deploy` resolves nothing, and the sync command then fetches the jar | `cmd/mxcli/docker/javadeps.go` (`SyncJavaDependencies`, `UnvendoredJarDependencies`), `cmd/mxcli/cmd_sync_java_deps.go` (`mxcli sync-java-deps [--check]`), `cmd/mxcli/docker/runlocal.go` (vendors before boot), `mdl/executor/cmd_modules.go` (`warnUnvendoredJarDependencies`) | **How to find the missing step**: the reporter's open question was \"does mxbuild skip Maven resolution, or does mxcli write it somewhere MxBuild cannot read?\" — neither. `strings mx.dll | grep -i dependenc` surfaced `ISyncJavaDependenciesRunner`/`SkipManagedDependencySync`, and `mx --help` listed `sync-java-dependencies`. When a model-level write \"works\" but the artefact never appears, check whether the **toolset** has a separate command for it before suspecting the write. Wired at three levels so the gap cannot stay silent: the executor says so the moment it writes an unvendored coordinate, `run --local` resolves it before boot, and `--check` exits non-zero as a build gate. Resolution needs network, so every call site is best-effort with an actionable message. Tests `cmd/mxcli/docker/javadeps_test.go`. mxcli-formula1 #12 |", "refs": ["#12"]}
+{"area": "cmd/mxcli", "date": "2026-08-07", "symptom": "`mxcli test tests/ -p app/App.mpr` fails with \"no such file or directory\" for a `tests/` that sits right next to the `.mpr`", "cause": "Test paths resolved against the process CWD only. Defensible in isolation, but mxcli otherwise encourages naming the project (`-p`) rather than standing in its directory, and project auto-discovery searches outward — so the two conventions collide and the failure looks like a missing directory", "file": "`cmd/mxcli/cmd_test_run.go` (`resolveTestPaths`)", "insight": "Fall back to project-relative **only when the CWD-relative path does not exist**: a `tests/` in both places must resolve to the one the user is standing in, since silently preferring the project's copy would run the wrong suite. A path that exists in neither is passed through unchanged so the error names what was typed, not a rewritten path the user never mentioned. Tests `cmd/mxcli/cmd_test_run_paths_test.go`. mxcli-formula1 #13", "refs": ["#13"]}
+{"area": "cmd/mxcli", "date": "2026-08-07", "symptom": "A test annotated `@cleanup rollback` (or with no `@cleanup` at all — rollback is the documented default) still leaves its rows in the database; a misspelled strategy like `@cleanup rollbak` does the same, silently, while the run reports PASS", "cause": "`TestCase.Cleanup` was parsed and then used nowhere. The after-startup runner had no seam to implement it — tests run inside the startup action, so there is no context the runner owns. The test endpoint creates that seam: it builds the `IContext` each test runs on", "file": "`cmd/mxcli/testrunner/endpoint.go` (the handler's execute block), `cmd/mxcli/testrunner/cleanup_strategy.go`", "insight": "Wrap the call in `ctx.startTransaction()` … `ctx.rollbackTransaction()` in a **finally** (a throwing test is the one most likely to leave half-written data), gated on a `rollback=1` query parameter the client sends per test. Report `rolledBack`/`rollbackError` in the response and warn per test — a rollback that fails silently is worse than none. Reject an unknown `@cleanup` value at **parse** time so `--list` catches it too. Verify against the database, not the endpoint's own claim: run one test with rollback and one with `@cleanup none` in the same suite and query Postgres — the `none` row must be the only survivor"}
+{"area": "cmd/mxcli", "date": "2026-08-08", "symptom": "A suite passes under `mxcli test --attach` and fails under `--local`, with assertions that depend on startup state (a loaded cache, seeded reference data) seeing zero rows", "cause": "The `--local` runner pointed after-startup at its own registration microflow and did **not** chain the project's own, so the app's startup logic never ran. It was a deliberate choice (a known baseline) but was invisible: the run printed only `After-startup set to MxTest.RegisterEndpoint`, never that the user's microflow had been displaced", "file": "`cmd/mxcli/testrunner/runner.go` (`runEndpoint`), `cmd/mxcli/testrunner/cleanup_strategy.go` (`describeStartup`)", "insight": "Capture project state **before** generating the endpoint MDL, and pass `state.afterStartup` to `GenerateEndpointMDL` so the generated flow chains it — the hosted `--test-endpoint` path already did this, and the mismatch between the two was the bug. Add `--skip-app-startup` for a deterministic empty baseline, and always print which of the two happened. Note the startup microflow's writes run at boot, outside any test transaction, so `@cleanup rollback` does not undo them. mxcli-formula1 findings #19", "refs": ["#19"]}
+{"area": "cmd/mxcli", "date": "2026-08-08", "symptom": "`mxcli test tests/ -p app/App.mpr --list` fails with `stat tests/: no such file or directory` while the same command without `--list` runs fine", "cause": "The `--list` branch passed raw `args` to `ListTests`, bypassing `resolveTestPaths` — so a path relative to the project (rather than the working directory) resolved for execution but not for listing", "file": "`cmd/mxcli/cmd_test_run.go` (the `if list` branch)", "insight": "Pass `resolveTestPaths(args, projectPath)` there too. When a command has two entry points into the same input, check both go through the same path resolution. mxcli-formula1 findings #15", "refs": ["#15"]}
+{"area": "cmd/mxcli", "date": "2026-08-08", "symptom": "An app themed dark still shows light-mode drop shadows under the datagrid's filter-operator popover and dropdown filter lists", "cause": "The generated widget layer re-pointed `.column-selectors` but not the four rules in `_datagrid-filters.scss` that bake the same two-layer shadow. Each already takes its *background* from `--bg-color-secondary`, so Atlas re-colours the panel and leaves the shadow — which is why it reads as a partial fix rather than an untouched widget", "file": "`cmd/mxcli/theme/assets/*/files/theme/web/_mxcli-widgets.scss`", "insight": "**Read the selectors out of the shipped `themesource/`, not the bug report** — the fourth here is `.dropdown-container .dropdown-list`, nested under a parent the report did not name. **Verify in the compiled CSS, never the source** (the §33 rule): apply the theme to a real project, run `mxbuild --target=deploy --java-home=… --java-exe-path=…`, then grep `theme-cache/web/theme.compiled.css` and check the *line number* — the fix must land after the widget module's own rule (30794 vs 27765 here) or the cascade eats it. A theme-cache file older than the SCSS you just wrote is a stale compile, and mtime is the cheapest way to catch it. mxcli-formula1 #33 / suggested issue 4", "refs": ["#33"]}
+{"area": "cmd/mxcli", "date": "2026-08-08", "symptom": "Every page in a locally-run app is a black screen. `mxcli check` passes, the build reports success, the runtime log is quiet, `curl /` returns 200 with a valid HTML shell, and every OData service answers — only a browser sees it. It also comes and goes between runs of the same command at the same version", "cause": "`run --local` bundles the browser client at step 5b, then the runtime boot runs Gradle `clean-custom-classes compile package`, whose package pass repopulates `deployment/web` and takes `dist/` with it — deleting the bundle 51 seconds after the same command wrote it. It only bites when Gradle has work to do (a new Java action, a full recompile), which is why the app boots fine for weeks and then stops", "file": "`cmd/mxcli/docker/webclient.go` (`WebClientBundled`, `EnsureWebClientBundle`, `ReportLostWebClientBundle`), `cmd/mxcli/docker/runlocal.go` (step 6b, after the boot), `cmd/mxcli/docker/localapp.go` (headless boots warn instead of paying ~30s)", "insight": "**A pre-condition established before a step that rewrites the same directory is not a post-condition** — verify after, not before. The guard is a `stat` when the bundle survived, which is what makes it affordable at every boot; re-ordering the bundle to after the boot instead would leave the app reachable-but-blank for ~30s on every cold start. **`curl /` returning 200 is not evidence the app renders**: the shell is served by the runtime, the client by a file the shell references. The one-line check is `curl -o /dev/null -w '%{http_code}' <app>/dist/index.js`. **Do not silently pay for a repair on a path that does not need it** — `test --local` destroys the bundle too, but tests are headless, so it prints the loss and the remedy rather than spending 30s on a two-second loop. Tests `webclient_bundle_test.go`; both controls run (guard never fires → the wipe test fails; guard always fires → the survivor test fails). mxcli-formula1 §35"}
+{"area": "cmd/mxcli", "date": "2026-08-08", "raw": "| `.ai-context/skills/` still carries the previous release's guidance after the mxcli binary is upgraded — binary rebuilt at 12:05, skills stamped the day before — with no warning that they disagree | The skills are embedded in the binary and written exactly once, by `mxcli init`. Nothing re-ran init on upgrade, and nothing compared what was on disk against what the binary carried | New `cmd/mxcli/init_skills_sync.go` (`syncAIContextSkills`, `reportSkillSync`), `--sync-skills` flag in `cmd/mxcli/init.go`, and a sync step in the SessionStart bootstrap in `cmd/mxcli/init_hook.go` | **Stale guidance is worse than missing guidance**, because an agent reads it with identical confidence either way — so the failure mode is silent and confident. Fix it where it is consumed, not where it is authored: the SessionStart bootstrap already runs on every session and can fetch the binary, so it is the one place guaranteed to execute immediately before an agent reads the files. Two properties keep an every-session job acceptable: **write only what differs** (an mtime that moves every session makes \"when did this last change\" unanswerable — a test asserts the mtime holds) and **stay silent when current**. Never fatal: a skills refresh must not block a session, hence `|| true`. A test asserts the bootstrap script actually calls it *before* the exec'd setup, since a step ordered after an `exec` never runs. Tests `init_skills_sync_test.go`; the control (write-once) leaves the stale file in place. mxcli-formula1 §16 |"}
+{"area": "cmd/mxcli", "date": "2026-08-09", "symptom": "No way to see what a running app's subsystem is doing: everything logs at `INFO`, the detail is not in the log at all, and raising the whole runtime to `TRACE` is unusable on a busy app", "cause": "Nothing in mxcli drove the runtime's per-node log levels, though the M2EE admin API has exposed them all along", "file": "New `cmd/mxcli/docker/loglevels.go` (`GetLogSettings`, `SetLogLevels`, `NormalizeLogLevel`, `MatchLogNodes`), `cmd/mxcli/cmd_log.go` (`mxcli log list` / `log set`), documented in `.claude/skills/mendix/analyze-runtime.md`", "insight": "**Probe an undocumented API before designing the command around it.** Every fact here came from a live 11.12.1 runtime: `get_log_settings` requires one of `node`/`subscriber`/`sort`; `sort` accepts only `node` and `subscriber`; `set_log_level` takes `{\"nodes\":[{name,level}],\"force\":bool}`. **The HTTP response for an AdminException says only \"See logging output for details\" — the actual message (\"Please specify node, subscriber or sort option in params\", \"Unknown sort option: name\", \"Unknown LogNode X. Use the 'force' parameter…\") is in the runtime log**, so probe with the runtime log open or you learn nothing. `force` means \"allow a node that does not exist yet\" and **permanently registers the name**, so a typo becomes a real empty node — hence it is opt-in, and an unknown node is an error by default. **Resist the subsystem-specific command**: this was proposed as `mxcli odata trace`, but `set_log_level` takes a list of nodes, so the primitive is generic and the OData knowledge belongs in docs. **The node list is a property of the APP, not of Mendix** — a node appears only once something registers it. A first pass concluded \"there is no log node for a published OData service\" from a project that had none; adding one service turns 57 nodes into 58 and `OData Publish` (with a space) appears, logging the full incoming URI at TRACE — exactly the question that motivated the command. Enumerating capabilities against one sample app and generalising is the trap; `log list` against *this* app is the answer. Distinguish \"cannot reach the admin API\" from \"the runtime refused the request\" (`ErrAdminUnreachable`) or the wrong hint buries the real one. Tests `cmd_log_test.go`, `loglevels_test.go`; verified end-to-end against a booted runtime (both arg forms, multi-node, typo refused, `--force` accepted, unreachable port). mxcli-formula1 suggested issue 4"}
+{"area": "cmd/mxcli", "date": "2026-08-09", "symptom": "A headless browser cannot log in to an app started with `--hub`, so every screenshot silently shows the login page and rendering defects survive every other check", "cause": "Under `--hub` the runtime boots with the public **https** root URL, so it marks session cookies `Secure` and prefixes them `__Host-`; a browser on a non-trustworthy http origin cannot store them", "file": "`cmd/mxcli/docker/screenshot_login.go` — the login browser context declares `X-Forwarded-Proto: http` when the target is http (Mendix 10.24+ lets that header override `ApplicationRootUrl`)", "insight": "**The reported cause did not reproduce as stated, and saying so is part of the fix.** On 11.12.1 an https root URL does *not* block a headless browser on `127.0.0.1`: loopback is a **trustworthy origin**, so Chromium accepts `Secure`/`__Host-` cookies there — the app rendered clean, no console errors, no failed requests. The mechanism is real only for a **non-loopback** http origin (a container hostname, a LAN address). Fix shipped anyway because the header is *accurate* rather than a workaround (the request genuinely is http), it costs nothing on an already-http root URL, and real users over https are unaffected. Verified at the layer the bug lives in: the captured Playwright storage state goes from `__Host-XASSESSIONID(secure=true)` to `XASSESSIONID(secure=false)`. **`curl` cannot see this class of bug and neither can a loopback browser** — when a report blames cookie flags, check whether the origin is trustworthy before believing the flags are the blocker. mxcli-formula1 §38 / suggested issue 7"}
+{"area": "cmd/mxcli", "date": "2026-08-09", "symptom": "`mxcli run --local` refuses to boot — *\"port 6643 is already in use — a previous 'mxcli run --local' … is likely still serving on it\"* — and names a process the user already killed. The guard is right to refuse; the diagnosis is a guess, and the recovery it suggests is a three-command `pgrep` hunt whose own pattern (`pgrep -f 'mxcli run'`) matches the shell it is typed into", "cause": "Two different situations printed one message. mxcli **does** reap its children on Ctrl-C/SIGTERM (`procgroup_unix.go` puts mxbuild's JVM, the runtime and the bundler each in their own process group and signals the group), so a held port after a graceful stop is a *foreign* listener. But `kill -9`, a crash, or a reaped container runs no handler at all, and then it really is the previous run's orphan. The guard could not tell them apart because it never asked who held the port", "file": "`cmd/mxcli/docker/portowner_linux.go` (`listenerOnPort`, `parseListeningInodes`, `pidForSocketInode`), `portowner_other.go` (non-Linux stub), `portguard.go` (`portCulpritAdvice`), wired into `checkTargetPortsFree` (`runlocal.go`) and `checkLocalAppPortsFree` (`localapp.go`)", "insight": "**Resolve the port owner from `/proc`, never by shelling out to `lsof`/`ss`** — both are routinely absent from slim containers, and needing a subprocess to explain why a boot failed is its own failure mode. `/proc/net/tcp{,6}` gives the socket inode; scanning `/proc/<pid>/fd` for `socket:[<inode>]` gives the pid. **Read `tcp6` as well as `tcp`**: a JVM binding \"localhost\" lands on `[::1]` or dual-stack `[::]` as often as `127.0.0.1`, and its local_address is a 128-bit hex blob, not the 32-bit one. **Filter on state `0A` (TCP_LISTEN)** — an ESTABLISHED socket on that port is a *client*, and naming it would tell the user to kill their own browser. **Report the two cases differently**: a leftover of a previous run gets `kill <pid>`, a foreign listener gets \"pick another port\" and no kill suggestion, because offering to kill a stranger's process is worse advice than the vague message it replaced. Keep the guard **detection-only** — reaping someone else's process stays the user's call. **Three test traps hit in a row here.** (1) The live-IPv6 test only ever *skipped* (no IPv6 in the container), so the tcp6 parser was effectively untested — assert against captured kernel output instead. (2) A parser test calling `parseListeningInodes` directly does not prove `listeningInodes` *opens* both files: deleting `/proc/net/tcp6` from the list left every test green. (3) Making the list a `var` so a test can point it at fixtures then means the test no longer covers the **shipped** default either — assert the default's contents before overriding it. Only the third version of that control failed. The best test in the file is the cheapest: bind a port in the test process and demand `listenerOnPort` return `os.Getpid()` — it cannot pass by accident. Tests `cmd/mxcli/docker/portowner_linux_test.go`. mxcli-formula1 suggested issue 8"}
+{"area": "cmd/mxcli", "date": "2026-08-11", "symptom": "After `mxcli marketplace install <id> -p app.mpr`, the project's `mprcontents/` folder is gone, the `.mpr` has grown from tens of KB to tens of MB, and `mxcli diff-local` no longer works. Git shows hundreds of deleted `.mxunit` files and one enormous binary", "cause": "`mx module-import` rewrites an MPR **v2** project as **v1** — silently, and one-way. Measured on a blank 11.12.1 app: 69,632-byte `.mpr` + 341 `.mxunit` → 14,295,040-byte `.mpr` + 0, with the `_Transaction` table dropped. Reproduced independently on 11.13.0, so it is not version-specific. mxcli's install command shells straight out to it against the **user's** project", "file": "`cmd/mxcli/cmd_marketplace_install.go` (`checkStorageFormatPreserved`, `isMPRv2`, `reportFormatChange`, `--allow-format-change`)", "insight": "**Refuse, do not warn** — the conversion cannot be undone (`mx convert` targets Mendix versions, not storage formats) and it destroys the per-document layout `diff-local`, `.mxunit` merges and ADR-0008's observable idempotence all rest on. **Detect the format the way the readers do** (presence of `mprcontents/`), not with a second definition. **Check the guard's negative case**: a test that only asserts \"v2 is refused\" also passes a guard that refuses everything — assert a v1 project still imports. **Do not guard every `module-import` call site**: `marketplace diff` runs one against a throwaway reference project, where the format is irrelevant (and the resulting v1 reference still diffs exactly against a v2 project, because DESCRIBE output does not depend on storage). Related, same family: `mx module-import` also refuses any module whose `Projects$ModuleImpl → IsThemeModule` is `true` (exit 112), which is the sole gate — flipping that one boolean makes an otherwise identical package import cleanly. Tests `cmd/mxcli/cmd_marketplace_install_test.go`. Reported in mxcli-formula1 FINDINGS §53"}
+{"area": "cmd/mxcli", "date": "2026-08-11", "symptom": "A .mpr extracted from a `.mpk` (or copied anywhere beside an existing project) reads with the wrong unit contents: edits appear to succeed, `ListRawUnitsByType` returns plausible documents, and a write lands nowhere the file will carry. Downstream the operation fails exactly as if nothing had been attempted", "cause": "The MPR format test is **adjacency, not content**: an `.mpr` is treated as v2 when an `mprcontents/` directory sits next to it (`sdk/mpr/reader.go` `OpenWithOptions`). A package's v1 `project.mpr` unpacked into a work directory that already holds a scratch v2 project is therefore read as v2, and every unit resolves against the *other* project's `.mxunit` files", "file": "`cmd/mxcli/marketplace/theme.go` (`makeImportable` unpacks into its own `os.MkdirTemp` subdirectory)", "insight": "**Unpack any foreign .mpr into a directory of its own** — never beside a project, even a throwaway one. **The failure is silent in both directions**: the read returns real-looking documents (from the wrong model) and the write reports success, so nothing surfaces until a later step refuses. The tell is a fix that provably works in isolation (`mx module-import` accepted the hand-built package) but does nothing in situ — that gap is environment, not logic. Test `TestMakeImportable_UnpacksAwayFromTheScratchProject` asserts the unpack does not land in the work-directory root"}
+{"area": "cmd/mxcli", "date": "2026-08-12", "symptom": "A marketplace module update leaves the app running the OLD widget code: `show modules` reports the new version, pages reference new widget definitions, and the binaries in `widgets/` are unchanged. Symptoms are whatever the version gap causes at render time, with no build error naming the cause", "cause": "The update moved only the **model**. A widget module's `.mpk` ships its widget binaries under `widgets/` inside the package, and copying units out of a reference project never touches them. Measured on DataWidgets 3.5.0 → 3.11.3: model updated cleanly, all 10 widget binaries still 3.5.0 (`Datagrid.mpk` project=216193 vs package=166933)", "file": "`cmd/mxcli/marketplace/update.go` (`InstallPackageWidgets`, called from `PerformUpdate`)", "insight": "**Take the widget files from the `.mpk`, not from the reference project** — the reference is a blank app plus the module, so its `widgets/` also holds the template's widgets and copying those overwrites widgets the update has nothing to do with. **Skip zero-size directory entries** in the zip or you write a stray file (the 3.11.3 package has 10 `widgets/` entries and 9 real files). **A module with no widgets cannot expose this**: Administration updated end-to-end and looked completely correct, which is why the gap survived a full slice. Pick a second subject with a different shape before believing an update path works. Related but distinct: after any headless module install `mx update-widgets` is needed (CE0463); and a newer module can want a newer Atlas than the project has (29 × CE6083 on DataWidgets 3.11.3), which `rename-design-properties` does NOT fix — that is a dependency, not a resync", "ce": ["CE0463", "CE6083"]}
+{"area": "cmd/mxcli", "date": "2026-08-12", "symptom": "After a marketplace module update, `mx check` reports `CE6083` \"Design property X is not supported by your theme\" on the updated module's own widgets, and it survives BOTH `mx update-widgets` and `mx rename-design-properties` (which renames 0)", "cause": "The update copied only the model and `widgets/`. The design properties are declared in the module's **own** `themesource/<module>/web/design-properties.json`, which was still the old version's copy — so the model referenced properties the shipped theme file did not define", "file": "`cmd/mxcli/marketplace/update.go` (`InstallPackageFiles` replaces `InstallPackageWidgets`)", "insight": "**Copy everything the package ships**, excluding only `project.mpr` and `package.xml` — enumerating the directories that seem to matter is what produced two bugs in a row (widgets, then themesource). **CE6083 surviving `rename-design-properties` is the tell**: that command renames properties between Atlas generations, so 0 renamed means the declaration is missing entirely rather than renamed. **Do not diagnose this as a cross-module Atlas dependency** — that was the wrong call here; the declaring module was the one being updated. Guard against `..` in package paths while copying. Measured: DataWidgets 3.5.0 → 3.11.3, 49 files replaced, 29 errors → 0", "ce": ["CE6083"]}
+{"area": "cmd/mxcli", "date": "2026-08-12", "symptom": "A project that was MPR v2 is v1 after a marketplace install or update: `mprcontents/` is empty or gone, the `.mpr` jumped to tens of MB, `mxcli diff-local` stops working. The user followed the command's own \"Next:\" hint, or the docs", "cause": "The hint said to run bare `mx update-widgets <project.mpr>` to clear the CE0463 a headless install leaves behind. That command performs the resync **and** rewrites a v2 project as v1 — measured on 11.12.1: 369 `.mxunit` files → 0, a 69,632-byte index → 14,405,632 bytes. Same family as the `mx module-import` collapse, arriving through advice rather than through a call", "file": "`cmd/mxcli/cmd_marketplace_install.go` + `cmd_marketplace_update.go` (the \"Next:\" lines now name `mxcli docker check`), `docs-site/src/guides/marketplace.md`, `.claude/skills/mendix/download-marketplace-content.md`", "insight": "**`mxcli docker check` is the v2-safe resync** — it runs the same `mx update-widgets` under a storage-format snapshot (`cmd/mxcli/docker/update_widgets.go`, #808), so the check sees the resynced model and the project keeps its format. Verified: 369 `.mxunit` / 69,632 bytes before and after. **The resync is then not persisted** — the stored model still holds the old widget definitions and a later `mx check` reports CE0463 again; Studio Pro's \"Update all widgets\" persists it in v2, and `mxcli widget sync` is the partial headless equivalent (7 of 40 on the reference fixture). Say that rather than implying the resync sticks. **A guard in the code does not cover a string in the help text**: #808 already protected every call site mxcli owns, and the collapse came back as a sentence telling the user to bypass it", "refs": ["#808"], "ce": ["CE0463"]}
+{"area": "cmd/mxcli", "date": "2026-08-12", "symptom": "`mxcli marketplace install <id> -p app.mpr` fails with `mx module-import failed: exit status 117` — \"The package could not be imported, because it was created with a newer version of Mendix Studio Pro\" — after downloading the package and building a reference project, and the message is buried under the command's full flag list", "cause": "The marketplace publishes new releases against the newest Studio Pro patch within days, and `install` with no `--version` resolves to the latest, so on any project not on the very newest patch the **default** version is the one that cannot be installed. Measured 2026-08-12 on an 11.12.1 project: the latest release of all six agent-stack modules required 11.12.2, published five days earlier. Every version the API returns already carries `minSupportedMendixVersion` — nothing consulted it", "file": "`cmd/mxcli/marketplace_compat.go` (`checkMendixCompatibility`, `newestCompatibleVersion`, `mendixVersionOf`), called from `cmd_marketplace_install.go` and `cmd_marketplace_update.go`; `SilenceUsage`/`SilenceErrors` on install/update/diff", "insight": "**Check what the API already told you before spending a download and a reference build on it** — the refusal was always going to happen, three layers lower and in mxcli's voice rather than Mendix's. **Name the version to use, not just the problem**: `--version 4.1.0 (the newest release built for 11.12.1 or older)` is the whole fix. **Skip, do not refuse, when the check cannot evaluate** (no project version, no published minimum) — same rule as `checkFeature`. **`SilenceErrors` belongs with `SilenceUsage`**: `main()` already prints what `Execute` returns, so silencing only usage leaves every refusal printed twice. Tests `cmd/mxcli/marketplace_compat_test.go`, including the negative case — a check that refuses everything passes the refusal test"}
+{"area": "cmd/mxcli", "date": "2026-08-12", "symptom": "After a headless module install, `mx check` reports project-level `CE6087` \"Design properties have been renamed in your theme and need to be updated\" with an empty location, and no mxcli command clears it — or the same for `CE0463`, which `mxcli docker check` makes pass without actually fixing", "cause": "The module ships its own design properties; Mendix's fix is `mx rename-design-properties`, which mxcli never ran. Measured on 11.12.1: it does real work (149 design properties across 41 documents) **and** collapses MPR v2 — 1,865 `.mxunit` files to 0, a 249,856-byte index to 39,895,040 bytes. Third member of the family, after `mx module-import` and `mx update-widgets`", "file": "`cmd/mxcli/docker/harvest.go` (`RunToolPreservingFormat`), `cmd/mxcli/cmd_fix.go` (`mxcli fix design-properties` / `fix widgets`)", "insight": "**The `update-widgets` snapshot trick does not transfer** — that one restores the pre-run storage because the resync only has to hold for the duration of the check, whereas these renames must **persist**, so restoring undoes the fix. **Harvest instead**: let the tool convert the project, read every unit back out of the converted file, restore the v2 storage, then write the changed units into it through the writer — which is also where `canon.Reconcile` elides the units the tool rewrote without changing (ADR-0008), so a second run writes 0. Safe for the same reason a module transplant is: no binary `$ID` crosses a unit boundary. **Restore on every failure path after the tool has run**, or a failed command leaves a half-converted v1 file. **Print the storage count before and after** — the collapse this prevents shows up there as a zero, and a success message without its own evidence is how it shipped the first time. **`mprcontents/` is not all units**: it also holds an `mprname` file, so a naive file count is one high and reads as a dropped unit. Measured: 203 errors (202 CE0463 + 1 CE6087) to 0 on a vanilla 11.12.1 app, MPR v2 intact at 1,868 units, reproduced from a restored pre-fix snapshot. Tests `cmd/mxcli/docker/harvest_test.go` — each verified to fail with the reported symptom when the fix is stubbed out", "ce": ["CE0463", "CE6087"]}
+{"area": "cmd/mxcli", "date": "2026-08-11", "symptom": "`mxcli new` into a deep output directory dies with `System.IO.PathTooLongException` and leaves the directory holding ~259 files and no `.mpr` — output that looks like a project until you try to open it", "cause": "MxToolset refuses any full destination path over **259 characters** (its own Windows-compatibility limit, not the filesystem's) and aborts extraction PART WAY THROUGH. mxcli pointed `mx create-project` straight at the user's output directory, so the abort happened there", "file": "`cmd/mxcli/newproject_paths.go` (new: `stagedProjectDirs`, `longestRelativePath`, `warnIfPathTooLongForStudioPro`, `moveProject`), wired into `cmd/mxcli/cmd_new.go` step 2", "insight": "**Stage the work somewhere safe and move it in, rather than validating a path you could just avoid** — creating in a short temp dir and renaming makes ANY depth work (POSIX allows 4096) instead of merely failing politely, and the destination is never partially populated because nothing is written there until creation succeeded. Check the relocation is safe first: `grep -rl <abs path> <project>` returned **0 files**, so a fresh Mendix project embeds no absolute paths. **Bisect for the real threshold instead of trusting arithmetic** — 77 characters creates a project on 11.13.0, 78 fails leaving 259 files, which pins `len(dest) + 1 + longest ≤ 259` exactly. **Measure the template, don't hardcode it**: the longest relative path is 181 on 11.13.0 and 182 on 11.12.0, so walk the staged tree and use the real number, or the reported budget drifts a character per release. **Warn, don't refuse, when the finished path is over budget** — the project works on POSIX, so refusing would block a machine where it is fine; but Studio Pro on Windows would not open it, so silence would be worse. Cross-device staging needs an `os.CopyFS` fallback: `os.Rename` cannot cross filesystems. Tests `cmd/mxcli/newproject_paths_test.go`. upstream #825", "refs": ["#825"]}
+{"area": "cmd/mxcli", "date": "2026-08-12", "symptom": "Widgets silently go backwards: a project on DataWidgets 3.11.3 ends up running 3.4.0 widget code after updating an unrelated module (Atlas_Web_Content, FeedbackModule). `mx check` stays clean, `show modules` shows the new module version, and nothing mentions widgets", "cause": "A module `.mpk` bundles a copy of every widget its pages use, pinned at its author's release time — and different modules pin different versions of the **same** widget. `InstallPackageFiles` copied everything the package shipped, so the last module installed decided the widget versions. Measured on the published packages: Atlas_Web_Content 4.3.0 ships 5 Data Widgets at 3.4.0 against DataWidgets 3.11.3's 3.11.3", "file": "`cmd/mxcli/marketplace/widgetversion.go` (`widgetVersionInMpk`, `versionLess`, `unpackedTwinOf`), `update.go` (`InstallPackageFiles` returns `[]SkippedFile`), `cmd_marketplace_update.go` (`reportSkippedFiles`)", "insight": "**Read `<clientModule version>`, not `<package version>`** — the root attribute is the manifest schema and is `1.0` on every widget ever published, so comparing it makes every version look equal, which is exactly as broken as not comparing. **An unparseable version must never count as \"older\"** — the default is to install, and a wrong \"older\" verdict silently withholds a file the package shipped. **Skipping must be reported**: a silent skip is the same class of bug as the silent overwrite it replaces. **Test the negative half** — a guard that skips every widget also passes \"the newer one survived\"; assert that a newer *and* an equal bundled widget still install. Same file handles FINDINGS §18: a package that ships a widget as both `.mpk` and unpacked tree (FeedbackModule 5.0.0, both 12.0.4) installs only the `.mpk`, but an unpacked widget with **no** packaged twin must still install. Verified against the real packages: 5 kept, 13 twin entries skipped. Reported in mxcli-chat FINDINGS §14/§18"}
+{"area": "cmd/mxcli", "date": "2026-08-12", "symptom": "`mxcli marketplace update`/`diff` fail with `version \"6.0.0\" not found` on a module the project actually has, and `--force` does not bypass it", "cause": "Both download the **installed** version to build the local-edit baseline, and that version had been unpublished. A blank 11.13 app ships NanoflowCommons 6.0.0 while the 6.x line now starts at 6.1.1 — so the module most in need of updating is the one whose baseline cannot be built", "file": "`cmd/mxcli/cmd_marketplace_update.go` (`--no-baseline`, and the refusal now names it)", "insight": "**`--force` was never going to work**: it overrides a *finding*, and here the comparison never ran, so there is no finding. Needing a second flag is the signal that these are two different decisions — \"I accept losing edits I have been shown\" vs \"I accept not being shown\". **Say what the flag costs in the flag's own message** — with no baseline, local edits go without being named, so the honest instruction is to commit first. Reported in mxcli-chat FINDINGS §15"}
+{"area": "cmd/mxcli", "date": "2026-08-12", "symptom": "A constant set with `alter settings constant 'M.C' value '…' in configuration 'Default'` has no effect on the running app. The statement succeeds, `describe settings` round-trips it, `mx check` is clean, and the app behaves as if the constant were still at its default", "cause": "mxbuild writes `deployment/model/config.json` with each constant's **default** value, and that map is what `run --local` hands the standalone runtime as `MicroflowConstants` — the configuration's overrides are not in it, and nothing read them. An app ran for hours with an empty encryption key while the model said otherwise", "file": "`cmd/mxcli/runconstants.go` (`resolveConstantOverrides`, `reportConstantOverrides`), `cmd_run.go` (`--configuration`), `cmd/mxcli/docker/localboot.go` (`mergeConstantOverrides`)", "insight": "**A silent no-op is the worst shape a bug can take** — every layer reported success. The fix therefore prints in *every* case, including \"no overrides applied\", so silence stops meaning \"your value is in effect\". **Merge, never replace**: `config.json` carries the defaults for constants the configuration is silent about, and replacing the map drops them (the app 530s on the first microflow that reads one) — which is exactly the shape `--runtime-setting MicroflowConstants={…}` has. **A private override has no value in the model at all** (a `Settings$PrivateValue` marker; the value lives on the workstation), so applying it would blank the constant — skip and name it. **Do not guess between configurations**: with several and no `Default`, applying one silently could push production's API key into a local run. Tests `cmd/mxcli/runconstants_test.go`, `cmd/mxcli/docker/localboot_constants_test.go`; verified live — the run now prints `Applying 1 constant value(s) from configuration \"Default\"`. Reported in mxcli-chat FINDINGS §33"}
+{"area": "cmd/mxcli", "date": "2026-08-12", "symptom": "`mxcli marketplace diff` reports local edits on a project nobody has edited — typically an Atlas snippet and a building block. `--save-edits` then writes MDL that would *destroy* the element if replayed (an empty `create or modify snippet X (Folder: 'Web') { }`)", "cause": "The comparison is on DESCRIBE output, and `Describable()` only asked whether describe *errored*. Some types describe successfully into output that says nothing: an empty `{ }` body, or a building block under \"Building blocks are read-only; they cannot be created via MDL\". Two such renderings can still differ — one unresolved name is enough — and the difference was reported as a user edit", "file": "`cmd/mxcli/marketplace/snapshot.go` (`Element.Conclusive`, `declaredReadOnly`, `emptyBody`), `compare.go` (`classify`), `update.go` (`SaveEdits`)", "insight": "**Check equality BEFORE conclusiveness** — identical text is solid evidence of \"unchanged\" whatever the type, and inverting the order marks every Atlas building block unknown and drains `verified` of meaning. **Judge the output, not the type**: a type list goes stale the moment a describe handler improves, while \"this text contains nothing to compare\" stays true by construction — match the handler's own read-only wording so the two stay in step. **A rescue file must never be a deletion**: the same rule gates `--save-edits`, including `OnlyInstalled` findings, which reach it without passing through `classify`. **Test that a real edit is still Modified** — a guard that returns unknown for everything passes every \"not evidence\" test. Tests `cmd/mxcli/marketplace/inconclusive_test.go`. Reported in mxcli-chat FINDINGS §16"}
+{"area": "cmd/mxcli", "date": "2026-08-13", "symptom": "A `.test.mdl` asserting on something a **constant** feeds passes under `mxcli test --attach` and fails under `mxcli test --local` (or the reverse), with nothing in either output to explain the difference", "cause": "`--local` boots an app of its own through `StartLocalApp`, whose options had no `ConstantOverrides` field — so it ran with each constant's **default** from `deployment/model/config.json`, while `--attach` runs against an app `run --local` booted, which applies the configuration's shared overrides. A constant resolving to the wrong value is not an error, so both runs reported success and only the assertion differed", "file": "`cmd/mxcli/docker/localapp.go` (`LocalAppOptions.ConstantOverrides`, `runtimeOptions`), `cmd/mxcli/testrunner/localapp_options.go` (new, shared by both `--local` runners), `runner.go` (`RunOptions.ConstantOverrides`), `cmd/mxcli/cmd_test_run.go` + `main.go` (`--configuration`)", "insight": "**A boot path that takes options needs one mapping function, not an inline struct literal per caller** — the two `--local` runners each built their own `LocalAppOptions`, so a field added for one would not reach the other, and neither had the constants. Both now go through `localAppOptions`, and the `LocalAppOptions`→`LocalRuntimeOptions` step is `runtimeOptions()` so the forwarding is assertable without booting anything: a dropped field there is otherwise invisible until an app runs with the wrong configuration. **Resolve in one place**: `cmd/` decides precedence and the runner only carries the map, or \"which configuration wins\" gets two answers. **Only report what this run actually uses** — `--attach` inherits the constants of the app it attached to, so resolving and printing them there would be a confident lie. Verified at the layer the symptom lives in (`.claude/skills/verify-in-runtime.md`): the same suite, one project, `--local` and `--attach` must agree, with the reverted-wiring control run showing the constant's default. Unit tests `cmd/mxcli/testrunner/localapp_options_test.go`, `cmd/mxcli/docker/localboot_constants_test.go`. See `docs/11-proposals/PROPOSAL_constant_values.md` slice 1"}
+{"area": "cmd/mxcli", "date": "2026-08-13", "symptom": "A constant value that must not be committed has nowhere to live: a constant's default and a shared configuration override both go to git, and Mendix's own **private** configuration value — the correct slot — is encrypted per user account by Studio Pro from 10.9, so nothing headless can read or write it", "cause": "Not a defect so much as an absent layer. mxcli mirrors the concept with a store it can actually reach: `<project>/.mxcli/constants.json`, mode 0600, gitignored, sitting between `--constant` and the configuration", "file": "`cmd/mxcli/constantstore/` (load/save), `cmd/mxcli/cmd_constant.go` (`constant set/unset/list`), `cmd/mxcli/constant_gitignore.go` (`ensureStoreIgnored`), `cmd/mxcli/constants_resolve.go` (`layerMachine`)", "insight": "**The promise has to be made true, then checked — asserting it is not enough.** `mxcli init` writes a `.gitignore` only when the project has none, and a Mendix project usually already has one, so the entry the whole layer rests on could simply be absent. `constant set` appends it *and then asks git*, refusing to write the value on \"not ignored\": a store that leaks is worse than no store. **Which rule defeats an ignore entry is not guessable** — `!.mxcli/**` does NOT re-include anything (git cannot re-include a file whose parent directory is excluded), while `!.mxcli` does; the test was corrected against measured git behaviour rather than the assumed case. **A corrupt store is an error, a stale entry is not**: an unparseable file means values the author set are about to be silently absent (fatal), while an entry naming a constant the project dropped is the user's own file and is skipped-and-named, or every run fails until it is hand-edited. **An empty store is deleted, not written as `{}`** — a file that configures nothing should not exist. Tests `cmd/mxcli/constantstore/store_test.go`, `cmd/mxcli/constant_gitignore_test.go`; verified live that the value reaches a running app and that `git status` never sees the file. See `docs/11-proposals/PROPOSAL_constant_values.md` slice 3"}
+{"area": "cmd/mxcli", "date": "2026-08-13", "symptom": "A constant value changed on disk (machine store, or the project configuration) does not reach an app that is **already running** — a `mxcli run --local` keeps serving the old value until it is restarted", "cause": "Constants are a boot-time layer: mxcli sends them once, in the `update_configuration` call at start. Changing them live needs the M2EE admin API, and needs BOTH of its calls", "file": "`cmd/mxcli/docker/localboot.go` (`ApplyConstants`, `LocalRuntime.BootConfig`), `cmd/mxcli/devloop_handshake.go`, `cmd/mxcli/cmd_constant.go` (`--apply`)", "insight": "**`update_configuration` is STAGED, not applied** — measured on 11.12.1: the running app keeps its old values, and the call still answers `result:0`. Only the next `reload_model` applies them, so a version sending just the first call reports success and changes nothing. That is why the two calls live in one function rather than at the call site. **Re-send the WHOLE payload**: the admin action has no read-back (`get_configuration`, `get_current_configuration`, `runtime_config`, `get_current_runtime_status` are all \"Action not found\"), so anything not sent is simply gone from the configuration afterwards — which is why the dev loop publishes what it booted with rather than a second process guessing. **A handshake from a dead process is refused, not used**: its ports may since have been taken by something else, and pushing a configuration change into the wrong process is worse than reporting no dev loop. **Say plainly what cannot be confirmed** — with no read-back, two successful calls are the strongest evidence available, so the command names what would actually confirm it (a microflow that returns the constant) instead of claiming success. **Failure to apply is not failure to set**: the value is already on disk and the next boot uses it, so `--apply` reports and returns rather than exiting non-zero over a half-succeeded command. Tests `cmd/mxcli/docker/localboot_constants_test.go`, `cmd/mxcli/devloop_handshake_test.go`. See `docs/11-proposals/PROPOSAL_constant_values.md` slice 4"}
+{"area": "cmd/mxcli", "date": "2026-08-08", "symptom": "`mxcli run --local --ensure-db` fails on a freshly built `mxcli init` dev container — there is no PostgreSQL service to start and no `postgres` superuser — even though `psql` is on PATH", "cause": "The generated Dockerfile installed `postgresql-client` **only**. `EnsureDatabase` starts a local service (`service postgresql start`) and provisions the role + database through `sudo -u postgres psql`, both of which need the **server** package. `psql` being present makes the container look correctly provisioned", "file": "`cmd/mxcli/tool_templates.go` (`generateDockerfile`)", "insight": "Install `postgresql` alongside `postgresql-client`. **Generalisable**: when a feature shells out to a service, assert the *server* package in the image template, not the client that happens to satisfy a `LookPath` check — the CI/web image having the server is what hid this (`/usr/lib/postgresql/16` is present there but not in the generated dev container). Guarded by `TestGenerateDockerfile_PostgresServer`, which asserts the server package for both the docker and podman variants"}
+{"area": "cmd/mxcli", "date": "2026-08-15", "raw": "| `mxcli test` reports **PASS for an assertion that must fail** — `@expect 1 = 2`, `@expect length($result) = 999`, `@expect find($result, 'Z') >= 0` with the needle absent. Nothing in the output distinguishes a real assertion from a vacuous one, so a suite certifies work as verified while asserting only that the microflow did not throw. Mutation testing is what exposes it: mutants that return an obviously wrong value survive the suite | The `@expect` annotation was matched with a regex for one shape — `@expect $var (=|<>) <value>` — and `FindStringSubmatch` returning nil produced **no assertion at all** rather than an error. A test with zero assertions passes if its body completes. So the narrow support was not the defect; the silence was | `cmd/mxcli/testrunner/parser.go` (`expectPattern`, `parseAnnotations`), `cmd/mxcli/testrunner/expect.go` (new — `ParseExpect`, the validating parser), `cmd/mxcli/testrunner/generator_endpoint.go` + `generator.go` (emit the condition, not a rebuilt equality), `cmd/mxcli/testrunner/results.go` (`expectErrorResult`) | Capture the **whole** annotation body and hand it to a validating parser; anything it cannot compile becomes an `ExpectErrors` entry, the test is not generated at all, and the runner reports `StatusError` (which `FailCount` counts, so the exit code is non-zero). The parser is a strict recursive-descent pass over `exprcheck.Lex` — **not** `mdl/exprcheck`'s own parser, which recovers and emits hints, exactly the wrong behaviour here. Two measurements pinned the emitted expression against mxbuild 11.6.6: `<>` really is CE0117 (so the rewrite to `!=` is load-bearing, not cosmetic) and a wrong-typed comparison really is caught (`$result = 3` → CE0117), which is what makes the 0-error run on the 11 generated shapes mean something. **Generalisable**: when a pattern-matching parser can match *less* than its input, the non-match branch is a silent-failure path — audit every `if m := re.FindStringSubmatch(...); m != nil` whose else-branch does nothing. Repro `mdl-examples/bug-tests/expect-vacuous-assertions.mdl`. mxcli-sudoku FINDINGS #46 |", "refs": ["#46"], "ce": ["CE0117"]}
+{"area": "cmd/mxcli", "date": "2026-08-16", "symptom": "A test suite's green is unreadable: a test that asserts **nothing** prints the same `PASS` as one with six assertions, and `@verify` — documented as an OQL post-condition — is parsed and evaluated by nothing at all. After @expect started failing closed, the cheapest way back to green is to delete the assertion, and the output cannot tell that apart from a repair", "cause": "Two silent-absence paths rather than the silent-drop path fixed in the row above. `TestResult` carried no assertion count, so nothing downstream could report one; and `TestCase.Verify` was populated by `parseAnnotations` and read by nothing but `--list` — `grep -n '\\.Verify' cmd/mxcli/testrunner/*.go` returns the parser and the lister, no runner", "file": "`cmd/mxcli/testrunner/results.go` (`TestResult.Assertions`/`SourceFile`, `newResult`, `vacuousResult`, `resultNote`, `VacuousCount`), `cmd/mxcli/testrunner/parser.go` (`AssertionCount`, `AssertionErrors`, the @verify rejection), `cmd/mxcli/testrunner/junit.go` (`junitClassName`, assertions property), `cmd/mxcli/main.go` + `cmd_test_run.go` (`--require-assertions`)", "insight": "Count assertions on the test case and carry them onto every result through **one** constructor (`newResult`) — the previous code built `TestResult` literals at five sites, which is exactly how a new field gets populated in one path and silently missing in another. Report the count on the ordinary result line, not behind `--verbose`: the whole lesson of #46 is that the *default* output must distinguish a test that asserted from one that did not. Vacuous tests warn by default and error under `--require-assertions`, because a smoke test is legitimate but an indistinguishable one is not. **Generalisable**: when auditing an annotation/config field for dead ends, grep for *readers*, not writers — a field with a parser and no consumer is a feature the docs promise and the code does not deliver, and it fails silently by construction. mxcli-sudoku FINDINGS #46 (follow-up)", "refs": ["#46"]}
+{"area": "cmd/mxcli", "date": "2026-08-17", "symptom": "`@verify` cannot fail. No OQL — well-formed or not, true or not, against a real entity or an invented one — makes a test fail: `@verify select count(*) as n from Mod.Game = 999999` reports PASS on a table with one row, and so does `this is not a query`", "cause": "The annotation was parsed into `TestCase.Verify` and read by nothing but `--list`. Same silent-absence class as the dropped `@expect`, in the annotation covering the *harder* half of Mendix testing: most microflows are side effects, so asserting on rows written is the only way to test them", "file": "`cmd/mxcli/testrunner/verify.go` (new — `ParseVerify`, `scalarOf`, `compare`, `runVerifies`), `cmd/mxcli/testrunner/parser.go` (`checkVerifyCleanup`), `runner_endpoint.go` + `runner_attach.go` + `watch.go` (`adminOptions` on `testTarget`), `runner.go` (`rejectVerifyOnLegacyRunner`)", "insight": "Run the OQL over the admin API after the microflow returns, compare against a literal, and keep three outcomes apart: holds → unchanged, does not hold → FAIL with the observed value, cannot be evaluated → ERROR. Three things are enforced rather than left to trip you up, each learned by running it: **`@cleanup rollback` is refused** (the default undoes the writes before the query could see them, so it would assert against the pre-test state); **the result must be one row × one column** (picking a cell out of a table is a guess); and the **legacy after-startup runner refuses the whole suite**, since its tests run during boot with no seam to query at. Split the expected value off at the **last** comparison operator outside quotes and parens, then require the RHS to be a literal — without that check the split silently eats a `where x = 1` and sends a truncated query. **Generalisable**: unit tests with a stubbed endpoint proved the logic and would have shipped it broken — the first real run against a booted app found the OQL endpoint unreachable on that Mendix and the alias requirement, neither of which any stub could show. mxcli-sudoku FINDINGS #48", "refs": ["#48"]}
+{"area": "cmd/mxcli", "date": "2026-08-17", "symptom": "Running `mxcli test` dirties the project: `git status` reports the `.mpr` modified after a run that changed nothing, so a \"run the tests, assert the tree is clean\" CI step fails and a pull request carries a meaningless diff. `mprcontents/` is byte-identical; only the `.mpr` differs, and a `.mpr` diff is opaque", "cause": "The runner injects an `MxTest` module and takes it back out. Cleanup restores the model, but every unit write stamps a fresh UUID into the `.mpr`'s `_Transaction.LastTransactionID` (`updateTransactionID`, in both engines' writers) **and** the insert/delete cycle relays SQLite's pages. Restoring the row alone is measurably insufficient: three consecutive runs then hold the id stable and still produce a different file hash each time", "file": "`cmd/mxcli/testrunner/snapshot.go` (new — `projectSnapshot`, `documentTreeDigest`), `cmd/mxcli/testrunner/runner.go` (`captureProjectState`, `restoreProjectFile` at all three cleanup sites), `cmd/mxcli/testrunner/host.go` (`HostedEndpoint.Remove`)", "insight": "Snapshot the whole `.mpr` before injecting and write it back after a successful cleanup — byte-exact by construction rather than by enumerating what might have changed. Two refusals are load-bearing: **cleanup failed** and **the `mprcontents/` tree moved**. In either case the project is not in the state the snapshot describes, and restoring would turn a visible harmless discrepancy into an invisible misleading one — a tree that reads as clean while the model is not. Write through a temp file + rename so an interrupted restore cannot truncate the `.mpr`. **Generalisable**: a tool that mutates a project to do its work owes a restore that is byte-exact, not semantically equivalent — every consumer downstream of it compares bytes. And when the obvious cause is a single row, measure the file hash before concluding it is the only one. Verified with the reporter's own harness: 3 runs, `.mpr` and `mprcontents` hashes unchanged throughout. mxcli-sudoku FINDINGS #47", "refs": ["#47"]}
+{"area": "cmd/mxcli", "date": "2026-08-17", "symptom": "`run --local --watch` deploys a **half-applied model** when an `mxcli exec` is running, and there is no way to recover: re-running the script writes nothing (it is byte-idempotent), so nothing re-triggers the watcher and the stale build stands", "cause": "`watchAndApply` (`cmd/mxcli/docker/runlocal.go`) rebuilt on the **first** mtime bump. An exec rewrites the `.mpr` and many `mprcontents/*.mxunit` over seconds, so the build snapshots the tree mid-write. There was a settle for the web bundler and nothing for the model. Two behaviours each correct alone: idempotency removed a *recovery path* nobody had written down as one — \"just run it again\" was load-bearing", "file": "`cmd/mxcli/docker/runlocal.go` (`settleSource`, `sourceSettleWindow`, the `case <-ticker.C` branch)", "insight": "Wait for the source mtime to stop advancing (two poll intervals of quiet) before building. The wait is unbounded on purpose — a long exec is the case it exists for, and building late beats building mid-write — but it still honours the interrupt channel so Ctrl-C is not swallowed. `touch` on the `.mpr` remains the force-rebuild hatch, now documented. **Generalisable, twice over**: (a) a change *signal* is not a change *event* — anything polling mtime must debounce or it samples a writer mid-flight; (b) when adding an optimisation that skips work, ask what informal recovery procedure depended on that work happening. **Test trap hit while fixing it**: the first version asserted the file count *after* `wg.Wait()`, which holds against a `settleSource` that returns immediately — the assertion has to read the writer's state at the moment it returned. mxcli-sudoku FINDINGS #45", "refs": ["#45"]}
+{"area": "cmd/mxcli", "date": "2026-08-18", "raw": "| `mxcli check script.mdl -p app.mpr` prints an unqualified `Check passed!` having resolved **nothing** against the project — a misspelled icon, entity or page name sails through the command that was handed the model. Reported as \"check does not validate icon names\", which it does | `cmd_check.go` gated the whole reference pass on `--references`, so supplying `-p` alone ran only the model-free rules. `validate_icon_refs.go` already existed and works (it names the offending icon and the `describe icon collection` command); it returns early when `!ctx.Connected()`, so it simply never ran | `cmd/mxcli/cmd_check.go` (`checkRefs = checkRefs || projectPath != \"\"`, the qualified pass message, help text), `cmd/mxcli/main.go` (flag help) | Make `-p` imply reference resolution — someone who hands the command a project has said what they want — and keep `--references` accepted so existing invocations survive. A run *without* a project now qualifies its verdict by naming what was not resolved. **Generalisable, and the third instance this month**: a clean report that cannot distinguish *checked and clean* from *not checked* is the same defect as a vacuous test assertion. When a feature needs two flags to do its job, the second one is usually a bug. Before adding a validator, check whether one exists and is merely unreachable. mxcli-dbreplication F5 |"}
+{"area": "cmd/mxcli", "date": "2026-08-18", "symptom": "A skill pack mxcli ships teaches a guard that cannot fire: `references/patterns.md` shows a splice caller doing `IF $Q/Rejected THEN -- fail the request`, and a project wrote and then deleted a Java action for that branch", "cause": "The pack's **own** `QueryObject.java` throws `IllegalArgumentException` when `r.rejected && rejectUnsupported` **before** `Core.instantiate`, so a caller that receives a Query at all always has `Rejected = false`. The code is right and the documentation is wrong — and two further places repeated the claim (`SKILL.md`'s field table said `both`, `failure-modes.md` said \"Pass `true`: `Rejected` comes back set\")", "file": "`.claude/skills/packs/mendix-odata-pushdown/references/patterns.md`, `SKILL.md`, `references/failure-modes.md` (embed under `cmd/mxcli/skillpacks/` is regenerated by `make build`)", "insight": "Delete the dead branch from the pattern and say why it cannot run, quoting the throw; mark `Rejected` as a **bind**-caller field. **Generalisable**: when a doc and the code it documents disagree, grep the whole pack — the claim is rarely in one place, and the two secondary mentions were the ones that would have re-taught it. A documented safeguard that silently is not one is the same defect class as a vacuous assertion. mxcli-owid #30", "refs": ["#30"]}
+{"area": "cmd/mxcli", "date": "2026-08-17", "symptom": "`mxcli oql` fails on every Mendix older than 11.11 with *\"Action not found ... upgrade mxcli\"*, and separately reports a **rejected query as `0 rows`** rather than as an error", "cause": "Two independent misreadings of the runtime's replies. (1) The 11.11+ REST route `/dev/preview_execute_oql` does not exist on older runtimes, and the admin API does not 404 it — it dispatches the POST as an ordinary admin request, finds no `action` field, and answers **HTTP 200** with `{\"result\":1,\"message\":\"Action not found\"}`. The fallback to the legacy M2EE action keyed on the 404 alone, so the legacy action — which works fine there — was never tried. (2) That legacy action reports a bad query as `{\"feedback\":{\"error\":\"...\"},\"result\":0}` — inside the feedback, with a **success** result code — so `M2EEError()` (which keys off the result) says nothing and the error body parses as an empty result", "file": "`cmd/mxcli/docker/oql.go` (`legacyOQL`, `oqlDevErrorKind`, the `error` field in `parseOQLFeedback`'s envelope)", "insight": "Fall back to the legacy action on *either* absence signal, and surface `feedback.error` regardless of the result code. Measured on 11.6.6: before, `mxcli oql` could not run any query; after, `select count(*) as n from Mod.E` returns a row, and a bad query is an error instead of `0 rows`. **Generalisable**: when a fallback is keyed on one specific failure signal, check what the *other* end actually sends — an HTTP-level 404 and an application-level \"not found\" are different wires, and a success code next to an error message is common enough to assume it happens. Found while wiring @verify (FINDINGS #48); related to #39", "refs": ["#39", "#48"]}
+{"area": "cmd/mxcli", "date": "2026-08-14", "symptom": "Windows Defender flags the mxcli **Windows** release binary as `Trojan:Script/Sabsik.EN.A!ml`; enterprise EDR (Defender for Endpoint, CrowdStrike, SentinelOne) blocks it harder. Not the generic unsigned-Go-binary false positive of #185", "cause": "The binary genuinely embedded **chisel**, a dual-use tunnelling/pivoting tool (SSH over WebSocket), on every platform — although the tunnel only ever runs inside a Linux container. `run --hub` linked `chisel/client`, `tunnel-hub` linked `chisel/server`, so windows/darwin carried 32 packages incl. the whole `x/crypto/ssh` stack for a feature they cannot use", "file": "`cmd/mxcli/docker/tunnel_linux.go` + `tunnel_other.go` (client seam), `cmd/mxcli/tunnelhub/control_linux.go` + `control_other.go` (server seam), `scripts/check-tunnel-deps.sh` (guard)", "insight": "**Never obfuscate, pack or rename to dodge the scanner** — attacker tradecraft, and it makes the binary less trustworthy, not more. **Code signing does not fix this class**: a signed binary containing chisel is still flagged behaviourally; signing only addresses #185's generic false positive. The fix is to stop shipping the capability where it is unused: one interface per seam, `_linux.go` impl + `!linux` stub, commands still registered everywhere but failing with an actionable message. **Prove absence three ways, and know that `go tool nm` is not one of them** — release ldflags `-s -w` strip the symbol table, so nm reports \"no symbols\" whether or not the code is linked and would give a false pass; use `go list -deps`, `go version -m`, and `strings` (nm only on a deliberately unstripped build). **Guard against the transitive path, not the name**: match the module list (`x/crypto/ssh`, `gorilla/websocket`, `armon/go-socks5`, `jpillora/*`) so re-entry without the word \"chisel\" still trips it, and assert a **positive control** (chisel IS in the linux graph) so the check cannot pass vacuously. Verified by re-adding the import and watching the guard fail on all four windows/darwin targets. Result: -13.5 MB (-14.7%) on windows+darwin, linux unchanged. See ADR-0009", "refs": ["#185"]}
+{"area": "cmd/mxcli", "date": "2026-08-19", "symptom": "`run --local` / `test --local` on macOS (or Windows) die with a raw `fork/exec ~/.mxcli/mxbuild/<v>/modeler/mxbuild: exec format error`, while `setup mxbuild` and `docker build` correctly use Studio Pro's binary. `--mxbuild-path` does not help", "cause": "`MxBuildCDNURL` branches on **GOARCH only, never GOOS** — both URLs are Linux tarballs (Mendix ships macOS mxbuild inside Studio Pro, not on the CDN), so an arm64 Mac caches a Linux *aarch64* ELF: the arch matches, so nothing notices until exec. `docker build` resolves via `resolveMxBuild` (PATH → Studio Pro → known locations → cache) and `setup mxbuild` via `NativeMxBuildForSetup`, but the local loop called `DownloadMxBuild` directly at `runlocal.go` and `StartServe` looked only at the cache. `LocalRunOptions.MxBuildPath` was documented as an override and never read for the serve binary, so there was no workaround either", "file": "`cmd/mxcli/docker/mxbuild_platform.go` (new: `ResolveMxBuildForLocal`, `binaryOS`, `verifyRunsHere`) + `runlocal.go` (the `DownloadMxBuild` call) + `mxserve.go` (`StartServe`)", "insight": "Reuse the rule the codebase already had rather than inventing one: `NativeMxBuildForSetup(goos, version)` returns Studio Pro's path, or \"\" meaning \"Linux, download is fine\", or an error plus guidance. Order: explicit path → (non-Linux) Studio Pro → cache/CDN. **Do not stop the download on Windows** — the cache holds a Linux binary there deliberately, for Docker builds; the fix belongs at resolve/exec time. Guard exec with a magic-byte check (ELF / Mach-O incl. fat / PE) and let an unrecognised format through, since a shell wrapper has no magic and refusing on a guess would block a working setup. **Inject `goos` into the helpers** (`resolveMxBuildForLocalOn`, `verifyRunsOn`): the whole bug is platform-specific and is otherwise untestable from a Linux runner. Repro without a Mac: plant a Mach-O magic at the cache path and call `StartServe` — reproduces the reporter's message verbatim. Tests `TestBinaryOS`, `TestVerifyRunsOn_LinuxBinaryOnMac`, `TestResolveMxBuildForLocal_*`; reverting makes `ExplicitPathWins` fail **by downloading from the CDN for 34s**, which is the ignored override made visible. **Unverified:** no macOS host was available, so the Studio Pro discovery path itself (`resolveStudioProDirMacOS`) is exercised only by its own existing tests. Issue #916", "refs": ["#916"]}
+{"area": "cmd/mxcli", "date": "2026-08-19", "symptom": "Windows: `run --local` behaves as though Java were undetected, and a local run can fail looking for Gradle", "cause": "Two separate things. (a) **The `.exe` suffix**: `isJDK21` appended it, every CONSUMER did not — `--java-exe-path` handed to mxbuild and the path `exec.Command` runs to boot the runtime were both `<jh>\\bin\\java`, so a correctly-detected JDK was passed on in a form that need not resolve. Five sites built it by hand. (b) **Gradle is not mxcli's**: it ships inside the mxbuild bundle (`modeler/tools/gradle`, 8.5) and mxbuild invokes it — mxcli never calls gradle, so \"Gradle missing\" indicates a foreign/incomplete mxbuild bundle, usually #916", "file": "`cmd/mxcli/docker/javaexe.go` (new `JavaExePath`) used from `mxserve.go`, `build.go`, `settle.go`, `localboot.go`, `detect.go`; `jdkSearchPathsFor` in `detect.go`", "insight": "One helper, not five hand-built joins — the sixth call site would have repeated the bug. **Check the platform's own docs before adding a search path**: \"add Studio Pro's JDK\" turned out to be a non-task, because Mendix's install guide says Studio Pro installs **Eclipse Temurin 21** rather than bundling a JDK, so the existing Adoptium glob already IS Studio Pro's JDK; what was genuinely missing was the per-user `%LOCALAPPDATA%\\Programs` install location. Inventing a `Mendix\\<version>\\jdk` path would have been dead code. Make the not-found error list what was searched — \"JDK 21 not found\" alone sends a user reading mxcli's source. Inject `goos` (`jdkSearchPathsFor`, `javaExeName`): the only Windows CI job is the tunnel seam, scoped with `-run`, so it compiles Windows code and executes almost none of it — which is exactly how a missing `.exe` survives. **Unverified**: no Windows host; the fix is code-level with OS-injected tests. Reported via a user relay, not an issue", "refs": ["#916"]}
+{"area": "cmd/mxcli", "date": "2026-08-20", "symptom": "A CLI flag is accepted but does nothing: `mxcli test tests/ -p app.mpr --require-assertions` exits 0 on a suite where every test asserts nothing. `--help` lists the flag, it parses, and the summary line even prints \"1 test(s) asserted nothing\" — so the run looks like it noticed and chose to pass", "cause": "The flag was consulted in exactly one of the two result-assembly loops. `vacuousResult` had a single caller, in the endpoint runner's loop (`--local`, `--attach`); the after-startup runner (Docker default, and `--local --legacy-runner`) assembles results in `ParseLogResults(logReader, suite)`, whose signature had no parameter the flag could arrive through — it could not honour it even in principle", "file": "`cmd/mxcli/testrunner/results.go` (`ParseLogResults`, `preRunResult`), `cmd/mxcli/testrunner/runner_endpoint.go` (`runSuite`), `cmd/mxcli/testrunner/runner.go` (the `ParseLogResults` call in `runAfterStartup`)", "insight": "Give the pre-run verdicts — the ones decided by the *parsed test case* rather than by the run — **one** function (`preRunResult`) and route both loops through it, then pin that it is their only caller (`TestPreRunVerdictsHaveOneCallSite`). Same lesson as the `newResult` constructor two rows up: a decision reachable from one path and not the other is the defect, and a single call site is what prevents the next one. **Do not reach for the refusal precedent without checking it applies**: `rejectVerifyOnLegacyRunner` refuses `@verify` on this runner because it genuinely cannot evaluate it (its tests run during boot, there is no seam to query the app at). `AssertionCount()` is a static property of the parsed test case, known before any runner starts — refusing there would have denied a capability the runner has. **Generalisable**: when auditing a flag for dead ends, grep for its *consumers* and count them against the number of code paths that should honour it; a unit test on the helper (`TestRequireAssertionsMakesVacuousTestsErrors` called `vacuousResult` directly) proves the helper works and says nothing about whether any runner calls it. Issue #926", "refs": ["#926"]}
+{"area": "cmd/mxcli", "date": "2026-08-21", "symptom": "`mxcli test`: (a) a `.test.mdl` file whose first test is preceded by a **file-level `/** … */` header** reports one test fewer — the first one vanishes with no pass, no fail and no error, and every later test renumbers over it; the workaround (a `--` header) re-triggers it the moment that header's **prose spells out `/**` and `*/`**. (b) `@expect count($Var) = N` on a bare `retrieve` block reported **PASS unconditionally** on v0.18.0, for any N, against an empty table", "cause": "Two independent \"substring instead of structure\" defects in `cmd/mxcli/testrunner`. (a) `extractDocAndBody` took the FIRST `/**`…`*/` in a `/`-separated chunk as the test's doc comment. A header is not separated from the test below it by a `/`, so both are one chunk: the header became the doc, carried no `@test`, and the chunk — real test included — was skipped. The delimiters were found by `strings.Index` with no notion of comment or string state, which is why writing them inside a `--` comment recreated the fusion. Test IDs were numbered by **chunk index**, so a skipped chunk left a gap (`test_2` as a file's only test) and the line number came from searching the whole file for the chunk's first 20 bytes (wrong chunk when two start alike; **panics** on a chunk shorter than that). (b) `count()` is not a Mendix expression *function* — counting a list is an Aggregate list **activity** — so `ParseExpect` could not compile it. Pre-0bf9382 that dropped the annotation, and a test with no assertions passes as long as its body does not throw", "file": "`cmd/mxcli/testrunner/parser.go` (`splitTestBlocks`, `extractDocAndBody`, `scanDocComments`, `skipMDLString`), `expect.go` (`expectAggregate`, `parseAggregate`, `collectAggregates`), `generator_endpoint.go` (`writeExpectAggregates`), `generator.go` (`renameExpect`)", "insight": "Scan the chunk (whitespace / `--` / `/* */` / `'…'`) instead of searching it: the doc is the **last** comment of the leading run, the body starts after it, and the line travels with the chunk from `splitTestBlocks`. Number tests, not chunks. **Two `@test` docs in one chunk is refused**, not resolved — either resolution runs one and drops the other, which is the bug. For (b), hoist the aggregate into the activity the author would write (`$mxtest_count_X = COUNT($X);`) ahead of the decision, and refuse `sum`/`average`/`minimum`/`maximum` (they need an attribute an assertion cannot supply) with the helper-microflow workaround named. In the monolithic runner the generated variable must be renamed per test like the body's own, or two tests counting same-named lists declare it twice. **Verify (b) at the Mendix layer, not the parser's**: `mxcli check` accepts plenty that mxbuild rejects — the generated flows were exec'd into a real 11.13.0 project and `mx check` run with a pristine-copy baseline (1 pre-existing error either side). **Controls**: pre-fix binary on the repro file finds 2 of 4 tests; stubbing `isListAggregate` to false restores \"count() is not a Mendix expression function\". Repro `mdl-examples/bug-tests/927-test-mdl-leading-comment-and-count.test.mdl`. Issue #927", "refs": ["#927"]}
+{"area": "cmd/mxcli", "date": "2026-08-21", "symptom": "A `.test.mdl` test gains an assertion, a cleanup strategy or an expected error **nobody wrote**, because a sentence in its doc comment quotes the annotation — writing \"`@expect $x = 1` in a sentence\" gives the test that assertion, and \"@cleanup none would apply here\" changes its cleanup strategy. The invented assertion usually fails to compile, so the test reports an ERROR whose message quotes prose", "cause": "The annotation patterns in `parseAnnotations` were unanchored (`@expect\\s+(.+)`), so they matched anywhere in a line rather than at its start. An annotation is a javadoc **tag**, and a tag opens its line", "file": "`cmd/mxcli/testrunner/parser.go` (the six patterns in the `var (…)` block)", "insight": "Anchor every pattern with `^`. The leading `*` and its indentation are already stripped before they run, so the real spellings — at any javadoc indentation, and the one-line `/** @test x */` form — are unaffected; keep a control asserting that, or a fix that simply stops reading annotations passes. Found while writing the #927 repro file: its header explained the bug, and explaining it created an assertion that then errored against a test nobody had written. **Generalisable**: the sibling of #927's own root cause — a delimiter means nothing outside the structure it delimits, whether that structure is a comment or a line", "refs": ["#927"]}
+{"area": "cmd/mxcli", "date": "2026-08-21", "symptom": "A test carrying both `@throws` and `@expect` reports making two assertions and makes one: the `@expect` is never evaluated, silently. It cannot fail, whatever it claims", "cause": "`@throws` selects a different generated shape in **both** generators (`writeThrowsFlowBody` / `writeThrowsTestBlock`, where the verdict starts as a failure and only the error handler clears it) and neither emits the `@expect` checks — but `AssertionCount` still counted them. Same silent-absence class as the dropped `@expect` and the unimplemented `@verify`, in the one combination where the assertion cannot be made to work at all: the body was expected not to produce a result to assert on", "file": "`cmd/mxcli/testrunner/parser.go` (`checkThrowsExpect`, called from `parseAnnotations` beside `checkVerifyCleanup`)", "insight": "Move the expects to `AssertionErrors` and clear them, so the test is an ERROR and gets no microflow — the annotation pipeline's fail-closed rule. Keep the `@throws` itself: it is the assertion that still stands. **Prove it end to end, not on the struct**: the visible symptom is `AssertionCount` and the generated MDL, so the test parses a file, checks the count, and greps the generated flow for the microflow's absence. Sibling of the `@verify`-under-rollback refusal, which is the precedent for the message shape (name the annotation, name the one-line change)"}
+{"area": "cmd/mxcli", "date": "2026-08-22", "symptom": "A bundled skill renders with a stray `---` fence and a duplicated `name:` at the top of its body, and `mxcli init` ships it that way. `TestEmbeddedSkillsCarryAgentSkillsFrontmatter` passes — the frontmatter it checks is valid", "cause": "The #906 migration **prepended** a `name`/`description` block to every skill, including the one file that already had one (`custom-widgets`, under its pre-rename name `mendix-custom-widgets`). Everything after the FIRST `---` block is body, so the old block became visible text. The test's `frontmatter.FindSubmatch` matches the first block and validates it correctly, which is precisely why it is blind to a second one", "file": "`.claude/skills/mendix/custom-widgets/SKILL.md` (two blocks merged into one, keeping the old block's trigger words — child slots, `.def.json`, engine internals); guard added to `cmd/mxcli/init_skills_standard_test.go`", "insight": "**A first-block check cannot see a rename-and-prepend**, and that is the exact shape of a migration that renames things — so a bulk frontmatter edit needs a guard against a SECOND block, not a better check of the first. **Measure the pre-state before a bulk prepend**: 1 of 68 files already had frontmatter, which was known and written down, and the migration script still did not branch on it. **Do not attribute a defect to the change you are looking at** — this was reported against PR #222, whose diff touches only the `description:` inside the first block and shows the stray `---` as unchanged context; `git log -S 'name: mendix-custom-widgets'` settles it in one command. Two adjacent traps from the same report: `make test` did not depend on `sync-all` while `make build` did, so a bare `go build` left the generated `cmd/mxcli/skills` stale and six tests failed — and the failure message named the `go:embed` directive, which was fine, instead of the missing build step. A **differential across refs is only as sound as the procedure both sides share**: the same stale build made main fail 4 and the branch fail 6, which looked like a regression and was a test-count difference. mxcli-formula1 finding 68", "refs": ["#222", "#906"]}
+{"area": "cmd/mxcli", "date": "2026-08-12", "symptom": "`mxcli run --ensure-db` fails to start PostgreSQL when no service manager becomes ready (e.g. Arch): `exec: \"pg_ctlcluster\": executable file not found in $PATH`, though `initdb`/`pg_ctl`/`psql` are present", "cause": "`startLocalPostgres` only knew the `service`/`pg_ctlcluster` helpers (the latter a placeholder that could never run), and role/database provisioning assumed `sudo -u postgres`, which a user-owned cluster does not need", "file": "`cmd/mxcli/docker/ensuredb.go` (`startLocalPostgres`, `startUserCluster`, `resolveSuperuser`)", "insight": "Fall back to a user-owned `initdb`/`pg_ctl` cluster under `~/.mxcli/postgres`, but never initialize a competitor when the requested TCP port is already owned by a service-started server that is still recovering. Enforce the passwordless-superuser boundary instead of assuming it: explicitly tighten an existing socket directory to `0700`, set the socket itself to `0700`, and persist `listen_addresses`/`port`/`unix_socket_directories` in `postgresql.conf` so a plain later `pg_ctl start` stays safe. Refuse, with a cleanup path, a cluster made by the earlier development revision if its host authentication is still `trust`. Reuse a running cluster only when both the port and socket directory in `postmaster.pid` match. Keep `sudo -u postgres` for system clusters, but make both sudo and psql non-interactive, retain peer authentication over the system Unix socket at the exact requested port, and force SCRAM password storage for pre-14 defaults. Normalize the endpoint once and return it to the runtime; parse the bracketed form before any last-colon IPv6 compatibility fallback. Tests stub every external tool and exercise slow service startup, legacy-cluster refusal, permissions, persisted settings, endpoint propagation, sudo arguments, and repeated/running cases. Issue #823", "refs": ["#823"]}
+{"area": "cmd/mxcli", "date": "2026-08-25", "symptom": "`mxcli test` **panics** — `slice bounds out of range [:-1]` in `extractDocAndBody` — on a `.test.mdl` saved with **CRLF** line endings; the identical file with LF works. Separately, **one unparseable file aborts the whole directory**: `mxcli test tests/` (and `--list`) reports the bad file and runs none of the others", "cause": "Two independent defects behind one report. (1) The line-number estimate searched the **raw file bytes** for the first 20 characters of a block that had already been rebuilt by joining scanner lines with `\"\\n\"` — under CRLF the needle can never match, `strings.Index` returns -1, and `content[:-1]` panics. Fixed as a side effect of #927's block/line pairing (`testBlock` carries its own `Line`), which left it **untested**. (2) `ParseTestDir`/`parseTestFiles` returned on the first file that failed to parse, so an unrelated malformed file cost every other test in the directory", "file": "`cmd/mxcli/testrunner/parser.go` (`TestSuite.FileErrors`, `FileError`, `ParseTestDir`), `cmd/mxcli/testrunner/runner.go` (`parseTestFiles`, `Run`, `dispatchRun`, `reportFileErrors`, `suiteFileErrorResults`), `cmd/mxcli/testrunner/watch.go`; tests `cmd/mxcli/testrunner/parser_crlf_test.go`, `cmd/mxcli/testrunner/parser_file_isolation_test.go`", "insight": "**Never search reconstructed text inside the original bytes** — normalising line endings on the way in and then indexing the raw content is the whole bug, and it is silent on LF machines. **A CRLF test must write the bytes at runtime** (`os.WriteFile`), not live in a checked-in fixture: git's line-ending handling would normalise it and the test would pass vacuously. **Assert on line NUMBERS, not just \"does not panic\"** — the defect lived in a line estimate, so a smoke test would not have detected a wrong answer; the LF file is the control. For (2), the fail-closed rule this package is built around is **ERROR, not abort**: an uncompilable `@expect` becomes a `StatusError` result counted with the failures, and an unparseable file now gets the same treatment — red exit code, file named, other tests still run", "refs": ["#927"]}
+{"area": "cmd/mxcli", "date": "2026-08-25", "raw": "| `mxcli lint --format json \\| jq .` fails with `Invalid numeric literal at line 1`; `--format sarif > results.sarif` writes a corrupt file. stdout begins `Connected to: …` / `Loading cached catalog…` / `✓ Catalog ready` before the payload | The executor is constructed with `executor.New(os.Stdout)` via `newLoggedExecutor`, so every progress line shares the stream the payload is written to. Independent of which formatter runs — the chatter is emitted during connect and catalog build, before the formatter is reached | `cmd/mxcli/output_stream.go` (`isMachineReadableFormat`, `progressSink`), `cmd/mxcli/main.go` (`newLoggedExecutorTo`), `cmd/mxcli/cmd_lint.go`, `cmd/mxcli/cmd_report.go` | Pick the executor's writer from the resolved format: stderr when stdout carries a machine-readable payload (json/sarif/html/markdown), stdout otherwise. Route to **stderr, not io.Discard** — the progress is wanted on a terminal and in CI logs, it was merely on the wrong stream. `mxcli report` needs the extra condition that `-o <file>` frees stdout, so progress goes back to stdout there. Text mode must be left alone; assert that, or the fix silently degrades interactive use. Two commands share this because both build a catalog before formatting; any future command that prints a payload to stdout needs `progressSink` too. Issue #904 (residue) |", "refs": ["#904"]}
+{"area": "cmd/mxcli", "date": "2026-08-25", "symptom": "A brand palette hand-edited into `theme/web/custom-variables.scss` works once, and then `mxcli theme apply` reports the file as `skipped` and refuses to touch it — the project has silently taken the theme out of mxcli's hands to change one colour", "cause": "The theme registry was embed-only: `List`/`Get` read `assetsFS` and nothing else, so there was nowhere to put a fourth theme and the generated block was the only place to put a palette", "file": "`cmd/mxcli/theme/source.go` (the two-source registry), `cmd/mxcli/theme/create.go` (`theme create`), `cmd/mxcli/theme/tokens.go`", "insight": "**A digest fence that refuses an edit is a signal that the thing being edited should have been authorable.** Project-local themes live in `theme/mxcli-themes/` — committed (`.mxcli/` is gitignored by `mxcli init`) and not compiled (mxbuild's entry point is `theme/web/main.scss`; it does not glob `theme/`, verified against a real 11.13 build that nothing under it reaches `deployment/`). Scaffolding **must** rename the identifiers built from the theme name (`@mixin mxcli-<name>-<alt>`, the `@import`) — a plain copy collides the moment both themes exist. Verified end to end: seeded palette → `mxbuild --target=deploy` → measured `--brand-primary` in a real browser in both variants. Tests `cmd/mxcli/theme/create_test.go`, `cmd/mxcli/cmd_theme_test.go`"}
+{"area": "cmd/mxcli", "date": "2026-08-25", "symptom": "A design-derived `--mxt-*` token is written into a theme, the theme applies with every file reporting `created`, and the app renders exactly as before — indistinguishable from the design never having been applied", "cause": "Nothing reads an unrecognised custom property, so a typo (`--mxt-brand-color` for `--mxt-brand`) is a no-op with no error anywhere in the chain", "file": "`cmd/mxcli/theme/create.go` (`validateTokens`, `knownTokens`)", "insight": "**Validate a token vocabulary at authoring time or the failure has no symptom.** `theme create --from` refuses a `--mxt-*` name the base theme does not declare and names it; `mxcli theme show <name>` prints the vocabulary. Related trap: seed only the *scoped* extras into the alt-palette mixin — a variant-independent token like `--mxt-radius` belongs in the palette, and copying it into both means retuning it twice"}
+{"area": "cmd/mxcli", "date": "2026-08-25", "symptom": "A theme's SCSS fails to compile with `Error: Expected expression` pointing at a `$…-scope:` line, and every Go test is green — `mx check` says nothing either, because the failure is in mxbuild's Sass pass, before any model validation", "cause": "A selector was assigned to a Sass variable bare (`$s: :root` or `$s: a, b`). Neither is a Sass expression; only a **quoted string** is, and `#{}` drops the quotes at the point of use", "file": "`cmd/mxcli/theme/theme.go` (`expand`, the `{{SCOPE}}` substitution quotes; `{{PALETTE_SCOPE}}` does not, because that file is plain CSS)", "insight": "**An asset-driven feature whose correctness depends on a compiler the tests never run needs one real compile in the loop.** This shape passed every unit test and broke the build on the first `mxbuild --target=deploy` — the same class as recurring-finding #20. Two placeholders that look interchangeable are not: one lands in plain CSS, one in a Sass expression", "refs": ["#20"]}
+{"area": "cmd/mxcli", "date": "2026-08-25", "symptom": "Applying several themes as a set is never idempotent — `mxcli-fonts/OFL.txt` reports `updated` on every run, forever — and the installed licence covers the wrong fonts", "cause": "Every theme vendored a different font family and wrote its SIL OFL text to the *same* path. With one theme installed the last apply won and it settled; with a set, each theme overwrote the previous one on every pass", "file": "`cmd/mxcli/theme/assets/*/files/theme/web/mxcli-fonts/OFL-<theme>.txt` (renamed per theme)", "insight": "**Two themes writing different content to one verbatim path is a licensing bug before it is a churn bug** — the churn is just the symptom that made it visible. `TestThemesDoNotClaimTheSameVerbatimPathWithDifferentContent` hashes every non-fenced file across every theme and fails on a collision; controlled by renaming them back, which reproduces the original failure"}
+{"area": "cmd/mxcli", "date": "2026-08-25", "symptom": "A JavaScript action with a parameter throws `<Param> is not defined` the first time a user clicks it. `mx check` reports 0 errors, `mxcli check` says nothing, the build is clean, and the generated file cannot be patched — it is rewritten on every build", "cause": "mxbuild **lowers the first letter** of a parameter when it generates the wrapper: `Skin: String` reaches the body as `skin`. A body written with the modelled spelling is a ReferenceError, and nothing between MDL and the click can see it — Mendix treats the body as opaque user code", "file": "`cmd/mxcli/theme/switcher.go` (both parameterised actions); the same rule applies to any `create javascript action` with parameters", "insight": "**Model the parameter capitalised, read it lowercased.** Verified against a real 11.13 build (`export async function SetAppSkin(skin)`) and in a browser by importing the generated module and calling it — `ReferenceError: Skin is not defined` before, the correct return after. The guard walks *every* parameter of *every* generated action, so a new one cannot reintroduce it. Note the trap in writing that guard: a regex anchored on `javascript action` also matches `call javascript action` in the nanoflows, which made the first version run past a real declaration and pass against the very defect it was written for — anchor on `create or modify javascript action` and assert the match count. ako/mxcli-ledger #135", "refs": ["#135"]}
+{"area": "cmd/mxcli", "date": "2026-08-25", "symptom": "`mxcli theme create` lists `theme/web/custom-variables.scss` and `theme/web/main.scss` as `created`, on a project that has hand-written versions of both. Nothing was touched", "cause": "The reported paths were relative to the scaffold, not to the project, so they collided exactly with the app paths — printed by the one command whose whole purpose is to write into `theme/`", "file": "`cmd/mxcli/theme/create.go` (`CreateResult.Files` carries scaffold-root-relative paths), `cmd/mxcli/cmd_theme.go` (prints them under the scaffold root)", "insight": "**A path in output is a claim about a location.** Two files in different trees sharing a relative path means the output has to carry the root or it asserts the wrong one. `theme.json` sits at the scaffold root and everything else under `files/`, so the result carries that distinction rather than the printer re-deriving it. ako/mxcli-ledger #139", "refs": ["#139"]}
+{"area": "cmd/mxcli", "date": "2026-08-26", "symptom": "A test written with a bare `@throws` fails on the very exception it was written to expect, reporting \"exception during execution\" and \"no assertions\"", "cause": "`mxcli test` treats a test as a throws-test only when the annotation carries a NON-EMPTY message (`generator_endpoint.go`, `if tc.Throws != \"\"`), so a bare `@throws` is silently ignored and the exception propagates as a failure. The message itself is **never compared** — `@throws 'ZZZ-NOT-THE-REAL-MESSAGE'` passes against any error — so it documents intent rather than asserting it", "file": "`cmd/mxcli/testrunner/generator_endpoint.go` (`writeThrowsFlowBody`, `rewriteBodyForThrows`)", "insight": "Write `@throws '<description>'` and give the test its meaning with a CONTROL — the same call with input that must NOT throw — because the annotation alone only proves something was raised, not what. Two separate defects to fix: a bare `@throws` should be a parse error rather than silently dropped, and the message should either be matched or documented as unmatched (the annotations reference shows `@throws 'validation failed'`, which reads as a match). Found while asserting #261's `or error` at run time", "refs": ["#261"]}
+{"area": "cmd/mxcli", "date": "2026-08-27", "symptom": "`mxcli run --local` on a Mendix 11.14 app dies at `bundling web client: no rollup.config.mjs in …/deployment/web (run a serve Deploy build first)` — and a serve Deploy build HAS just run", "cause": "11.14 bundles the browser client itself. `BuildWebClient` exists to close a gap that 11.13 and earlier left (client source + a rollup config, but no bundler run), and its gate tested for the CONFIG, so it failed on the absence of a file whose purpose had been served. Measured on a blank app, same build target: 11.13 `rollup.config.mjs` PRESENT / `dist/index.js` ABSENT; 11.14 exactly inverted", "file": "`cmd/mxcli/docker/webclient.go` (`BuildWebClient`), called fatally at `runlocal.go:664` and `:1091`", "insight": "**Gate a compatibility step on the GAP it closes, not on the shape one version happened to leave behind.** Skip when `WebClientBundled(deployDir)` is already true; keep requiring the config when it is not, because then rollup is the only thing that can produce a bundle. Do NOT make it an unconditional no-op when `dist/` exists — `runlocal.go:1091` re-bundles when the file is present but not SERVED, and a blanket skip would break that recovery. The doc comment called it \"no-op-safe\" and it was not; it is now. Affects EVERY 11.14 app, so a version-gated workaround is wrong — the condition is about the bundle, not the version. ako/mxcli-ledger #146", "refs": ["#146"]}
+{"area": "cmd/mxcli", "date": "2026-08-27", "symptom": "A project made by `mxcli new --version 11.14` fails its very first build with `error: release version 25 not supported`, and installing a JDK 25 moves the failure to boot (`UnsupportedClassVersionError … class file version 69.0`)", "cause": "Mendix 11.14's `mx create-project` writes `JavaVersion = 25`, but mxcli builds and launches the runtime on **JDK 21** and validates it (`resolveJDK21` refuses any other `JAVA_HOME`). Compiling for 25 and running on 21 cannot work in either direction — and 11.14's own runtime bundles are still Java 21 class files (major version 65)", "file": "`cmd/mxcli/cmd_new_java.go` (`alignJavaVersion`, `runtimeMaxJavaVersion`), called from `cmd_new.go` **before** the first build; the launcher side is `cmd/mxcli/docker/detect.go` (`resolveJDK21`)", "insight": "**Lower the project, do not raise the JDK.** Set `JavaVersion` to what the runtime launcher actually uses, and only when the project asks for MORE — so it is a no-op on 11.13 and disappears by itself when the launcher becomes version-aware. Order matters: align BEFORE `SettleGeneratedSources`, or that build is the thing that fails. Mendix then warns \"Java versions below 25 are deprecated\", which is a deprecation on a project that builds rather than an error on one that does not. An unparseable version is left alone rather than overwritten. `runtimeMaxJavaVersion` and `resolveJDK21` must move together — there is a test asserting it. ako/mxcli-maintenance #1, #3", "refs": ["#1", "#3"]}
+{"area": "cmd/mxcli", "date": "2026-08-27", "raw": "| A Mendix 11.14 project will not build (`error: release version 25 not supported`) or, if built elsewhere, will not boot (`UnsupportedClassVersionError … class file version 69.0`) | mxcli resolved a JDK **21 unconditionally** and refused any other `JAVA_HOME`. Studio Pro 11.14 supports Java 25 and its blank app asks for it, so the Java release is now a per-project variable (Settings > Model > JavaVersion) rather than a constant | `cmd/mxcli/docker/javaversion.go` (`ProjectJavaMajor`, `ParseJavaMajor`), `cmd/mxcli/docker/detect.go` (`resolveJDK`, `isJDK`, `jdkSearchPathsFor`); the four call sites are `build.go`, `settle.go`, `mxserve.go`, `localboot.go` | **Resolve the JDK from the project, not a constant** — and use the SAME major for the build and the runtime, because class files from a newer release cannot be loaded by an older JVM. Two traps. (1) The version glob is matched against `java -version` text, so the major must be followed by a dot, whitespace or the closing quote — a bare `21` also matches `210`; there is a test. (2) Zero must mean the default, or every options struct that forgets the field silently changes behaviour. The control worth running: boot a Java **21** project with `JAVA_HOME` pointing at a JDK **25** — it must ignore it and find the 21, and `ps` per-process is the only reliable way to check, since a stale JVM from an earlier run will fool `ps | head -1`. ako/mxcli-maintenance #1 |", "refs": ["#1"]}
+{"area": "cmd/mxcli", "date": "2026-08-27", "symptom": "CI's `build-and-test` fails on every open PR with a **compile** error in a `_test.go` file — e.g. `undefined: resolveJDK21` — while `make build`, `make test` and `make lint` are all green locally, and the failing job burns ~30 minutes before reporting it", "cause": "The file is behind `//go:build integration`. A bare `go vet ./...` and `go test ./...` do not compile it, so a rename can leave it uncompilable and the entire fast gate stays green. The break lands on **main** and every open PR inherits it, which makes it look like N separate PR failures", "file": "The stale call site (here `cmd/mxcli/docker/build_integration_test.go`), and the gate that missed it: `Makefile` (`vet`)", "insight": "**Fix it on a branch off `main`, not in the PRs** — they all inherit it, and fixing it in one leaves the others red. Then close the gap: `make vet` now vets once per build-tag set (`\"\"` and `integration`), which type-checks the tagged files in seconds without needing mx, a JDK or Docker. Grep for stale references with `go vet -tags integration ./...` before renaming anything an integration test touches. Where the renamed symbol became version-aware, do NOT just pass the old constant back in — `resolveJDK(21)` would reinstate exactly the assumption the rename removed; resolve from the project (`ProjectJavaMajor`), which for a skip guard means moving it after the fixture is scaffolded."}
+{"area": "cmd/mxcli", "date": "2026-08-27", "raw": "| A `mxcli test` case written with a bare `@throws` reports **FAIL … exception during execution** — it fails on the very error it was written to expect — and separately, `@throws 'ZZZ-NOT-THE-REAL-MESSAGE'` reports **PASS** | Both generators keyed a throws test on `tc.Throws != \"\"`, and a bare annotation leaves `Throws` empty — the same value an ABSENT annotation leaves, so the two states were indistinguishable and the bare form was dropped in silence. The message half was decorative: the generated `ON ERROR` handler cleared the pre-set failing verdict for **any** exception, so a stale or simply wrong expectation kept passing against a completely different error. The regexp required the quotes, so an unquoted message matched nothing and removed the `@throws` entirely | `cmd/mxcli/testrunner/parser.go` (`parseThrows`, `TestCase.ExpectsThrow`, `expectsThrow()`), `generator_endpoint.go` (`throwsHandler`), `generator.go` (`throwsFlagHandler`) | **`$latestError/Message` is available inside an `ON ERROR` handler and compiles** — measured at 0 errors on mxbuild 11.6.0 and 11.13.0, with `$noSuchThing/Message` as the control (**CE0109** \"Undefined variable\"). Match with `contains`, not equality: a real Mendix message carries an activity name or an object id the test cannot predict (`Could not find object of type 'RtMap.Person'`), so equality would make most expectations unwritable. Two fields can say \"this is a throws test\" and they must not disagree — read them through **one accessor** (`ExpectsThrow || Throws != \"\"`), or every existing construction site that sets only the message silently becomes a non-throws test. Prove it at RUNTIME, not on the generated MDL: the control (`if want == \"\"` → `if true`, rebuilt) reproduces both reported symptoms verbatim against `mdl-examples/bug-tests/mapping-runtime-proof.test.mdl` under `run --local --test-endpoint` + `test --attach`. That suite's own `@throws 'the object was not found'` was **wrong and passing** — a fixed matcher turns a wrong expectation red, so expect to correct existing tests. ako/mxcli#301 |", "refs": ["ako/mxcli#301"], "ce": ["CE0109"]}
+{"area": "cmd/mxcli", "date": "2026-08-27", "symptom": "`mxcli test <dir>` prints `Found 0 test(s) in 1 file(s)` then `no tests found in the provided files`, for a directory that visibly contains a `.mdl` test", "cause": "Discovery matches on the file NAME (`*.test.mdl` / `*.test.md`), and nothing said so. The `1 file(s)` was the DIRECTORY counted as a path, so it read as though a file had been opened and found wanting", "file": "`cmd/mxcli/testrunner/runner.go` (`emptySuiteError`, `parseTestFiles`), `cmd/mxcli/testrunner/parser.go` (`TestSuite.FilesRead`, `ParseTestDir`)", "insight": "**Count files read, not paths given** — one directory is one path and zero-to-many files. When the suite is empty, name the `.mdl`/`.md` files that were skipped for their name: a `.mdl` in a test directory is almost always the intended test misnamed, so listing it turns a dead end into a rename. Do NOT list unrelated extensions (`.txt`), and on a genuinely empty directory do NOT claim files were skipped — describe the format instead. Both branches have tests, and `FilesRead` has a positive control so it cannot pass by never being incremented. ako/mxcli-maintenance §5"}
+{"area": "cmd/mxcli", "date": "2026-08-28", "symptom": "Under `run --local --watch`, after roughly ten hot-applies a page dies with the runtime's generic error dialog and `runtime.log` fills with `404 - file not found for file: dist%2Fchunks%2F<hash>.js`. The model is clean, `mx check` is clean, and a plain restart fixes it with no model change", "cause": "The browser bundle is internally inconsistent: `index.js` imports a content-hashed chunk that is not on disk. `ensureClientServed` probes **only `/dist/index.js`**, which is served with a 200 in this state — so the apply is reported as successful and the fault reads as an application bug", "file": "`cmd/mxcli/docker/webclient_chunks.go` (`danglingClientChunks`), called first from `ensureClientServed` in `runlocal.go`", "insight": "**Walk the import graph from `index.js`, and follow only chunks that EXIST.** An orphan left by an earlier bundle references old hashes, so scanning every file in `chunks/` reports a healthy bundle as broken. One level is not enough either — a real rollup bundle has `index.js` importing a single chunk with the rest hanging off it, so a one-level check misses almost every real breakage. The safety control matters more than the detection here, because this gates an automatic re-bundle: run it against several REAL built bundles and require zero findings, then delete one referenced chunk from a copy and require detection. ako/mxcli-maintenance-2"}
+{"area": "cmd/mxcli", "date": "2026-08-28", "symptom": "A documented `~/.mxcli/mxbuild/*/modeler/mx check app.mpr` fails with `Verb '/root/.mxcli/mxbuild/<other>/modeler/mx' is not recognized`, and it looks like a broken mxbuild install", "cause": "The shell expands the `*` to every cached version and `mx` reads the second path as an argument. Both binaries are fine; it is purely the command line, and the failure mode is misleading enough that an earlier report recorded the wrong binary as broken", "file": "`cmd/mxcli/init_claudemd.go` (the generated project docs), plus ~15 `.md` files including three SYNCED skills (`manage-security`, `custom-widgets`, `alter-page`)", "insight": "**Document `mxcli docker check -p <app>.mpr` first** — it resolves the version from the project, which is the whole problem. Where `mx` must be called directly, name a version (`<version>`), never glob. Note the split: `filepath.Glob` in Go (`cmd/mxcli/docker/detect.go`) is CORRECT and must not be \"fixed\" — it globs then picks, whereas a shell passes all matches through. This reaches every user, since anyone who has used two Mendix versions has two cached. ako/mxcli-maintenance-2"}
+{"area": "cmd/mxcli", "date": "2026-08-28", "raw": "| A test fails only on CI and never locally — e.g. `TestWatcherDebounce`: `expected 1 debounced message, got 2` | The test ASSUMED a timing premise instead of checking it. A debounce test needs the whole burst of writes to land inside the debounce window; each write resets the timer, so a gap larger than the window splits the burst and it debounces as two. On a loaded runner one gap between five `os.WriteFile` calls exceeded 500ms | `cmd/mxcli/tui/watcher.go` (`newWatcherDebounced`, the window is a field not a constant), `cmd/mxcli/tui/watcher_test.go` | **Get the observed value out of the CI log before theorising** — `gh run view <id> --log \\| grep <test>`. I guessed \"count 0, event delivery too slow\" and built two controls for it; both passed, because the log said `got 2` and the real mechanism was the opposite one. Three fixes, each aimed at the measured failure: a window far longer than production (2s vs 500ms) so headroom is orders of magnitude rather than 2×; the premise **measured and skipped on** (`if burst >= debounce { t.Skip }`) so a machine too slow to emit a burst reports its own limitation instead of a product defect; and the message **polled for, not slept for**, so delivery latency cannot decide the outcome. The grace after the first message must be a FULL window — a split's second timer fires one window after the last write, so a shorter wait stops looking before the evidence arrives. Control the mechanism deterministically (100ms window, 150ms gaps → count 5) rather than trying to reproduce load, and verify the skip path actually fires (temporarily set the window to 1ns). This is the checklist item \"tests don't rely on `time.Sleep` for synchronization\" — the original even named the hazard in a comment without removing it. |"}
+{"area": "cmd/mxcli", "date": "2026-08-29", "symptom": "CodeQL `go/incorrect-integer-conversion` (high) on `strconv.ParseUint(…, 16, 32)` narrowed to `int`", "cause": "The parse width was chosen from the *field's* width in the file, not the *type's*. A TCP port is 16 bits and the kernel writes it `%04X`, so a 32-bit parse accepts values the caller then compares as if they were ports; where `int` is 32 bits the conversion wraps (`FFFFFFFF` → `-1`, `ok=true`)", "file": "`cmd/mxcli/docker/portowner_linux.go` (`hexPort`)", "insight": "**Parse at the target type's real width and let the parser do the range check** — that is the whole fix, and it turns an unchecked narrowing into a rejection at the boundary. Establish reachability before rating it: the input here is `/proc/net/tcp`, written by the kernel, so no hostile value reaches it and the consequence of the wrap is a *missed* port match (the diagnostic falls back to its generic message), not memory unsafety. Two things make it worth fixing anyway — a range check that lives in the parser cannot be forgotten by the next caller, and the alert otherwise stays open forever. Measure the wrap rather than asserting it: a `GOARCH=386` binary **runs on an amd64 host**, so the 32-bit behaviour is directly observable, and the same run showed the repo does not currently build for 386 at all (`mdl/settingsoverlay` has `9007199254740992` as an untyped int constant) — worth knowing before claiming a 32-bit impact. A test written at 64 bits still catches it: at width 32 `hexPort` returns `4294967295, true` where it should refuse. Keep a 32-bit-safe test literal (`int(^uint32(0))`, not `4294967295`, which is not a valid `int` constant on 386)."}
+{"area": "cmd/mxcli", "date": "2026-08-29", "raw": "| CodeQL `go/unsafe-unzip-symlink` on a tar extractor that already checks the joined path and the symlink target — looks like a false positive | It is not. A **chain of two symlinks** escapes: the guard resolves each link against its **lexical** parent while the OS resolves it against its **real** one. `sub/up -> ..` genuinely is the root (allowed, correctly); `sub/up/w -> ..` therefore really is `root/w`, pointing at the root's **parent**, and lexically looks like `root/sub`. Then `sub/up/w/pwned` contains no `..` and passes every check | `cmd/mxcli/docker/download.go` — one `extractTarGzInto` on `*os.Root` behind both `extractTarGz` and `extractTarGzStrip1`, plus `tarEntryPath` / `symlinkStaysInside` / `pathWithin` | **Try to break it before rating it, and keep trying after the first six attempts fail.** Six single-step archives (absolute link, `../..` link, absolute name, link-to-root, …) were all correctly refused, which is exactly what makes \"false positive\" tempting; the seventh — two chained up-links — wrote a file into the extraction root's parent, and an eighth reached any sibling directory. The fix is `os.OpenRoot` + `Root.OpenFile`/`MkdirAll`/`Symlink` (Go 1.24/1.25), which hands containment to the kernel (`openat2` `RESOLVE_BENEATH`) instead of to string comparison — the failure is then `path escapes from parent` from the OS. Keep a **link-target** check as well and resolve its parent with `EvalSymlinks`: `os.Root` stops *mxcli* following an outward link, not mxbuild or the JVM that read the tree afterwards. Two things the rewrite fixed for free: `strings.Contains(name, \"..\")` silently dropped legitimate files (`foo..bar` never appeared, no error) — `filepath.IsLocal` is the right test, on path *elements* — and a `HasPrefix` containment test with no separator puts `/cache/runtime-evil` inside `/cache/runtime`. Settle \"would refusing break real downloads?\" by measurement, not caution: the 11.13.0 CDN tarballs are 3,646+279 (runtime) and 33,188+5,036 (mxbuild) entries with **zero symlinks**, listed with `curl \\| tar -tzv` without saving the archive. Control both directions — the ordinary-archive test must pass, and against the old extractor the chained cases must actually write outside (they do, in both the stripping and non-stripping variants). |"}
+{"area": "cmd/mxcli", "date": "2026-08-30", "raw": "| `mxcli run --local`/`--hub` sits at several hundred percent CPU for hours while the app is gone; `ps -o stat` shows the runtime JVM as `Z` (zombie) under it, `curl localhost:<app-port>` returns `000`, and the hub preview URL still answers | `cmd/mxcli/docker/localboot.go` (`watchExit`, `alive`, `stopProcess`), `cmd/mxcli/docker/runlocal.go` (`waitForInterruptOrExit`, `runtimeStoppedError`) | Two mechanisms. (1) **Nothing ever called `Wait()`** on the runtime process, so an exited JVM stayed an unreaped zombie — and `alive()` asked `Signal(0)`, which **succeeds on a zombie**. Measured (Linux 6.18, go1.26): proc state `Z`, `Signal(0)` → nil; after `Wait()` → \"process already finished\". So the liveness check reported a runtime that had terminated itself hours earlier as alive. `Signal(0)` is only a correct liveness test *because* something reaps — removing `watchExit` silently breaks that line, which is why the control is on the reaper, not on `alive()`. (2) **After boot, `run` waited on a signal and nothing else**, so a correct answer had no one asking; it now waits on the signal OR `rt.Exited()` and returns a **non-zero** error, because returning 0 after the app has gone is what let a supervisor conclude all was well. **Why it happens at all**: the local standalone runtime uses a development licence with a maximum run time and terminates *itself* (measured lifetimes 3h52m and 5h07m — not a fixed number, and shorter than a working session); `runtimeExitReason` lifts that from the runtime's own log, and reports nothing rather than guessing when it cannot tell. **Two waiters on one process deadlock**, so `stopProcess` consults the reaper's channel instead of taking its own `Wait`. The CPU spin itself was NOT reproduced and is not claimed fixed by name — it lived in the tunnel client, under a supervisor blind to its dead child; what is fixed is the state it occurred in, since mxcli now exits and takes the tunnel with it. **Generalisable**: a 200 from a tunnelled URL is not evidence the app is alive — the tunnel outlives the runtime. Reported as mxcli-formula1 FINDINGS §60 |"}
+{"area": "cmd/mxcli", "date": "2026-08-30", "raw": "| A widget keyword the grammar accepts is absent from `mxcli syntax page widgets`, so it is concluded not to exist and worked around at length (reported for `tabcontainer`, which cost two days and five hand-rolled pages) | `cmd/mxcli/syntax/features_page.go`, `cmd/mxcli/syntax/widget_keywords_drift_test.go` | The lesson the reporter drew — \"absence from the documentation is not absence from the grammar\" — is true and is a bad thing for the docs to require. `TestEveryWidgetKeywordIsInAPageSyntaxTopic` makes it false instead: it reads the `widgetTypeV3` rule out of the **committed** `.g4` (only the *generated parser* is uncommitted, and the grammar is the authority the reporter was told to consult) and fails when a keyword appears in no `page.*` topic. It found **18**, not one. Exemptions go in `documentedElsewhere` **with the topic that owns them** — layout constructs (`scrollcontainer`, `region`, `navigationtree`, `menubar`, `placeholder`) and pluggable-widget object-list keywords (`group`, `series`, `marker`, …) are not page widgets; an entry with no home is the same defect. The guard carries its own vacuity control: a keyword that does not exist must not match, and one that does must. **Do not document a keyword without running it** — probing all 18 on 11.13 found four the parser accepts and the *default engine refuses* (`statictext`, `staticimage`, `dynamicimage`, `dropdown` → \"widget *pages.X not yet supported by the modelsdk engine\"), two refused on both engines (`referenceselector`, `legacydatagrid`), and one whose bare form emits **CE0463** (`image`). Reported as mxcli-formula1 FINDINGS §69 |", "ce": ["CE0463"]}
+{"area": "cmd/mxcli", "date": "2026-08-31", "symptom": "Every open PR goes red at once on `build-and-test` with a failure in a package none of them touched — `--- FAIL: TestSessionLog_PersistAndPrune`, \"after reload+prune: 0 records, want 1\" — and the same test fails on a clean checkout of `main`", "cause": "A **time bomb in the test**, not a regression: the fixture pinned `base := time.Date(2026, 8, 1, ...)` against a 30-day retention window, and `NewSessionLogFile` prunes inside `load()` — *before* the test can assign `log2.now`, so the reload prune runs on the real `time.Now()` whatever clock is injected afterwards. It passed for 30 days and then failed permanently, on every branch simultaneously", "file": "`cmd/mxcli/tunnelhub/sessions_test.go` (`TestSessionLog_PersistAndPrune`), `cmd/mxcli/tunnelhub/sessions.go` (`load` → `pruneLocked` → `clock`)", "insight": "**First establish it is not yours**: run the failing test on a clean `origin/main`. Several PRs failing on one unrelated test is the signature. Then make the fixture relative — `base := time.Now().UTC()` — so the record ages, not the calendar, decide the outcome; the other tests in the file keep their fixed base legitimately, because they use `NewSessionLog` and inject the clock before recording. **A date fixture is only safe where no code path reads the real clock**; the moment a constructor prunes, expires or compares against `time.Now()` before the seam is in place, an absolute date has a fuse on it. Control the repair: stub `pruneLocked` to a no-op and confirm the test still fails (2 records, want 1), or the fix is just a test that stopped testing"}
+{"area": "cmd/mxcli", "date": "2026-08-31", "symptom": "`mxcli test --local` cannot start a runtime for ANY project: `Error: local runtime: runtime admin API did not come up: runtime process exited during startup`, then `java.lang.IllegalArgumentException: Path '<project>/.mxcli/deployment-test/model/bundles' cannot be resolved in base path '<project>/.mxcli/deployment-test'`. The tree has `data/` and no `model/`", "cause": "**mxbuild writes the deployment to `<app dir>/deployment` and has no option to move it** \u2014 measured, not inferred: `--target=deploy` on a project whose `deployment/` had just been deleted recreated it there, `mxbuild --help` lists no deployment-path flag, and `BuildRequest` carries none. So giving the test boot a `DeployDir` of its own moved where the RUNTIME reads and not where the BUILD writes, and it booted against an empty directory. `StartLocalApp` now refuses a `DeployDir` the build will not populate, naming mxbuild as the constraint. The \u00a762 blanking the scratch tree was meant to prevent is fixed the only way the constraint allows: `preserveWebClientBundle` copies `deployment/web/dist` aside before the boot and puts it back after (a few MB of copy, against the ~30s re-bundle that made warning the earlier choice), restoring only when the bundle is actually gone so a fresher one is never clobbered.", "file": "`cmd/mxcli/docker/localapp.go` (`checkDeployDirIsBuildable`, the `preserveWebClientBundle` call), `cmd/mxcli/docker/webclient_preserve.go` (new), `cmd/mxcli/docker/localapp_integration_test.go` (new), `cmd/mxcli/testrunner/localapp_options.go`, `cmd/mxcli/testrunner/runner_local.go`, `cmd/mxcli/testrunner/runner.go`", "insight": "**The lesson is in the tests that did not catch it**, and two reporting projects drew it independently (mxcli-ledger \u00a7150, mxcli-sudoku \u00a751): four unit tests asserted `DeployDir` was set, was under `.mxcli/`, was per-project and was not the dev loop's \u2014 all four passed against a build that could not start, because every one was about the OPTION while the symptom lived in what is on disk after mxbuild runs. A fix that redirects a consumer without redirecting the producer moves the failure rather than removing it. The guard is now an integration test asserting the artefact: after a real build, the directory the runtime boots against holds `model/bundles`. Note the reporters' prescribed fix \u2014 thread `DeployDir` through the build \u2014 is not available; mxbuild has no such parameter, which is why the shared tree is accepted and the bundle carried across instead. Controls, both end-to-end on a real 11.13 project: the pre-fix binary reproduces the reported JVM error byte for byte while the fixed one passes; and with `preserveWebClientBundle` stubbed the sentinel bundle is destroyed by a test run that still reports all tests passed. Reinstating the regression fails the new integration test naming both missing paths."}
+{"area": "cmd/mxcli", "date": "2026-09-01", "symptom": "After `mxcli test --local`, a live `mxcli run --local` serving the SAME project starts answering **HTTP 200 with a zero-byte body** on every microflow-backed resource \u2014 not a 500, not an error page \u2014 while source-backed ones keep working, so half the app looks fine. The runtime log shows `java.lang.NoClassDefFoundError` on a project class. In a two-app solution it surfaces as tests failing in the OTHER app.", "cause": "The test run recompiles the project's Java into `deployment/run/bin`, which is the classpath the running JVM is holding open. Measured on a real 11.13 project: after one test run all 134 class files have **new inodes and byte-identical content** \u2014 every one deleted and rewritten. A JVM loads classes lazily, so one it has not reached yet can fail permanently. mxcli cannot prevent this: mxbuild's Gradle pass owns the compile and the deployment directory cannot be moved (ledger \u00a7150). So it warns instead, which is what was missing.", "file": "`cmd/mxcli/devloop_recompile_warning.go` (new \u2014 `warnIfDevLoopServing`, `recompileWarning`), `cmd/mxcli/cmd_test_run.go`; reads the existing `cmd/mxcli/devloop_handshake.go`", "insight": "**The mechanism already existed and a duplicate would have broken it.** `mxcli run --local` publishes `devLoopHandshake` at `.mxcli/run-local.json` for `mxcli constant set --apply` \u2014 same path, same pid-liveness staleness check, plus the `adminPass` and `bootConfig` that `--apply` and `--attach` depend on. A second state file was written at that path before this was noticed; it parsed fine (JSON ignores unknown fields) but its WRITER would have silently dropped those two keys. Grep the path before inventing a file. **The liveness check is the feature**: a `run --local` killed or ended by its development licence (\u00a760, measured lifetimes under six hours) leaves the file behind, and a warning driven by the file alone fires forever \u2014 one that is always wrong teaches the reader to skip it. It **warns rather than refuses**, since the warm loop exists so an app can stay up while you work and the reporting project runs two apps that way; neither `--attach` nor `--skip-build` builds, so neither warns. The finding's cost was diagnosis, not breakage \u2014 108 log lines and a wrong hypothesis about a different app, for something whose remedy is one restart \u2014 so the warning names the symptom (HTTP 200, empty body), the part nobody guesses. Controls, end-to-end against a real `run --local`: the warning carries that app's actual pid and port and its handshake still has adminPass and 9 bootConfig keys afterwards; with the loop stopped, and with a stale dead-pid handshake, the same command is silent. Reported as mxcli-formula1 FINDINGS \u00a781."}
diff --git a/.claude/skills/fix-issue/findings/mdl-backend.jsonl b/.claude/skills/fix-issue/findings/mdl-backend.jsonl
new file mode 100644
index 0000000000..bbdd546813
--- /dev/null
+++ b/.claude/skills/fix-issue/findings/mdl-backend.jsonl
@@ -0,0 +1,83 @@
+{"area": "mdl/backend", "date": "2026-07-31", "symptom": "A microflow writes and `mxcli` reports success, but Studio Pro cannot open the project: `System.Collections.Generic.KeyNotFoundException: The given key '<guid>' was not present in the dictionary`. Triggered by a `break`/`continue` inside an if/case within a loop", "cause": "`microflowObjectToGen`'s `default:` branch returns nil for an unhandled object type, so the event object was dropped at serialization while the SequenceFlow pointing at it was written — a DestinationPointer to a GUID that exists nowhere. Exactly the shape already fixed once for `Microflows$ErrorEvent`", "file": "`mdl/backend/modelsdk/microflow_write.go` (`microflowObjectToGen`) — compare against `sdk/mpr/writer_microflow.go`, which handles the full set", "insight": "Add the missing `case *microflows.XxxEvent:` returning the gen element with ID, position and size. **Diagnose without Studio Pro**: dump the microflow (`mxcli bson dump --type microflow --object M.F`), collect every `$ID`, and check every key ending in `Pointer` resolves — a dangling pointer is this bug. When a check-time rule exists only as a stopgap for a write-path bug (MDL051 was), remove it with the real fix, and check whether it covered every affected keyword (MDL051 covered `break`, not `continue`, which is how #791 reached users). Repro `mdl-examples/bug-tests/791-loop-continue-dangling-flow.mdl`. Issue #791, ledger #52", "refs": ["#52", "#791"], "rules": ["MDL051"]}
+{"area": "mdl/backend", "date": "2026-07-30", "symptom": "An **external (OData) entity** loses its remote settings on any read-modify-write — `describe external entity` says `is not an external entity (source: )`, and `alter entity … set allow_create_change_locally = true` reports success but the flag stays off. Works under `--engine legacy`", "cause": "`entityFromGen` recognised only `DomainModels$OqlViewEntitySource`, so the three `Rest$OData*` sources read back as no source at all: `Source` empty, every remote field zeroed. The write path was fine — it switches on `e.Source`, which the read never populated", "file": "`mdl/backend/modelsdk/domainmodel.go` (`entityFromGen`'s source switch, `odataKeyFromGen`)", "insight": "Mirror the legacy parser (`sdk/mpr/parser_domainmodel.go`) for all three flavours: RemoteEntitySource (capabilities + CreateChangeLocally + key), EntityTypeSource (type name + IsOpen + key), PrimitiveCollectionEntitySource (service only). `Updatable` has no gen accessor and the writer does not emit it — leaving it zero is symmetric. **Check the read side first when a write-path field \"does not stick\"**: a switch on a field the read never fills looks like a write bug. Repro `mdl-examples/bug-tests/782-external-entity-create-change-locally.mdl`. Issue #782", "refs": ["#782"]}
+{"area": "mdl/backend", "date": "2026-07-30", "symptom": "A pluggable widget's datasource (or child widget, or client action) is **silently dropped at write time** — `exec` prints `Created page` but the widget lands with the piece missing, and only a `log` line mentions `not yet supported — rerun with MXCLI_ENGINE=legacy`", "cause": "The converter *does* return an error, but it travels through `widgetobj.ChildSerializer`, whose methods return BSON with no error channel (the `TODO(shared-types)` in `mdl/backend/widgetobj/builder.go`), so the caller logged it and returned nil", "file": "`mdl/backend/modelsdk/widget_pluggable_write.go` (`recordChildSerializeErr`, `takeChildSerializeErr`) + the drains in `page_write.go` / `snippet_write.go`", "insight": "Record the failure in a package-level accumulator and drain it at every page/snippet write entry point, so the statement fails instead of the write succeeding with data missing (ADR-0004: refuse, don't drop). The real fix is the deferred `ChildSerializer` interface change; until then, any **new** write entry point that builds pluggable widgets must drain too. Repro `mdl-examples/bug-tests/795b-flow-datasource-context-entity.mdl`"}
+{"area": "mdl/backend", "date": "2026-07-07", "symptom": "MCP op reports `MCP error -32000: Request timed out` but the page/document/entity EXISTS in Studio Pro afterwards", "cause": "Studio Pro's ~30s server-side per-call limit fires while the op still applies — a client false failure, not a server rejection", "file": "`mdl/backend/mcp/timeout.go` (`isTimeoutErr`, `timeoutVerifyDelay`, `pedUpdateVerify`, `pedDocumentExists`)", "insight": "Verify-on-timeout, never blind-retry a non-idempotent op: idempotent root-replace (`pgWritePage`) retries once; creates confirm via `ped_find_document`; entity adds confirm via a shallow `/entities` read. Unverified → error with save-before-re-run guidance (a blind re-run from a fresh session duplicates elements)"}
+{"area": "mdl/backend", "date": "2026-07-30", "symptom": "`ALTER PAGE INSERT`/`REPLACE` into a list bound `from association` **or** `datasource: microflow/nanoflow` produces a widget whose Attribute binds to the WRONG entity (the outer data view's) or nothing — `mxcli check` ✓ but `mx check` fails **CE1613** (\"attribute no longer exists\") or **CE0402** (\"No value specified\"); DESCRIBE masks it by printing only the short attribute name", "cause": "The ALTER mutator read the enclosing entity from `DataSource.EntityRef.Entity`, only set for a DIRECT ref (database). An `AssociationSource` stores its destination on the last `DomainModels$EntityRefStep` of an `IndirectEntityRef`; a `MicroflowSource`/`NanoflowSource` stores NO entity at all (its entity is the flow's RETURN type, in the flow document). Either way the list reported no entity, so the context stayed at the outer data view (or empty)", "file": "`mdl/backend/pagemutator/mutator.go` (`extractEntityFromDataSource`+`lastStepDestinationEntity` for association; `EnclosingDataSourceFlow`+`findNearestDataSourceDoc` for flows) + `mdl/executor/cmd_alter_page.go` (`resolveDataSourceFlowEntity`)", "insight": "Association: read the `IndirectEntityRef`'s last `EntityRefStep.DestinationEntity`. Microflow/nanoflow: the mutator returns the nearest-enclosing (or own, for INTO) flow QN — a nearer non-flow source shadows an outer flow — and the executor resolves its return entity via `getMicroflowReturnEntityName`/`getNanoflowReturnEntityName`. Guards `TestEnclosingEntity_AssociationSource`, `TestEnclosingDataSourceFlow`; repro `mdl-examples/bug-tests/55-alter-page-insert-assoc-binding.mdl`. FINDINGS #55", "refs": ["#55"], "ce": ["CE0402", "CE1613"]}
+{"area": "mdl/backend", "date": "2026-07-29", "symptom": "Runtime `Failed to load model: ... Class 'Workflows$CallMicroflowTask' could not be found` — the WHOLE app won't boot, yet `mxcli check` ✓ and `mx check` → 0 errors", "cause": "Mendix 11.9 (WOR-2802) split MicroflowBasedActivity into CallMicroflowActivity + AIAgentTaskActivity, renaming the workflow call-microflow on-disk `$Type` from the pre-11.9 `CallMicroflowTask` to `CallMicroflowActivity`. Writing the old name to an 11.9+ project is fatal at boot only. Evidence: 11.6.3 modeler = only Task; 11.10 modeler = both (Task marked \"Removed ... WOR-2802\" + a conversion routine); 11.10+ runtime jars = only Activity", "file": "`mdl/backend/modelsdk/workflow_write.go` (`applyCallMicroflowStorageName`, `useCallMicroflowActivityName`) + legacy `sdk/mpr/writer_workflow.go` (`renameCallMicroflowTypeBSON`)", "insight": "Version-gate the emitted `$Type` at 11.9 (same boundary as the `HasOwner`→`HasOwnerAttr` gate): build with the legacy name, rewrite the tree to `CallMicroflowActivity` for `pv.IsAtLeast(11,9)`; register codec TypeDefaults + list-marker under BOTH names; read path already folds both into one semantic type. Repro `mdl-examples/bug-tests/263-workflow-callmicroflow-storage-name.mdl`. FINDINGS #39", "refs": ["#39"]}
+{"area": "mdl/backend", "date": "2026-07-30", "symptom": "`describe microflow` prints `-- Empty action` for a `set task outcome` / `open user task` / `notify workflow` statement (default engine); a describe→drop→exec round-trip silently drops it. Legacy engine (`MXCLI_ENGINE=legacy`) describes it fine", "cause": "The modelsdk read path (`actionFromGen`) had no case for the workflow microflow actions, so they read back as nil → \"Empty action\". The write path + DESCRIBE formatter already handled them; only the modelsdk read case was missing", "file": "`mdl/backend/modelsdk/microflow_read_actions.go` (`actionFromGen`)", "insight": "Add cases for `genMf.SetTaskOutcomeAction` / `OpenUserTaskAction` / `NotifyWorkflowAction`, mirroring the legacy parsers. Test `TestActionFromGen_WorkflowActions`; repro `mdl-examples/bug-tests/54-describe-set-task-outcome.mdl`. FINDINGS #54", "refs": ["#54"]}
+{"area": "mdl/backend", "date": "2026-06-30", "symptom": "`DESCRIBE microflow` on the **modelsdk** engine renders a rule-based split as `if true then …` instead of the real `Module.Rule_X(args)` condition (body renders, only the condition text is wrong)", "cause": "`splitConditionFromGen` only handled `*ExpressionSplitCondition`; a `RuleSplitCondition` returned nil → renderer fell back to `true`. Even when handled, the rule name lives under the `RuleCall.Microflow` storage key, but gen decodes the property as `Rule` (and `ByNameRef` decode bypasses `fieldAliases`), so `RuleQualifiedName()` is empty", "file": "`mdl/backend/modelsdk/microflow.go` (`splitConditionFromGen`)", "insight": "Reconstruct `*microflows.RuleSplitCondition` from the gen `RuleCall`; read the rule name from `rc.Raw().Lookup(\"Microflow\")` when `RuleQualifiedName()` is empty (same raw-storage-key pattern the action readers use). The existing `formatSplitCondition` renders it"}
+{"area": "mdl/backend", "date": "2026-06-30", "symptom": "`DESCRIBE microflow`/`nanoflow` on the **modelsdk** engine omits the `grant execute on microflow … to <roles>;` line that legacy emits", "cause": "`microflowFromGen`/`nanoflowFromGen` never read the allowed module roles, so `Microflow.AllowedModuleRoles` was empty and the describer skipped the grant block", "file": "`mdl/backend/modelsdk/microflow.go` (`microflowFromGen`/`nanoflowFromGen`)", "insight": "Populate `out.AllowedModuleRoles` from the gen `AllowedModuleRolesQualifiedNames()` (BY_NAME role refs, stored as qualified-name strings)"}
+{"area": "mdl/backend", "date": "2026-06-30", "symptom": "`DESCRIBE microflow` on the **modelsdk** engine renders a loop `break;`/`continue;` as `-- Empty action`", "cause": "`flowObjectFromGen` had no cases for `Microflows$BreakEvent` / `Microflows$ContinueEvent`, so they fell through to the ActionActivity default with a nil action", "file": "`mdl/backend/modelsdk/microflow.go` (`flowObjectFromGen`)", "insight": "Add both object cases (renderer already maps them to `break;`/`continue;`)"}
+{"area": "mdl/backend", "date": "2026-06-30", "symptom": "`DESCRIBE microflow` on the **modelsdk** engine renders `export to mapping …` / `import from mapping …` as `-- Empty action`; and single-object mapping results render `as list of Entity` instead of `as Entity`", "cause": "`actionFromGen` lacked `ExportXmlAction`/`ImportXmlAction` cases; `restResultHandlingFromRaw` set `SingleObject` only from `Range.SingleObject`, ignoring an object var type (REST) and `ForceSingleOccurrence` (XML import)", "file": "`mdl/backend/modelsdk/microflow_read_actions.go` (`actionFromGen`, `restResultHandlingFromRaw`, `readMappingCall`)", "insight": "Add both XML-action cases reading mapping/arg/output from raw `ResultHandling`/`OutputMethod`/`ImportMappingCall`; extract `readMappingCall`; apply the object-type rule (REST) and force fallback (XML import) — mirrors legacy `parseExportXmlAction`/`parseImportXmlAction`/`parseResultHandling`"}
+{"area": "mdl/backend", "date": "2026-06-30", "symptom": "`DESCRIBE microflow` on the **modelsdk** engine drops a database retrieve's `sort by …` clause", "cause": "`retrieveSourceFromGen` read Entity/XPath/Range but not the sort columns, which live in the `DatabaseRetrieveSource`'s `NewSortings` child", "file": "`mdl/backend/modelsdk/microflow_read_actions.go` (`retrieveSourceFromGen`, `sortItemsFromRaw`)", "insight": "Generalize `sortItemsFromRaw` to accept the `NewSortings` wrapper key (it already handled the Sort list-op `Sortings` key); set `s.Sorting = sortItemsFromRaw(g.Raw())`"}
+{"area": "mdl/backend", "date": "2026-07-02", "symptom": "A database retrieve's `sort by …` is **completely missing** from DESCRIBE after any modelsdk **write** (regression on switching to the modelsdk engine; \"no more sort\") — reproduces on a fresh `create microflow … retrieve … sort by …` round-trip", "cause": "The WRITE counterpart of the row above: `retrieveSourceToGen` set an **empty** `genMf.NewSortItemList()` and never serialized `s.Sorting`, so nothing was stored for the read to render. The generated `SortItemList` type also stores items under `\"Items\"`, but Mendix stores retrieve sort columns under `\"Sortings\"` (like the Sort list-op), so the gen convenience type is the wrong tool", "file": "`mdl/backend/modelsdk/microflow_write.go` (`retrieveSourceToGen`)", "insight": "Build the envelope manually, mirroring the `SortOperation` branch: `newElem(\"Microflows$SortingsList\",\"\")` + `addPartList(sl,\"Sortings\", sortItemToGen(each))` + `g.SetSortItemList(sl)`. Guard with a toGen→encode→decode→fromGen round-trip test asserting the sort items survive. Note \"completely missing\" ⇒ write dropped it (nothing stored); a *blank-attribute* sort line ⇒ a read/name-resolution gap instead. Issue #727", "refs": ["#727"]}
+{"area": "mdl/backend", "date": "2026-07-02", "symptom": "Consumed OData service **Configuration microflow** has no effect in Studio Pro ≥ 11.10 — the \"Configuration source\" dropdown stays on \"Constants only\" even though `describe odata client` shows the microflow", "cause": "Mendix **renamed the BSON storage field** across versions (from the `Rest$ConsumedODataService` reflection metadata): `ConfigurationMicroflow` was introduced 10.12.0 and **DELETED 11.10.0**; `ConfigurationEntityMicroflow` was introduced 11.10.0. mxcli wrote the pre-11.10 key on all versions, so ≥ 11.10 Studio Pro ignored the unknown field. Both engines were affected (identical BSON). The codebase had flip-flopped this key (573→`ConfigurationEntityMicroflow`, then reverted) — the reflection `VersionInfos` Introduced/Deleted is the authority", "file": "`model.ODataConfigMicroflowBSONKey` (new, version-gated), wired into `mdl/backend/modelsdk/odata_write.go` (`consumedODataServiceToGen` via `Backend.configMicroflowKey()`) **and** `sdk/mpr/writer_odata.go` (`serializeConsumedODataService` via `w.reader.ProjectVersion()`)", "insight": "Gate the write key on project major/minor (≥ 11.10 → `ConfigurationEntityMicroflow`). On read, coalesce **all** historical keys (`model.ODataConfigMicroflowBSONKeys()` in the legacy parser; `firstNonEmpty(ConfigurationEntity…, Configuration…, Headers…)` of the gen getters in `integration_read.go`) so a service authored by any version round-trips. When a storage name looks version-dependent, check `modelsdk/gen/*/version.go` `VersionInfos` before guessing. Issue #728", "refs": ["#728"]}
+{"area": "mdl/backend", "date": "2026-06-30", "symptom": "`DESCRIBE microflow` on the **modelsdk** engine renders an inheritance split header as `split type $` (empty variable) and drops its `@caption`", "cause": "`flowObjectFromGen` created a bare `InheritanceSplit` without reading `SplitVariableName`/`Caption`/`Documentation` off the gen element", "file": "`mdl/backend/modelsdk/microflow.go` (`flowObjectFromGen`)", "insight": "Populate `VariableName`/`Caption`/`Documentation` from the gen `InheritanceSplit` accessors"}
+{"area": "mdl/backend", "date": "2026-07-07", "symptom": "`mx check` **CE4899** \"concurrent execution: error message or microflow required\" after a microflow round-trip (`GetMicroflow` → `UpdateMicroflow`), even though the microflow allowed concurrent execution", "cause": "`microflowFromGen` never read `AllowConcurrentExecution`/`MarkAsUsed` back (the write path set them), so the round-trip reset them to `false` → \"disallow concurrent execution\" with no error message configured", "file": "`mdl/backend/modelsdk/microflow.go` (`microflowFromGen`)", "insight": "Read both flags back from the gen getters (`mf.AllowConcurrentExecution()`, `mf.MarkAsUsed()`) — keep the FromGen converter lossless. Guarded by a `toGen→encode→decode→fromGen` Go test, not MDL (create-or-modify rebuilds the microflow from MDL, so it can't reproduce a read-back bug). Issue #723 A1", "refs": ["#723"], "ce": ["CE4899"]}
+{"area": "mdl/backend", "date": "2026-07-07", "symptom": "Studio Pro renders **every activity/decision as a 1-px sliver** (caption wraps one letter per line) after a modelsdk round-trip; `mx check` reports **NO** error (it ignores box size, so the corruption is silent)", "cause": "`flowObjectFromGen` carried each object's `Position` but not its `Size`, so the round-trip rewrote every node with size `0;0`", "file": "`mdl/backend/modelsdk/microflow.go` (`sizeFromGen`, `splitFlowObjects`)", "insight": "Add `sizeFromGen` (mirrors `pointFromGen`) and apply it at the `splitFlowObjects` call site — covers nested loop bodies via recursion; add `GetSize`/`SetSize` to `BaseMicroflowObject`. Go round-trip test (not MDL, same reason as A1). Issue #723 A2", "refs": ["#723"]}
+{"area": "mdl/backend", "date": "2026-07-07", "raw": "| `mx check` **CE0117** \"Error in expression\" when creating a rule-based decision (`if Module.SomeRule(...)`) via MDL on the **modelsdk** engine; the decision's subtype is demoted Rule→Expression on every round-trip | modelsdk `*Backend` never implemented `IsRule` → fell back to the embedded `unimplemented` stub (which errors); the builder's `isRule, err := backend.IsRule(...); if err != nil || !isRule` guard treated the error as \"not a rule\" and emitted an invalid `ExpressionSplitCondition` | `mdl/backend/modelsdk/microflow.go` (`IsRule`) | Implement `IsRule` on `*Backend` (list `Microflows$Rule` units, match qualified name via `moduleNameFor`), mirroring the legacy reader; it shadows the generated stub. With the existing builder mock-test this guards the full chain modelsdk.IsRule→RuleSplitCondition. Issue #723 A4 |", "refs": ["#723"], "ce": ["CE0117"]}
+{"area": "mdl/backend", "date": "2026-06-30", "symptom": "`DESCRIBE microflow` on the **modelsdk** engine renders `download file $X …;` as `-- Empty action`", "cause": "`actionFromGen` lacked a `DownloadFileAction` case", "file": "`mdl/backend/modelsdk/microflow_read_actions.go` (`actionFromGen`)", "insight": "Add the case reading `FileDocumentVariableName()`/`ShowFileInBrowser()`, defaulting an empty `ErrorHandlingType` to Rollback. Note: the storage key is `ShowFileInBrowser` (legacy's `parseDownloadFileAction` reads the wrong `ShowInBrowser` key — a latent legacy bug; the gen reads it correctly)"}
+{"area": "mdl/backend", "date": "2026-06-30", "symptom": "`DESCRIBE microflow` on the **modelsdk** engine renders a legacy SOAP `call web service …` as `-- Empty action`", "cause": "`actionFromGen` lacked a `WebServiceCallAction` case", "file": "`mdl/backend/modelsdk/microflow_read_actions.go` (`actionFromGen`, `webServiceActionRequiresRawBSON`)", "insight": "Add the case: read the structured fields (ImportedService / OperationName / NewResultHandling / RequestHandling) and, when the action carries any field the structured form can't represent, set `RawBSON = a.Raw()` so the renderer emits `call web service raw '<base64>'`. Mirror legacy's supported-key set exactly; `canonicalRawBSON` makes both engines' base64 byte-identical"}
+{"area": "mdl/backend", "date": "2026-07-01", "symptom": "`DESCRIBE microflow` on the **modelsdk** engine emits a REST `body mapping X` line with no `from $var`, which fails to re-parse (`mismatched input … expecting FROM`) — breaks the DESCRIBE roundtrip", "cause": "`restRequestHandlingFromRaw` read the export-mapping source variable from the wrong key `ParameterVariable`; the real storage key is `MappingVariableName` (same key ExportXmlAction uses), so it came back empty and the renderer dropped the grammar-mandatory `from $var`", "file": "`mdl/backend/modelsdk/microflow_read_actions.go` (`restRequestHandlingFromRaw`)", "insight": "Read `ParameterVariable` from `MappingVariableName` (fallback to `ParameterVariable`). Note this makes modelsdk *more* faithful than legacy, whose `parseRequestHandling` drops the REST request body mapping entirely (\"would be parsed here if needed\")"}
+{"area": "mdl/backend", "date": "2026-07-01", "symptom": "`SHOW ACCESS ON PAGE` / Page section of `SHOW SECURITY MATRIX` reports \"no roles\" for a restricted page on the **modelsdk** engine (legacy is correct) — under-reports page access, a security-audit hazard", "cause": "`pageFromGen` never read the page's allowed module roles into `Page.AllowedRoles`, so it defaulted to empty. (The gen `Page` decode is correct — it has the storage-name override `allowedRoles`↔`AllowedModuleRoles`.) The microflow/nanoflow equivalent was fixed separately", "file": "`mdl/backend/modelsdk/page.go` (`pageFromGen`)", "insight": "Populate `out.AllowedRoles` from the gen `AllowedRolesQualifiedNames()` (mirrors `microflowFromGen`). Fixes both `SHOW ACCESS ON PAGE` and the matrix Page section. Issue #722", "refs": ["#722"]}
+{"area": "mdl/backend", "date": "2026-05-16", "symptom": "Pluggable widget `Selection` BSON value is lowercase (`single` / `multi` / `none`) but Studio Pro stores PascalCase — contributes to CE0463 drift on stricter widgets and looks wrong in diffs", "cause": "MDL passes the user's typed value verbatim to `SetSelection`; the builder didn't normalise", "file": "`mdl/backend/mpr/widget_builder.go` `SetSelection`", "insight": "Canonicalise via `canonicalSelectionValue` helper (lowercase-keyed switch → `Single` / `Multi` / `None`); unknown values pass through", "ce": ["CE0463"]}
+{"area": "mdl/backend", "date": "2026-06-19", "symptom": "A page-level property can't be set — `ALTER PAGE X { SET PopupWidth = 800; }` (or any page-level prop other than Title/Url) fails with `unsupported page-level property: …`", "cause": "The page-level SET handler only special-cased a couple of properties; everything else fell through to the default error", "file": "`mdl/backend/pagemutator/mutator.go` → `applyPageLevelSetMut` (shared by both engines)", "insight": "Add a `case` writing the field at the top level of the Forms$Page doc via `dSetOrAppend` with the on-disk BSON type (int64 for PopupWidth/PopupHeight, bool for PopupResizable — verify against a Studio Pro page with `mxcli bson dump --format bson`). Page-level prop names are **case-sensitive**. For DESCRIBE roundtrip, emit the values back in the CREATE PAGE header. CREATE-time support: add a generic `IDENTIFIER COLON propertyValueV3` to `pageHeaderPropertyV3` (regen grammar), recognize the keys in `parsePageHeaderV3` (`applyGenericPageHeaderProp`, error on unknown), carry `*int`/`*bool` on `CreatePageStmtV3`, default to 600/600/false in `buildPageV3`, and have both writers honour `page.Popup*` (legacy `sdk/mpr/writer_pages.go` int64; codec `mdl/backend/modelsdk/page_write.go` int32 via gen — tolerated by mx check). The MCP backend has its **own** `mcpPageMutator` (pg content tree, not raw BSON) — page-level SET there reaches `SetWidgetProperty(\"\")`; map it or reject honestly (it rejects, pending a `pg_read_page` probe of the pop-up keys). Issue #661", "refs": ["#661"]}
+{"area": "mdl/backend", "date": "2026-06-30", "symptom": "`CREATE EXTERNAL ENTITIES FROM Module.Service` imports external entities as plain **PERSISTED** entities and NPEs **without the \"from Service\" link** (regression on the default modelsdk engine; legacy `--engine legacy` was correct)", "cause": "The modelsdk write adapters dropped all external-entity serialization: `entityToGen` only handled `DomainModels$OqlViewEntitySource`, `attributeToGen` always emitted `StoredValue`, and `assocToGen` forced `Source` null. So `e.Source = \"Rest$ODataRemoteEntitySource\"` (+ RemoteServiceName/EntitySet/KeyParts) was ignored and the entity fell to the plain NoGeneralization path", "file": "`mdl/backend/modelsdk/domainmodel_write.go` (`entityToGen`, `attributeToGen`, `assocToGen`) — the executor (`applyExternalEntityFields` in `mdl/executor/cmd_contract.go`) already stamps the right `domainmodel` fields; only the write adapter was lossy. The legacy serializer `sdk/mpr/writer_domainmodel.go` is the parity reference", "insight": "Port the legacy logic into the codec adapters using the gen `Rest$OData*` types (all present in `modelsdk/gen/rest`): `externalEntitySourceToGen` builds `Rest$ODataRemoteEntitySource`/`…EntityTypeSource`/`…PrimitiveCollectionEntitySource` (+ `ODataKey`/`ODataKeyPart`, with fresh IDs since `assignEntityIDs` only stamps the top source); `attributeToGen` takes an `isExternal` flag and emits `Rest$ODataMappedValue` / `…MappedPrimitiveCollectionValue`; `externalAssociationSourceToGen` emits `Rest$ODataRemoteAssociationSource` / `…PrimitiveCollectionAssociationSource` (the `DomainModels$Association` NullFields:[\"Source\"] default still nulls Source for plain associations because SetSource only emits when set). Tests in `external_entity_write_test.go`. Issue #718", "refs": ["#718"]}
+{"area": "mdl/backend", "date": "2026-07-01", "symptom": "`CreatePage: ListView source *pages.DatabaseSource not yet supported by the modelsdk engine — rerun with MXCLI_ENGINE=legacy` — a native `listview` with a `database`/`database from … where …` datasource fails on the default engine", "cause": "`listViewSourceToGen` only handled `*pages.MicroflowSource`; database (and context/listen/association) sources fell through to the \"not supported\" error. DataView, DataGrid2, and Gallery database sources already worked — only native ListView was missing", "file": "`mdl/backend/modelsdk/widget_write.go` (`listViewSourceToGen`); mirror the `customWidgetDataSourceToGen` database branch and the legacy `serializeListViewDataSource`", "insight": "Add a `*pages.DatabaseSource` case building `genPg.NewListViewXPathSource()` with EntityRef (`DirectEntityRef`), XPathConstraint, a `NewGridSortBar()` (GridSortItem per `d.Sorting`, note gen uses **SortBar** not the legacy `Sort`/`ListViewSort`), and a `NewListViewSearch()` — the codec already has all types. Verify with `mx check` = 0 errors. Tests in `listview_source_write_test.go`"}
+{"area": "mdl/backend", "date": "2026-06-29", "symptom": "CE0488 \"No entity configured for the data source of this data view\" on a context (page-parameter-bound) data view authored over **MCP** — DESCRIBE looks correct (`dataview dvX (DataSource: $Param)`), but the model has no entity on the source. DataGrids with database sources are fine", "cause": "`mapDataViewSource`'s `*pages.DataViewSource` case used a mutually-exclusive `switch`: when `ParameterName != \"\"` it wrote only `sourceVariable` and never `entityRef`. Studio Pro/pg write **both** entityRef AND sourceVariable for a context source (see `testdata/pg-page-contact-newedit.json`)", "file": "`mdl/backend/mcp/page_widgets.go` → `mapDataViewSource`", "insight": "Drop the exclusive switch: set `entityRef` (DomainModels$DirectEntityRef) whenever `EntityName != \"\"` AND `sourceVariable` (Pages$PageVariable) whenever `ParameterName != \"\"`. The executor already resolves the parameter's entity into `EntityName` (`cmd_pages_builder_v3.go` parameter case), so both are available. MCP-only — the MPR engines were never affected", "ce": ["CE0488"]}
+{"area": "mdl/backend", "date": "2026-06-19", "raw": "| Under the default modelsdk engine a SHOW/DESCRIBE errors `… not implemented yet — rerun with MXCLI_ENGINE=legacy`, OR the read \"works\" but DESCRIBE drops nested config (return type, parameters, exposed-as info) into a half-shell that's fine under `--engine legacy` | The modelsdk `Backend` never overrode the read method (falls through to the generated `unimplemented` embed), OR a gen-accessor converter read children under the codegen property names while real Studio-Pro BSON stores them under the original storage names — the gen codec decodes those keys into empty lists/parts | `mdl/backend/modelsdk/*_read.go` (add the override) + `mdl/backend/modelsdk/unimplemented_gen.go` (confirm the stub) | First confirm the gap: `comm -23 <(grep -hoP 'errUnimplemented\\(\"\\K[^\"]+' mdl/backend/modelsdk/unimplemented_gen.go \\| sort -u) <(grep -rhoP 'func \\([a-z]* \\*Backend\\) \\K[A-Za-z0-9_]+' mdl/backend/modelsdk/*.go \\| grep -v _test \\| sort -u)`. Then **dump the real raw keys before writing the converter** (a gen-accessor port silently half-shells): iterate `b.ListRawUnitsByType(typePrefix)` + `b.GetRawUnit(id)` and read the fidelity-sensitive children from the empirical keys, not the gen accessors. JS actions store `JavaReturnType`/`Parameters`/`TypeParameters`/`MicroflowActionInfo` (gen wants `ActionReturnType`/`ActionParameters`/`ActionTypeParameters`/`ModelerActionInfo`) — see `javascript_read.go`. Validate with describe-parity vs `--engine legacy` (modelsdk may be *more* correct, e.g. recovers `Enum X` where legacy drops to `Object`). Issue 7 |"}
+{"area": "mdl/backend", "date": "2026-06-19", "symptom": "`ALTER ENTITY ... ADD ATTRIBUTE` (or any ALTER) succeeds and `DESCRIBE ENTITY` is byte-identical before/after, but `mx check` then reports CE1613 \"attribute … no longer exists\" — often on a *different* entity's inherited system member (`createdDate`) referenced by grids/sort-bars in another module", "cause": "The ALTER target is rebuilt from the semantic `domainmodel.Entity` (`entityToGen` → fresh `NewEntity`, `raw==nil`), so the codec's `EmitGUID` default writes `GUID = $ID`, discarding the entity's real on-disk GUID. The GUID is the stable cross-reference identity inheriting entities/pages resolve members through, so changing it dangles those refs. The forgiving reader re-derives DESCRIBE from flags and never shows GUID, so mxcli can't see its own damage. (Legacy `sdk/mpr` had the broader form: it re-serializes the *whole unit* and forces `GUID = $ID` on every sibling too)", "file": "`mdl/backend/modelsdk/domainmodel_alter.go` → `UpdateEntity`", "insight": "Transplant the original element's raw bytes onto the rebuilt target (`ge.SetRaw(orig.Raw())`) so the codec treats it as an EXISTING element: dirty properties re-encode from `ge`, unmodeled fields (GUID, Capabilities, …) pass through verbatim. Siblings already survive via the list-rebuild raw passthrough. When a write \"succeeds\" but `DESCRIBE` is suspiciously byte-identical, suspect an identity (`$ID`/`GUID`) the reader doesn't surface — assert on raw BSON, not DESCRIBE. Issue #657", "refs": ["#657"], "ce": ["CE1613"]}
+{"area": "mdl/backend", "date": "2026-07-01", "symptom": "`mx check` reports CE6621 \"Attribute 'X' has max length '200' which is not the same as max length in the OData service which is 'unlimited'\" on every unlimited-length string attribute of a `create external entities from …` import — **only under the default modelsdk engine**; `--engine legacy` is clean", "cause": "The codec's encoder only emits *dirty* properties for a new element. `attributeTypeToGen` skipped `SetLength` when `Length == 0` (unlimited), so the `Length` property stayed non-dirty and the field was omitted from the BSON entirely. Studio Pro then applies its own UI default of 200, which contradicts the OData service's \"unlimited\" type. Legacy's `writer_domainmodel.go` always writes `Length: t.Length` (including 0), so it never regressed", "file": "`mdl/backend/modelsdk/domainmodel_write.go` → `attributeTypeToGen` (`*domainmodel.StringAttributeType` case)", "insight": "Always call `g.SetLength(int32(at.Length))` — drop the `if at.Length > 0` guard — so `Length: 0` is emitted explicitly, matching the legacy serializer. General rule for the codec write path: any field whose *zero value is meaningful* (0 = unlimited here) must be Set unconditionally, because an omitted field falls back to Studio Pro's own default, not to zero. Assert on the serialized `NewType` map (not DESCRIBE) — the reader treats a missing Length as unlimited so it hides the damage. Test `TestEntityToGen_ODataRemoteEntitySource` in `external_entity_write_test.go`. Issue #718", "refs": ["#718"], "ce": ["CE6621"]}
+{"area": "mdl/backend", "date": "2026-07-11", "symptom": "`CREATE PAGE` with a widget `Action: nanoflow …` fails on the **default (modelsdk)** engine: `client action *pages.NanoflowClientAction not yet supported by the modelsdk engine — rerun with MXCLI_ENGINE=legacy` (legacy works). Blocks any nanoflow-triggered button/link written via MDL", "cause": "`clientActionToGen` had cases for save/cancel/close/delete/page/microflow/create-object client actions but **no `*pages.NanoflowClientAction` case** → hit the `default` refuse-loudly branch. (The sibling microflow-arg drop was the separate Bug 1, already fixed on `microflowSettingsToGen`.)", "file": "`mdl/backend/modelsdk/widget_write.go` → `clientActionToGen`", "insight": "Add a `*pages.NanoflowClientAction` case building a gen `CallNanoflowClientAction`. Unlike the microflow action (which nests a `Forms$MicroflowSettings`) it carries the Nanoflow name + `ParameterMappings` **directly**: `SetNanoflowQualifiedName`, `SetProgressBar(\"None\")`, `SetDisabledDuringExecution(true)`, and one `NanoflowParameterMapping` per arg (`SetParameterQualifiedName(nanoflow+\".\"+param)` BY_NAME + `SetExpression($var)`); register `Forms$CallNanoflowClientAction` TypeDefaults (`MandatoryLists:[ParameterMappings]`, `NullFields:[ProgressMessage,ConfirmationInfo]`). Mirror the legacy `writer_widgets_action.go`. The modelsdk **read** already round-trips it (describe shows `nanoflow M.NF(Form: $Form)`). Verify both engines with `mx check`=0. Bug-test `bug2-modelsdk-nanoflow-widget-action.mdl`; tests `TestNanoflowClientAction_Serialized` (+ `TestMicroflowClientAction_PersistsParameters` guards Bug 1's mapping stays wired through the shared helper). Bug 2"}
+{"area": "mdl/backend", "date": "2026-07-03", "raw": "| `GRANT VIEW ON PAGE Module.Page TO Module.Role` prints success but the page's allowed roles appear to stay empty: `mxcli lint` still reports `CE0557`/`MPR007` (\"used as home page … but has no allowed roles\") across a freshly rebuilt catalog, while entity-access grants on the same roles verify fine (`describe entity` shows them). Reported on **modelsdk** engine (default), Mendix 11.11 | NOT a write bug — the grant **does** persist (`AllowedModuleRoles: [3, \"Module.Role\"]` on disk; `mx check` = 0 errors; Studio Pro would load clean). The regression was on the **read** path: modelsdk `pageFromGen` didn't populate `Page.AllowedRoles`, and `mxcli lint`'s CE0557 rule counts `len(pg.AllowedRoles)` from `ListPages()` — so it read every page as having zero roles and false-fired. `SHOW ACCESS ON PAGE` / `SHOW SECURITY MATRIX` under-reported the same way. The entity-vs-page asymmetry the reporter saw = different read paths (entity `describe` worked; page `lint` didn't), not different writes | `mdl/backend/modelsdk/page.go` → `pageFromGen` | Already fixed by `88a2d50b1` (issue #722): populate `out.AllowedRoles` from the gen `AllowedRolesQualifiedNames()`, mirroring `microflowFromGen`. Guard for the reporter's exact end-to-end flow: `TestUpdateAllowedRoles_PagePersistsForLintRead` (`mdl/backend/modelsdk/page_roles_test.go`) writes a page role then reopens fresh and asserts the lint read path (`ListPages`→`AllowedRoles`) sees it. **Diagnosis tip**: when a write \"reports success but the value stays empty\" *only in a read/lint/show command*, dump the raw unit (`mxcli bson dump`) — if the bytes are there, it's a read-adapter (`*FromGen`) gap, not a write bug; confirm by reverting the suspected read commit and re-running | ", "refs": ["#722"], "ce": ["CE0557"]}
+{"area": "mdl/backend", "date": "2026-07-06", "symptom": "`MOVE ENTITY X to OtherModule` where a **view entity's OQL** joins through `X`: passes `mxcli check`, but `mx check` on **Mendix 10.x** reports `CE0174 \"…path '…/DmTest.Customer' does not resolve to an entity\"` at the view entity — **only on the modelsdk engine**, only on 10.x (11.x is clean; legacy is clean)", "cause": "Mendix <11 stores a view entity's OQL in **two** places: the top-level `DomainModels$ViewEntitySourceDocument` unit AND inline on the entity's `DomainModels$OqlViewEntitySource` (see `entityToGen`, gated `major < 11`). modelsdk's `UpdateOqlQueriesForMovedEntity` rewrote only the source document, leaving the inline copy pointing at the old module. 11.x doesn't write the inline copy (OQL lives only on the source doc), so it was never affected — hence 10.x-only. Legacy updates the inline copy incidentally by re-serializing the domain model", "file": "`mdl/backend/modelsdk/move_view_write.go` → `UpdateOqlQueriesForMovedEntity`", "insight": "After the ViewEntitySourceDocument sweep, also iterate every domain model (`ListDomainModels` → `loadDomainModelGen`), find each entity whose `Source()` is `*genDm.OqlViewEntitySource` with an `Oql()` containing the old qualified name, `SetOql(strings.ReplaceAll(...))`, and `persistDM`. Mirrors the `UpdateEnumerationRefsInAllDomainModels` walk. **Diagnosis tip**: when a value updates in one storage location but a stale copy elsewhere still breaks `mx check`, dump raw `mprcontents` and grep for the value across `$Type`s — Mendix often duplicates a field (OQL, captions) and a version gate (`major < 11`) can make one copy version-conditional. Repro: `mdl-examples/bug-tests/move-entity-oql-view-inline-ref.mdl`", "ce": ["CE0174"]}
+{"area": "mdl/backend", "date": "2026-07-06", "symptom": "`MOVE ENTITY` / `MOVE ENUMERATION` cross-module prints `Warning: Could not update OQL queries` / `Could not update enumeration references: load domain model 00000000-0000-0000-0000-000000000002: open …/mprcontents/00/00/00000000-…002.mxunit: no such file or directory` — **modelsdk engine only**. The move itself succeeds and (today) user modules are still updated, because `ListDomainModels` appends the failing System DM **last** — but the warning is spurious and the ordering dependence is fragile", "cause": "Both reference-update sweeps iterate `ListDomainModels()`, which **injects the virtual System-module domain model** (ID `…002`, `buildSystemDomainModel`) so platform entities resolve. Each sweep then re-loads every listed DM from disk via `loadDomainModelGen(info.ID)` — but the System module isn't stored in `mprcontents`, so its `.mxunit` read fails. Legacy never hit this: it walks in-memory `*domainmodel.DomainModel` objects and never re-reads from disk", "file": "`mdl/backend/modelsdk/association_move_write.go` → `UpdateEnumerationRefsInAllDomainModels`; `mdl/backend/modelsdk/move_view_write.go` → `UpdateOqlQueriesForMovedEntity`", "insight": "Skip the System DM at the top of each DM loop: `if string(info.ID) == meta.SystemDomainModelID { continue }` (import `modelsdk/meta`). It never holds user enum refs or user view-entity OQL, so skipping is correct and removes the disk-read failure regardless of iteration order. **Diagnosis tip**: a \"no such file / not found\" on the fixed ID `…002` (or module `…001`) means code is trying to load the *virtual* System unit from disk — filter it out, don't try to read it. Regression: `TestUpdateRefsForMovedEntity_SkipsSystemDomainModel` (`move_refs_system_test.go`)"}
+{"area": "mdl/backend", "date": "2026-07-11", "symptom": "Under the **default (modelsdk)** engine, any page widget with an **association datasource** (`datasource: $currentObject/Module.Assoc`, the master-detail idiom) fails at exec: `CreatePage: DataView source *pages.AssociationSource not yet supported by the modelsdk engine — rerun with MXCLI_ENGINE=legacy`. Same for a nested `listview`", "cause": "`customWidgetDataSourceToGen` (pluggable widgets) already handled `*pages.AssociationSource`, but `dataViewSourceToGen`/`listViewSourceToGen` had no case → hit the \"not yet supported\" default. (Legacy doesn't error but writes a **broken** `Forms$AssociationSource{EntityRef: nil}` in `serializeListViewDataSource`, so legacy is not a valid reference — tracked as **L1** in [`docs/03-development/LEGACY_ENGINE_KNOWN_ISSUES.md`](../../docs/03-development/LEGACY_ENGINE_KNOWN_ISSUES.md); do **not** fix legacy, it will be removed when modelsdk matures)", "file": "`mdl/backend/modelsdk/widget_write.go` (`associationSourceToGen`, wired into `dataViewSourceToGen`+`listViewSourceToGen`) + `mdl/executor/cmd_pages_describe.go` (`associationSourcePath`) + `cmd_pages_describe_parse.go` (DataView/ListView datasource cases) + `cmd_pages_describe_output.go` (`associationDataSourceExpr`)", "insight": "**modelsdk engine only.** Extract the proven `AssociationSource` block from `customWidgetDataSourceToGen` into a shared `associationSourceToGen` (Forms$AssociationSource → `IndirectEntityRef` of `EntityRefStep{Association, DestinationEntity}` + optional page-param `SourceVariable`; `$currentObject` → nil source var) and add a `case *pages.AssociationSource` to the DataView and ListView source builders. Matches the canonical legacy `serializeAssociationSource` (writer_widgets.go) and the Studio-Pro-verified `EntityRefStep` structure — NOT the broken `serializeListViewDataSource` stub. DESCRIBE reconstructs `$currentObject/Module.Assoc` from `EntityRef.Steps`. **An association source is valid only on LIST-producing widgets (listview/datagrid/gallery/templategrid), NOT a plain DataView** — Studio Pro rejects a DataView association source (\"cannot have a data source of type association\"); the widget still exec-creates (valid BSON), so `check` flags it with **MDL-WIDGET08** (`validateStaticWidget`). Tests: `mdl/backend/modelsdk/widget_assoc_source_test.go`, `mdl/executor/cmd_pages_describe_assoc_source_test.go`, `validate_widgets_test.go`; bug-tests `mdl-examples/bug-tests/assoc-datasource-modelsdk.mdl` (valid listview) + `dataview-association-source-rejected.fail.mdl` (MDL-WIDGET08)"}
+{"area": "mdl/backend", "date": "2026-07-09", "symptom": "Under the **default (modelsdk)** engine, any page widget with an **association datasource** (`datasource: $currentObject/Module.Assoc`, the master-detail idiom) fails at exec: `CreatePage: DataView source *pages.AssociationSource not yet supported by the modelsdk engine — rerun with MXCLI_ENGINE=legacy`. Same for a nested `listview`", "cause": "`customWidgetDataSourceToGen` (pluggable widgets) already handled `*pages.AssociationSource`, but `dataViewSourceToGen`/`listViewSourceToGen` had no case → hit the \"not yet supported\" default. (Legacy doesn't error but writes a **broken** `Forms$AssociationSource{EntityRef: nil}` in `serializeListViewDataSource`, so legacy is not a valid reference — tracked as **L1** in [`docs/03-development/LEGACY_ENGINE_KNOWN_ISSUES.md`](../../docs/03-development/LEGACY_ENGINE_KNOWN_ISSUES.md); do **not** fix legacy, it will be removed when modelsdk matures)", "file": "`mdl/backend/modelsdk/widget_write.go` (`associationSourceToGen`, wired into `dataViewSourceToGen`+`listViewSourceToGen`) + `mdl/executor/cmd_pages_describe.go` (`associationSourcePath`) + `cmd_pages_describe_parse.go` (DataView/ListView datasource cases) + `cmd_pages_describe_output.go` (`associationDataSourceExpr`)", "insight": "**modelsdk engine only.** Extract the proven `AssociationSource` block from `customWidgetDataSourceToGen` into a shared `associationSourceToGen` (Forms$AssociationSource → `IndirectEntityRef` of `EntityRefStep{Association, DestinationEntity}` + optional page-param `SourceVariable`; `$currentObject` → nil source var) and add a `case *pages.AssociationSource` to the DataView and ListView source builders. Matches the canonical legacy `serializeAssociationSource` (writer_widgets.go) and the Studio-Pro-verified `EntityRefStep` structure — NOT the broken `serializeListViewDataSource` stub. DESCRIBE reconstructs `$currentObject/Module.Assoc` from `EntityRef.Steps`. A `Forms$AssociationSource` is valid on **LIST-producing** widgets (listview/datagrid/gallery/templategrid). A plain **DataView** cannot use `Forms$AssociationSource` (MxBuild **CE6705**) — but the DataView *association* case is still valid via a **different** source type; see the \"data from context over association\" row below (an earlier fix wrongly rejected it with MDL-WIDGET08, now removed). Tests: `mdl/backend/modelsdk/widget_assoc_source_test.go`, `mdl/executor/cmd_pages_describe_assoc_source_test.go`; bug-test `mdl-examples/bug-tests/assoc-datasource-modelsdk.mdl` (valid listview)", "ce": ["CE6705"]}
+{"area": "mdl/backend", "date": "2026-07-09", "symptom": "A **DataView bound to a to-one referenced object over an association** (\"data from context\", e.g. an inner DataView showing the referenced Employee's `Name`/`Email` inside an `Expense` DataView) can't be authored/round-tripped: `dataview dvEmp (datasource: $currentObject/Module.Assoc)` was rejected (MDL-WIDGET08), a bare nested `dataview { textbox (attribute: Name) }` bound children to the **parent** entity (CE1613), and `describe` dropped the source → describe/exec **silently strips** the association DataView (round-trip corruption)", "cause": "A DataView over an association is **not** a `Forms$AssociationSource` (that's list-widgets-only; CE6705 on a DataView). It is a `Forms$DataViewSource` whose `EntityRef` is a `DomainModels$IndirectEntityRef` navigating the association (a DataViewSource *is* an `EntityPathSource`, so its EntityRef may be indirect — `generated/metamodel/types.go:558`). mxcli generated the wrong source type, then (Bug 5 v1) wrongly rejected the whole case", "file": "`mdl/backend/modelsdk/widget_write.go` (`dataViewContextAssociationSourceToGen`, wired into `dataViewSourceToGen`'s `*pages.AssociationSource` case) + `mdl/executor/cmd_pages_builder_v3_widgets.go` (removed the `buildDataViewV3` association guard) + `mdl/executor/validate_widgets.go` (removed MDL-WIDGET08) + `mdl/executor/cmd_pages_describe_parse.go` (`Forms$DataViewSource` reads `EntityRef.Steps` via `associationSourcePath`)", "insight": "**modelsdk engine only.** For a DataView association datasource, emit `Forms$DataViewSource` with `EntityRef = IndirectEntityRef{EntityRefStep{Association, DestinationEntity}}` (+ optional page-param `SourceVariable`; `$currentObject` → none) — mirrors `associationSourceToGen` but wraps the IndirectEntityRef in a DataViewSource. Children then bind to the destination entity. DESCRIBE reconstructs `$currentObject/Module.Assoc`. Removes the earlier MDL-WIDGET08 over-rejection. **When two widget kinds share a navigation but MxBuild accepts it on only one, the distinction is the source `$Type` wrapper, not the EntityRef inside it** — check `generated/metamodel/types.go` for the widget's allowed `DataSource` subtypes. mxbuild-validated (`mxcli docker check --no-update-widgets` = 0 errors) + full describe→re-exec round-trip. Tests: `mdl/backend/modelsdk/widget_assoc_source_test.go` (`TestDataViewAssociationSource_Serialized`); bug-test `mdl-examples/bug-tests/dataview-context-association-source.mdl`. Bug 5 (reclassified)", "ce": ["CE1613", "CE6705"]}
+{"area": "mdl/backend", "date": "2026-07-10", "symptom": "`DESCRIBE` of a view entity on the **default (modelsdk)** engine omits the `as (… OQL …)` clause entirely (legacy renders it) — the describe→exec round-trip silently drops the query, leaving a queryless view. Reproduces on any Mendix **11.x** project", "cause": "On Mendix 11.0+ the OQL is stored **only** in the separate `DomainModels$ViewEntitySourceDocument`; the inline `OqlViewEntitySource.Oql` field was removed (see the writer's `if !pv.IsAtLeast(11,0)` gate in `serializeOqlViewEntitySource`). The modelsdk read (`entityFromGen`: `out.OqlQuery = src.Oql()`) only read the now-empty inline field and never followed the `SourceDocumentRef`. Legacy was correct — `loadViewEntityOqlQueries` in `sdk/mpr/reader_documents.go` already joins the source docs", "file": "`mdl/backend/modelsdk/domainmodel.go` (`populateViewEntityOql`, wired into `ListDomainModels` + `GetDomainModel`)", "insight": "After building the domain models, list `ViewEntitySourceDocument` units (`mprread.ListUnitsWithContainer[*genDm.ViewEntitySourceDocument]`), map `moduleName.docName → Oql()`, and fill `OqlQuery` for any view entity with an empty `OqlQuery` + a `SourceDocumentRef` (mirrors the legacy join; guarded by a cheap pre-check so non-view projects pay nothing). When a view-entity read differs between engines on 11.x, suspect a field the platform moved out-of-line into a source document. Test: `TestGetDomainModel_ViewEntityOqlFromSourceDocument` (round-trips via both read paths)"}
+{"area": "mdl/backend", "date": "2026-07-10", "symptom": "`DESCRIBE WORKFLOW` on the **default (modelsdk)** engine renders some activities as non-round-trippable comments — `-- [Workflows$StartWorkflowActivity]`, `-- [Workflows$JumpToActivity]`, `-- [Workflows$WaitForTimerActivity]`, `-- [Workflows$WaitForNotificationActivity]` — so `describe → exec` drops those activities and you can't learn their syntax from an existing workflow. User tasks, decisions, splits, call-microflow/workflow round-trip fine (legacy round-trips all of them)", "cause": "The describe **formatter** (`formatWorkflowActivities`) already has typed cases for jump/wait/start/end, but the modelsdk **reader** never produced them: these activities have no `genWf` struct (written via generic `newElem`), so `workflowActivityFromGen`'s type switch fell through to `GenericWorkflowActivity`, which the formatter renders as `-- [$Type]`. Legacy's `parser_workflow.go` had dedicated cases, so legacy was correct — modelsdk-only gap", "file": "`mdl/backend/modelsdk/workflow_read.go` (`workflowActivityFromGen` default → new `workflowSimpleActivityFromGen`)", "insight": "Recognise the untyped simple activities by `el.TypeName()` and rebuild the semantic struct, reading fields from raw BSON via `genWf.RawFieldString` (`TargetActivity` for jump, `Delay` for the timer) — mirrors the legacy parser. Start/end become typed so the formatter **skips** them (implicit in MDL); jump/wait become executable statements. When an engine emits `-- [$Type]` in describe, the *formatter* usually already handles the type — the gap is the *reader* decoding it to `GenericWorkflowActivity`. Test: `TestWorkflowSimpleActivities_ReconstructedTyped`; round-trip validated describe→drop→exec→`docker check` = 0 workflow errors. Bug 11b (11a = the missing `write-workflows.md` authoring skill)"}
+{"area": "mdl/backend", "date": "2026-07-11", "symptom": "A built-in widget action (`actionbutton`/`container`/`linkbutton` `Action: microflow M.Flow(Param: $x)`) **silently drops the argument** on the **default (modelsdk)** engine — `describe` shows `Action: microflow M.Flow` (no args), the flow runs with no parameter, and a required-param flow never fires so the button/row no-ops at runtime. `mxcli check`/`docker check`/`docker build` all pass (0 errors) — silent break. Legacy persists it (the workaround)", "cause": "`clientActionToGen`'s `MicroflowClientAction` case built the `Forms$MicroflowSettings` from the microflow **name only** (`microflowSettingsToGen(x.MicroflowName)`), never serializing `x.ParameterMappings` — the executor builds them correctly into the model, the writer threw them away. (NOT the same as `custom-widgets.md`'s \"action mapping too complex for auto-mapping\" — that's about *pluggable-widget action-typed properties* in def.json generation, a different path.)", "file": "`mdl/backend/modelsdk/widget_write.go` (`microflowSettingsToGen`)", "insight": "Give `microflowSettingsToGen` the mappings param; emit one `genPg.MicroflowParameterMapping` each — `SetParameterQualifiedName(\"<MicroflowQName>.<ParamName>\")` (BY_NAME) + `SetExpression(variable-or-expression)` — mirroring the legacy `writer_widgets_action.go` BSON. The client-action caller passes `x.ParameterMappings`; the microflow-datasource callers pass `nil`. Verified: default-engine describe now keeps `(Param: $x)`; a type-correct page = 0 mxbuild errors (both engines give the *same* CE0117 on a type-mismatched arg — that's a model error, not the writer). Tests: `TestClientActionToGen_MicroflowParameterMappings`; bug-test `mdl-examples/bug-tests/bug1-widget-action-param-mapping.mdl`. Nanoflow widget actions were a separate gap (the whole `NanoflowClientAction` case was missing) — now fixed in Bug 2 below. Bug 1", "ce": ["CE0117"]}
+{"area": "mdl/backend", "date": "2026-07-22", "symptom": "A page with a native **LISTVIEW** over a `database from` (XPath) datasource passes `mx check` but **crashes the browser client at runtime** and redirects to login: `TypeError: Cannot read properties of undefined (reading 'length')` at `processResult` → `retrieveByXPath`. Pluggable Gallery/DataGrid2 database sources are fine", "cause": "The serialized `Forms$ListViewXPathSource` omitted the arrays the client reads `.length` of. **Codec (default):** `Forms$ListViewSearch` emitted without its `SearchRefs` list — the encoder drops an empty, never-`Set` PartList unless the `$Type` is in `RegisterTypeDefaults` (GridSortBar.SortItems was registered; ListViewSearch was not). **Legacy:** wrote a bogus `Forms$ListViewSort` + a `Paths` key (renamed `SearchRefs` in 7.11.0) and no `Forms$GridSortBar`. NOT a `SortItems` marker issue — an empty `[2]` compiles fine when search is off; the crash is the absent `SearchRefs`. Diagnose by building a Deploy target and reading the compiled `deployment/web/pages/<Page>.js` (the client model) + `mxcli bson dump --type page` on the source", "file": "`mdl/backend/modelsdk/widget_write.go` (`init` RegisterTypeDefaults) + `sdk/mpr/writer_widgets_display.go` (`serializeListViewDataSource`, `emptyListViewXPathSource`)", "insight": "Codec: `RegisterTypeDefaults(\"Forms$ListViewSearch\", {MandatoryLists: []string{\"SearchRefs\"}})` (emits empty marker-3 list). Legacy: emit `Forms$GridSortBar`/`SortItems` (mirror `SerializeCustomWidgetDataSource`) + `Forms$ListViewSearch`/`SearchRefs` + `ForceFullObjects`; drop the bogus `Sort`/`Paths`. Tests: `TestListViewSourceToGen_SearchRefsEmitted` (codec, encode-level), `TestSerializeListViewDataSource_Database` + `TestEmptyListViewXPathSource_Shape` (legacy). Repro `mdl-examples/bug-tests/listview-database-source-searchrefs.mdl`"}
+{"area": "mdl/backend", "date": "2026-07-27", "symptom": "`alter page P { set class = 'x' on <builtin> }` (lowercase property) hard-errors on EVERY built-in widget: `property \"class\" not found (widget has no pluggable Object)` — but `create page` accepts the same lowercase prop, and these aren't pluggable widgets", "cause": "The MPR page mutator dispatched first-class props via a case-SENSITIVE switch on canonical casing (\"Class\"/\"Caption\"/\"DynamicClasses\"); a lowercase name missed every case and fell through to the pluggable-Object path. `create page` was fine (WidgetV3.GetStringProp is case-insensitive); the sibling MCP mutator already lowercased", "file": "`mdl/backend/pagemutator/mutator.go` (`setRawWidgetPropertyMut`)", "insight": "`switch strings.ToLower(propName)` with lowercase case labels; keep the pluggable fallback (default) on the original casing (template keys are case-sensitive). Test `TestSetWidgetProperty_LowercaseFirstClassProps`; repro `mdl-examples/bug-tests/alter-page-lowercase-set-on-builtin.mdl`. Findings #1", "refs": ["#1"]}
+{"area": "mdl/backend", "date": "2026-07-27", "symptom": "`call javascript action` (e.g. NanoflowCommons.OpenURL) passes `check --references` + `exec` but persists as `-- Empty action`; `mx check` fails CE0008 \"No action defined.\" + CE0109 on the output variable. Affects microflows AND nanoflows", "cause": "The default `modelsdk` engine's `microflowActionToGen` had no case for `*microflows.JavaScriptActionCallAction` → returned nil → ActionActivity written with no Action. Read path + legacy engine both handled it (hence check/exec looked green); nanoflows reuse the same converter", "file": "`mdl/backend/modelsdk/microflow_write.go` (`microflowActionToGen`)", "insight": "Add the `JavaScriptActionCallAction` case, built directly to mirror the legacy serializer (storage keys JavaScriptAction/OutputVariableName; JS parameter mappings use the `ParameterValue` key, not the Java-style `Value`). Test `TestMicroflowActionToGen_JavaScriptActionCall`; repro `mdl-examples/bug-tests/javascript-action-call-persist.mdl`. Findings #11", "refs": ["#11"], "ce": ["CE0008", "CE0109"]}
+{"area": "mdl/backend", "date": "2026-08-06", "symptom": "A **`CREATE JAVASCRIPT ACTION`** succeeds, `mxcli check` passes and the build is clean, but calling the action in the running app throws **`JavaScript action was not implemented`** and the nanoflow aborts", "cause": "mxcli wrote the source to `javascriptsource/<ModuleName>/actions/` using the module's own casing. Mendix reads a **lowercased** directory — a blank Mendix 11 app ships `javascriptsource/nanoflowcommons/`, `/datawidgets/`, `/webactions/` for modules named `NanoflowCommons`, `DataWidgets`, `WebActions`. Finding no source at the path it reads, mxbuild generates a stub whose body is `throw new Error(\"JavaScript action was not implemented\")` and bundles that. Only reproduces on a **case-sensitive filesystem**, which is why it survived: on macOS and Windows the two spellings are the same directory", "file": "`mdl/backend/modelsdk/javascript_write.go` and `sdk/mpr/writer_javascriptactions.go` (`jsActionSourceDir`)", "insight": "`strings.ToLower(moduleName)` in both writers — the comment in each previously asserted the opposite (\"unlike javasource, which is lowercased\"), so the belief was documented, not tested. **Generalisable — the shape to look for**: when generated *source files* pair with model units, the model unit is not evidence the file is found; the filesystem path is a separate contract, and a case-only mismatch is invisible on the developer's own machine. Check against the directories a blank project already ships rather than against what the code says. Nothing short of running the app catches it: parse, check and build all pass. Test `mdl/backend/modelsdk/javascript_write_dir_test.go`; verified end-to-end (button click flips the theme instead of throwing)"}
+{"area": "mdl/backend", "date": "2026-08-05", "symptom": "`ALTER PAGE … ON <col>` targeting a DataGrid2 column: (a) the authored MDL column name (`column colFoo`) fails with a bare `widget \"colFoo\" not found`, and (b) a name shared by two columns (duplicate captions) **silently mutates the first** and reports `Altered page`, leaving the second unreachable", "cause": "DataGrid2 columns carry **no stored name** in the Mendix model (their WidgetObject has no `Name` property), so the authored name is dropped on write and mxcli addresses a column by a *derived* name (attribute leaf, else caption, else `col{N}`). The bare-name resolver `findInWidgetArray` returned on the **first** derived-name match, so duplicates collided silently; the miss path emitted a generic \"widget not found\" with no hint that columns use a derived name", "file": "`mdl/backend/pagemutator/mutator.go` — the column loop in `findInWidgetArray` (now counts matches → `bsonWidgetResult.matchCount`), `findBsonColumn` (returns `(result, error)`), and the mutation entry points `SetWidgetProperty`/`DropWidget`/`InsertWidget`/`ReplaceWidget` (reject `matchCount > 1`, use `widgetNotFoundError` which lists derived names)", "insight": "Persisting the authored name is **not possible** — columns have no name slot, and inventing one is the Studio-Pro-won't-open hazard (ADR-0005 guard-don't-drop). So implement the finding's two fallbacks: reject an ambiguous `ON <name>` with an actionable error instead of silently taking the first (a *data hazard*, not just a wart), and on a miss list the addressable derived names + explain the derived-name model (run DESCRIBE PAGE). **Generalisable**: a resolver that returns the first of N matches hides ambiguity — count matches and reject >1 at every *mutating* entry point, not just the read path. Repro `mdl-examples/bug-tests/ledger-78-datagrid-column-addressing.mdl`; A/B: pre-fix binary reports `Altered page` for the duplicate-caption `ON \"Amount\"`, fixed errors with \"ambiguous\". Ledger #78", "refs": ["#78"]}
+{"area": "mdl/backend", "date": "2026-08-07", "symptom": "`alter page … set Editable = [expr]` (or `set Visible`) writes a project Studio Pro refuses to open: `StorageLoadException: Conditional editability settings has an invalid value '' for property Attribute`. `mxcli check` ✓ and `mx check` ✓ — neither inspects the stored value. The identical settings written by `create page` load fine", "cause": "The ALTER path builds the `Forms$Conditional{Visibility,Editability}Settings` node by hand and wrote `Attribute: null`. `Attribute` is a **BY_NAME** `AttributeIdentifier`, so its unset value is the empty string, not null — exactly what the CREATE path already encodes via `codec.RegisterTypeDefaults(..., EmptyStringFields: []string{\"Attribute\"})`, whose comment records this same StorageLoadException from #627. Only the hand-built ALTER node missed it", "file": "`mdl/backend/pagemutator/mutator.go` (`setWidgetConditionalSettingMut`)", "insight": "Write `{Key: \"Attribute\", Value: \"\"}`, not `nil`. **General rule: when one path hand-builds BSON that another path builds through the codec, diff the two encodings rather than eyeballing the hand-built one** — `mxcli bson dump --type page --object M.P` on a CREATE-authored and an ALTER-authored widget makes the divergence a one-line diff (key sets and values were otherwise identical). `SourceVariable` stays `nil`: it is BY_ID, where null *is* the absent value, so \"null is wrong\" is per-field, not a blanket rule. Test `TestSetWidgetConditionalSetting_AttributeIsEmptyString`; repro `mdl-examples/bug-tests/851-alter-page-conditional-attribute.mdl`. Issue #851", "refs": ["#627", "#851"]}
+{"area": "mdl/backend", "date": "2026-08-07", "symptom": "`download file $Doc;` is accepted by `mxcli check` and `mxcli exec` (\"Created microflow\") but the activity lands with **no action at all** — `describe` renders `-- Empty action` and `mx check` fails `[CE0008] \"No action defined.\"`. Same for `download file $Doc show in browser;`", "cause": "`microflowActionToGen` (the modelsdk write path) had no `*microflows.DownloadFileAction` case, so it hit `default: return nil` and the enclosing ActionActivity was serialized with a nil Action. Grammar, visitor, flow builder, read path and DESCRIBE formatter were all already in place, so the statement passed every stage that reports anything and vanished at the one that does not", "file": "`mdl/backend/modelsdk/microflow_write.go` (`microflowActionToGen`)", "insight": "Add the case, setting `FileDocumentVariableName`, `ShowFileInBrowser` and `ErrorHandlingType` (Rollback default). **The storage key is `ShowFileInBrowser`, not `ShowInBrowser`** — the gen setter binds the right one; legacy's `parseDownloadFileAction` reads the wrong key. **Test at the round trip, not the reader**: a reader-only test starts from BSON the writer never had to produce, so `TestActionFromGen_DownloadFile` was green throughout. `roundTripMicroflow` (model→gen→codec→model) is the harness; assert the ActionActivity's `Action` is non-nil, which is the CE0008 shape itself. This is the same silent-drop mechanism as the `microflowObjectToGen` default branch (#791) — when auditing, diff the write switch's cases against `sdk/mpr/writer_microflow_actions.go`. Test `TestMicroflowRoundTrip_DownloadFile`; repro `mdl-examples/bug-tests/850-download-file-action.mdl`. Issue #850", "refs": ["#791", "#850"], "ce": ["CE0008"]}
+{"area": "mdl/backend", "date": "2026-08-08", "symptom": "A microflow using `split type` writes a project mxbuild cannot **load**: `KeyNotFoundException: The given key '<guid>' was not present in the dictionary` at `StreamingBsonUnitReader.ResolvePostponedProperties`. `mxcli check` ✓ and `mxcli exec` ✓; reproduced on 11.6.6 and 11.13.0", "cause": "Two gaps in the modelsdk writer, both the #791 shape. (1) `microflowObjectToGen` had no `*microflows.InheritanceSplit` case → `default: return nil`, so the split was dropped while three sequence flows kept pointing at its `$ID`. (2) `caseValueToGen` had no `InheritanceCase` case → every branch degraded to a bare `Microflows$NoCase`, losing the entity it selects on. Its value-receiver normalisation also omitted the type, so a pointer-only fix would still miss half the calls", "file": "`mdl/backend/modelsdk/microflow_write.go` (`microflowObjectToGen`, `caseValueToGen`) — mirror `sdk/mpr/writer_microflow.go`", "insight": "Add both cases. **Diagnose with the #791 recipe**: `mxcli bson dump --type microflow`, collect every `$ID`, check each key ending in `Pointer` resolves (before: 27 objects / 3 dangling; after: 28 / 0). **Take field lists from the GENERATED type, not from legacy** — legacy writes `ErrorHandlingType` on the split but `initInheritanceSplit` has no such property, i.e. legacy writes a field Mendix does not define. **When adding a case-value type, update the value-receiver normalisation too.** Modelling rules confirmed on both versions while verifying: a type split needs an outgoing flow for every type INCLUDING the base (CE0090), and an `else` does NOT substitute for the base-type case. Tests `TestMicroflowRoundTrip_InheritanceSplit`, `TestCaseValueToGen_InheritanceCase{,ValueReceiver}`; repro `mdl-examples/bug-tests/split-type-dangling-pointer.mdl`", "refs": ["#791"], "ce": ["CE0090"]}
+{"area": "mdl/backend", "date": "2026-08-08", "symptom": "`alter page … set <prop> on <widget>` reports `widget \"X\" not found` when the widget sits inside a datagrid column rendered as `customContent`; only CREATE OR REPLACE PAGE can touch it", "cause": "`findInWidgetChildren`'s pluggable branch searched the grid's own `Object.Properties[].Value.Widgets` and matched columns by derived name, but never descended into a COLUMN's own content. Columns live at `Object.Properties[columns].Value.Objects[]`; their widgets are one level deeper at `Properties[content].Value.Widgets[]`", "file": "`mdl/backend/pagemutator/mutator.go` (`findInWidgetChildren`, the columns loop)", "insight": "Descend into each column's `Properties[].Value` and reuse `findInWidgetArray(…, \"Widgets\", name)`. **Address by the nested widget's OWN name, not a `grid.column.widget` path**: DataGrid2 columns carry no stored name in the MPR (see `findBsonColumn`), so a column segment could only be a derived name that changes when the caption is edited — a path that goes silently stale. Keep the existing column-by-derived-name lookup working (a test pins it, or the descent could shadow it). Test `TestFindBsonWidget_InsideCustomContentColumn`; repro `mdl-examples/bug-tests/834-alter-customcontent-column-widget.mdl`. Issue #834", "refs": ["#834"]}
+{"area": "mdl/backend", "date": "2026-08-08", "symptom": "`alter page … set Caption = '…' on <actionbutton>` fails with `widget has no Caption property` — for EVERY action button, nested or top-level", "cause": "An ActionButton has no `Caption` document: its caption is a `Forms$ClientTemplate` under **`CaptionTemplate`** (Template → Items[] → Translation.Text), the same shape `setWidgetContentMut` already walked for `Content`. `setWidgetCaptionMut` only looked for `Caption`", "file": "`mdl/backend/pagemutator/mutator.go` (`setWidgetCaptionMut`, `setClientTemplateText`)", "insight": "Fall back to `CaptionTemplate` via a shared `setClientTemplateText` helper, which `setWidgetContentMut` now uses too. **Found while fixing #834 — check whether a symptom reproduces OUTSIDE the reported context before attributing it**: this failed on a top-level button as well, so it was a second, independent defect and the #834 finder fix alone would not have made the reporter's command work. When a widget property will not set, dump the widget's key list (`mxcli bson dump --type page`) before assuming the setter is wired — the field is often stored under a different, template-shaped key", "refs": ["#834"]}
+{"area": "mdl/backend", "date": "2026-08-08", "symptom": "`create or modify external entity Mod.E (… Countable: false)` — touching only an entity-level property — detonates every attribute: `[CE6612] \"Attribute 'circuitId' of external entity 'Stg_Circuit' is not supported.\"`, one per attribute, leaving a project that cannot build", "cause": "Not the executor: it already preserves attributes it was not asked to change (`if len(attrs) > 0`). One layer down, `attributeFromGen` handled `StoredValue` and `OqlViewValue` but **not** `Rest$ODataMappedValue`, so every attribute of an external entity read back with no `RemoteName`, and the writer's `isExternal && a.RemoteName != \"\"` arm then fell through to a plain StoredValue on the next read-modify-write", "file": "`mdl/backend/modelsdk/domainmodel.go` (`attributeFromGen` gains the `ODataMappedValue` / `ODataMappedPrimitiveCollectionValue` arms)", "insight": "**The attribute-level half of #782**, which fixed the entity level and stopped there — when a read-modify-write loses data, check every *nesting level* of the read, not just the one named in the report. A polymorphic `Value` switch that silently ignores a variant is the shape to look for: it compiles, it reads, and it drops. Reproduce with a **local metadata file** (`MetadataUrl: './contract.xml'`) — no server needed, and the import is the same code path. Also learned here: the reported attribute *rename* (`name` → `Stg_Circuitname`) is a different thing entirely — it happens at import, from `reservedEntityAttrNames`, and `name` is **not** actually reserved (verified: Mendix builds an external entity with an attribute literally named `name`). Tests `external_entity_read_test.go`. mxcli-formula1 #25", "refs": ["#25", "#782"], "ce": ["CE6612"]}
+{"area": "mdl/backend", "date": "2026-08-09", "symptom": "Re-running `create external entities from` adds two more associations every time — `season_2`, `season_3`, then `season_4`, `season_5`, … unbounded. `mx check` is clean, every test passes, and the only symptom is duplicate links in Studio Pro's domain model", "cause": "The re-import dedup matches an existing association by the OData **nav-property** name, but association names are unique per MODULE, so the second entity with a `season` nav property is stored as `season_2` — which can never match `season`. The nav-property index that would have matched it is keyed on `RemoteParentNavigationProperty`, and the **modelsdk reader never read the OData source back**, so that index was always empty under the default engine. The legacy reader did read it, which is why this only bit the default path", "file": "`mdl/backend/modelsdk/domainmodel.go` (`assocFromGen` now reads `*genRest.ODataRemoteAssociationSource`), `mdl/executor/cmd_contract.go` (`indexExistingAssociations`)", "insight": "**A field that the write path sets and the read path drops survives exactly one save.** Grep both directions when a round-trip matters — `RemoteParentNavigationProperty` appeared in `domainmodel_write.go`, in gen, and in the legacy parser, and was missing only from the modelsdk read, which is invisible if you only grep for the identifier. **Do not \"fix\" this by stripping a trailing `_<n>` from names**: that heuristic also swallows a user's genuine `season_2`, and the model already records the true origin. Damage is cumulative and pre-existing: a project that ran the import N times carries 2N spurious associations, and they cannot simply be deleted — external-entity access rules reference them, so removing one leaves CE1613 \"The selected association no longer exists\". Tests `mdl/backend/modelsdk/association_odata_source_test.go` (round-trip, plus a control that a plain association is not stamped as external) and `mdl/executor/cmd_contract_reimport_test.go` (the index, incl. the assertion that the suffixed ones match via the nav index and NOT the name index — otherwise the guard passes for the wrong reason). mxcli-formula1 §50", "ce": ["CE1613"]}
+{"area": "mdl/backend", "date": "2026-08-10", "symptom": "DESCRIBE renders an activity as `-- Empty action` and its entire error branch is missing from the output — the MDL stays syntactically valid, nothing is printed to stderr, and a describe→edit→exec cycle deletes both", "cause": "Two unrelated defects stacked. (a) The modelsdk reader — the DEFAULT engine — had no case for the action's `$Type`, so `ActionActivity.Action` was nil and `formatAction(nil)` returned the anonymous comment; 27 of 58 `MicroflowAction` types were in that state, 12 of them ones the legacy parser handles. (b) `emitActivityStatement` returned as soon as the statement started with `--`, *before* consulting `errorHandlerFlow`, so the branch was never traversed — for **every** unmapped action, not just the reported one", "file": "`mdl/backend/modelsdk/microflow.go` (nil → `UnsupportedAction` stand-in carrying `$Type` + `ErrorHandlingType`), `mdl/backend/modelsdk/microflow_read_actions.go` (`errorHandlingTypeOf` reads the field by property name), `mdl/executor/cmd_microflows_show_helpers.go` (`emitCommentedErrorHandler`), `mdl/executor/cmd_microflows_format_action.go`", "insight": "**Count the gap before fixing the instance** — decoding each `$Type` through the real reader turned \"SynchronizeAction is unsupported\" into \"27 types are, and `ExecuteDatabaseQueryAction` is a shipped feature you cannot describe back\". **The early return is load-bearing**: annotations before a line comment make exec fail `no viable alternative at input '@position...'`, so keep it and emit the branch **commented-out** — emitting it live is worse than dropping it, since the next exec runs those activities unconditionally in the main flow instead of on failure. **Never take an enum from the UI wording**: Studio Pro says \"Selected object(s)\", the model stores `Specific` (Model SDK `SynchronizationType`, fetched via `npm pack mendixmodelsdk` — authoritative when `reference/` is not vendored). **A Mendix array's element 0 is a version marker, not data**: `property.EnumList.BSONValue()` returns a bare `[]string`, so a one-element list read back empty and mxbuild said CE2004 \"No variables to synchronize have been selected.\" with the value plainly in the dump. Also CE0011 if a custom error handler has no outgoing error flow — call `finishCustomErrorHandler`. Tests `cmd_microflows_unsupported_action_test.go`, `microflow_synchronize_test.go`; example `mdl-examples/bug-tests/863-synchronize-and-unsupported-actions.mdl`. upstream #863", "refs": ["#863"], "ce": ["CE0011", "CE2004"]}
+{"area": "mdl/backend", "date": "2026-08-10", "symptom": "`execute database query` is written correctly and builds, but DESCRIBE renders it as `-- Empty action` (or, after #863, `-- Unsupported action: DatabaseConnector$ExecuteDatabaseQueryAction`) — a shipped feature you can author and never get back", "cause": "The modelsdk reader (the DEFAULT engine) had no case for it. Both the MDL grammar and the DESCRIBE formatter were already there; only `actionFromGen` was missing, so `ActionActivity.Action` came back nil", "file": "`mdl/backend/modelsdk/microflow_read_actions.go` (`case *genDb.ExecuteDatabaseQueryAction`, plus `rawDocElements` for versioned arrays)", "insight": "**The `$Type` is `DatabaseConnector$ExecuteDatabaseQueryAction`, not `Microflows$`** — several actions live in their own sub-metamodel, so a probe under the wrong prefix proves nothing either way and a `case \\*genMf\\.` grep under-counts what is mapped. **Read from raw against the keys the WRITER builds** (`Query` / `DynamicQuery` / `OutputVariableName` / the two mapping lists): the writer constructs the element directly rather than through gen setters, and gen exposes the named query as `QueryQualifiedName`, so pinning reader and writer to one key set is what makes the round trip mean anything. **Element 0 of a versioned array is the marker, not a mapping** — skip non-documents rather than slicing `[1:]`. **A text-stable round trip is not a valid model**: `describe→exec→describe` diffed clean while `mx check` died at load, because the fixture's `create database connection … username 'app'` wrote a literal into a ConstantIdentifier property (`StorageLoadException`, still-open defect, same class as #854) — always run the build, not just the diff. Tests `microflow_dbquery_test.go`, example `mdl-examples/bug-tests/863-execute-database-query-describe.mdl`. upstream #863 follow-up", "refs": ["#854", "#863"]}
+{"area": "mdl/backend", "date": "2026-08-11", "symptom": "`call workflow`, `get workflow data/workflows/activity records`, `open`/`lock`/`unlock workflow` and `workflow operation` all DESCRIBE as a placeholder, so a describe→edit→exec cycle deletes them — while authoring and building them works fine", "cause": "The modelsdk reader (the DEFAULT engine) had no case for any of the eight; each read back with a nil Action. The formatters and grammar were already there, so only `actionFromGen` was missing", "file": "New `mdl/backend/modelsdk/microflow_workflow_read.go` (+ dispatch in `microflow_read_actions.go`), `mdl/grammar/domains/MDLMicroflow.g4` + `mdl/visitor/visitor_microflow_workflow.go` (positional `call workflow` form), `mdl/executor/cmd_microflows_builder_workflow.go` (abort reason)", "insight": "**Read against the WRITER's keys, not gen's** — gen binds every \"get\" action's result as `VariableName` while the model stores `OutputVariableName`, so an accessor-based reader silently drops the variable; round-trip tests (not reader-only tests on hand-written BSON) are what catch it. **`WorkflowSelection` has two variants and the object form uses `WorkflowDefinitionVariable`**, not `WorkflowVariable`; its ABSENCE is meaningful (the all-workflows case), so do not synthesise one. **Dispatch the operation on `$Type` before reading fields** — only Abort carries a Reason. **Finishing the reader exposes what could not be seen while nothing rendered**: `call workflow` described to a positional form the grammar rejected (the model never stores the parameter NAME, so DESCRIBE cannot emit the named form), and the abort reason stored the expression *including its quotes* into a StringTemplate Text, so Mendix rendered the quotes at runtime and every round trip doubled them. **Still open**: `lock/unlock workflow all` writes an activity mxbuild rejects with CE1825 — a lock always needs a specific definition, and supplying an empty selection does not satisfy it. Tests `microflow_workflow_read_test.go`, example `mdl-examples/bug-tests/workflow-actions-describe.mdl`", "ce": ["CE1825"]}
+{"area": "mdl/backend", "date": "2026-08-11", "symptom": "`transform $In with Module.Transformer` reports \"Created microflow\" and the build then fails `[CE0008] \"No action defined.\"` — the activity is in the model with no action inside it", "cause": "The modelsdk writer (the DEFAULT engine) had no `TransformJsonAction` case, so it fell through to `default: return nil`. The grammar, builder, DESCRIBE formatter and the LEGACY writer all handled it, which is why it looked supported. The reader was missing too, so even a correctly written action described as a placeholder", "file": "`mdl/backend/modelsdk/microflow_write.go` (writer case), `mdl/backend/modelsdk/microflow_read_actions.go` (reader cases for `TransformJsonAction`, `CallExternalAction`, `RestOperationCallAction`)", "insight": "**A missing WRITER case and a missing READER case present identically in a coverage audit** — grepping for reader cases found `transform` \"authorable but unreadable\" when it was actually unwritable, a strictly worse bug. Check both directions before sizing the work. **Mirror the legacy serializer for keys** (`InputVariableName`/`OutputVariableName`/`Transformation`); for the other two, note `CallExternalAction` stores its result under `VariableName` (not `ResultVariableName`) and REST's two mapping lists are NOT symmetric — the query list keys its name as `QueryParameter`. **Do not reconstruct `CallExternalAction.ResultDataType`**: it is resolved from the consumed service's cached `$metadata` at write time, so reading it back would let a stale value round-trip as if authored. **CE0008 turning into CE1613 is progress, not a new bug** — the action now exists and the build has moved on to validating its reference. Tests `microflow_integration_actions_test.go`, example `mdl-examples/bug-tests/transform-json-write-and-describe.mdl`", "ce": ["CE0008", "CE1613"]}
+{"area": "mdl/backend", "date": "2026-08-11", "symptom": "`describe import mapping M.X` / `describe export mapping M.X` reports \"not found\" for a mapping that exists and that `show` lists. `create or modify json structure` silently creates a duplicate instead of modifying the existing one. All of them work if the document happens to sit directly under the module rather than in a folder", "cause": "`Backend.moduleNameFor` resolved a unit's module by reading its **direct** container (`GetModule(u.ContainerID)`). Studio Pro nests documents in folders — and folders in folders — so for any foldered document the container is a `Projects$Folder`, `GetModule` returns nil, the name resolves to `\"\"`, and every `…ByQualifiedName` lookup built on it misses. In a stock marketplace project this is the *normal* case, not an edge case: 15 of 16 microflows, both JSON structures and both mappings were foldered, while all 8 domain models sat directly under their module — which is exactly why the three domain-model callers worked and hid the defect", "file": "`mdl/backend/modelsdk/domainmodel_write.go` (`moduleNameFor`); callers in `mapping_write.go`, `json_write.go`, `microflow.go`, `domainmodel_alter.go`", "insight": "Walk the containment chain to the first enclosing module instead of reading one level. Build the parent map once (the old code re-scanned `ListUnits()` per call, inside a loop over every document — O(n²)), and **guard the walk against cycles**: the project root is its own container, so an unguarded loop hangs. Behaviour is unchanged for direct children, so the domain-model callers are unaffected. **Generalisable — the shape to look for**: a containment lookup that reads one level where the model allows arbitrary nesting. It works on every fixture built by `create module` + `create X` (nothing is foldered) and fails on every real project, so unit tests pass while users see \"not found\". **Diagnostic trap**: `describeImportMapping` wraps any error containing \"not found\" in `mdlerrors.NewNotFound`, so the surfaced message is identical whichever layer failed and cannot be used to identify the engine — call the reader and the backend directly to tell them apart. The legacy `sdk/mpr` reader walks the chain correctly (`buildContainerModuleNameMap`), so **the two engines disagreed** and only the default (modelsdk) was broken. Test `mdl/backend/modelsdk/module_resolution_test.go`"}
+{"area": "mdl/backend", "date": "2026-08-12", "symptom": "`alter entity … add attribute` on an entity that has a **RegEx or Range** validation rule silently turns that rule into a **Required** rule: the regex reference (or the min/max bounds) is gone, the field is merely mandatory, and `mx check` reports nothing — a Required rule is perfectly valid. Happens on BOTH engines", "cause": "A matched pair of fallbacks. The modelsdk READER (`ruleTypeFromGen`) collapsed every RuleInfo except Unique to `\"Required\"`, and BOTH writers (`ruleInfoToGen`, `serializeRuleInfo`) fell back to `RequiredRuleInfo` for any type they did not recognise. ALTER ENTITY round-trips the whole entity through read→write, so the two defaults compose into a silent downgrade", "file": "`mdl/backend/modelsdk/domainmodel.go` (`ruleTypeFromGen` now derives the name from `$Type`), `mdl/backend/modelsdk/domainmodel_write.go` + `sdk/mpr/writer_domainmodel.go` (both rule-info serializers return **nil = refusal**, plus `reproducibleRuleType`/`validationRulesAreReproducible`), guards in both `UpdateEntity` implementations", "insight": "**A read default and a write default are individually defensible and jointly destructive** — neither function looks wrong alone; the corruption only exists in the round trip. When auditing a rewrite path, check the reader's fallback and the writer's fallback TOGETHER. **`mx check` is not a safety net for a type substitution**: both rules are valid, so the build stays green and the only evidence is the stored `$Type`. **A fourth gen-vs-reality key mismatch**: `modelsdk/gen` binds `RegExRuleInfo`'s reference to BSON `RegularExpression`, while the Studio Pro document (Mendix Email Connector 6.4.2) stores `RegExIdentifier` — so RegEx rules cannot be written through gen at all today, which is *why* the fix is a refusal rather than a round trip. There is no `supplements.json` or `cmd/modelsdk-codegen` in this tree, so correcting gen is not currently available. **Injection fixtures need ORDERED BSON**: re-marshalling a unit through `bson.M` randomises key order and Mendix refuses to load it (`Expected '$ID' as the first property of a storage object`) — use `bson.D` throughout, or the fixture's own invalidity masks the thing you are testing. **Required/Unique rules were never affected**, and are authorable today via the `not null error '…'` / `unique error '…'` attribute constraints — only the standalone `create validation rule` statement is dead (grammar with no AST, visitor or handler). Tests `sdk/mpr/writer_validationrule_test.go`, `mdl/backend/modelsdk/validationrule_test.go`"}
+{"area": "mdl/backend", "date": "2026-08-11", "symptom": "`ALTER PAGE` over `--mcp` fails against Studio Pro **11.13** with `pg_patch_page: … PROP_NOT_PRIMITIVE: Property 'widgets' is not a primitive property`. `CREATE PAGE` is fine; the page itself is left intact", "cause": "11.13 gave `pg_read_page` a **`depth` argument defaulting to 4**, replacing anything deeper with the literal string `\"...\"`. ALTER PAGE is read-modify-**replace-whole-page**, so the truncated read went straight back as the new page body. Measured live: `Administration.Account_Overview` read 32,594 bytes at full depth but **1,052 bytes** at the default, its entire tree reduced to `{\"widgets\":[\"...\",\"...\"]}`. Every ordinary page truncates — three of three PgTest pages did", "file": "`mdl/backend/mcp/page.go` (`pgReadPage`, `pgReadFullDepth`, `hasTruncationSentinel`), `mdl/backend/mcp/client.go` (`SupportsToolArg`)", "insight": "Request the full depth, and **guard rather than trust it**: refuse a read still carrying the sentinel instead of letting a partial page reach a write (ADR-0005 guard-don't-drop). Two traps. (1) **Do not send `depth` unconditionally** — 11.11/11.12 declare `pg_read_page` `additionalProperties:false` without it, so the whole call fails; gate on a live `tools/list` probe of the tool's input schema, because `serverInfo.version` is frozen at `1.0.0` across 11.11/11.12/11.13 and cannot discriminate releases. (2) **Match the sentinel only as an array element** — a caption or title legitimately reading `\"...\"` is real content, and a naive substring scan rejects valid pages. The release notes announced none of this, exactly as 11.12 silently removed `pg_write_page` (#697): on any Studio Pro upgrade, re-probe `tools/list` and diff the input schemas, not just the tool names. Tests `mdl/backend/mcp/page_depth_test.go`; controls: stub the depth arg (full-depth test fails) and stub the guard (truncation test fails)", "refs": ["#697"]}
+{"area": "mdl/backend", "date": "2026-08-12", "symptom": "A `call java action` whose parameter is a **microflow** (`MCPServer.AddTool`'s `ExecutingMicroflow`, and every other \"register a callback\" action) fails `mx check` with **CE0115** — the microflow's name is stored as a literal string", "cause": "The modelsdk engine's java-action read had no case for the parameter type, so `codeActionBasicFromGen` fell through to its `default` and returned a `StringType`. The microflow builder's `microflowTypeParams` branch was therefore never taken and it authored `Microflows$BasicCodeActionParameterValue{Argument: \"'M.MyFlow'\"}` instead of `Microflows$MicroflowParameterValue{Microflow: \"M.MyFlow\"}`", "file": "`mdl/backend/modelsdk/java_read.go` (`codeActionBasicFromGen`), `java_write.go` (`codeActionParamTypeToGen`), `mdl/executor/cmd_javaactions.go` (`astDataTypeToJavaActionParamType`, `bareDataTypeName`)", "insight": "**A `default:` that returns a plausible type is how a read path lies.** The legacy parser and the executor both handled this correctly for years; only the gen→semantic converter did not, and it degraded to String rather than erroring — so every layer downstream looked correct in isolation. **Fix read and write together**: without the write case an *update* of such an action rewrites the parameter as a String, which is worse than the read bug. **Watch what DESCRIBE starts printing** — the fix made it emit the honest `Microflow`, which then round-tripped into an entity type with an empty module (`.Microflow`) until `astDataTypeToJavaActionParamType` learned the bare word. Probe the stored `$Type` from the marketplace `.mpk` before theorising; MCP Server 5.1.0 stores `JavaActions$MicroflowJavaActionParameterType`. Tests `mdl/backend/modelsdk/java_read_test.go`, `mdl/executor/cmd_javaactions_test.go`, example `mdl-examples/bug-tests/javaaction-microflow-parameter.mdl`; verified 0 errors under `mx check` 11.12.1. Reported in mxcli-chat FINDINGS §36", "ce": ["CE0115"]}
+{"area": "mdl/backend", "date": "2026-08-13", "symptom": "`GRANT <role> ON Module.Specialization (READ *, WRITE *)` writes a model Mendix rejects with **CE0066** \"Entity access is out of date\", while the same grant on the generalization checks clean. The executor passes 3 MemberAccess entries and storage holds 2", "cause": "`ReconcileMemberAccesses` — which runs after every program and after every `create association` — recomputes each rule's expected member set from the entity's **own** attributes and the module's **FROM-side** associations. An inherited association matched neither, so it was classed stale and deleted, one step after the GRANT that had just written it correctly", "file": "`mdl/backend/modelsdk/domainmodel_security_write.go` (`sameModuleAncestors`, `entitiesByName`, `assocRefBelongsTo`, `ownerIDs` in `ReconcileMemberAccesses`), `mdl/executor/cmd_associations.go` (reconcile after DROP)", "insight": "**The write path was innocent** — `AddEntityAccessRule` stored all 3; the deletion happened in the reconcile that ran next. When a value is written and then absent, instrument the *later* pass before the writer. **Preserve what cannot be checked**, as the attribute branch already did (#758): an association is qualified by the module that DECLARES it, so an ancestor in another module (the reported `OpenAIDeployedModel extends GenAICommons.DeployedModel`) names a domain model that is not loaded here. **The counter-control is the whole test**: a walk that collected every association in the module passes both positive cases and puts an entry on the TO side of an `OWNER Default` association, which is *itself* CE0066 — so assert that the unrelated entity does **not** get one. **Reconcile must add as well as keep**, or a rule written before the ancestor gained the association never catches up. Verifying this surfaced a neighbouring bug: `drop association` never reconciled at all, leaving entries Mendix rejects with CE1613 — on the declaring entity too, so it predates inheritance support. Tests `mdl/backend/modelsdk/reconcile_inherited_assoc_test.go` (5 cases incl. both controls), `mdl/executor/cmd_associations_mock_test.go`; example `mdl-examples/bug-tests/grant-on-specialization.mdl`, measured 1 error → 0 on mxbuild 11.12.1. Reported in mxcli-chat FINDINGS §25", "refs": ["#758"], "ce": ["CE0066", "CE1613"]}
+{"area": "mdl/backend", "date": "2026-08-14", "symptom": "Authoring a pluggable widget property that lives in a **conditionally shown group** writes a widget Mendix rejects with **CE0463**, while the same widget's other properties take non-default values happily. On ProgressCircle both `showLabel: true` and `labelType: 'percentage'` do it; `showLabel: false` and General-group properties are clean. No DESCRIBE involved", "cause": "Two gaps on the same axis. **Serialization**: #574 nulls the TextTemplate of a HIDDEN conditional property, but left a VISIBLE one null — and Mendix stores an empty `Forms$ClientTemplate` there. Null and empty are each invalid in the other's state, so nulling hidden ones was only half the rule. **Extraction**: the editorConfig reader did not understand a ternary's ELSE branch (`cond ? (…) : hidePropertiesIn([…])`), so the `showLabel` gate was never seen and `labelText` read as visible whenever `labelType` was `\"text\"` — its default", "file": "`mdl/backend/widgetobj/builder.go` (`ApplyVisibilityRules`, `bsonFieldIsNil`), `mdl/executor/editorconfig_extract.go` (`parseGuard` `:` case, `ternaryCondition`, `trailingExpr`)", "insight": "**Fixing one gap alone inverts the bug rather than closing it** — filling visible templates without the missing gate made `showLabel: false` fail where `true` had, because mxcli still thought labelText was visible. Measured both ways round before and after; a fix that moves which case fails is not a fix. **Let Mendix say what the shape should be**: `mx update-widgets` on a COPY of the failing project reconciles the widget, and diffing that against mxcli's output named the single meaningful path (`Object/Properties[N]/Value/TextTemplate` null vs `Forms$ClientTemplate`) out of 969. **The good/bad control does the isolation for free**: authoring the same widget with the boolean both ways gave two documents differing in exactly ONE path, so no other candidate needed testing. **Only CONDITIONAL properties are filled** — Studio Pro's convention for an unset TextTemplate is not uniform (a DataGrid custom-content column stores null for `tooltip` and an empty template for `exportValue`, per `emptyClientTemplateRules`), so filling every unset one would trade this bug for its mirror image. **The extractor's preamble matters**: the ternary is preceded by a whole `switch`, and walking back past the `?` to the function start yields a fragment with an unbalanced `}` that parses to nothing and looks like \"unsupported shape\" — hence `trailingExpr`. Regression signal: the widgetdemo showcase applies with **0 CE0463** (its 4 CE1613 are a pre-existing attribute reference). Tests `mdl/backend/widgetobj/widget_visibility_test.go`, `mdl/executor/editorconfig_extract_test.go`; example `mdl-examples/bug-tests/pluggable-describe-roundtrip.mdl` now exercises the group. Reported in mxcli-ledger FINDINGS #104 follow-on", "refs": ["#104", "#574"], "ce": ["CE0463", "CE1613"]}
+{"area": "mdl/backend", "date": "2026-08-14", "symptom": "`ALTER PAGE` **`REPLACE <col>`** or **`INSERT AFTER <col>`** naming a DataGrid2 column with a BARE name reports \"Altered page\", but the column vanishes (REPLACE) or nothing changes (INSERT) — and Studio Pro / `mx check` then cannot **LOAD** the project: `System.InvalidCastException: Unable to cast object of type '…LayoutWidgets.DivContainers.DivContainer' to type '…CustomWidgets.WidgetObject'`", "cause": "`ast.WidgetRef` treats only a **dotted** name as a column, so a bare `NextRunAt` gives `Widget=\"NextRunAt\"`, `Column=\"\"`, `IsColumn()==false`. The op skipped the `InsertColumns`/`ReplaceColumn` paths — which work correctly — and fell through to the generic widget path, which built the `COLUMN` as a **layout container** and wrote it into the grid's column list. Nothing refused because `findBsonWidget` **recurses into pluggable-widget internals**, so the bare name *did* resolve — to the column node. `DESCRIBE PAGE` then skipped the malformed node, which is what made REPLACE look like a clean deletion and INSERT like a harmless no-op", "file": "`mdl/backend/pagemutator/mutator.go` (`refuseObjectListItemTarget`, called from `InsertWidget` + `ReplaceWidget`)", "insight": "Discriminate on the resolved node's **`$Type`**: an object-list item (DataGrid2 column, Accordion group, PopupMenu basicItem) is `CustomWidgets$WidgetObject`, a real widget is `Forms$*` / `CustomWidgets$CustomWidget`. Refuse the bare form and name the qualified `grid.column` in the message — do **not** auto-resolve, since guessing which grid was meant is what produced the invalid document. Do not discriminate by *counting* name matches: `columnMatchCount` already existed but only refused when `n > 1`, so the single-match case (the common one) sailed through, and a widget that merely shares a name with some column elsewhere would be a false positive. Guard belongs in the **mutator**, not the executor — `FindWidget` matches columns too, so an executor-level check on it only catches names that are absent entirely, which the mutator already refuses. Repro `mdl-examples/bug-tests/891-alter-page-bare-column-target.fail.mdl`. Issue #891", "refs": ["#891"]}
+{"area": "mdl/backend", "date": "2026-08-18", "symptom": "`ALTER PAGE SET DynamicCellClass` / `SET Visible` on a DataGrid 2 column reports success and changes nothing visible: the value does not come back from `describe page`, and `mx check` stays at 0 errors", "cause": "`setColumnPropertyMut` wrote every value to `PrimitiveValue`. `columnClass` and `visible` are **Expression**-valued, and a `CustomWidgets$WidgetValue` carries *every* field at once — Expression, PrimitiveValue, TextTemplate, AttributeRef — with the unused ones empty, so key-presence cannot tell you which one to write and the always-primitive default looked plausible. The value landed in a field Mendix does not read", "file": "`mdl/backend/pagemutator/mutator.go` (`columnValueField`, `buildColumnPropKeyMap` now also returns kinds, `bsonWidgetResult.colPropKinds`)", "insight": "Take the kind from the schema — the column's `PropertyTypes[].ValueType.Type` — and write Expression, PrimitiveValue or the TextTemplate path accordingly; refuse the structured kinds (Attribute, DataSource, Action, Widgets) rather than writing a string where a reference belongs. Verified on Mendix 11.13.0: before, the write was invisible to DESCRIBE and `mx check` said 0 errors; after, it round-trips and mxbuild **validates** it — a valid expression builds at 0 errors and a bare identifier is CE0117, matching what CREATE produces for the same input. **Generalisable**: when a container type carries every variant field at once, presence is not a discriminator — the schema is. A silent wrong write is worse than the loud failure it was hiding behind", "ce": ["CE0117"]}
+{"area": "mdl/backend", "date": "2026-08-17", "symptom": "Authoring a pluggable widget with an **object list** (Accordion group, Pop-up menu item, chart series) raises **CE0463** \"the definition of this widget has changed\" on the widget itself, on a widget created seconds ago against the current package", "cause": "An object-list item's **required TextTemplate** that the author left unset was serialized as `null`. `emptyClientTemplateRules` in `widgetobj/builder.go` is a hardcoded per-widget table covering only DataGrid columns, so every other object-list widget fell through it. Required-ness is genuinely absent from the widget XML for these properties — and the widget schema **defaults `required` to true** — so the Accordion's `headerText` is mandatory even though nothing says so", "file": "`mdl/backend/widgetobj/builder.go` (`isUnsetRequiredTextTemplate`, `buildDefaultTextClientTemplateProperty`), plus the entry plumbing in `mdl/types/widget_property_type.go`, `modelsdk/widgets/loader.go`, `sdk/pages/pages_widgets_advanced.go`, `mdl/backend/modelsdk/widget_pluggable_write.go` (`convertPropTypeIDs`)", "insight": "Serialize a required unset TextTemplate with the widget's **shipped `<translations>`**, read off the template ValueType's `Translations` beside the `Required` flag. **Both weaker forms were measured and fail**: `null` is CE0463, and an *empty* `Forms$ClientTemplate` is **CE4899** \"Property 'Groups/1/Text' is required\" — so the intuitive \"emit an empty template\" fix only moves the error. Populating is what `mx update-widgets` itself writes (verified: mxcli and the reference now emit the same `'Header'`/`'Koptekst'`). Scope it to **required** properties: filling every TextTemplate is the documented way to take CE0463 from 33 to 127. Note `PropertyTypeIDEntry` exists in THREE places (`mdl/types` — canonical and aliased by `modelsdk/widgets`; `sdk/pages` — what the builder consumes; `sdk/widgets` — the legacy engine's own), so a field added for this must be carried through `convertPropTypeIDs` or it silently never arrives. Repro `mdl-examples/bug-tests/891-accordion-group-nested-widgets.mdl`. Issue #891", "refs": ["#891"], "ce": ["CE0463", "CE4899"]}
+{"area": "mdl/backend", "date": "2026-08-18", "symptom": "`describe database connection` omits `returns` / `map (…)` / `parameter` on the **default (modelsdk) engine** while the legacy engine renders them, so a describe → exec round trip drops the return entity, the column mapping and every query parameter", "cause": "The modelsdk reader populated neither `TableMappings` nor `Parameters`, so the DESCRIBE renderer (which does handle them) only ever saw empty slices — dead code on that engine. The round-trip test existed but was pinned to the legacy backend via `setupTestEnv`, so it passed while the default engine was lossy", "file": "`mdl/backend/modelsdk/integration_read.go` (`tableMappingsFromGen`, `queryParametersFromGen`); test `mdl/executor/roundtrip_dbconnection_test.go`", "insight": "Mirror the legacy reader field for field, and run the round-trip test over `gateEngines` rather than the default backend. **The cross-engine DESCRIBE matrix is the check that finds these**: write with engine A, read with engine B, all four combinations — a gap on one engine is invisible from inside that engine. Fixing one field (TableMappings) and not its sibling (Parameters) is the characteristic mistake; enumerate every child collection of the document before calling it done"}
+{"area": "mdl/backend", "date": "2026-08-18", "symptom": "`calculated by Module.Microflow` on an attribute is accepted by `check` and by exec (\"Added attribute\"), but the stored document holds a plain `DomainModels$StoredValue` with no calculation link — the microflow name appears nowhere in the domain model unit, `mx check` reports **0 errors**, and the attribute is simply empty at runtime. Both the CREATE (inline) and ALTER (`ADD`/`MODIFY ATTRIBUTE`) paths. A microflow whose signature cannot work is accepted too, masked by the same drop", "cause": "`attributeToGen` in the **modelsdk** writer had arms for OqlViewValue / ODataMappedValue / ODataMappedPrimitiveCollectionValue and a `default:` that emits StoredValue — no `CalculatedValue` arm — so the binding the executor had already resolved fell through and was discarded. The **legacy** writer had the arm all along (`sdk/mpr/writer_domainmodel.go`), which is why the feature read as implemented; modelsdk is the default engine (`--engine`), so everyone hit the broken path. The reader had no `CalculatedValue` case either, so an unrelated ALTER on the same entity destroyed a binding made in Studio Pro", "file": "`mdl/backend/modelsdk/domainmodel_write.go` (`attributeToGen`) + `domainmodel.go` (`attributeFromGen`) + `mdl/executor/calculated_attributes.go` (`resolveCalculatedValue`, called from the three sites in `cmd_entities.go`)", "insight": "Add the write arm (`genDm.NewCalculatedValue`, `SetMicroflowQualifiedName` → the `Microflow` ByNameRef key, `SetPassEntity`) **and** the read arm — a write-only fix leaves the read-modify-write data loss in place, which is the worse half. Derive `PassEntity` from the signature rather than hardcoding it (legacy hardcoded `microflowRef != \"\"`): measured on 11.13.0, an entity-parameter microflow (`PassEntity=true`) and a parameterless one (`PassEntity=false`) BOTH build at 0 errors, so refusing the parameterless form would have been wrong. Signature rules are refused at exec (the #833 placement), and each was checked against mxbuild rather than assumed — wrong entity parameter and wrong return type are both **CE7247**, but the return-type message is *\"should be Integer/Long\"*, so **Integer and Long are one family** and a strict equality check refuses valid MDL (caught only by reading the CE text). To ask mxbuild about a binding mxcli now refuses, stub the check and rebuild — `--engine legacy` does NOT bypass it, because the validation lives in the engine-independent executor. Tests `TestAttributeToGen_CalculatedValue`, `TestAttributeFromGen_CalculatedValue`, `TestResolveCalculatedValue_*` (the backend three fail with `value is *domainmodels.StoredValue` when reverted); fixture `mdl-examples/bug-tests/917-calculated-attribute-binding.mdl`. Issue #917", "refs": ["#833", "#917"], "ce": ["CE7247"]}
+{"area": "mdl/backend", "date": "2026-08-19", "symptom": "`ALTER PAGE` at a **dotted** DataGrid2 column target (`insert after grid1.Col { container … }` / `replace grid1.Col with { container … }`) reports \"Altered page\", and `mx check` then aborts before checking anything: `System.InvalidCastException: Unable to cast object of type '…DivContainers.DivContainer' to type '…CustomWidgets.WidgetObject'`. Separately: a widget **inserted into a customContent cell** binds nothing — `ContentParams` naming an association path stores the raw path as the attribute name (**CE1613**) and `describe page` shows the path with its first hop silently gone", "cause": "Two defects. (a) #891's guard covers only the BARE column form; the dotted form is legitimate and skips the guard entirely, so a **non-`column` body** still fell through to the generic widget path and was serialized into the grid's column list. The wrong thing is the *pairing* (widgets at an object-list target), not the target. (b) The entity-context walk descended into a pluggable widget's own widget properties but not into an object-list ITEM's — a column keeps its cell widgets one level deeper at `Objects[].Properties[content].Value.Widgets`, the same descent `findInWidgetChildren` gained in #834 — and never read a **pluggable** widget's datasource at all, so the grid's own entity was invisible too. Empty entity context ⇒ `resolveAssociationAttributePath` bails ⇒ the raw path is stored as the attribute name", "file": "`mdl/backend/pagemutator/mutator.go` (`refuseWidgetsAtColumnTarget` called from `InsertWidget`/`ReplaceWidget`; `findEntityContextInChildren`, `widgetOwnEntity`, `entityFromEntityRef`)", "insight": "(a) Refuse when `columnRef != \"\"` — resolve the column FIRST so a mistyped name still reports not-found with the available names, then refuse and name both alternatives (`column …` body, or address the widget inside the cell by its own name, per #834). (b) Descend into `Value.Objects[].Properties[].Value.Widgets`, keyed on the BSON shape rather than the `columns` property key so Accordion groups and PopupMenu items are covered by the same code; resolve a pluggable datasource through the shared `entityFromEntityRef`, which also gives it the IndirectEntityRef (association) case the plain reader already had. **Note the guard cannot key on the target alone** the way #891's does, and a unit test on the mutator alone under-proves it: reverting only shows a nil-deref in the fixture. The honest control is the CLI + `mx check` — measured on Mendix 10.24.20.105674, exception before / 0 errors after, and CE1613 before / 0 after. Repros `mdl-examples/bug-tests/935-alter-page-widgets-at-column-target.mdl` and `935-customcontent-column-entity-context.mdl`. Issue #935", "refs": ["#834", "#891", "#935"], "ce": ["CE1613"]}
+{"area": "mdl/backend", "date": "2026-08-19", "symptom": "`GRANT <role> ON <entity> (READ (A))` **shrinks** an existing access rule instead of widening it: attributes granted by an earlier GRANT come back `None`, and `(CREATE, DELETE, READ *, WRITE *)` followed by a narrow re-grant loses create, delete and every write right. No error, no warning, no diff. Reported as WHERE-specific and as a \"silent security regression\"", "cause": "Two defects. (a) The codec engine's upsert **cleared the matched rule's MemberAccesses and rebuilt them from the current statement alone**. The executor emits an entry for *every* member of the entity (unnamed ones at the rule's default, normally `None`), so each GRANT reset every member it did not mention; `AllowCreate`/`AllowDelete`/default rights were overwritten the same way. Legacy has merged additively since it shipped (`mergeAccessRule`), so this was an **engine regression**, not a longstanding gap — which is why the documented contract (\"GRANT is additive … never removes permissions\") held on one engine and not the default one. (b) **Both** engines matched a stored rule on its module-role set alone, ignoring `XPathConstraint`, collapsing two legitimate rules into one", "file": "`mdl/backend/modelsdk/domainmodel_security_write.go` (`AddEntityAccessRule`); `sdk/mpr/writer_security.go` (the upsert's match + `mergeAccessRule`); lattice shared via `mdl/types.AccessRightsLevel` / `HigherAccessRights`", "insight": "**Measure the reported trigger before scoping the fix to it.** WHERE was a red herring — the same loss reproduced with no WHERE and with `READ *`, so a fix aimed at the constrained path would have passed the reporter's repro and left most of the bug. Equally, the report understated the damage: only attributes were mentioned, but structural rights went too, so re-derive the blast radius rather than inheriting it. **Run the other engine as the control** — `MXCLI_ENGINE=legacy` merging correctly is what turned \"longstanding bug\" into \"regression\" and handed over the reference semantics (OR create/delete, take the higher default, take the higher rights per member) instead of having to invent them. For (b), **check the platform's own docs before calling multi-rule a user error**: Mendix's refguide says \"Rules are additive … all access rights of those rules are combined\", so one role holding one rule per constraint is the normal way to write row-level security, and `mx check` confirms it at 0 errors. Put the constraint in the match key and treat the empty constraint as a *value*, not a wildcard, so an unconstrained and a constrained rule coexist and re-running a script stays idempotent (ADR-0008). **Fixing (b) breaks anything keyed on roles alone**: `formatAccessRuleResult` then echoed a *different* rule's rights back at the user, so it needed the constraint too (REVOKE passes `anyXPath`, since it narrows every matching rule). Rights merge on `None < ReadOnly < ReadWrite`, so a merge never narrows — that is what keeps GRANT and REVOKE inverses rather than two spellings of \"set\". Issue #936", "refs": ["#936"]}
+{"area": "mdl/backend", "date": "2026-08-20", "symptom": "`ALTER STYLING … SET '<design property>' = '<value>'` prints `Updated styling on widget \"x\"` and writes **nothing**. The same statement works on a Studio Pro-authored widget, and the inline `DesignProperties: [...]` form works everywhere", "cause": "Two defects composing into a silent no-op. `bsonnav.DSet` takes a `bson.D` **by value**, so it can only overwrite an existing key — it returns `false` and does nothing when the key is absent, and `DSetArray` ignored that result. And the key WAS absent: the codec omits an empty, never-appended `PartList`, so `Forms$Appearance` on an mxcli-authored widget carried no `DesignProperties` at all (Studio Pro writes the empty marker `[3]` on all 16 pages of a blank app)", "file": "`mdl/backend/bsonnav/bsonnav.go` (`DSetArray` now returns bool + refuses a markerless write, new `DSetArrayIn`); `mdl/backend/pagemutator/mutator.go` (`writeDesignProperties`); `mdl/backend/modelsdk/widget_write.go` (`Forms$Appearance` MandatoryLists, `CustomWidgets$CustomWidget` LabelTemplate)", "insight": "**Fixing the append without fixing the marker turns a silent no-op into an unopenable project.** A Mendix array's first entry is its typed-array marker; measured on 11.13, a `DesignProperties` array written bare fails to LOAD (`Type OptionDesignPropertyValue does not contain a constructor with a parameter of type Appearance`) and `create-module-package` dies with \"Unknown export error\", while a doubled marker throws `StorageLoadException`. So `DSetArray` refuses rather than guessing, and the marker is passed explicitly at the one call site that creates the property. **Diff against `mx update-widgets`' own output** to find missing keys: handing an mxcli-authored page to Mendix's tool and diffing the unit it writes back (pointer identity preserved, key order intact) surfaced `DesignProperties`, `LabelTemplate` and a set of int32/int64 width mismatches in one pass. Not changed: `Forms$Page.AllowedModuleRoles` is marker 3 where Studio Pro writes 1 — `NewByNameRefListV3` documents CE0557 as the reason, and nothing currently misbehaves. Issue mendixlabs/mxcli#931", "refs": ["mendixlabs/mxcli#931"], "ce": ["CE0557"]}
+{"area": "mdl/backend", "date": "2026-08-21", "symptom": "A microflow that reads `if Module.SomeRule(param = $x) then` is written with **no Condition at all** — `mx check` reports **CE0080** \"The 'Condition' property is required.\" naming the Decision, whose caption still shows the call. `DESCRIBE` renders it as `if true then`, so the round trip looks like valid MDL, and re-applying an identical `CREATE OR MODIFY` over a Studio Pro-authored microflow turns a clean project into a broken one", "cause": "Two defects, one behind the other. (a) `splitConditionToGen` handled only `ExpressionSplitCondition` and fell through to `default: return nil`; the caller then skipped `SetSplitCondition` entirely. The READ side had been implemented for #723, and that asymmetry is what made it silent. (b) `modelsdk/gen` binds `Microflows$RuleCall.Rule` to BSON key `Rule`, where Mendix stores **`Microflow`** (rules share the microflow namespace) — so fixing (a) alone writes a reference Mendix never reads and produces the same CE0080 for a different reason", "file": "`mdl/backend/modelsdk/microflow_write.go` (`splitConditionToGen`, new `ruleCallToGen`, the `Microflows$RuleCall` marker registration); `modelsdk/gen/microflows/types.go` (`initRuleCall` + `RuleCall.InitFromRaw` — STORAGE-NAME OVERRIDE on both sides); strike the row off `modelsdk/gen/keyaudit_test.go`; tests `mdl/backend/modelsdk/microflow_rule_split_write_test.go`; repro `mdl-examples/bug-tests/939-rule-split-condition.mdl`", "insight": "**\"Works on Mendix 10, fails on 11\" was an ENGINE difference, not a version one** — same script, same project, `MXCLI_ENGINE=legacy` is 0 errors and the default (modelsdk) is CE0080. The microflow write path branches only on `major >= 10` / `<= 9`, so 10.24 and 11.12 take identical code; check the engine before believing a version story. **A round-trip test cannot see a wrong storage key** — it passes whichever key is used as long as both sides agree, which is exactly the shape of (b) — so assert the KEY on the encoded document, in a separate test with its own control. **Reconstruct the missing document type when the fixture does not exist**: MDL cannot author rules and no module in a blank Mendix 11 app ships one, so the repro rewrote an mxcli-created microflow's unit as `Microflows$Rule` (keeping only the ten properties `initRule` declares) — `mx check` 0 errors on the synthetic rule is the control that it is a valid stand-in. Verify the fix against the legacy engine's BSON, not just against a green build: the two documents are identical modulo key order. Issue mendixlabs/mxcli#939", "refs": ["#723", "mendixlabs/mxcli#939"], "ce": ["CE0080"]}
+{"area": "mdl/backend", "date": "2026-08-21", "symptom": "`ALTER WORKFLOW` over `--mcp` inserts a `CALL MICROFLOW` and Studio Pro shows **CE0495 \"Duplicate name\"** on the workflow, while `mxcli`'s own read-back looks fine and the statement reported success", "cause": "A `CALL MICROFLOW` activity is named after its target microflow (`buildCallMicroflowTask`: `task.Name = n.Microflow.Name`), so two calls to the same microflow collide before anything inspects them. The file backends deduplicate in `wfmutator`; the MCP backend had no equivalent and sent the derived name verbatim. Two separate gaps, both needed: PED **accepts** the duplicate with `SUCCESS` and does **not** auto-rename (measured live), and `mcpWorkflowMutator.Save()` early-returned when only activity ops had run, so `ped_check_errors` — the only thing that sees a consistency error — was never called. `CREATE`/`CREATE OR REPLACE` are **not** affected: the executor dedups at `cmd_workflows_write.go` for every backend", "file": "`mdl/backend/wfnames/` (shared policy); `mdl/backend/mcp/workflow.go` (`resolve`/`searchActivities` collect names on the walk, `Save`/`checkSettled`); `mdl/backend/wfmutator/mutator.go` (`serializeAndDedup`, `buildSubFlowBson`)", "insight": "Deduplicate **before the add** — PED refuses `set` on an activity's `/name` (`Element type does not support renaming`), so there is no repair after the fact. Collect the taken-set on the walk `resolve` already does, or the fix costs a PED round-trip per level. **Use a taken-set, not a seen-count**: counting re-collides the moment the workflow already contains the suffixed name (`A, A, A_2` counts its way to `A, A_2, A_2`). Uniqueness is workflow-**wide**, so recurse into the inserted activity's own outcome and boundary-event sub-flows. **`ped_update_document` reporting `SUCCESS` proves nothing about consistency** — it reports op-level failures only; `ped_check_errors` is the only signal, and it reads Studio Pro's **background** error list, which lags the write in BOTH directions (26 samples at a 20ms poll interval: error becomes visible 77-115ms after the write, stops being shown 75-128ms after the fix; one symmetric debounce, no growth under load). Asked too early it answers \"No errors found.\" for a document just broken **and** still reports an error a just-applied op has already cleared — measured against an immediate check as the control, 6 trials each: immediate missed the real error 6/6 and falsely failed on a cleared transient 6/6, settled 0/6 on both. `Backend.pedCheckDocument` owns the pacing for every call site (delay, then re-ask while clean) so a new write path cannot forget it. **Poll at a fine interval when measuring a debounce** — a first pass at 50-100ms reported 170-350ms and \"grows under load\", both pure granularity artifacts. Issue #945", "refs": ["#945"], "ce": ["CE0495"]}
+{"area": "mdl/backend", "date": "2026-08-21", "symptom": "`ALTER WORKFLOW … REPLACE ACTIVITY X WITH <activity named X>` silently renames it to `X_2`, and re-running the same script compounds it — `X_2_2`, `X_2_2_2`, … A no-op replace (nothing changed) renames too. Invisible to `mxcli check`, `exec` output, and — for `CALL MICROFLOW` steps, whose DESCRIBE renders only the target microflow — to `DESCRIBE` as well", "cause": "The dedup helper was written for INSERT and reused by REPLACE. `collectAllActivityNames()` walks the still-unmodified tree, so the activity about to be spliced out is still in the name pool when the replacement's name is checked against it — a same-name replace therefore always \"collides\" with itself. The MCP backend had the same shape, propagated deliberately in PR #204 on a **guess** that the file backends' choice was intentional", "file": "`mdl/backend/wfmutator/mutator.go` (`serializeAndDedup` gains `freeName`, `ReplaceActivity` passes the outgoing name); `mdl/backend/mcp/workflow.go` (`activityRefMatch.name` / `wfLocation.name`, `delete(loc.taken, loc.name)`); tests `mdl/backend/wfmutator/replace_samename_test.go`, `mdl/backend/mcp/workflow_dedup_test.go`", "insight": "Free **only the outgoing activity's name**, and read it off the **resolved element** — the reference may be a caption, not the name, so using `activityRef` frees the wrong key (or none). Keep a control proving a replacement colliding with a *surviving* activity still dedupes, or the fix over-corrects into CE0495. **Check the severity claim before believing it**: the report argued renames detach in-flight `System.WorkflowUserTask` records, but Mendix's [workflow-versioning docs](https://docs.mendix.com/refguide/workflow-versioning/) list \"changing names, captions, and titles\" as explicitly **non-conflicting** — the engine matches structurally, not by name. The real harm is unbounded accretion and the ADR-0008 idempotence break. **The fix only half-closes that**: a no-op replace still rewrites the `.mpr` because `addFreshPersistentID` re-mints `PersistentId` on every activity write in both engines and neither reads it back (measured: untouched siblings keep theirs, the replaced one does not). Issue #944", "refs": ["#204", "#944"], "ce": ["CE0495"]}
+{"area": "mdl/backend", "date": "2026-08-21", "symptom": "`CREATE OR REPLACE WORKFLOW` silently deletes a boundary event (timer + its whole handler flow) or an event sub-process that the script does not restate — `exec` reports \"Created workflow\" and exit 0, and `mx check` afterwards reports 0 errors because the result is a valid workflow that simply no longer does what it did. `DESCRIBE WORKFLOW` does not show the construct either, so nothing reveals the loss", "cause": "Two separate defects. (1) The **default (modelsdk) engine's workflow reader had no boundary-event support at all** — `grep BoundaryEvent mdl/backend/modelsdk/workflow_read.go` → 0, while `sdk/mpr/parser_workflow.go` → 17. Both engines *write* them, so a boundary event mxcli itself had just written read back as absent. (2) A rewrite rebuilds from the statement, so anything unstated is dropped, and no guard existed — unlike the queued-call and validation-rule paths", "file": "`mdl/backend/modelsdk/workflow_read.go` (`boundaryEventsFromGen`, wired into the 6 gen types with `BoundaryEventsItems`); `mdl/executor/validate_workflow_rewrite.go` (`checkNoDroppedWorkflowConstructs`, called from `cmd_workflows_write.go`); `mdl/executor/cmd_workflows.go` (clause order)", "insight": "**Read the stored side from the RAW unit, not the semantic model** — the reader is what was blind, and a guard sharing its blind spot cannot see what it protects; `GetRawUnit` also covers constructs no engine models yet (event sub-processes exist in `modelsdk/gen` but have no semantic type, reader or writer anywhere). Match the `$Type` by **substring** so all three timer variants and any later one are caught. Authorable constructs get the queue treatment (restate them and the rewrite proceeds); unauthorable ones refuse outright. **Fixing a reader can expose a describer bug**: with boundary events finally readable, `describe → exec` stopped parsing, because the call-microflow describer emitted `boundary event` BEFORE `outcomes` and the grammar requires the reverse — pre-existing on legacy, invisible while the default engine emitted neither. Always re-run a describe→re-exec round trip after widening a reader. Issue #948", "refs": ["#948"]}
+{"area": "mdl/backend", "date": "2026-08-23", "symptom": "`GRANT … ON Module.Entity` over `--mcp` fails with `failed to read module security for X: GetModuleSecurity: not supported by the MCP backend` — `--mcp-verbose` prints **no PED tool call at all**, and `mxcli mcp capabilities` reports entity access rules as available in the same session. `SHOW MODULE ROLES` / `SHOW USER ROLES` / `SHOW PROJECT SECURITY` fail the same way", "cause": "The MCP backend embeds `unsupportedBackend` and overrides only what it supports; `gen_unsupported.go`'s own header says it delegates \"the reads those [writes] need\" — i.e. a read is added **reactively, per write method**. `AddEntityAccessRule` (#704) shipped and was unit-tested, but the executor calls `validateModuleRole` → `GetModuleSecurity` **before** it, and a pre-check made outside the backend package is invisible from inside it. Three reads were missing, not one", "file": "`mdl/backend/mcp/security.go` (`GetModuleSecurity`, `ListModuleSecurity`, `GetProjectSecurity` → `b.reader`); tests `mdl/backend/mcp/grant_executor_test.go`", "insight": "**Test the statement, not the backend method** — a unit test on the method passes against a completely unreachable feature, which is exactly how this shipped; drive real MDL through `executor.New` + `SetBackendFactory` against `newFakePED` and assert a `ped_update_document` actually happened. **Probe the whole class**: the reported symptom was GRANT, but the same three-line omission had broken every security `SHOW`, none of which writes anything. **The capability report is a hand-written YAML declaration, not a verified claim** — `capabilities.go` says report and behaviour \"cannot drift\", and that holds only for the four *method-gated* keys; `entity_access_rules` is a display-only row, so it can and did contradict the very next command. Routing a read to the local `.mpr` is safe **only when PED is not a writer of that document**: roles are by-name references Studio Pro resolves on apply, so a stale file yields \"module role not found\", never a wrong write — unlike the domain model, which needs the dirty-set router. A module created over PED this session has no security document on disk at all, so answer that case explicitly rather than letting the reader say \"not found for module mcp~module~X\". Issue #900", "refs": ["#704", "#900"]}
+{"area": "mdl/backend", "date": "2026-08-24", "symptom": "A pluggable widget's text-template property is authored and **silently dropped** — the document keeps the enumeration that says the text exists but no text, so `tooltipType: 'customText', tooltip: '…'` builds as *\"'Tooltip' cannot be empty when 'Custom' type is chosen\"*. The tell that makes it findable: `tooltip: 'Value {Score}'` WORKS while `tooltip: 'Plain text'` does not", "cause": "`setTextTemplateValue` only ever **updated an existing** TextTemplate and returned the element untouched when it was nil. A CONDITIONAL template is stored nil while its condition hides it (#574), and the Slider's tooltip is hidden under its own default `tooltipType: \"value\"` — so a statement that turns the condition on and writes the text in one go finds nothing to edit. `ApplyVisibilityRules` then fills the now-visible property with an EMPTY template, which is what reaches disk. The `{AttrName}` spelling escapes it only because `SetTextTemplateWithParams` **replaces** the whole template instead of editing it", "file": "`mdl/backend/widgetobj/builder.go` (`setTextTemplateValue`); the params gap it exposed is `mdl/executor/widget_engine.go` (`applyOperation` \"texttemplate\" + `resolveMapping` \"TextTemplate\", `BuildContext.ClientParams`)", "insight": "Build the envelope when the slot is nil (`updateTemplateText(BuildEmptyClientTemplate(), text)`) rather than special-casing visibility — `ApplyVisibilityRules` still runs afterwards and re-nulls a genuinely pruned property, so authored text can never survive into a slot the editor hides. **Studio Pro is the tool that localises this**: `pg_read_page` shows the stored template as a well-formed, EMPTY `Pages$ClientTemplate`, which distinguishes \"no text was written\" from \"the template is malformed\" — the BSON cannot. Two traps. Fixing the drop makes the **`{1}` spelling reachable**, and the MAPPING pass ignored `contentparams:` where the explicit-property pass has routed it since #928, so the newly-landing text hit CE0720 until both passes agreed. And **DESCRIBE still does not emit any text-template property for a pluggable widget** (`extractExplicitProperties` reads AttributeRef and PrimitiveValue only), so a tooltip survives a write and is lost on the next describe→exec — measured on the Timeline control too, i.e. every widget, tracked separately. Repro `mdl-examples/bug-tests/254-slider-custom-tooltip.mdl`. Issue #254", "refs": ["#254", "#574", "#928"], "ce": ["CE0720"]}
+{"area": "mdl/backend", "date": "2026-08-25", "symptom": "`describe microflow` prints `range($List)` for a range that stores an offset and an amount — both expressions dropped, no warning, exit 0, and `mxcli check` clean on the truncated output, which re-executes as an *unpaged* range. Mirror-image on the write side: `range($L, $o, $a)` authored through mxcli builds as **CE6520** *\"Amount and offset are not specified\"*, and on `--engine legacy` the project will not **load** at all (*\"Expected '$ID' as the first property of a storage object, but got 'NewOperation'\"*)", "cause": "Mendix nests the bounds one level below where mxcli looked: `Microflows$ListRange{ListName, CustomRange}` → `Microflows$CustomRange{LimitExpression, OffsetExpression}`. The modelsdk engine had them **flat on both sides** — `listOperationToGen` wrote them onto the ListRange and `listOperationFromRaw` read them from there — so mxcli round-tripped its own documents perfectly and only Mendix disagreed. The legacy engine had no `ListRangeOperation` case at all, fell through to `return nil`, and `serializeListOperationAction` appended that nil under `NewOperation`, writing an **empty sub-document** that Mendix's loader rejects outright", "file": "`mdl/backend/modelsdk/microflow_write.go` (`listOperationToGen`), `mdl/backend/modelsdk/microflow_read_actions.go` (`listOperationFromRaw`), `sdk/mpr/writer_microflow_actions.go` (`serializeListOperation` + the nil guard in `serializeListOperationAction`), `mdl/executor/validate_microflow.go` (`checkRangeHasABound`, MDL068); tests `mdl/backend/modelsdk/microflow_listrange_test.go`, `sdk/mpr/writer_listoperation_test.go`, `mdl/executor/validate_range_bounds_test.go`; repro `mdl-examples/bug-tests/list-range-custom-bounds.mdl`", "insight": "**A clean round trip proves nothing when one engine wrote the document.** Both sides being wrong in the same direction is what hid this for a release: the reporter concluded \"the authoring side works correctly\" from exactly that evidence. Read a document Studio Pro wrote, or cross-read with the *other* engine — here the legacy PARSER had been right all along, so `--engine legacy` on a default-engine project was a free control. **`generated/metamodel` settles the nesting**: a `*Microflows$X` pointer field is a child element, a plain string is a property. When a writer's `default:` returns nil, check what the CALLER does with it — appending nil is how an unloadable file gets written, and omitting the key (CE0008, which names the activity) is always the better failure. The reader keeps a **flat fallback** so a project written by the broken writer still describes its bounds and repairs itself on the next `exec` — verified: CE6520 → describe → exec → 0 errors", "ce": ["CE0008", "CE6520"], "rules": ["MDL068"]}
+{"area": "mdl/backend", "date": "2026-08-26", "symptom": "Every layout reports `Layout Type: Responsive` — including the Phone, Tablet, ModalPopup and native ones, 19 of the 22 Atlas ships", "cause": "Two faults compounding. `LayoutType` is **not on `Forms$Layout`**; it is on the content wrapper. `modelsdk/gen` nonetheless exposes `Layout.LayoutType()`, bound to a key the document does not carry, so it reads `\"\"` — a phantom property, not a wrong key, which is why `keyaudit_test.go` does not list it. `DESCRIBE LAYOUT` then defaulted `\"\"` to `\"Responsive\"`, rendering a failed read as a fact", "file": "`mdl/backend/modelsdk/page.go` (`layoutTypeOf` reads the wrapper), `mdl/executor/cmd_pages_describe.go` (no fallback)", "insight": "**Never default a value every real document carries** — an empty one means the read failed, and a plausible default is what hides it. `generated/metamodel` was right about the location all along (property of `PagesWebLayoutContent`/`PagesNativeLayoutContent`), so the arbiter rule held; what no source got right was the *value set*, six values splitting by platform (web: Responsive/Phone/Tablet/ModalPopup, native: Default/Popup) against two declared in gen and in the metamodel enum. Measured across all 22"}
+{"area": "mdl/backend", "date": "2026-08-26", "symptom": "A layout mxcli wrote builds cleanly (`mx check`: 0 errors) but Studio Pro refuses to open the project: `System.InvalidOperationException: Sequence contains no matching element` at `MprProperty.cs`", "cause": "The layout carried `MainPlaceholderName`. `modelsdk/gen` declares it on `Layout` so the setter compiles, and mxbuild tolerates unknown properties — but `generated/metamodel`'s `PagesLayout` declares only eight properties and none of the 22 layouts Atlas ships on 11.13.0 carries the key. Studio Pro resolves every stored property against the type's list", "file": "`mdl/backend/modelsdk/layout_write.go` (`layoutToGen`), `mdl/executor/cmd_pages_layout_v3.go` (the header refuses any property but `layouttype`)", "insight": "**A `Forms$Layout` has exactly ten keys** — `$ID`, `$Type`, `Appearance`, `CanvasHeight`, `CanvasWidth`, `Content`, `Documentation`, `Excluded`, `ExportLevel`, `Name` — measured identical across all 22. Which placeholder is \"main\" is a *naming convention*: every Atlas layout names one `Main`, and a page binds to a placeholder by qualified name anyway, so the document has nothing to say. gen's whole placeholder family (`MainPlaceholder`, `AcceptButtonPlaceholder`, `UseMainPlaceholderForPopups`, …) is phantom here. `mx check` is not the control for this class — the key set is. Pinned by `TestLayoutToGen_WritesExactlyTheKeysStudioProWrites`"}
+{"area": "mdl/backend", "date": "2026-08-26", "symptom": "`ALTER PAGE … SET Layout` / `ALTER LAYOUT` cannot find any widget in a layout — \"widget X not found\" for a widget DESCRIBE LAYOUT clearly shows", "cause": "Two finder gaps compounding. `findBsonWidget` starts from the page's `FormCall`, which a `Forms$Layout` does not have (its tree hangs off `Content`), so every widget in every layout was unreachable; and `findInWidgetChildren` never descended into a `ScrollContainer`'s five named slots, so a layout's topbar (`Top`) and navigation (`Left`) were out of reach even once the root was found — as was anything inside a scroll container a *page* places", "file": "`mdl/backend/pagemutator/mutator.go` (`findBsonWidgetInLayout`, region descent in `findInWidgetChildren`), `mdl/backend/pagemutator/scrollregion.go`", "insight": "**A region is addressed by slot, not by name** — it has no `Name`, so `INSERT INTO layoutContainer.top` reuses the dotted widgetRef that also serves DataGrid2 columns, and which one it means is decided by the named widget's `$Type`. Only `INSERT INTO` takes a region: BEFORE/AFTER position a widget among siblings, and silently treating them as INTO would put widgets somewhere the script did not ask for. The MDL slot name is `center`; the stored key is `CenterRegion`. Controlled by emptying the slot list and by respelling the centre key"}
+{"area": "mdl/backend", "date": "2026-08-27", "symptom": "No export mapping mxcli writes matches its Studio Pro original, so every one stays in #260's silent-loss set even once its source kind is authorable", "cause": "The export writers hardcoded three properties the IMPORT twin already read off the element: `MinOccurs 0` (a schema root has **1**), `MaxLength 0`, and `IsKey` not written at all. `MaxLength` is the one that cannot be a constant — Studio Pro stores **0 for a string element and -1 for a numeric one**, mirroring the bound schema element exactly as `MaxOccurs` already did", "file": "`mdl/backend/modelsdk/mapping_write.go` (`exportValueElementToGen`, `exportObjectElementToGen`) + `mapping_read.go`, `sdk/mpr/writer_export_mapping.go`, `modelsdk/mpr/serialize_mappings.go`, `mdl/executor/cmd_export_mappings.go`, `model.ExportMappingElement`", "insight": "The export element model had **none** of these fields and the reader populated none of them, so this is four layers (model, reader, builder, three writers), not a writer patch — and a writer patch alone would have written zeros from an empty model. Clone them from the schema element where the builder already clones `MaxOccurs`. Check the import twin first when an export property looks wrong: this was a divergence between the two writers, not a considered decision, and the import side is the correct reference. Repro `mdl-examples/bug-tests/mapping-277-export-property-set.mdl`, tests `sdk/mpr/writer_export_mapping_properties_test.go`. Issue ako/mxcli#277", "refs": ["#260", "ako/mxcli#277"]}
+{"area": "mdl/backend", "date": "2026-08-27", "symptom": "A rebuilt mapping drops `MessageDefinition2`, so a document written by Studio Pro 11.10+ never round-trips", "cause": "The key is version-introduced — `modelsdk/gen/mappings/version.go` records `messageDefinition2` as `Introduced: \"11.10.0\"` — and gen generates **no accessor** for it, so nothing read or wrote it. A blank 11.13 app's own mappings carry it as `\"\"`; none of the older pinned fixtures has it at all", "file": "`model.ImportMapping`/`ExportMapping` (`MessageDefinition2 *string`), `mdl/backend/modelsdk/mapping_read.go` (`messageDefinition2FromRaw`) + `mapping_write.go`, `sdk/mpr/parser_*_mapping.go` + `writer_*_mapping.go`, `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`", "insight": "**Carry it, do not derive it.** A pointer, because nil (absent) is NOT the same as present-and-empty — writing the key onto a pre-11.10 document is the overlay-rule mistake CLAUDE.md warns about, which mxbuild tolerates and Studio Pro refuses to open. The executor decides: carry `existing.MessageDefinition2` on an update, apply the version gate only on a CREATE where there is nothing to read it off. A plain version gate in the writer looks equivalent and is not — it re-adds the key to every older document a rewrite touches, which turned four previously-clean fixtures red. gen having no accessor means the read goes to raw BSON, the route `parameterEntityFromRaw` takes. **`MappingSourceReference` is the same family and deliberately NOT carried**: its gate (10.16) predates every project in the field, and the codec emits it through a package-level `TypeDefaults` registration, so making it conditional would touch every mapping write to preserve one pre-10.16 fixture. Issue ako/mxcli#279", "refs": ["ako/mxcli#279"]}
+{"area": "mdl/backend", "date": "2026-08-31", "symptom": "`DESCRIBE NAVIGATION` prints `home page` and the menu but **silently omits `login page` and `not found page`**, so pasting its output back (the documented copy workflow) deletes both from the profile. The clauses are on disk and `MXCLI_ENGINE=legacy` prints them", "cause": "The **reader**, not the writer: `mdl/backend/modelsdk/navigation_read.go` type-asserted only the `$Type`s `modelsdk/gen` declares for those two slots, and neither is what the documents carry — `LoginPageSettings` is stored as `Forms$FormSettings` with the page under `Form` (gen expects `Navigation$NavigationProfileLoginFormSettings` / `LoginPage`), and `NotFoundHomepage` as `Navigation$HomePage` (gen and `generated/metamodel` both expect `Navigation$NotFoundHomePage`). A failed type assertion leaves the field empty, so the loss is silent", "file": "`mdl/backend/modelsdk/navigation_read.go` (`navLoginPageOf`, `navNotFoundPageOf`), cross-check `generated/metamodel/types.go` `NavigationNavigationProfile`", "insight": "**The other engine is the control.** Legacy read the same bytes correctly throughout, which is what identifies a reader bug: `describe navigation X` on both engines must agree, and a disagreement localises the defect to the one that reads through gen. Accept the `$Type` the documents actually carry and keep gen's as a fallback branch. Note the two slots fail in **opposite directions** and want opposite fixes: for the login page a real Studio Pro document and `generated/metamodel` agree with the writers, so **gen** is wrong; for the not-found page — Studio Pro's **\"Fallback page\"** — metamodel and gen agree with each other and the three mxcli **writers** are the odd one out, emitting `Navigation$HomePage` where Studio Pro stores `Navigation$NotFoundHomePage`. Only a reference document could tell those apart, since mxbuild accepts either; ako/TestApp supplied it. Keep reading both `$Type`s regardless: documents written before the writer fix carry the `HomePage` spelling and must keep round-tripping. Repro `mdl-examples/bug-tests/navigation-describe-profile-pages.mdl`"}
diff --git a/.claude/skills/fix-issue/findings/mdl-executor.jsonl b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
new file mode 100644
index 0000000000..08ea896a55
--- /dev/null
+++ b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
@@ -0,0 +1,498 @@
+{"area": "mdl/executor", "date": "2026-07-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-07-30", "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-07-30", "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-07-30", "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-07-30", "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-06-21", "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-04-21", "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-04-21", "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-07-29", "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-07-29", "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-07-30", "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-07-30", "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-07-30", "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-07-30", "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-07-30", "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-07-30", "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-07-30", "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-07-24", "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-04-21", "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-05-07", "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-05-08", "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-05-08", "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-07-03", "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-07-03", "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-05-15", "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-06-20", "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-05-15", "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-07-02", "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-06-04", "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-06-18", "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-06-20", "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-06-18", "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-07-02", "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-07-02", "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-06-04", "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-06-04", "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-06-04", "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-06-04", "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-05-15", "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-05-28", "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-05-29", "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-07-01", "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-05-22", "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-05-29", "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-06-02", "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-05-29", "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-06-20", "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-06-19", "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-07-09", "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-07-09", "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-07-02", "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-07-03", "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-07-07", "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-07-08", "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-07-09", "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-07-24", "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-07-25", "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-07-25", "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-07-09", "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-07-09", "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-07-09", "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-07-09", "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-07-10", "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-07-10", "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-07-10", "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-28", "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-07-12", "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-07-29", "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-07-11", "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-07-25", "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-07-25", "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-07-26", "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-07-26", "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-07-27", "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-07-27", "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-07-27", "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-07-27", "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-07-27", "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-07-27", "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-07-27", "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-24", "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-07-28", "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-07-28", "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-07-28", "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-07-29", "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-07-29", "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-07-29", "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-07-29", "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-07-29", "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-07-29", "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-07-29", "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-07-29", "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-07-29", "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-07-29", "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-07-29", "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-01", "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-05", "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-05", "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-06", "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-05", "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-06", "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-06", "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-06", "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-06", "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-06", "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-06", "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-06", "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-07", "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-07", "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-07", "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-07", "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-11", "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-07", "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-08", "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-08", "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-08", "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-08", "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-07", "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-07", "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-07", "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-08", "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-08", "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-08", "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-08", "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-08", "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-08", "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-08", "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-08", "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-09", "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-09", "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-09", "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-09", "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-10", "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-10", "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-10", "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-11", "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-11", "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-11", "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-11", "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-11", "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-13", "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-12", "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-13", "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-14", "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-14", "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-14", "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-14", "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-18", "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-18", "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-18", "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-18", "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-16", "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-16", "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-17", "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-17", "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-17", "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-17", "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-18", "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-18", "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-18", "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-18", "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-18", "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-18", "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-18", "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-19", "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-19", "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-19", "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-20", "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-20", "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-20", "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-20", "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-20", "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-20", "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-20", "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-20", "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-20", "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-21", "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-21", "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-21", "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-21", "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-21", "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-21", "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-23", "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-23", "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-23", "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-24", "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-23", "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-23", "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-24", "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-24", "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-24", "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-24", "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-24", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-25", "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-26", "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-26", "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-26", "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-26", "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-26", "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-27", "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-27", "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-27", "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-27", "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-27", "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-27", "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-28", "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-28", "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-28", "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-28", "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-28", "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-28", "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-28", "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-28", "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-28", "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-28", "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-28", "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-28", "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-28", "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-28", "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-28", "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-30", "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-30", "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-30", "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-30", "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": "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/fix-issue/findings/mdl-grammar.jsonl b/.claude/skills/fix-issue/findings/mdl-grammar.jsonl
new file mode 100644
index 0000000000..e0ed86139d
--- /dev/null
+++ b/.claude/skills/fix-issue/findings/mdl-grammar.jsonl
@@ -0,0 +1,53 @@
+{"area": "mdl/grammar", "date": "2026-07-30", "symptom": "A `/** … */` doc comment between `alter entity … add attribute` clauses is a **parse error** (`no viable alternative at input '/**'`)", "cause": "`alterEntityAction` accepted a doc comment only INSIDE an `attributeDefinition` (after the ADD ATTRIBUTE keyword), not between clauses. `--` line comments are NOT an equivalent workaround — they are discarded, whereas a `/** */` doc comment is persisted as the attribute's Mendix documentation", "file": "`mdl/grammar/domains/MDLDomainModel.g4` (`alterEntityAction`) + `mdl/visitor/visitor_entity.go` (`ExitAlterEntityAction` ADD branch)", "insight": "Add `docComment?` before `ADD ATTRIBUTE`/`ADD COLUMN`; the visitor attaches it as the added attribute's documentation when the attributeDefinition has none. `make grammar` regenerates the parser (not committed). Test `TestAlterEntityAddAttributeDocComment`; repro `mdl-examples/bug-tests/traceops-27-doc-comment-between-clauses.mdl`. traceops #27", "refs": ["#27"]}
+{"area": "mdl/grammar", "date": "2026-07-30", "raw": "| A bare MDL keyword used as a WIDGET name (`container body`, `dynamictext content`) is a parse error (`mismatched input 'body' expecting {IDENTIFIER, QUOTED_IDENTIFIER}`) | `widgetV3`'s name only accepted `IDENTIFIER \\| QUOTED_IDENTIFIER`, not `keyword` — unlike `attributeName`/placeholder names | `mdl/grammar/domains/MDLPage.g4` (`widgetV3`) + `mdl/visitor/visitor_page_v3.go` (`buildWidgetV3` name extraction) | Add `keyword` to the widget-name alternatives; the visitor reads `wCtx.Keyword()` too. `make grammar` regenerates the parser. Test `TestKeywordWidgetName`; repro `mdl-examples/bug-tests/traceops-11-12-16-strings-names.mdl`. traceops #12 |", "refs": ["#12"]}
+{"area": "mdl/grammar", "date": "2026-07-30", "symptom": "A `'…'` string literal spanning multiple lines fails to parse (`missing END at '…'`) — the newline terminated the token", "cause": "`STRING_LITERAL` excluded `\\r\\n` (`~['\\r\\n\\\\]`)", "file": "`mdl/grammar/MDLLexer.g4` (`STRING_LITERAL`)", "insight": "Drop `\\r\\n` from the exclusion (`~['\\\\]`); mxbuild accepts a multi-line String value (verified). A missing close-quote now spans lines — the standard multi-line-string trade-off. Test `TestMultiLineStringLiteral`. traceops #11", "refs": ["#11"]}
+{"area": "mdl/grammar", "date": "2026-04-16", "symptom": "MDL check gives \"unexpected token\" on valid-looking syntax", "cause": "Grammar missing rule or token", "file": "`mdl/grammar/MDLParser.g4` + `MDLLexer.g4`", "insight": "Add rule/token, run `make grammar`"}
+{"area": "mdl/grammar", "date": "2026-05-15", "symptom": "`ALTER <DOC TYPE> ...` parse error \"no viable alternative at input 'ALTER<TYPE>'\" but `CREATE <DOC TYPE> ...` works", "cause": "The grammar lists ALTER variants explicitly per document type; a new doc type was added to `createStatement` but not to `alterStatement`", "file": "`mdl/grammar/MDLParser.g4` `alterStatement` block + dedicated visitor + new `Alter*Stmt` AST type + `register_stubs.go`", "insight": "Add ALTER rule (mirror the closest sibling — `ALTER ODATA CLIENT` for SET-only, `ALTER PUBLISHED REST SERVICE` for SET+ADD/DROP); regenerate grammar; add `Alter*Stmt` with `Changes map[string]string`; route via `exitAlterStatement` dispatcher; register handler. Add the new AST type to `registry_test.go`'s `allKnownStatements()`"}
+{"area": "mdl/grammar", "date": "2026-07-01", "symptom": "\"Class is not a Page property\" — can't set a CSS class/style on a page via `CREATE PAGE (Class: '…')` (grammar rejects it) or ALTER PAGE", "cause": "A page's Class/Style live on its `Forms$Appearance` sub-doc, but nothing wired it to MDL: `pages.Page` had no Class/Style field, the writers hardcoded the appearance empty, and `Class`/`Style` are reserved lexer tokens so the header's generic `IDENTIFIER` branch never matched them", "file": "grammar `mdl/grammar/domains/MDLPage.g4` (`pageHeaderPropertyV3`) + `pages.Page` + AST `CreatePageStmtV3` + visitor `visitor_page_v3.go` + builder `cmd_pages_builder_v3.go` + writers `sdk/mpr/writer_pages.go` & `mdl/backend/modelsdk/page_write.go` + describe `cmd_pages_describe.go` + ALTER `mdl/backend/pagemutator/mutator.go` (`applyPageLevelSetMut`)", "insight": "Add explicit `CLASS COLON STRING_LITERAL` / `STYLE COLON STRING_LITERAL` alternatives to `pageHeaderPropertyV3` (regen grammar — keyword tokens don't match `IDENTIFIER`); add `Class`/`Style` to `pages.Page` + AST + visitor header handling + builder; legacy `serializePage` and modelsdk `newAppearance(page.Class, page.Style, …)` honor them; describe reads `rawData[\"Appearance\"].Class/Style` into the CREATE PAGE header; ALTER page-level SET writes the `Appearance` sub-doc (create if absent). Same pattern as PopupWidth #661/#713. Bug-test `mdl-examples/bug-tests/714-page-class.mdl`. Issue #714", "refs": ["#661", "#713", "#714"]}
+{"area": "mdl/grammar", "date": "2026-06-18", "raw": "| `DESCRIBE PAGE` emits a widget whose name is a reserved keyword (`container List`, `dynamictext Template`) and the output fails `mxcli check` (`mismatched input 'List' expecting IDENTIFIER`); quoting it by hand (`container \"List\"`) also failed | The widget-name position `widgetV3` accepted only a bare `IDENTIFIER`, so neither the keyword nor a `QUOTED_IDENTIFIER` parsed; and DESCRIBE emitted the name unquoted. Note this is *not* the general reserved-word problem — qualified names / params / attributes already go through `identifierOrKeyword` (a 552-entry keyword allowlist). The gap is the ~103 strict-`IDENTIFIER` positions, of which widget names are the highest-impact | grammar `mdl/grammar/domains/MDLPage.g4` (`widgetV3`) + `mdl/visitor/visitor_page_v3.go` (`buildWidgetV3`) + `mdl/executor/cmd_pages_describe_output.go` | Widen the name position to `(IDENTIFIER \\| QUOTED_IDENTIFIER)`, `make grammar`, and `unquoteIdentifier` it in the visitor. On output, quote via `executor.mdlIdent` (which lexes the name and quotes only when it does *not* lex as a bare `IDENTIFIER` — no hardcoded keyword list, no false positives like a widget named \"Dot\"). For other strict-`IDENTIFIER` name positions apply the same pattern: `pageParameter`/`snippetParameter` bare names were widened the same way (issue #114 — note the SHOW_PAGE colon arg it reported already worked via `identifierOrKeyword`, and DESCRIBE emits params `$`-prefixed so output was already safe; the fix only closed the bare-declaration gap). Security `read(...)`/`write(...)` member lists and the validation-rule `attributeReference` were widened to `(IDENTIFIER \\| QUOTED_IDENTIFIER)` via dedicated sub-rules (`entityMemberName`, `attributeRefSegment`); the grant DESCRIBE emitter quotes members through `mdlIdent` for a clean roundtrip (issue #675). Issues #619, #114, #675 |", "refs": ["#114", "#619", "#675"]}
+{"area": "mdl/grammar", "date": "2026-07-10", "raw": "| Chart `series` datasource/attribute sub-properties don't parse — `staticDataSource: database from View` → `extraneous input 'from'`; and even if parsed, were silently dropped (`buildObjectListItem` `default: continue` for datasource) | Object-list item sub-properties of datasource/attribute type had no grammar, visitor, or executor support (deferred at #538). The **BSON layer already handled it** (`widgetobj/builder.go` `overlayItemValue` datasource case) — only the upstream plumbing was missing | grammar `mdl/grammar/domains/MDLPage.g4` (`widgetPropertyV3` generic datasource alt + `propertyValueV3` QUOTED_IDENTIFIER) + visitor `mdl/visitor/visitor_page_v3.go` (generic datasource branch + quoted value) + executor `mdl/executor/widget_engine.go` (`buildObjectListItem` pre-pass, `datasource` case, `DataSource:` alias, empty-CT emission) + `mdl/backend/mutation.go`/`widgetobj/builder.go` (`EmptyTemplate` flag) + `mdl/executor/widget_defs.go` (`ItemPropertyMapping.DataSource` from `PropertyDef.DataSource`, bump `WidgetDefGeneratorVersion`) | Add `(IDENTIFIER\\|keyword) COLON dataSourceExprV3` (before scalar generic branches; leading DATABASE/MICROFLOW/etc token disambiguates from `propertyValueV3`) + `QUOTED_IDENTIFIER` to `propertyValueV3`; `make grammar`. Visitor stores the datasource under the property name and unquotes quoted values. In `buildObjectListItem`: a pre-pass resolves datasource sub-props (setting the item's entity context so `staticXAttribute` resolves against the SERIES' own datasource, not the parent); the friendly `DataSource:` alias routes to `staticDataSource`/`dynamicDataSource` by dataSet mode; emit the pre-built datasource from the `prebuiltDataSources` map (not the child.Properties lookup, which misses the alias). **CE0463 nuance**: a VISIBLE-but-unset texttemplate series sub-prop (staticName always in static mode; static·/dynamic· names once their datasource is configured) must serialize an empty `Forms$ClientTemplate`, not null. Visibility = dataSet-mode gate (from editorConfig `hideNestedPropertiesIn`) + dataSource-binding gate; scoped to SERIES/LINE containers so Accordion `GROUP`/DataGrid columns are untouched. **Diagnose CE0463** with the update-widgets diff: dump the page, `mx update-widgets`, dump again, `diff` the series WidgetObject — the delta was one `TextTemplate: null` → empty CT. The residual chart CE0463 (bare chart too, on a version-mismatched mxbuild) is orthogonal WidgetType drift (#529/#600) that `mxcli docker check`/`build` fix via update-widgets. Tests: `chart_series_test.go`, `visitor_chart_series_test.go`; bug-test `mdl-examples/bug-tests/bug9-chart-series-datasource.mdl`; spec `mdl-examples/doctype-tests/34-chart-widget-examples.mdl`. Bug 9a |", "refs": ["#529", "#538", "#600"], "ce": ["CE0463"]}
+{"area": "mdl/grammar", "date": "2026-07-10", "symptom": "`ALTER ENTITY … MODIFY ATTRIBUTE X: Type NULLABLE` reports \"Modified attribute\" but the attribute stays NOT NULL — no way to make a required attribute optional. Any specified constraint (NOT NULL / UNIQUE / DEFAULT) is likewise ignored; there is no `NULLABLE` keyword, and it \"parsed\" only because trailing tokens were swallowed", "cause": "Three-layer drop: (1) the visitor's MODIFY branch captured only `CALCULATED`; (2) `AlterEntityStmt` had no constraint fields; (3) the executor only set `attr.Type`. NOT NULL / UNIQUE are stored as **entity ValidationRules** (`Type:\"Required\"`/`\"Unique\"`, keyed by AttributeID), not attribute flags — so making nullable means **removing** the Required rule. Gotcha: the modelsdk read sets `ValidationRule.AttributeID` to the qualified name (`Mod.Ent.Attr`) while a created attr's ID is a UUID, so matching by ID alone fails", "file": "grammar `mdl/grammar/MDLLexer.g4` (`NULLABLE` token) + `MDLDomainModel.g4` (`attributeConstraint`) + `MDLSettings.g4` (keyword lists) + AST `mdl/ast/ast_entity.go` (`ModifyNotNull *bool` etc.) + visitor `mdl/visitor/visitor_entity.go` (MODIFY constraint switch) + executor `mdl/executor/cmd_entities.go` (`setAttributeValidationRule`, `ruleTargetsAttribute`)", "insight": "Add a real `NULLABLE` token (+ to both `keyword` lists so it stays a usable identifier) and an `attributeConstraint` alt; `make grammar`. **Semantics: apply-specified, preserve-unspecified** (non-breaking — the documented \"DEFAULT survives a type change\" behavior stays): NULLABLE→`ModifyNotNull=&false` (drop Required rule), NOT NULL/REQUIRED→`&true` (re-add), UNIQUE→add Unique rule, DEFAULT→set value; nil pointer = leave as-is. Match the existing rule via `ruleTargetsAttribute` (UUID **or** last-dot-segment name, since read-back rules use the qualified name); store new rules with the qualified name (`validationRuleToGen` writes a dotted AttributeID verbatim). Verify with `describe entity` + `mx check`=0. Bug-test `mdl-examples/bug-tests/bug12a-modify-attribute-nullable.mdl`; tests `TestModifyAttributeConstraintsCaptured`, `TestRuleTargetsAttribute`, `TestSetAttributeValidationRule`. Bug 12a"}
+{"area": "mdl/grammar", "date": "2026-07-11", "symptom": "A `create page` over a layout with **more than one placeholder** (e.g. Main + Right/Topbar) can only populate Main — there is no MDL syntax to target a second placeholder, so the layout renders wrong", "cause": "The page body was a flat widget list; the executor built exactly **one** `Forms$FormCallArgument` for the Main placeholder (`getMainPlaceholderRef` → hardcoded `\"<Layout>.Main\"`). NOT a BSON/engine gap — placeholders are BY-NAME (`Parameter=\"<Layout>.<Placeholder>\"`) and `layoutCallToGen` already iterates *multiple* arguments; the whole gap was upstream (grammar/AST/visitor/executor produced a single arg). DESCRIBE also *flattened* every argument's widgets into one list", "file": "grammar `mdl/grammar/domains/MDLPage.g4` (`placeholderBlockV3`) + AST `mdl/ast/ast_page_v3.go` (`PagePlaceholderV3`) + visitor `mdl/visitor/visitor_page_v3.go` (`buildPagePlaceholdersV3`) + executor `mdl/executor/cmd_pages_builder_v3.go` (one FormCallArgument per placeholder) + describe `mdl/executor/cmd_pages_describe.go` (`getPageWidgetGroupsFromRaw`)", "insight": "Add a `placeholder <Name> { … }` block (name = `identifierOrKeyword` so `Right`/`Left`/`Content` parse); bare widgets still bind to Main (backward-compatible). `make grammar`. Executor groups widgets by placeholder (Main = bare body + any `placeholder Main` block) and emits one arg each with `ParameterID = \"<Layout>.<Name>\"` and a numbered `conditionalVisibilityWidget<N>` wrapper. DESCRIBE groups by argument's `Parameter` and emits explicit `placeholder` blocks only when >1 placeholder has widgets (single-Main stays bare → no test churn). Verified both engines `mx check`=0; stable describe→exec→describe round-trip. Bug-test `mdl-examples/bug-tests/532-page-layout-placeholders.mdl`; tests `TestPagePlaceholderBlocksParsed`, `TestPageWithoutPlaceholdersUnaffected`. Layout placeholder names come from the layout's `Forms$Placeholder` widgets (e.g. Atlas_SideBar = Main + Topbar). Issue #532", "refs": ["#532"]}
+{"area": "mdl/grammar", "date": "2026-06-21", "symptom": "A clickable `CONTAINER` can't be expressed: `OnClick: MICROFLOW …` / `Click:` error in the parser (`mismatched input 'MICROFLOW' expecting {',', ')'}`), and the one form that parses (`Action: MICROFLOW …`) is silently dropped — the container's BSON always has `OnClickAction = Forms$NoAction`", "cause": "Layers all hardcoding \"no click\": (1) only the `Action:` keyword's `actionExprV3` accepted an action value, so `OnClick:`/`Click:` had no rule taking `MICROFLOW …`; (2) `buildContainerV3` never read `GetAction()`; (3) the `Container` model had no `OnClickAction` field and both writers (`serializeContainer`, modelsdk `widgetToGen`) emitted `serializeClientAction(nil)`/`noActionGen()`; (4) DESCRIBE never read it back", "file": "grammar `mdl/grammar/domains/MDLPage.g4` (`widgetPropertyV3`) + `mdl/visitor/visitor_page_v3.go` (`buildWidgetPropertyV3`) + `sdk/pages/pages_widgets_container.go` (`Container`) + `mdl/executor/cmd_pages_builder_v3_layout.go` (`buildContainerV3`) + `sdk/mpr/writer_widgets_layout.go` (`serializeContainer`) + `mdl/backend/modelsdk/widget_write.go` (DivContainer case) + `mdl/executor/cmd_pages_describe_parse.go`/`cmd_pages_describe_output.go`", "insight": "Add an `ONCLICK COLON actionExprV3` alternative aliasing `Action:` (`make grammar`), stored under the same `Properties[\"Action\"]` key. Add `OnClickAction ClientAction` to `Container`; in `buildContainerV3` read `GetAction()` → `buildClientActionV3()`; both writers serialize the real action (nil falls back to NoAction, so non-clickable containers are unchanged). DESCRIBE: extract `w[\"OnClickAction\"]` via `extractButtonAction` (synthesize `{\"Action\": …}`) and emit `Action: <action>` in the container output. Verified with `mx check` = 0 errors. `Forms$DivContainer.OnClickAction` is required & introduced 8.3.0, so no version gate. Issue #603", "refs": ["#603"]}
+{"area": "mdl/grammar", "date": "2026-07-25", "symptom": "A single `alter entity` with **comma-separated** `add attribute` clauses fails to parse — e.g. `add attribute A: integer default 9, add attribute B: integer default 9` → `no viable alternative at input '9'`. Looks like \"only the first `add` can carry a `default`\" but the real cause is the comma", "cause": "`alterStatement`'s `ALTER ENTITY qualifiedName alterEntityAction+` had **no separator** — commas between actions weren't allowed at all; the error surfaced on the second clause's `default` value token, which misdirects. Sudoku findings #5", "file": "`mdl/grammar/MDLParser.g4` (`alterStatement`, ALTER ENTITY alt)", "insight": "Change `alterEntityAction+` → `alterEntityAction (COMMA? alterEntityAction)*` (optional comma, mirroring `entityOptions`); `make grammar`. Newline-separated actions still parse. Bug-test `mdl-examples/bug-tests/f5-alter-entity-comma.mdl`. **Diagnosis pattern**: a parse error on the *value* inside the *second* item of a list usually means the list rule lacks a separator, not that the value form is wrong", "refs": ["#5"]}
+{"area": "mdl/grammar", "date": "2026-07-10", "symptom": "A documented object-list widget child keyword parse-errors: `line lRevenue (...)` inside a LineChart/TimeSeries/BubbleChart, or `scalecolor scLow (...)` inside a HeatMap → `mismatched input 'line' expecting '}'`. `series` (etc.) works", "cause": "The executor side was already complete — `deriveObjectListKeyword` maps `lines`→`LINE` and `scaleColors`→`SCALECOLOR`, and `buildObjectListItem` routes any object-list child generically via the widget's `.def.json`. The **grammar** just lacked the tokens: `LINE`/`SCALECOLOR` weren't lexer tokens nor `widgetTypeV3` alternatives", "file": "`mdl/grammar/MDLLexer.g4` (token) + `mdl/grammar/domains/MDLPage.g4` (`widgetTypeV3`) + `mdl/grammar/domains/MDLSettings.g4` (`keyword` rule)", "insight": "Add the token, the `widgetTypeV3` alternative (alongside `SERIES`/`MARKER`), **and** the `keyword` rule entry (so a very common word like `line` stays usable as an identifier via `identifierOrKeyword`); `make grammar`. No executor/def changes needed — `deriveObjectListKeyword` already produces the singular-uppercase keyword and the def.json carries the mapping. Verify child data lands in BSON (`Lines`/`Series` array). Confirmed via `mdl-examples/doctype-tests/34-chart-widget-examples.mdl` (exec 0 errors; `line`/`scalecolor` persist). DESCRIBE round-trip is handled by the row below"}
+{"area": "mdl/grammar", "date": "2026-07-12", "symptom": "No way to change an existing **enumeration value's caption** in place — `alter enumeration` had only `ADD`/`RENAME`/`DROP VALUE` + `SET COMMENT`; `RENAME VALUE X TO Y` changes the *name*, not the caption. The only route was drop + recreate, which fails while the enum is referenced by an attribute", "cause": "Missing grammar action + AST op + executor case — a full-stack gap, not a code bug", "file": "`mdl/grammar/domains/MDLDomainModel.g4` (`alterEnumerationAction`) → `mdl/ast/ast_enumeration.go` (`AlterEnumOp`) → `mdl/visitor/visitor_enumeration.go` (`ExitAlterEnumerationAction`) → `mdl/executor/cmd_enumerations.go` (`execAlterEnumeration`)", "insight": "Add `MODIFY VALUE IDENTIFIER CAPTION STRING_LITERAL` (reuses existing `MODIFY`/`CAPTION` tokens, so no lexer change); add `AlterEnumModifyCaption` op reusing the `Caption` field; executor finds the value by name and replaces only the `en_US` translation (preserves the value's ID + other locales). Re-captions in place, so it works while referenced (mxbuild 0 errors) — no drop needed. Value names in `alter` must be plain identifiers (a reserved-word-named value like `Created` can't be targeted — pre-existing, shared by ADD/RENAME/DROP). Tests: `TestAlterEnumeration_ModifyValueCaption` (visitor) + `TestAlterEnumeration_ModifyValueCaption_Mock` (executor); example in `01-domain-model-examples.mdl`"}
+{"area": "mdl/grammar", "date": "2026-07-25", "symptom": "Re-running a domain script that is 90% already-applied applies **none** of the remaining 10%: `alter entity … add attribute X` errors `attribute 'X' already exists` and, because `exec` halts on the first error, everything after it is skipped. No idempotent add/drop and no continue-past-errors", "cause": "Two gaps: (1) `ADD ATTRIBUTE` / `DROP ATTRIBUTE` had no `IF NOT EXISTS` / `IF EXISTS` guard, so a re-apply was a hard error; (2) `ExecuteProgram` returns on the first statement error", "file": "grammar `mdl/grammar/domains/MDLDomainModel.g4` (`ifNotExists`/`ifExists`, `alterEntityAction`) + AST `mdl/ast/ast_entity.go` (`IfNotExists`/`IfExists`) + visitor `mdl/visitor/visitor_entity.go` (`ExitAlterEntityAction`) + executor `mdl/executor/cmd_entities.go` (add/drop guards) + `mdl/executor/executor.go` (`ExecuteProgramContinueOnError`) + `cmd/mxcli/cmd_exec.go` (`--continue-on-error`)", "insight": "Add `IF NOT EXISTS`/`IF EXISTS` to the grammar (regen), carry the flag on the AST, and in the executor turn the already-exists / not-found error into a skip-with-notice when the guard is set. Separately add `mxcli exec --continue-on-error`: attempts every statement, prints each failure as `statement N: …`, exits non-zero if any failed (never masks a real error; `exit`/`quit` still stop the run). Bug-test `mdl-examples/bug-tests/f10-idempotent-alter-entity.mdl`. Findings #10", "refs": ["#10"]}
+{"area": "mdl/grammar", "date": "2026-07-26", "symptom": "`index name on (cols)` inside `create entity` (or `alter entity add index name on (cols)`) fails with `extraneous input 'on' expecting '('` — the SQL-like form docs/users expect. The bare `index name (cols)` worked", "cause": "`indexDefinition` had no `ON` token: `IDENTIFIER? LPAREN indexAttributeList RPAREN`", "file": "`mdl/grammar/domains/MDLDomainModel.g4` (`indexDefinition`)", "insight": "Make `ON` optional: `IDENTIFIER? ON? LPAREN indexAttributeList RPAREN`, regen grammar. `buildIndex` reads columns from `IndexAttributeList` only, so ON can't be mistaken for a column and no visitor change is needed. Covers both CREATE (entityOption) and ALTER ADD INDEX (shared rule). Bug-test `mdl-examples/bug-tests/f4-entity-index-on.mdl`. Findings #4", "refs": ["#4"]}
+{"area": "mdl/grammar", "date": "2026-07-27", "symptom": "`textbox` silently drops `placeholder` and `onchange` (MDL-WIDGET07 warns \"unrecognized property … dropped\"); after `create page` + `DESCRIBE`, both are gone — the live-search box degrades to a button, the field loses its hint text", "cause": "The `pages.TextBox` model already had `Placeholder`/`OnChangeAction` fields, and the modelsdk (default) engine's `widgetToGen` already serialized them — but (a) the grammar had no `onchange:`/`placeholder:` property, (b) `buildTextBoxV3` never populated the model, (c) the legacy `serializeTextBox` hardcoded empty, (d) they weren't in `staticWidgetKnownProps`", "file": "grammar `mdl/grammar/domains/MDLPage.g4` (`widgetPropertyV3`); visitor `mdl/visitor/visitor_page_v3.go`; `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildTextBoxV3`); `sdk/mpr/writer_widgets_input.go` (`serializeTextBox`) + `writer_widgets.go` (`serializePlaceholderTemplate`); `validate_widgets.go` known-props", "insight": "Add `ONCHANGE COLON actionExprV3` + `PLACEHOLDER COLON STRING_LITERAL` (tokens already existed); visitor → `Properties[\"OnChange\"]`/`[\"Placeholder\"]`; `GetOnChange()`/`GetPlaceholder()` accessors; builder sets `tb.Placeholder` (a `*model.Text`) + `tb.OnChangeAction` (via `buildClientActionV3`, reusing the button path); legacy serializer emits `serializePlaceholderTemplate(tb.Placeholder)` + `serializeClientAction(tb.OnChangeAction)`; add `OnChange`/`Placeholder` to `staticWidgetKnownProps`. Tests `TestSerializeTextBox_PlaceholderAndOnChange`; repro `mdl-examples/bug-tests/textbox-placeholder-onchange.mdl`. Finding #9", "refs": ["#9"]}
+{"area": "mdl/grammar", "date": "2026-08-11", "symptom": "`mxcli check` **segfaults** (`SIGSEGV` in `visitor.(*Builder).ExitSqlDisconnect`) on the one-line script `SQL DISCONNECT source;` — which is the exact line in mxcli's own `mxcli syntax sql` example. Other aliases (`mydb`, `src`) are fine", "cause": "Two defects. **Grammar**: every `sqlStatement` alternative took a bare `IDENTIFIER` for the alias/driver/table, but `source` lexes as `SOURCE_KW` (`MDLLexer.g4:317`), so no alternative matched. `IMPORT FROM identifierOrKeyword` in the same file already accepted a keyword alias, so `import from source …` worked while `sql source …` did not. **Robustness**: ANTLR error-recovers and still walks the tree, so the listener received a context whose `IDENTIFIER()` was nil and `.GetText()` crashed the process — sibling handlers guarded their children (`if len(ids) < 2 { return }`), this one did not", "file": "`mdl/grammar/domains/MDLSettings.g4` (`sqlStatement` → `identifierOrKeyword`), `mdl/visitor/visitor_sql.go` (`sqlWords` helper + guards at all five handlers)", "insight": "Use `identifierOrKeyword` for every user-chosen word, and read children through a helper that tolerates a missing node. **Generalisable — the shape to look for**: a listener that dereferences `ctx.X()` without a nil check is a crash waiting for the first input that fails to parse *that rule* — ANTLR does not stop the walk on a syntax error. Grep for `ctx\\.[A-Z][A-Za-z]*()\\.GetText()` and treat each as unguarded. **Second shape**: when a bare `IDENTIFIER` names something a user picks (alias, table, column, prefix), it silently forbids every keyword; `identifierOrKeyword` is nearly always what was meant, and the inconsistency shows up as \"works in one statement, not the neighbouring one\". **Watch the index shift** when converting: the alias joins the `AllIdentifierOrKeyword()` list, so downstream `[0]`/`[1:]` offsets move (this bit `ExitSqlGenerateConnector`, where getting it wrong would generate a connector into a module named after the connection). **How it was found — and the trap it hid**: `TestExamplesParse` (new) feeds every `mxcli syntax` example through the parser; the panic **aborted the test binary**, masking ten further failures in entries sorted alphabetically after `sql`. A crash in a table-driven test is not one failure, it is an unknown number. Repro `mdl-examples/bug-tests/sql-keyword-alias-crash.mdl`"}
+{"area": "mdl/grammar", "date": "2026-08-06", "symptom": "An unquoted negative number in an XPath constraint fails to parse: `where [Amount > -7]` → `Parse error: extraneous input '7' expecting {',', ')'}`. Reported as \"negative numeric literals truncate (`-7` becomes `-`)\"", "cause": "`xpathWord` — the name-part rule inside XPath — is a **negated token set** that did not exclude `MINUS`, so the sign was consumed as a name word and the digits were left stranded (hence the truncation appearance). The lexer deliberately keeps `-` out of `NUMBER_LITERAL` (a leading sign there mis-tokenises `$x -2`), leaving negation to the parser; the general grammar has `unaryExpression` for this and the XPath grammar simply never got the equivalent", "file": "`mdl/grammar/domains/MDLPage.g4` (`xpathValueExpr` gains `MINUS xpathValueExpr`; `MINUS` added to the `xpathWord` exclusion set), `mdl/visitor/visitor_xpath.go` (`buildXPathValueExpr`), `mdl/visitor/visitor_page_v3.go` (`xpathExprToString` emits `-7`, not `- 7`)", "insight": "**The grammar fix alone is worse than the bug.** With the parser accepting `-7` but the XPath AST builder having no case for the new alternative, the constraint parses and silently serializes to `[Amount > ]` — a dropped operand instead of a loud parse error. Caught only because the visitor has a round-trip helper; the microflow write path uses `GetText()` and looked fine. **When adding a grammar alternative, check every consumer of that rule, not just the one your repro exercises.** **Scope correction**: the finding's own example (`addDays([%CurrentDateTime%], -7)`) still fails — `addDays` is a *microflow expression* function, not an XPath one, and it fails `CE0161` with a POSITIVE argument too, so the sign was never its problem. Repro `mdl-examples/bug-tests/it-18-xpath-negative-literal.mdl`; A/B on Mendix 11.12.1: pre-fix the script does not parse, fixed binary writes it and `mx check` reports 0 errors. issuetracker #18", "refs": ["#18"], "ce": ["CE0161"]}
+{"area": "mdl/grammar", "date": "2026-08-07", "raw": "| A widget conditional using a function whose name is also an MDL lexer keyword — `visible: [trim($currentObject/Slug) != '']`, `[length(…) > 0]`, `empty`/`count`/`find` — **silently drops the whole property**; `mxcli check` ✓, `mx check` ✓, and the widget renders unconditionally visible. `toUpperCase`/`isMatch`/`contains` in the same position work | `xpathFunctionName` (MDLPage.g4) enumerated only `IDENTIFIER \\| HYPHENATED_ID \\| NOT \\| TRUE \\| FALSE \\| CONTAINS`, so `trim(` never matched `xpathFunctionCall`. The enclosing `[...]` then failed to parse as an `xpathConstraint` and matched the generic `propertyValueV3` alternative instead, so the visitor set `Visible` (an array) rather than `VisibleIf`, and the builder's `else if pages.StaticVisibleExpression(...)` — which reads only bool/string — never fired | `mdl/grammar/domains/MDLPage.g4` (`xpathFunctionName`) + `mdl/executor/validate_widgets.go` (`validateConsumableConditional`) | Define `xpathFunctionName : xpathWord \\| NOT` — `xpathWord` is a negated token set, so it self-maintains as the lexer gains keywords; an enumerated list reacquires this bug with the next promoted function name. Safe because `xpathFunctionCall` requires a following LPAREN and no `xpathStepValue` may be followed by one, so bare `empty` still parses as a path word. `NOT` is spelled out (xpathWord excludes it). **Also add the general guard**: MDL-WIDGET19 errors when `Visible`/`Editable` holds a value that is neither routed to `VisibleIf`/`EditableIf` nor a bool/string — that is the residue signature of any conditional the visitor could not build, so the next one fails loudly instead of vanishing. `make grammar` regenerates the parser (not committed). **Verify in a browser, not at `mx check`** — a dropped property is still a valid model, so `mx check` reports 0 errors before AND after; the symptom only exists at render time (see `verify-in-runtime.md`). The repro script carries a `Bug852.Verify` page for this: `Slug` is three spaces, so `trim()` changes the outcome and a dropped `Visible` renders (Mendix defaults to visible). Pre-fix all 5 markers render; post-fix only the 3 that should. **One rule, two contexts**: `xpathConstraint` serves both `Visible:`/`Editable:` (a Mendix *client expression* — trim/length/toUpperCase/find) and a datasource `where` (real *XPath* — contains/starts-with/ends-with/string-length/not, `length()` = list length, aggregates Java-only, and `empty`/`NULL` are KEYWORDS not calls). The sets differ, so the grammar must not enumerate either; mxbuild adjudicates. Regression-test the XPath side when touching this rule — `[Name = empty]`, `[Name = NULL]`, `not()`, `contains()`, `starts-with()`, `string-length()` all still parse and `mx check` clean. Tests `TestConditionalVisibility_KeywordFunctionNames`, `TestValidateStaticWidget_UnconsumableConditional`; repro `mdl-examples/bug-tests/852-conditional-keyword-functions.mdl`. Issue #852 |", "refs": ["#852"]}
+{"area": "mdl/grammar", "date": "2026-08-07", "symptom": "`ALTER ENTITY X ADD EVENT HANDLER …` errors when the handler exists and `DROP EVENT HANDLER …` errors when it does not, so a script containing either cannot be re-run — and a defensive drop-then-add fails on whichever half does not match. `ADD ATTRIBUTE` has `IF NOT EXISTS`; event handlers had no equivalent", "cause": "The idempotency guards added for attributes (findings #10) were never extended to the event-handler clauses, which are the one member with no other re-run route", "file": "`mdl/grammar/domains/MDLDomainModel.g4` (`ifNotExists?` / `ifExists?` on the event-handler clauses), `mdl/visitor/visitor_entity.go`, `mdl/executor/cmd_entities.go`", "insight": "Reuse the existing `ifNotExists`/`ifExists` grammar rules rather than inventing a second spelling, so the guard reads the same everywhere. The error messages now name the flag, so the fix is discoverable from the failure. Verified by running the same script twice: first run drops (skipping, absent) then adds; second run skips both, exit 0, and the project still builds 0 errors. mxcli-todo #18", "refs": ["#10", "#18"]}
+{"area": "mdl/grammar", "date": "2026-08-11", "symptom": "`ALTER PAGE … SET Action = microflow M.F ON btn` does not parse — `extraneous input 'M' expecting {DROP, ADD, SET, INSERT, REPLACE, '}'}`. The documented workaround is `REPLACE`, which works but silently drops every property the statement does not restate (ButtonStyle, Class, design properties, tooltip)", "cause": "`alterPageAssignment` special-cases `DATASOURCE`, `VISIBLE` and `EDITABLE`, then falls through to `identifierOrKeyword EQUALS propertyValueV3` — and `propertyValueV3` has no `microflow <name>` form, so the value position could not hold an action at all. `CREATE PAGE` has had `ACTION COLON actionExprV3` all along", "file": "`mdl/grammar/MDLParser.g4` (`alterPageAssignment` gains `ACTION EQUALS actionExprV3`), `mdl/visitor/visitor_alter_page.go` (`buildAlterPageAssignment`), `mdl/executor/cmd_alter_page.go` (`convertASTAction` + routing), `mdl/backend/mutation.go` + `pagemutator/mutator.go` + `mock/` + `mcp/` (`SetWidgetAction`)", "insight": "Reuse `actionExprV3` — the same rule CREATE PAGE uses — and build through the **CREATE PAGE builder** (`pb.buildClientActionV3`) rather than a second switch. **Generalisable — the shape to look for**: when `SET` and `REPLACE` (or any narrow/wide pair) can express different vocabularies for the same property, the narrow one is a whitelist that will be extended one bug report at a time — #855 was the identical bug for `DataSource`, filed separately. Delegate instead of enumerating, and the pair cannot drift. **Guard-don't-drop**: refuse `SET Action` on a widget with no `Action` property rather than writing it — Studio Pro resolves every stored property against the type's property list and throws, while mxbuild tolerates the unknown key, so a silent write **builds clean and fails to open**; the build is not a safety net. **Measurement trap**: reverting only the grammar rule does not produce a failing test, it produces a *compile* error (the visitor references `ctx.ActionExprV3()`), so prove causation by reverting grammar+visitor together and re-running the original statement through the CLI. **Do not be misled by CE1571 on a `SHOW_PAGE` action** — authoring the same action through CREATE PAGE reproduces it exactly, so it is the builder's `$currentObject` auto-binding outside a dataview, not this change; always author the control before blaming the new path. Note `OPEN_LINK` still refuses on the modelsdk engine (`LinkClientAction` is unsupported by the codec) — also pre-existing, and CREATE PAGE refuses it identically. Repro `mdl-examples/bug-tests/alter-page-set-action.mdl`; verified end-to-end (Mendix 11.13.0, `mx check` 0 errors, `Class` survives four retargets without being restated)", "refs": ["#855"], "ce": ["CE1571"]}
+{"area": "mdl/grammar", "date": "2026-08-07", "symptom": "`alter settings configuration 'Default' …` is the write form, but `describe settings configuration 'Default'` is a **parse error** — and `show settings configurations` summarises the configuration without `ApplicationRootUrl`, so the obvious command for \"did my root URL land?\" cannot answer it (and renders an empty DatabaseUrl as a bare `, ,`)", "cause": "The grammar's `DESCRIBE SETTINGS` alternative took no object, so the read form of a write statement simply did not exist; the summary builder listed database/port fields and never gained the root URL when that property was added", "file": "`mdl/grammar/domains/MDLCatalog.g4` (`DESCRIBE SETTINGS (CONFIGURATION STRING_LITERAL)?`), `mdl/visitor/visitor_query.go` (reuses `DescribeStmt.Qualifier`), `mdl/executor/cmd_settings.go` (`writeSettingsConfiguration`, `describeSettingsConfiguration`, summary)", "insight": "**Read forms should mirror write forms** — where MDL has `alter X <selector>`, `describe X <selector>` should parse, and reaching for it and getting a parse error teaches the wrong lesson. Factor the emit into one helper so the whole-settings dump and the single-configuration dump cannot drift. An unknown name lists the ones that exist, or the user is guessing. **Watch for**: changing `describeSettings`'s signature broke three existing callers, and the same commit's `IsPartOfKey`→`KEY` change broke an OData round-trip test that only the FULL suite caught — run `go test ./mdl/...`, not just the new test. Tests `cmd_settings_configuration_test.go`. mxcli-formula1 #8", "refs": ["#8"]}
+{"area": "mdl/grammar", "date": "2026-08-07", "symptom": "`$Total = 5;` does not parse — `no viable alternative at input '$Total=5'` — while `DECLARE $Total Integer = 0;` does, and so do `$X = HEAD($List)`, `$X = create M.E (…)` and `$X = execute database query …`. The error names the token, not the missing keyword", "cause": "Assignment existed only as a **prefix** on specific activity statements (`(VARIABLE EQUALS)?` on CALL/CREATE/RETRIEVE/…), plus a `SET $Var = expression` statement. A plain value therefore required `SET`, which nothing in the error or the surrounding syntax suggested", "file": "`mdl/grammar/domains/MDLMicroflow.g4` (`setStatement : SET? …`), `cmd/mxcli/syntax/features_microflow.go`", "insight": "Make the guessable form work rather than improve the error: `SET` is now optional and both spellings produce the same `MfSetStmt`/`ChangeVariableAction`. **Prove a grammar relaxation causes no regressions with a control binary, not by reading**: `git stash` the `.g4`, `make grammar`, build `bin/mxcli-control`, sweep every `mdl-examples/**/*.mdl` with both — 13 scripts fail, the *same* 13, all pre-existing. ANTLR's adaptive prediction picks the activity-prefixed alternatives over `setStatement` on its own; no ordering change was needed. Executed against a real .mpr, mxbuild reports 0 errors. Tests `mdl/visitor/visitor_microflow_bare_assign_test.go` (bare and keyword forms must agree on the AST, not merely both parse). mxcli-formula1 #13", "refs": ["#13"]}
+{"area": "mdl/grammar", "date": "2026-08-07", "symptom": "After `SET` became optional, `mx check` on a project built from `02-microflow-examples.mdl` reports six errors that no MDL change caused: `[CE0109] \"Undefined variable 'ProductList.Price'.\"` at four Aggregate list activities, and `[CE0015] \"Aggregate function must specify a valid attribute.\"` at the expression-based one. Identical on both engines. `mxcli check` on the same script is silent", "cause": "Two conversions existed for one syntax. `$Sum = sum($List.Price)` used to reach the dedicated `aggregateListStatement` rule; making `SET` optional put `setStatement` — alternative 5 of ~50 — in front of it, so ANTLR matched the lower-numbered alternative and the statement fell through to `buildSetStatement`'s fallback conversion, which joined list and attribute into one name and dropped the per-item expression entirely. Underneath, `buildListAggregateAsFunction` never appended the expression argument, so the SET path could not have seen it either", "file": "`mdl/grammar/domains/MDLMicroflow.g4` (`setStatement` moved LAST in `microflowStatement`), `mdl/visitor/visitor_microflow_statements.go` (`buildSetAggregate` replaces `extractVariableAndAttribute`), `mdl/visitor/visitor_microflow_expression.go` (`buildListAggregateAsFunction` appends the expression argument)", "insight": "**A permissive alternative belongs last.** `$X = <expr>` overlaps every `VARIABLE EQUALS <function-call>` statement in the rule — aggregates, list operations, RANGE — and ANTLR's ALL(*) picks the lowest-numbered alternative that matches, so a new general form silently steals from every specific one above it. **The measurement trap that let this ship**: the `SET?` change was swept with a control binary over every `mdl-examples/**/*.mdl` and found no difference — but with `mxcli check`, which parses and validates and never serializes. This defect lives between the AST and the BSON, where only `exec` + `mx check` can see it. Sweeping with `check` proves the grammar still *parses*; it proves nothing about what the visitor *builds*. For a grammar change, the control sweep must run the integration gate (`go test -tags integration -run TestMxCheck_DoctypeScripts`), not `check`. Fix proven by reverting both halves and watching the new tests fail with the reported symptom. Tests `mdl/visitor/visitor_microflow_aggregate_test.go`. Upstream CI on the ako→mendixlabs sync PR", "ce": ["CE0015", "CE0109"]}
+{"area": "mdl/grammar", "date": "2026-08-08", "symptom": "`MOVE JAVA ACTION …` / `MOVE ODATA SERVICE …` is a parse error (`no viable alternative at input 'MOVEJAVA'`), and neither `CREATE` form takes a folder clause — so those documents can never leave the module root from MDL", "cause": "The `moveStatement` rule listed seven doctypes and nothing else; the missing ones were never unimplemented, just unlisted", "file": "`mdl/grammar/MDLParser.g4` (two alternatives), `mdl/ast/ast.go`, `mdl/visitor/visitor_entity.go` (dispatch **and** the MOVE FOLDER discriminator), `mdl/executor/cmd_move.go`, backend `MoveJavaAction` / `MovePublishedODataService`, `sdk/mpr` exports `MoveUnitByID`", "insight": "Both reduce to the existing reparent primitive — a top-level document move is one containment row, so a new doctype is a list entry plus a lookup, not new machinery. **Watch the discriminator**: `MOVE FOLDER` is told apart from a document move by the *absence* of a doctype keyword, so every keyword added to the rule must also be added to that condition or a folder move starts parsing as a document move. **Verify placement by differential count, not by reading the model**: run the script with and without the MOVE lines and diff `select ContainmentName, count(*) from Unit` — three new Folders rows (a nested path creates two) and an unchanged Documents count says reparented rather than copied or dropped. Grepping blobs for names is a trap; stock modules are full of the same words. Tests `visitor_move_doctypes_test.go`, example in `18-folder-examples.mdl` — which must sit **before** that script's `drop module`, a mistake the integration gate caught and `mxcli check` did not. mxcli-formula1 #32", "refs": ["#32"]}
+{"area": "mdl/grammar", "date": "2026-08-09", "symptom": "A navigation menu item cannot be given an icon at all — the grammar has no `ICON`, and every item mxcli writes gets `Icon: null`, so a menu authored in MDL is flat text next to one authored in Studio Pro", "cause": "The syntax was never added, and the reason it stayed unadded is instructive: the metamodel names the element `Pages$IconCollectionIcon`, but Mendix **stores** it as `Forms$IconCollectionIcon` — one more instance of the \"Form was the original term for Page\" rename CLAUDE.md documents for `ShowFormAction`. There was no way to know that from the metamodel alone, and inventing a `$Type` for a polymorphic child is the failure mode where mxbuild builds green and Studio Pro cannot open the document", "file": "`mdl/grammar/MDLParser.g4` (`navMenuItemDef`, both alternatives), `mdl/ast/ast_navigation.go`, `mdl/visitor/visitor_navigation.go` (positional `AllQualifiedName()` — the PAGE/MICROFLOW target and the icon share one indexed list), `mdl/types/navigation.go`, `mdl/executor/cmd_navigation.go` (`convertMenuItemDef`, `printMenuMDL`), `sdk/mpr/writer_navigation.go` (`buildMenuIconBson`), `mdl/backend/modelsdk/navigation_write.go`, `sdk/mpr/parser_misc.go`, `mdl/backend/mpr/convert.go` (`convertNavMenuItem` is a field-by-field copy and drops anything new)", "insight": "**The icon is a `qualifiedName`, not a string** — it is a reference into the model, so it is spelled like every other reference (ADR-0003). Atlas names are hyphenated, and `align-center` lexes as HYPHENATED_ID, so that *segment* is double-quoted: `ICON Atlas_Core.Atlas.\"align-center\"`. The DESCRIBE emitter (`quoteQualifiedName` in `mdl/executor/qualified_name_quoting.go`) must therefore decide quoting per segment, and **must not reuse `mdlIdent`**: mdlIdent quotes anything not lexing as a bare IDENTIFIER, but a qualifiedName segment is an `identifierOrKeyword`, which accepts keywords — and `home`, `user`, `add`, `folder` are all keyword tokens, so mdlIdent would quote nearly every icon. Decide acceptance by running the real parser on the segment, never a hardcoded keyword list. The invariant worth testing is not \"which names get quotes\" (I guessed that wrong twice) but **\"does the emitted statement re-parse\"** — feed DESCRIBE output back through `visitor.Build`. **Get the reference before writing the BSON.** A Studio Pro-authored project (`ako/mxcli-ledger`) settled in one dump what no amount of metamodel reading could: the storage name, the field (`Image`, a 3-part `Module.Collection.name`), the exact key set (`$ID`/`$Type`/`Image`, nothing more), and that **all three variants coexist** — `Forms$IconCollectionIcon{Image}`, `Forms$ImageIcon{Image}` (indistinguishable by name alone; it points into an *image* collection), `Forms$GlyphIcon{Code: int}`. Only the first is written; DESCRIBE emits a `-- icon … is not reproducible` comment for the other two rather than an `icon` clause that would convert the variant on replay. To dump a v2 unit: `grep -rl 'Menus$MenuItem' mprcontents` then `bson.Unmarshal` into a `bson.D`. **`mx check` reporting 0 errors is not the proof here** — its deserializer tolerates unknown properties; the proof is diffing the written element against the Studio Pro one (done: byte-shape identical, same key order). Icon *names* are also not guessable — `Atlas.list` and `Atlas_Filled.user-check` do not exist while `list-bullets` and `user` do; verify against the collection. **Second trap, in the read path**: `codec.Decode` returns a bare `*element.Base` for an *unregistered* `$Type` but a generated struct (which only *embeds* Base) for a registered one, so `icon.(*element.Base)` silently returns nothing for exactly the variants that exist in real projects — DESCRIBE printed every icon under `legacy` and none under `modelsdk`. Assert on `interface{ Raw() bson.Raw }`, which both shapes satisfy. A unit test passing `nil` did not reach this; **running `describe` against a real Studio Pro project under both `MXCLI_ENGINE` values did**, and that engine-vs-engine diff is the cheapest way to find a read-path divergence. Note `modelsdk/codec` is on bson **v2** while `mdl/backend/modelsdk`'s write path is on v1 — a test touching both needs an alias. Tests `sdk/mpr/writer_navigation_icon_test.go`, `mdl/visitor/visitor_navigation_icon_test.go`, `mdl/executor/cmd_navigation_icon_test.go`, `mdl/backend/modelsdk/navigation_icon_test.go`; example `mdl-examples/doctype-tests/11-navigation-examples.mdl`. mxcli-formula1 #9", "refs": ["#9"]}
+{"area": "mdl/grammar", "date": "2026-08-09", "symptom": "MDL cannot declare an OData action. `publish microflow …`, `publish action …` and every variant is a parse error at `missing ENTITY`, so a service's `$metadata` has an `EntityContainer` with `EntitySet` elements and no `ActionImport` — and every parameterised resource has to be modelled as an entity set that echoes its own arguments back as columns", "cause": "`createODataServiceStatement` admitted `publishEntityBlock*` and nothing else. Unlike the custom-auth gap the write path was missing too: neither `sdk/mpr/writer_odata.go` nor `mdl/backend/modelsdk/odata_write.go` had a single reference to `PublishedMicroflow`, though `modelsdk/gen/odatapublish` has `NewPublishedMicroflow()`/`NewPublishedMicroflowParameter()` with every setter wired", "file": "`mdl/grammar/domains/MDLService.g4` (`publishMicroflowBlock`, reusing `exposeClause`), `mdl/ast/ast_odata.go`, `mdl/visitor/visitor_odata.go`, `model/types.go` (`PublishedMicroflow`/`…Parameter`), `mdl/executor/cmd_odata_actions.go` (resolve the microflow, derive types), `sdk/mpr/writer_odata.go` + `parser_odata.go`, `mdl/backend/modelsdk/odata_write.go` + `odata_read_detail.go` + `integration_read.go`, `mdl/executor/cmd_odata.go` (`printPublishedMicroflowMDL`)", "insight": "**With no Studio Pro reference available, derive every shape from something already proven rather than stopping.** Property names/kinds came from the generated metamodel; the `Module.Microflow.Param` form of the `MicroflowParameter` by-name ref from `published_rest_write.go`, which already ships it; the `DataTypes$ObjectType`/`ListType` `Entity` key and `EnumerationType` `Enumeration` key from `serializeMicroflowDataType`. **Do not restate what the model already declares** — parameter types and the return type are read off the microflow, so they cannot drift. Store a data type as **kind + ref, never one string**: `Module.X` cannot say whether X is an entity or an enumeration. **`mx check` reporting 0 errors is near-worthless for a NEW element type** (mxbuild ignores unknown properties); the test that settles it is to delete the referent — dropping the microflow makes mxbuild answer `CE1613 … at Published microflow parameter DriverId from published microflow RecordPrediction`, naming the elements back in its own vocabulary. **A test that calls the emitter helper directly does not prove the emitter is wired**: reverting the loop in `outputPublishedODataServiceMDL` left every `printPublishedMicroflowMDL` test green, so the DESCRIBE test goes through the real entry point. Also note the replay control does NOT reproduce a missing emitter, because `create or replace` preserves microflows when the statement supplies none — the defect is an incomplete description, not in-place loss. Tests `mdl/visitor/visitor_odata_action_test.go`, `mdl/executor/odata_auth_microflow_test.go`; example `mdl-examples/doctype-tests/10-odata-examples.mdl`. mxcli-formula1 §47.1", "ce": ["CE1613"]}
+{"area": "mdl/grammar", "date": "2026-08-11", "symptom": "An association's line anchors can be preserved but not AUTHORED — a scripted domain model cannot lay out its own connector lines, so `@Position(x, y)` gets you boxes and nothing gets you the lines between them", "cause": "Feature gap, not a defect. `DomainModels$Association.ParentConnection`/`ChildConnection` had no MDL surface", "file": "`mdl/grammar/domains/MDLDomainModel.g4` (`SET ANCHOR`/`anchorPoint` — the ONLY grammar change), `mdl/visitor/visitor_association.go` (`anchorAnnotation`, `annotationParenPoint`, `anchorCoord`), `mdl/ast/ast_association.go` (`FromAnchor`/`ToAnchor` on both create and alter), `mdl/executor/cmd_associations.go` (`applyAnchors`, `describeConnectionPoints`)", "insight": "**Look for an existing annotation before inventing one** — `@anchor(from:, to:)` already existed for microflow sequence flows, asking the same question (where does the connector attach), and `annotationParamName` already admitted FROM and TO, and `(x, y)` was already `annotationParenValue`: CREATE needed **zero** grammar. The two forms cannot be confused because the microflow one names its inner params (`(from: right, to: left)`) while a coordinate pair is positional. **Let the storage pick the value type**: the measured pair is continuous (x takes 14 distinct values across 88 samples), so named anchors were never an option — see the preservation row above for how that was established. **Silence must mean \"preserve\", not \"default\"** — naming one end sets it and omitting one keeps what is stored, which is what stops a `create or modify association` about the delete behaviour from flattening a hand-tuned line; the AST carries POINTERS so \"not mentioned\" and \"mentioned as (0, 0)\" stay distinguishable. **Reject what the LOADER rejects, at check time**: a fractional coordinate must error, not be truncated to 0 — Mendix refuses to open such a project, and a silently-wrong value in a file that still loads is the worse failure. **Prove DESCRIBE round-trips by parsing its own output** — asserting on a string literal passes against a formatter emitting something nothing can read. Tests `mdl/visitor/visitor_association_anchor_test.go`, `mdl/executor/cmd_associations_anchor_test.go`, example `mdl-examples/bug-tests/872-association-line-anchors.mdl`. upstream #872", "refs": ["#872"]}
+{"area": "mdl/grammar", "date": "2026-08-13", "symptom": "An import activity's Range — Studio Pro's **All / First / Custom** — is absent from `DESCRIBE MICROFLOW`, and a `limit`/`offset` set in Studio Pro does not survive an mxcli round trip", "cause": "Worse than \"undescribed\". `Microflows$ImportMappingCall.Range` is polymorphic — `ConstantRange{SingleObject}` (All/First) or `CustomRange{LimitExpression, OffsetExpression}` (Custom) — and mxcli wrote only the first and read only `SingleObject`. So **Custom was unrepresentable**, a bounded import became unbounded on any rewrite, and all three settings described identically, so describe→edit→exec silently changed the activity", "file": "`mdl/grammar/domains/MDLMicroflow.g4` (`importMappingRange`) + `MDLLexer.g4` (`FIRST`) + `MDLSettings.g4` (keyword list), `mdl/visitor/visitor_import_export_mapping.go`, `mdl/ast/ast_microflow.go`, `sdk/microflows/microflows_actions.go` (`RangeSingleObject`, `RangeSingleObjectOf`), `mdl/executor/cmd_microflows_builder_calls.go` (`addImportFromMappingAction`), `mdl/executor/cmd_microflows_format_action.go` (`formatImportMappingRange`), `mdl/backend/modelsdk/microflow_write.go` (`importMappingRangeToGen`) + `microflow_read_actions.go`, `sdk/mpr/writer_microflow_actions.go` (`importMappingRange`) + `parser_microflow_actions.go`", "insight": "**The Range and the result variable's CARDINALITY are separate axes** — the first fix folded them and every `all` wrote a `ListType` against an object-rooted mapping, which mxbuild rejects with **CE0243** (\"the mapping used to return 'List of X' but now returns 'X'\"). Mendix's own `FeedbackModule.SUB_Feedback_PostToAppInsights` settles it: `ConstantRange{SingleObject:false}` against an **ObjectType** variable. The stored `VariableType` is the authority on cardinality; the range is its own flag (hence `RangeSingleObject *bool`, nil = \"not authored, fall back\"). **Count the write sites before declaring a serialization fixed** — the `ImportMappingCall` is built at THREE places (`importXmlActionToGen`, the REST `ResultHandlingMapping` case, and the legacy writer), and patching two let a limit reach the model while a `ConstantRange` was still written; extract one helper. **DESCRIBE must emit one of the three, never nothing** — silence re-enters the builder's inference, and an object-rooted mapping set to All (Studio Pro's default) comes back as First. **`first` is not `limit 1`**: one binds an OBJECT, the other a one-element LIST, so they cannot share syntax. **A platform rule you cannot author a positive case for is documentation, not validation** — Mendix rejects `offset` on a non-list mapping with **CE6100** while accepting `limit`, and mxcli cannot currently author a list-rooted import mapping (array-root mappings emit CE5015), so the constraint is documented rather than guessed at in a checker. Tests `mdl/executor/cmd_microflows_import_range_test.go`, `mdl/backend/modelsdk/microflow_import_range_test.go`, `sdk/mpr/parser_microflow_import_range_test.go`, example `mdl-examples/bug-tests/881-import-mapping-range.mdl`. upstream #881", "refs": ["#881"], "ce": ["CE0243", "CE5015", "CE6100"]}
+{"area": "mdl/grammar", "date": "2026-08-18", "symptom": "`describe microflow` renders a REST call's result as `returns String` when the activity actually stores the response in a **file document**, and the describe → exec round trip then writes String back — retyping the activity with `mx check` reporting nothing either way. On the legacy engine the `$var =` output variable disappears too", "cause": "MDL had no syntax for the case, `sdk/microflows` had no FileDocument variant, and both readers fell through to String: the legacy `parseResultHandling` had no `FileDocument` case (so the whole handling read back nil, taking the output-variable fallback with it), while modelsdk's `restResultHandlingFromRaw` read `VariableType.Entity` and then discarded it, matching only the literal `System.HttpResponse`. Mendix stores all five variants as ONE `Microflows$ResultHandling` carrying a `VariableType`, discriminated by the `ResultHandlingType` enum", "file": "`mdl/grammar/domains/MDLMicroflow.g4` (`restCallReturnsClause`), `mdl/ast/ast_microflow.go`, `mdl/visitor/visitor_microflow_actions.go`, `sdk/microflows/microflows_actions.go`, `sdk/mpr/parser_microflow_actions.go` + `writer_microflow_actions.go`, `mdl/backend/modelsdk/microflow_read_actions.go` + `microflow_write.go`, `mdl/executor/cmd_microflows_builder_calls.go` + `cmd_microflows_format_action.go`, rule in `validate_microflow_rest.go` (MDL064)", "insight": "Add `returns Module.Entity` as the LAST alternative so the keyword forms still win, and read Mendix's own `ResultHandlingType` discriminator rather than inferring from `VariableType` (keep the inference as a fallback — the property is `omitempty`). **Delete the silent `String` fallbacks**: an unreconstructable result handling must describe as something the parser REJECTS, or a reader gap becomes a model rewrite (ADR-0005). Mendix constraints worth knowing before designing syntax here: the BASE `System.FileDocument` is rejected as a return type (**CE0362**) so a specialization is mandatory, and HttpResponse **cannot** be specialized (**CE1540** allows only User, FileDocument, Image, Paging) — which is why `returns response` needed no change and the reporter's suggested \"HttpResponse specialization\" does not exist. Cross-engine round trip (`gateEngines`) is what proves it: the two readers failed differently and each looked fine from inside itself. Issue #922", "refs": ["#922"], "ce": ["CE0362", "CE1540"], "rules": ["MDL064"]}
+{"area": "mdl/grammar", "date": "2026-08-19", "raw": "| `describe import mapping` prints only the LAST segment of a value element's JsonPath, so a mapping that binds a nested leaf onto a parent entity describes as `Attr = name` when the model says `(Object)\\|customer\\|name` — and re-executing mxcli's own output fails with `\"name\" is not a member of the JSON structure at (Object)`. Authoring that shape was impossible too (`extraneous input '/'`) | Studio Pro can bind a leaf several levels below the object element it belongs to, with no entity for the levels in between, stored as ONE multi-segment JsonPath. `mappingMemberName` took `LastIndex(path, \"\\|\")`, assuming a value element is always a direct child, and the grammar's value alternative took a single `identifierOrKeyword` | grammar `mdl/grammar/domains/MDLDomainModel.g4` (`jsonMemberPath`), `mdl/visitor/visitor_import_export_mapping.go`, `mdl/executor/cmd_import_mappings.go` (`resolvePath`, `mappingMemberName`) + `cmd_export_mappings.go`; fixtures `mdl-examples/bug-tests/927-mapping-nested-member-path*.mdl` | Render the member RELATIVE to the enclosing object element (thread the parent's JsonPath through the printers) and resolve a `/`-separated member one segment at a time so each step keeps the raw-key/exposed-name tolerance from #882. **Use the parent path verbatim** — for an array the object element's own JsonPath is already the ITEM path, and trimming `\\|(Object)` off it makes a child of that item render as `(Object)/sku`. Two shapes must be REFUSED, both measured rather than assumed: an EXPORT mapping cannot collapse levels (**CE5015** — it has to produce the intermediate node; three-way control: same member in an import is 0 errors, same export with only top-level members is 0 errors), and an import member cannot cross a `0..*` element (**CE0256** \"a schema element with wrong occurrence\"). Measure by patching the JsonPath into a stored mapping and running `mx check` — and assert the patch landed before trusting a 0, since an mxcli parse error leaves the baseline project untouched. Issue #927 |", "refs": ["#882", "#927"], "ce": ["CE0256", "CE5015"]}
+{"area": "mdl/grammar", "date": "2026-08-19", "symptom": "Binary upload is reported as impossible in MDL — \"a consumed REST operation has no binary body, so use a Java action\". A Studio Pro-authored binary POST also **describes with no body at all**, and re-executing that DESCRIBE produces a request that sends nothing", "cause": "Right conclusion about the **wrong document**. Mendix models a binary request body on the microflow **REST CALL activity** as `Microflows$BinaryRequestHandling` + an action-level `RequestHandlingType: \"Binary\"` — a `Microflows$` type, which is why a metamodel grep for `Rest$*Body` finds only the three non-binary ones and \"proves\" it impossible. mxcli could **parse** it (`sdk/mpr/parser_microflow_actions.go`) and could neither write, read (modelsdk) nor describe it, so it survived a legacy read and vanished everywhere else", "file": "Grammar `mdl/grammar/domains/MDLMicroflow.g4` (`restCallBodyClause`); `mdl/ast/ast_microflow.go` (`RestBodyBinary`); `mdl/visitor/visitor_microflow_actions.go`; `mdl/executor/cmd_microflows_builder_calls.go`; writers `mdl/backend/modelsdk/microflow_write.go` + `sdk/mpr/writer_microflow_actions.go`; reader `mdl/backend/modelsdk/microflow_read_actions.go` (`restRequestHandlingFromRaw`); formatter `mdl/executor/cmd_microflows_format_action.go`; tests `mdl/executor/cmd_microflows_binary_body_test.go`; fixture `mdl-examples/bug-tests/rest-binary-post.mdl`", "insight": "**\"Not in the metamodel\" needs the right namespace before it is a conclusion** — the search was for `Rest$…Body` and the answer lives under `Microflows$…RequestHandling`. Ask for a Studio Pro example instead of reasoning from an absence: one 4-KB unit settled in minutes what a metamodel grep had \"disproved\". **The discriminator and the sub-element must agree** — `RequestHandlingType` was hardcoded `\"Custom\"` in BOTH engines regardless of the handler; only the Binary case is derived here, because the others have no measured reference and work today (a latent mismatch worth a separate look). **The expression is the `Contents` MEMBER** (`$Doc/Contents`), not the document, and is stored as source text — quoting it sends the path as a string literal. **Verify a round trip by re-executing DESCRIBE and diffing the BSON against Studio Pro's**: mxcli's output reproduced the Studio Pro action exactly (same type, same discriminator, same expression) with mxbuild 0 errors, which is stronger than any assertion about what \"should\" be written. Beware the sibling trap: read support in one engine and not the other looks like a describe bug"}
+{"area": "mdl/grammar", "date": "2026-08-20", "symptom": "A type split spelled `split type $x case Mod.E … else …` warns **MDL065**, or a script using `when Mod.E then` is rejected by an older mxcli", "cause": "The type split moved onto the enum split's branch syntax (#913): `case` used to introduce a BRANCH here while introducing the SUBJECT in `case $x when V then` and in expressions, so the word meant two things. Both spellings build the identical flow and both still parse", "file": "`mdl/grammar/domains/MDLMicroflow.g4` (`inheritanceSplitCase`, `inheritanceSplitElse`), `mdl/visitor/visitor_microflow_statements.go` (`buildInheritanceSplitStatement`), `mdl/executor/validate_microflow.go` (`checkInheritanceSplitSpelling`)", "insight": "Write `when Module.Entity then` and `when (empty) then`. **Never promote MDL065 to an error** — `TestMDL065_DoesNotBlockExecution` pins that, because `exec`'s pre-flight gate halts on errors and would refuse every script using the old form. When adding a spelling alias, pin the equivalence (`TestInheritanceSplit_BothSpellingsProduceTheSameAST`) rather than assuming it: the deprecation message promises \"both build the identical flow\", and that promise needs a test. Fixtures `mdl-examples/bug-tests/913-split-type-{unified,legacy}-syntax.mdl`", "refs": ["#913"], "rules": ["MDL065"]}
+{"area": "mdl/grammar", "date": "2026-08-20", "raw": "| `SHOW ACCESS ON ENTITY Mod.E` is a parse error — `extraneous input '.' expecting the start of a statement` — while `SHOW ACCESS ON MICROFLOW\\|PAGE Mod.Name` parse. The generated project CLAUDE.md documents all three. Separately, and found by the same sweep: `SHOW ACCESS ON PAGE` **parses and answers the wrong question**, printing the page's whole widget tree instead of its allowed module roles | Two ordering defects, one at each layer. (a) There was no `ACCESS ON ENTITY` grammar alternative, and `ENTITY` is in the `keyword` rule, so `showOrList ACCESS ON qualifiedName` matched the word ENTITY as the *whole* name; the statement ended there and the real name was extraneous. The command itself always existed — the bare `SHOW ACCESS ON Mod.E` is the same AST node and the same handler. (b) `ExitShowStatement` is a long if/else chain: the singular `SHOW PAGE`→DESCRIBE alias branch (added when four show alternatives had no visitor branch) sits ~200 lines BEFORE the `ACCESS` branch and matches on `ctx.PAGE() != nil` alone, so it swallowed `SHOW ACCESS ON PAGE`. The `ENTITY` branch would have swallowed the new alternative the same way | `mdl/grammar/domains/MDLCatalog.g4` (`showStatement`), `mdl/visitor/visitor_query.go` (`ExitShowStatement` — the `ENTITY` and `PAGE` branches) | Add the alternative, then guard **every earlier branch that matches a bare token the new alternative also contains** with `ctx.ACCESS() == nil`. **Generalisable — the shape to look for**: a token accessor (`ctx.PAGE()`) is true for several alternatives, so in an if/else visitor the first branch wins and the later one is dead. `TestEveryShowAlternativeProducesAStatement` cannot catch it: a statement IS produced, just the wrong one — so a new alternative needs a test asserting the ObjectType, not merely that something came out. Grep `ctx\\.[A-Z]*()` in the chain for a token that appears in more than one alternative before adding one. **The `-c` parse-error column is offset** by the `CONNECT LOCAL '<path>'; ` prefix `-p` prepends, which is why the report shows 1:60 for a 40-character command — do not chase the position, reproduce with `mxcli check <file>`. Three controls, each reverted separately: no grammar alternative ⇒ the original parse error; no ENTITY guard ⇒ `ObjectType = ENTITY`; no PAGE guard ⇒ `*ast.DescribeStmt`. Verified end-to-end on a real 10.24 project (access rules / allowed roles reported, `show entity` and `show page` still describing). Tests `mdl/visitor/visitor_show_access_test.go`, repro `mdl-examples/bug-tests/925-show-access-on-entity.mdl`. Issue #925 |", "refs": ["#925"]}
+{"area": "mdl/grammar", "date": "2026-08-20", "raw": "| `MOVE IMPORT MAPPING …` / `MOVE JSON STRUCTURE …` is a parse error, and neither mapping type takes a `FOLDER` clause on create — so those documents can never leave the module root from MDL. The documented doctype list (\"PAGE \\| MICROFLOW \\| NANOFLOW \\| SNIPPET \\| ENUMERATION \\| CONSTANT\") is itself stale, omitting three doctypes MOVE already supported | `moveStatement` listed nine doctypes and nothing else; the other twenty-two were never unimplemented, just unlisted. `MoveImportMapping` and `MoveExportMapping` were fully wired — interface, both engines, mock — and **called from nowhere**. Same shape as mxcli-formula1 #32, one layer wider | grammar `mdl/grammar/MDLParser.g4` (new `moveDocumentType` rule), registry `mdl/ast/ast.go` (`MoveDocumentTypeByKeyword`, `IsMoveDocumentType`), visitor `mdl/visitor/visitor_entity.go`, executor `mdl/executor/cmd_move_document.go` (generic path) + `cmd_move.go` (default case), backend `FindDocumentUnit` / `ListDocumentUnits` in `mdl/backend/placement.go` | **Make the doctype list a grammar RULE, not an inline alternation.** `MOVE FOLDER` is told from a document move by the *absence* of a doctype, and that discriminator was a hand-written negation of every doctype keyword — with twenty-two more keywords it would never have stayed in step. As a sub-rule it is one `ctx.MoveDocumentType() == nil` check that cannot go stale. **Resolve the document through the unit table, not a per-kind list**: one `FindDocumentUnit(module, name)` covers every doctype including ones added later, where twenty-two `List<Kind>()` scans would each be a place to forget a kind. **Do not build a doctype → `$Type` table to validate against** — two such tables already exist in this repo and disagree with each other and with a real project (`mdl/types/unit_types.go` says `JavaActions$JavaScriptAction`; the writer inserts and Studio Pro stores `JavaScriptActions$JavaScriptAction`). Derive the kind from the stored `$Type` instead (`types.DocumentKind`) and refuse only when the derived kind is *itself* a doctype MOVE can spell, so a derivation you cannot vouch for defers to the name lookup rather than blocking a legitimate move. **Report the kind you found, not the kind the statement named** — the lookup is by name, so the two can differ, and echoing the user's word would be a confident-sounding lie. Same reasoning fixed `LIST FOLDERS`, whose hand-maintained `documentsByContainer` still hid layouts, menus, JavaScript actions and building blocks after #892 added five kinds to it: it now fills gaps from `ListDocumentUnits()` (measured 78 → 259 documents listed on a 7-module project). Tests `mdl/visitor/visitor_move_alldoctypes_test.go` (drives the registry, so a doctype added to it without grammar support fails), `mdl/executor/cmd_move_document_test.go`; example in `mdl-examples/doctype-tests/18-folder-examples.mdl`. Issue #932 |", "refs": ["#32", "#892", "#932"]}
+{"area": "mdl/grammar", "date": "2026-08-21", "raw": "| An app needing **anonymous access** cannot be built unattended: `SHOW PROJECT SECURITY` reads `Guest Access` but no MDL statement writes it, so every headless run ends with a manual step in Studio Pro | `ALTER PROJECT SECURITY` had exactly two forms (`LEVEL`, `DEMO USERS`). Nothing was missing underneath — `SetEnableGuestAccess` already existed in gen — it had simply never been wired through grammar → AST → visitor → executor → backend | `mdl/grammar/domains/MDLSecurity.g4`, `mdl/ast/ast_security.go`, `mdl/visitor/visitor_security.go`, `mdl/executor/cmd_security_write.go` (`applyGuestAccess`), `mdl/backend/security.go` + both engines | **`DEMO USERS ON\\|OFF` is the whole template** for any project-security flag: same AST node, same unit, same write choke point. Copy it rather than designing. **What mxbuild does and does not enforce decides the syntax, and only measurement tells you which:** guest access on with an empty role is **CE0133** (measured 6 errors vs 5), so `ROLE` cannot be optional in effect — but guest access on with a role that **does not exist** builds with the *same* count as a valid one, so mxcli must validate the reference itself or a typo yields a silently broken public site. That asymmetry is why `ROLE` is optional in the *grammar* (a stored role satisfies CE0133, so re-enabling need not retype it) and required by the *executor*. **`OFF` keeps the stored role** — guest-off-with-role is valid Mendix, and clearing it would lose the operator's choice on a toggle. **No check-time (no-project) rule is possible for the bare `ON` case**: whether it is legal depends on what the project stores, which `mxcli check` cannot see — so unlike most refusals this one has no `validate_security.go` counterpart, deliberately. Example `mdl-examples/doctype-tests/30-guest-access.mdl`; tests `mdl/executor/cmd_security_guest_access_test.go`. Issue #924 |", "refs": ["#924"], "ce": ["CE0133"]}
+{"area": "mdl/grammar", "date": "2026-08-24", "symptom": "`DESCRIBE PAGE` emits MDL that does not parse — `line N:M mismatched input 'custombutton' expecting '}'` — so a page holding that widget cannot round-trip, and the object list's items cannot be authored at all", "cause": "The `.def.json` generator DERIVES the container keyword from the object-list property key (`customButtons` → `CUSTOMBUTTON`, via `deriveObjectListKeyword`), while the grammar's `widgetTypeV3` carries a HAND-MAINTAINED list of them. Nothing checked the two agree, so any widget whose object list had no keyword described back as unparseable MDL", "file": "`mdl/grammar/MDLLexer.g4` + `mdl/grammar/domains/MDLPage.g4` (`CUSTOMBUTTON`, `ALLOWEDFILEFORMAT`); guard test `mdl/executor/widget_container_keyword_test.go`", "insight": "**Add the guard, not just the keyword** — the list is derived on one side and hand-written on the other, so the next marketplace widget re-opens it; the test reads the accepted keywords straight out of `MDLPage.g4` so it cannot drift from the grammar, and fails with the fix instructions in the message. **Check the lexer before adding one**: measured across 43 widget defs, 5 derived keywords were missing and 3 of them (`ATTRIBUTE`, `ATTR`, `EVENT`) COLLIDE with existing tokens — `ATTRIBUTE` is the `Attribute:` property keyword — so they cannot simply be appended and are recorded in `knownUnsupportedContainers` with the reason rather than left to fail silently. The symptom is a parse error, so it is loud — but the thing it hides is not: an unparseable DESCRIBE means `describe → exec` **aborts**, and a round-trip test that only diffs the two describes passes, because a re-describe after a failed exec is trivially identical. Always confirm the exec applied (`Replaced …`) first. Issue #956", "refs": ["#956"]}
+{"area": "mdl/grammar", "date": "2026-08-23", "symptom": "`COMMIT $Obj;` writes **\"With events = No\"** — Studio Pro's default is Yes, so every mxcli-authored commit silently skips its before/after commit event handlers. Detection is nil across the board: `mxcli check` ✓, `mxcli lint` 0 errors, Studio Pro's consistency check ✓, `mxbuild --write-errors` BUILD SUCCEEDED. The reporter found it in production — 1,800 rows written, no handler run. Sibling symptom: a Studio Pro **DELETE** or **CREATE** activity with `Refresh in client = Yes` loses the flag on describe → exec", "cause": "Two layers, and only the first is the reported bug. **MDL**: the grammar had no `WITHOUT EVENTS` on `commitStatement`, so an absent modifier meant `false` — while MDL's own convention (stated in `commitClause`'s grammar comment) is that absent means *Mendix's* default. **Engine**: `modelsdk/gen`'s `initCommitAction` carries `// TODO: applyDefaults(o) — populate mandatory fields from reflection-data` (~900 such TODOs across gen), so nothing downstream corrects a wrong MDL default — though it is not the proximate cause here, since the writer sets the value explicitly either way. The refresh half is `#407` half-fixed: that issue added `REFRESH` to `change` and stopped, leaving `delete` and `create` with no grammar, no describer output, and (for create) no field in the semantic model at all", "file": "`mdl/grammar/domains/MDLMicroflow.g4` (`commitStatement`, `deleteObjectStatement`, `createObjectStatement`) + `mdl/executor/cmd_microflows_format_action.go`", "insight": "Invert the AST flag to `MfCommitStmt.WithoutEvents` so the **zero value is the language default** — a `WithEvents bool` defaults to the one value Studio Pro never writes, and that trap is what caused the bug. Keep `WITH EVENTS` parsing (it means the default) so pre-fix scripts still run. DESCRIBE must render the *deviation*, not the flag: `without events` when false, nothing when true — render it the other way and a Studio Pro default commit describes into its opposite. Share one `refreshModifier()` across all five activities; five inline conditionals is exactly how delete and create drifted. **Measure against a real Studio Pro document, not the refguide**: `CommitActivity.DefaultCommit` in ako/TestApp stores `WithEvents=true`, and its sibling stores `false`, so Studio Pro writes both spellings and neither is an omission Mendix fills in. **Prove the drop before fixing it**: flip `RefreshInClient` on a stored Delete through the backend, describe (renders `delete $Obj;`), re-exec → `Replaced` and the flag is gone; the commit probe under the same round trip reports `Unchanged`, which is the control that says the drop is delete-specific and not round-trip noise. `mx check` is worthless here — 0 errors before and after — so the fixpoint test is `Unchanged microflow:` from exec. MDL067 (info, once per microflow) names the documents whose behaviour changes. Tests `TestFormatAction_CommitObjects`, `TestFormatAction_RefreshInClient_AllActivities`, `TestCommitWithoutEvents`; repro `mdl-examples/bug-tests/895-commit-events-and-refresh-defaults.mdl`. Issue #895", "refs": ["#407", "#895"], "rules": ["MDL067"]}
+{"area": "mdl/grammar", "date": "2026-08-24", "symptom": "A domain script cannot be re-run. `alter entity … add index` is the silent one: a second run reports \"Added index\" and appends a duplicate, and the project then fails the build with **CE0072 \"Duplicate indexes\"** — mxcli said nothing was wrong. `drop index` is addressable only by an invented positional name (\"idx1\") that appears in no output, and the documented `drop index (Col)` does not parse. `create entity`/`create association` offer only `create or modify`, which replaces the whole definition and drops omitted attributes (finding #24)", "cause": "Three gaps in one surface. The `IF NOT EXISTS`/`IF EXISTS` family had been added for ATTRIBUTE and EVENT HANDLER only, so INDEX had no guard AND no duplicate check — the two omissions compose into a silent corruption rather than an error. DROP INDEX matched `fmt.Sprintf(\"idx%d\", i+1)` against a user-supplied name, which is a position, not an identity", "file": "`mdl/grammar/domains/MDLDomainModel.g4` (`ifNotExists?` on ADD INDEX / createEntityStatement / createAssociationStatement, `ifExists?` + `indexDefinition` on DROP INDEX), `mdl/executor/cmd_entities.go` (`findIndexByColumns`, `indexMatchesColumns`, `indexColumnLabel`, both index arms, the create-entity arm), `mdl/executor/cmd_associations.go` (`associationExists`), `mdl/executor/cmd_enumerations.go` (`validateIdempotencyGuard`, MDL067); tests `mdl/executor/alter_entity_index_idempotent_test.go`, `mdl/visitor/idempotency_guards_test.go`, `mdl/executor/validate_idempotency_guard_test.go`; repro `mdl-examples/bug-tests/sudoku-10-rerunnable-domain-script.mdl`", "insight": "**An index's identity is its columns, in order, with their directions** — Mendix builds a composite database index, so (Row, Col) is not (Col, Row) and ascending is not descending; a matcher looser than that makes ADD refuse a distinct index and DROP remove the wrong one. **A guard and a duplicate check are separate omissions**: adding `IF NOT EXISTS` alone would have left the unguarded form still corrupting, so the bare form must ERROR — and its message names CE0072 and the guarded spelling, because the author cannot otherwise connect a build failure to the statement that caused it. **`IF NOT EXISTS` is not `OR MODIFY`**: one leaves the stored element untouched, the other rebuilds it from the statement, so they are opposite answers for a partial statement and writing both is refused (MDL067) rather than silently resolved. **Check the docs against the parser**: four forms in `MDL_QUICK_REFERENCE.md` did not parse (`add (a, b)`, `drop (a)`, `rename X to Y`, `drop index (Col)`) — the exact drift class `scripts/check-skill-mdl.sh` names in its own header, which had never been pointed at that file. It is now wired into `make check-skill-mdl`. Verify with a THREE-run control: run 1 does the work, run 2 is nothing but skips, run 3 leaves `mprcontents` byte-identical and `mx check` at 0 errors. Sudoku finding #10", "refs": ["#10", "#24"], "ce": ["CE0072"], "rules": ["MDL067"]}
+{"area": "mdl/grammar", "date": "2026-08-25", "symptom": "A language cannot be enabled or disabled from MDL — `alter settings LANGUAGE` carries `DefaultLanguageCode` only, so the answer to \"translate this app\" was always \"go to Studio Pro\". Worse, `show languages` looks like the answer and is not: it lists languages that have TRANSLATIONS (from the catalog `strings` table), so a stock blank app reports **8** while **1** is enabled", "cause": "The enabled list (`Settings$LanguageSettings.Languages`) was read into the semantic model and never written: the settings overlay wrote `DefaultLanguageCode` and carried `Languages` through from the stored document. A handler could therefore report `Enabled language: ar_SD` and land **nothing** — the executor mutated `ps` and the writer dropped it on the floor", "file": "`mdl/grammar/domains/MDLSettings.g4` (`ADD`/`REMOVE` alternatives, `languageOptions`), `mdl/visitor/visitor_settings.go`, `mdl/executor/cmd_settings_languages.go`, and the write that makes it real: `mdl/settingsoverlay/settingsoverlay.go` (`Languages`, `Language`, `newLanguage`) wired from `mdl/backend/modelsdk/settings_write.go`", "insight": "Pin the element against a Studio Pro-authored reference before writing it — four things a guess gets wrong: the type is **`Texts$Language`** (not `Settings$…`) though it lives under `Settings$LanguageSettings`; there is **no `Description`** (Studio Pro derives \"Arabic, Sudan\" from `ar_SD`, so the code is the whole stored identity); Studio Pro **appends** rather than sorting; and **`CheckCompleteness` is stored `false` even for the default language**, whose Languages-table row reads \"Yes\" — the dialog says why (\"the default language is always checked\"), so that Yes is computed and writing `true` to match the UI produces a document Studio Pro never writes. Follow `settingsoverlay.ServerConfiguration`: match stored elements by their natural key, keep each one's document (so its `$ID` and any unmodelled property survive), derive a NEW element's shape from a sibling so no key is invented. **The refusal that was wrong:** removing a language does NOT delete its translations — the enabled list and the translation data are independent, which a stock app proves by enabling one language while storing translations in eight — so refusing on that basis would make the operation impossible on any project with a marketplace module and would assert something false about Mendix. Report the count instead. Verify by diffing the written element against the Studio Pro one field by field (identical here, `$ID` aside) and by checking the stored `$ID` of an untouched language survives. Example `mdl-examples/doctype-tests/languages.mdl`"}
+{"area": "mdl/grammar", "date": "2026-08-25", "symptom": "A language cannot be enabled or disabled from MDL — `alter settings LANGUAGE` carries `DefaultLanguageCode` only, so the answer to \"translate this app\" was always \"go to Studio Pro\". Worse, `show languages` looks like the answer and is not: it lists languages that have TRANSLATIONS (from the catalog `strings` table), so a stock blank app reports **8** while **1** is enabled", "cause": "The enabled list (`Settings$LanguageSettings.Languages`) was read into the semantic model and never written: the settings overlay wrote `DefaultLanguageCode` and carried `Languages` through from the stored document. A handler could therefore report `Enabled language: ar_SD` and land **nothing** — the executor mutated `ps` and the writer dropped it on the floor", "file": "`mdl/grammar/domains/MDLSettings.g4` (`ADD`/`REMOVE` alternatives, `languageOptions`), `mdl/visitor/visitor_settings.go`, `mdl/executor/cmd_settings_languages.go`, and the write that makes it real: `mdl/settingsoverlay/settingsoverlay.go` (`Languages`, `Language`, `newLanguage`) wired from `mdl/backend/modelsdk/settings_write.go`", "insight": "Pin the element against a Studio Pro-authored reference before writing it — four things a guess gets wrong: the type is **`Texts$Language`** (not `Settings$…`) though it lives under `Settings$LanguageSettings`; there is **no `Description`** (Studio Pro derives \"Arabic, Sudan\" from `ar_SD`, so the code is the whole stored identity); Studio Pro **appends** rather than sorting; and **`CheckCompleteness` starts `false`** on a newly added language. That flag is a REAL setting, not display sugar — ticking it makes Mendix report errors and warnings for texts with no translation in that language, instead of letting them fall back to the default silently — so it must be authorable (`add … (CheckCompleteness: true)`) and changeable (`modify`), never forced. The subtlety is only the DEFAULT language: a stock project stores `false` for `en_US` while its Languages-table row reads \"Yes\", because Mendix always checks the default whatever the flag says, so a run that sets it there should say the value is stored and inert until another language becomes the default. Follow `settingsoverlay.ServerConfiguration`: match stored elements by their natural key, keep each one's document (so its `$ID` and any unmodelled property survive), derive a NEW element's shape from a sibling so no key is invented. **The refusal that was wrong:** removing a language does NOT delete its translations — the enabled list and the translation data are independent, which a stock app proves by enabling one language while storing translations in eight — so refusing on that basis would make the operation impossible on any project with a marketplace module and would assert something false about Mendix. Report the count instead. Verify by diffing the written element against the Studio Pro one field by field (identical here, `$ID` aside) and by checking the stored `$ID` of an untouched language survives. Example `mdl-examples/doctype-tests/languages.mdl`"}
+{"area": "mdl/grammar", "date": "2026-08-25", "symptom": "A language cannot be enabled or disabled from MDL — `alter settings LANGUAGE` carries `DefaultLanguageCode` only, so the answer to \"translate this app\" was always \"go to Studio Pro\". Worse, `show languages` looks like the answer and is not: it lists languages that have TRANSLATIONS (from the catalog `strings` table), so a stock blank app reports **8** while **1** is enabled", "cause": "The enabled list (`Settings$LanguageSettings.Languages`) was read into the semantic model and never written: the settings overlay wrote `DefaultLanguageCode` and carried `Languages` through from the stored document. A handler could therefore report `Enabled language: ar_SD` and land **nothing** — the executor mutated `ps` and the writer dropped it on the floor", "file": "`mdl/grammar/domains/MDLSettings.g4` (`ADD`/`REMOVE` alternatives, `languageOptions`), `mdl/visitor/visitor_settings.go`, `mdl/executor/cmd_settings_languages.go`, and the write that makes it real: `mdl/settingsoverlay/settingsoverlay.go` (`Languages`, `Language`, `newLanguage`) wired from `mdl/backend/modelsdk/settings_write.go`", "insight": "Pin the element against a Studio Pro-authored reference before writing it — four things a guess gets wrong: the type is **`Texts$Language`** (not `Settings$…`) though it lives under `Settings$LanguageSettings`; there is **no `Description`** (Studio Pro derives \"Arabic, Sudan\" from `ar_SD`, so the code is the whole stored identity); Studio Pro **appends** rather than sorting; and **`CheckCompleteness` starts `false`** on a newly added language. That flag is a REAL setting, not display sugar — ticking it makes Mendix report errors and warnings for texts with no translation in that language, instead of letting them fall back to the default silently — so it must be authorable (`add … (CheckCompleteness: true)`) and changeable (`modify`), never forced. The subtlety is only the DEFAULT language: a stock project stores `false` for `en_US` while its Languages-table row reads \"Yes\", because Mendix always checks the default whatever the flag says, so a run that sets it there should say the value is stored and inert until another language becomes the default. Follow `settingsoverlay.ServerConfiguration`: match stored elements by their natural key, keep each one's document (so its `$ID` and any unmodelled property survive), derive a NEW element's shape from a sibling so no key is invented. **The refusal that was wrong:** removing a language does NOT delete its translations — the enabled list and the translation data are independent, which a stock app proves by enabling one language while storing translations in eight — so refusing on that basis would make the operation impossible on any project with a marketplace module and would assert something false about Mendix. Report the count instead. Verify by diffing the written element against the Studio Pro one field by field (identical here, `$ID` aside) and by checking the stored `$ID` of an untouched language survives. **DESCRIBE has to emit statements, not a comment**, or the settings do not round-trip — and the emitting is where the design work is: plain `add` refuses an already-enabled language, so a described project could not be replayed onto itself, which is why `ADD OR MODIFY` exists (the same upsert reasoning as `CREATE OR MODIFY`); `DefaultLanguageCode` is validated against the enabled list, so it must be emitted **after** the languages or the output fails on a project that lacks that language; and **every** option must be named, because MODIFY touches only what it names and an omitted `CustomDateFormat` would leave whatever the target already had. Measured both directions: replaying onto the same project leaves the unit byte-identical and reports `Unchanged language` per language (the verb is downgraded on positive evidence, as with `Unchanged nanoflow`), and replaying onto a BLANK project reproduces the language settings exactly. Example `mdl-examples/doctype-tests/languages.mdl`"}
+{"area": "mdl/grammar", "date": "2026-08-25", "symptom": "The documented way to remove a language's translations — `create or replace translations for <lang> ( );` — is a **parse error**, so there is no way to do it at all. The advice appears in the removal path's own error message, in the skill and in the docs", "cause": "`createTranslationsStatement` required at least one entry: `LPAREN translationEntry (COMMA translationEntry)* COMMA? RPAREN`. An empty list is the OR REPLACE semantics taken to the limit (the file names nothing, so everything in scope goes), and nothing else expresses it", "file": "`mdl/grammar/domains/MDLSettings.g4` (`createTranslationsStatement`), tested in `mdl/visitor/visitor_translations_test.go`", "insight": "Make the list optional — `LPAREN (translationEntry (COMMA translationEntry)* COMMA?)? RPAREN` — and nothing else: `ModeReplace` with an empty dictionary already removed everything and already named what it deleted. **The lesson is about the docs, not the grammar**: this was found by running the statements quoted in a skill through `mxcli check` rather than by reading them, and the same wrong advice had already shipped inside an error message telling users how to recover. Quote-then-check every statement a message or a skill recommends; `make check-skill-mdl` covers fenced blocks it recognises but not prose inside a Go string"}
+{"area": "mdl/grammar", "date": "2026-08-25", "symptom": "A `create … comment 'text'` option reports success and sets **no documentation**. Affected `create entity`, `create enumeration`, `create module`, `create microflow`, `create nanoflow`, `create rule` and `create association` — the text appears nowhere in the written project, and `mx check` passes because a document with no documentation is valid", "cause": "The visitor stored the option on `stmt.Comment`; the executor read `stmt.Documentation`. Two fields, never joined. `create module` was worse than unwired: `Projects$Module` has **no Documentation property**, so the option could never have done anything. The `/** … */` doc comment sets `Documentation` correctly on all of these except association, where **neither** spelling works (separate defect)", "file": "Grammar `mdl/grammar/domains/MDLMicroflow.g4` (`microflowOption`), `mdl/grammar/domains/MDLDomainModel.g4` (`entityOption`, `enumerationOption`, `moduleOption`); `mdl/visitor/visitor_microflow.go`, `visitor_entity.go`, `visitor_enumeration.go`; hint in `mdl/visitor/visitor.go` (`looksLikeRemovedCreateComment`); tests `mdl/visitor/create_comment_removed_test.go`", "insight": "**Remove a dead option rather than wiring it** when a working spelling already exists — two spellings, one of which lies, is worse than one. **A removed option needs a parse-error hint**: \"no viable alternative\" sends the author hunting for a different spelling of something that no longer exists. **`COMMENT` is alive on constants, JSON structures, image collections, database connections, workflow activities and `ALTER … SET COMMENT`** — a blanket search-and-replace across the visitors silently broke the *constant* branch, which `TestCreateConstant` caught; the removal test therefore carries a positive control listing every surviving site. Grep for `stmt.X = …` in a visitor with no matching read in the executor to find more of these"}
+{"area": "mdl/grammar", "date": "2026-08-25", "raw": "| A `find` mapping element always behaves as **find-or-create** whatever the document said, and `describe` cannot show the difference — a Studio Pro mapping that said \"error out\" comes back saying \"create silently\" | Mendix stores **two** properties on an object mapping element, not one: `ObjectHandling` {Parameter, Create, Find, Custom} and `ObjectHandlingBackup` {Create, Error, Ignore} (plus the bool `ObjectHandlingBackupAllowOverride`). mxcli only ever wrote the first and hardcoded the backup, so the runtime behaviour was mxcli's choice rather than the author's. Measured: rebuilding the shipped `Email_Connector.IMM_EmailTemplateMapping` flipped **7 elements from 'Error' to 'Create'**, with mxbuild reporting 0 errors on both — the documents are equally valid, they just do different things | `mdl/grammar/MDLLexer.g4` (`IGNORE`, `OVERRIDABLE`) + `mdl/grammar/domains/MDLDomainModel.g4` (`mappingHandlingBackup`) + `MDLSettings.g4` (keyword rule), `mdl/visitor/visitor_import_export_mapping.go` (`applyMappingHandlingBackup`), `mdl/executor/cmd_import_mappings.go` + `mapping_messagedefinition.go`, `mdl/backend/modelsdk/mapping_write.go` (`importBackupFor`) + `mapping_read.go`, `sdk/mpr/writer_import_mapping.go` + `parser_import_mapping.go`, `modelsdk/mpr/serialize_mappings.go` | `find M.E or create\\|error\\|ignore [overridable]`, with `find or create M.E` kept as the older spelling of the first. **A bare `find` is refused** — silently picking one of three runtime behaviours is the bug, so the executor names all three in the error rather than defaulting. Backups that are NOT the author's to choose: `create` and custom (`by`) handling keep 'Create', because \"Custom\" is not a member of the backup enum; **export** elements are always 'Error' (there is nothing to find), which is what Studio Pro writes. Two places the fix has to reach that a JSON-path test does not exercise: the **message-definition** builder (`mapping_messagedefinition.go`) has its own element construction, and it was the last 7 of the 8 fixture differences — a direct nested JSON test passed while the real document still regressed, so **diff the fixture, not a synthetic case**. The eighth was unrelated and adjacent: `xmlPrimitiveTypeName` fell through `Binary` to \"String\". Remember a `find` also needs a KEY (`Attr = member key`) or mxbuild reports **CE0250** \"Object element must have a key defined if object handling is set to 'Search for an object'.\" — pre-existing, but every repro of this fix trips it. Repro `mdl-examples/bug-tests/261-object-handling-backup.mdl`. Issue #261 |", "refs": ["#261"], "ce": ["CE0250"]}
+{"area": "mdl/grammar", "date": "2026-08-25", "symptom": "An import mapping cannot declare its INPUT OBJECT, so a custom handler's `Param: parameter` refers to something that cannot exist, and `describe` of a real one drops the declaration while still emitting the handler that uses it", "cause": "Mendix stores it as `ParameterType`, a `DataTypes$ObjectType` naming the entity. Measured across the demo apps: 10 of 327 mappings declare one (GenAICommons.ChunkCollection in eight), 190 import mappings store the `DataTypes$UnknownType` marker, and an EXPORT mapping carries no `ParameterType` property at all (0 of 127) — its parameter IS its root object, so there is no export spelling. All three writers hardcoded the UnknownType variant", "file": "`mdl/grammar/domains/MDLDomainModel.g4` (`importMappingParameterClause`), `mdl/visitor/visitor_import_export_mapping.go`, `mdl/executor/mapping_customhandler.go` (`resolveMappingParameter`, `requireDeclaredParameter`) + `cmd_import_mappings.go`, `mdl/backend/modelsdk/mapping_write.go` + `mapping_read.go` (`parameterEntityFromRaw`), `sdk/mpr/writer_import_mapping.go` + `parser_import_mapping.go`, `modelsdk/mpr/serialize_mappings.go`", "insight": "`parameter Module.Entity` on the header, after the schema source. gen models **no** `ParameterType` property at all, so the modelsdk read goes to raw BSON — the route `customHandlerFromRaw` takes. **The legacy parser unmarshals a unit into `map[string]any`, so a nested sub-document arrives as `map[string]any`, NOT `bson.D`**: asserting `bson.D` compiles, always fails, and leaves DESCRIBE silently dropping the clause on the legacy engine only — caught solely by running the same assertions on both backends, so write that test. Two refusals, each with the guard stubbed and measured on mxbuild 11.13: `Param: parameter` with nothing declared is **CE0279** \"Parameter is used in object handling microflow while the mapping does not specify one\", and an unknown entity is refused by name. **Deliberately NOT guarded**: a parameter whose entity does not match the microflow's parameter type — mxbuild reports **CE0282** naming both types, and duplicating it in mxcli would need a generalisation-aware walk that could refuse valid specialisations. Check the whole thing over the BUILT model in `finishImportMapping`, not the AST, so the JSON-structure and message-definition builders are covered at once. Repro `mdl-examples/bug-tests/265-mapping-input-parameter.mdl`, tests `mdl/executor/mapping_parameter_test.go`. Issue #265", "refs": ["#265"], "ce": ["CE0279", "CE0282"]}
+{"area": "mdl/grammar", "date": "2026-08-25", "raw": "| A `find` mapping element always behaves as **find-or-create** whatever the document said, and `describe` cannot show the difference — a Studio Pro mapping that said \"error out\" comes back saying \"create silently\" | Mendix stores **two** properties on an object mapping element, not one: `ObjectHandling` {Parameter, Create, Find, Custom} and `ObjectHandlingBackup` {Create, Error, Ignore} (plus the bool `ObjectHandlingBackupAllowOverride`). mxcli only ever wrote the first and hardcoded the backup, so the runtime behaviour was mxcli's choice rather than the author's. Measured: rebuilding the shipped `Email_Connector.IMM_EmailTemplateMapping` flipped **7 elements from 'Error' to 'Create'**, with mxbuild reporting 0 errors on both — the documents are equally valid, they just do different things | `mdl/grammar/MDLLexer.g4` (`IGNORE`, `OVERRIDABLE`) + `mdl/grammar/domains/MDLDomainModel.g4` (`mappingHandlingBackup`) + `MDLSettings.g4` (keyword rule), `mdl/visitor/visitor_import_export_mapping.go` (`applyMappingHandlingBackup`), `mdl/executor/cmd_import_mappings.go` + `mapping_messagedefinition.go`, `mdl/backend/modelsdk/mapping_write.go` (`importBackupFor`) + `mapping_read.go`, `sdk/mpr/writer_import_mapping.go` + `parser_import_mapping.go`, `modelsdk/mpr/serialize_mappings.go` | `find M.E or create\\|error\\|ignore [overridable]`, with `find or create M.E` kept as the older spelling of the first. **A bare `find` is refused** — silently picking one of three runtime behaviours is the bug, so the executor names all three in the error rather than defaulting. Backups that are NOT the author's to choose: `create` and custom (`by`) handling keep 'Create', because \"Custom\" is not a member of the backup enum; **export** elements are always 'Error' (there is nothing to find), which is what Studio Pro writes. Two places the fix has to reach that a JSON-path test does not exercise: the **message-definition** builder (`mapping_messagedefinition.go`) has its own element construction, and it was the last 7 of the 8 fixture differences — a direct nested JSON test passed while the real document still regressed, so **diff the fixture, not a synthetic case**. The eighth was unrelated and adjacent: `xmlPrimitiveTypeName` fell through `Binary` to \"String\". Remember a `find` also needs a KEY (`Attr = member key`) or mxbuild reports **CE0250** \"Object element must have a key defined if object handling is set to 'Search for an object'.\" — pre-existing, but every repro of this fix trips it. Repro `mdl-examples/bug-tests/mapping-261-object-handling-backup.mdl`. Issue ako/mxcli#261 |", "refs": ["ako/mxcli#261"], "ce": ["CE0250"]}
+{"area": "mdl/grammar", "date": "2026-08-25", "symptom": "An import mapping cannot declare its INPUT OBJECT, so a custom handler's `Param: parameter` refers to something that cannot exist, and `describe` of a real one drops the declaration while still emitting the handler that uses it", "cause": "Mendix stores it as `ParameterType`, a `DataTypes$ObjectType` naming the entity. Measured across the demo apps: 10 of 327 mappings declare one (GenAICommons.ChunkCollection in eight), 190 import mappings store the `DataTypes$UnknownType` marker, and an EXPORT mapping carries no `ParameterType` property at all (0 of 127) — its parameter IS its root object, so there is no export spelling. All three writers hardcoded the UnknownType variant", "file": "`mdl/grammar/domains/MDLDomainModel.g4` (`importMappingParameterClause`), `mdl/visitor/visitor_import_export_mapping.go`, `mdl/executor/mapping_customhandler.go` (`resolveMappingParameter`, `requireDeclaredParameter`) + `cmd_import_mappings.go`, `mdl/backend/modelsdk/mapping_write.go` + `mapping_read.go` (`parameterEntityFromRaw`), `sdk/mpr/writer_import_mapping.go` + `parser_import_mapping.go`, `modelsdk/mpr/serialize_mappings.go`", "insight": "`parameter Module.Entity` on the header, after the schema source. gen models **no** `ParameterType` property at all, so the modelsdk read goes to raw BSON — the route `customHandlerFromRaw` takes. **The legacy parser unmarshals a unit into `map[string]any`, so a nested sub-document arrives as `map[string]any`, NOT `bson.D`**: asserting `bson.D` compiles, always fails, and leaves DESCRIBE silently dropping the clause on the legacy engine only — caught solely by running the same assertions on both backends, so write that test. Two refusals, each with the guard stubbed and measured on mxbuild 11.13: `Param: parameter` with nothing declared is **CE0279** \"Parameter is used in object handling microflow while the mapping does not specify one\", and an unknown entity is refused by name. **Deliberately NOT guarded**: a parameter whose entity does not match the microflow's parameter type — mxbuild reports **CE0282** naming both types, and duplicating it in mxcli would need a generalisation-aware walk that could refuse valid specialisations. Check the whole thing over the BUILT model in `finishImportMapping`, not the AST, so the JSON-structure and message-definition builders are covered at once. Repro `mdl-examples/bug-tests/mapping-265-mapping-input-parameter.mdl`, tests `mdl/executor/mapping_parameter_test.go`. Issue ako/mxcli#265", "refs": ["ako/mxcli#265"], "ce": ["CE0279", "CE0282"]}
+{"area": "mdl/grammar", "date": "2026-08-27", "symptom": "`describe {import,export} mapping` emits MDL its own grammar rejects, or — worse — MDL that parses and rebuilds a DIFFERENT mapping (measured: 132 of 327 did not parse, 112 parsed and were unfaithful)", "cause": "Four independent describer/grammar defects. (1) An OBJECT element could not take a nested member path (`= meta/pagination`); #927 gave that to VALUE elements only. (2) An Array or Wrapper printed as an EMPTY value binding with its whole subtree DROPPED, because the printer branched on `Kind == \"Object\"` alone — the export half was fixed under #268, the import half was not. (3) `create ./Entity = x` and `create . = x` for association-less and entity-less object elements, neither ever accepted. (4) Members MDL cannot spell bare — `$type` (43 occurrences), `research%3Aread`, `https%3A//…` — emitted raw", "file": "`mdl/grammar/domains/MDLDomainModel.g4` (`importMappingChild`, `exportMappingChild`), `mdl/visitor/visitor_import_export_mapping.go`, `mdl/executor/cmd_import_mappings.go` (`resolvePathKind`, `mappingMemberName`, `quoteMemberPath`, the two-level array branch) + `cmd_export_mappings.go`", "insight": "**An object path may step THROUGH an array where a value may not**: one object per item is legal, while a value pulled through many items is CE0256 — so the occurrence guard is keyed on `def.Entity != \"\"`, not applied to everything. Intermediate `(Object)`/`(Wrapper)` markers are dropped when printing and stepped through when resolving; they are generated levels, never written. The **two-level import array** (container and item each carrying their own entity and association) is detected the same way #262 detects it on export — an array whose single child is an object element — and the item is built BY HAND, because putting it through the generic builder tries to resolve the marker as a member. Building it by hand means remembering everything the generic path does: the first attempt dropped the item's own custom handler and its CE0281 value elements. **Item 4 needed no grammar at all** — `identifierOrKeyword` already accepts a quoted identifier, so only the describer had to quote; check what the grammar already allows before extending it. The entity-less IMPORT container was deliberately NOT given syntax: 0 of 12 pinned documents have one in either direction, and inventing a spelling whose stored shape cannot be checked against a real document is how a mapping ends up valid to mxbuild and unopenable in Studio Pro — DESCRIBE emits a comment naming it instead. **Alternative ORDER matters in the export rule**: `group` is a keyword `qualifiedName` accepts, so the bare-entity alternative placed before `GROUP AS` swallows `group as x` and stores an entity called \"Module.group\" — caught by TestExportGroupElement, not by any parse error. Repro `mdl-examples/bug-tests/mapping-260-describe-roundtrip.mdl`. Issue ako/mxcli#260", "refs": ["#262", "#268", "#927", "ako/mxcli#260"], "ce": ["CE0256", "CE0281"]}
+{"area": "mdl/grammar", "date": "2026-08-27", "raw": "| After ako/mxcli#260, ten of the 327 demo-app mappings still describe into MDL that does not parse — an export root printed as `. {`, and a custom-handler parameter printed as `Suggestion: (Value)` | Two leftovers of the same families. (1) `group as` covers a nested entity-less node (#262) but a ROOT has no member name, so it had no spelling at all. (2) `customHandlerParamText` rendered the stored value path raw, so an array-of-primitives parameter leaked Mendix's `(Wrapper)`/`(Value)` markers | `mdl/grammar/domains/MDLDomainModel.g4` (`exportMappingRootElement`), `mdl/executor/cmd_export_mappings.go` (the entity-less-root branch, and the association-less handling), `mdl/executor/mapping_customhandler.go` (`customHandlerParamText`, `buildCustomHandler`) | **Printing the member is only half of it**: emitting `Value` while the builder concatenates it back as `…|(Wrapper)|Value` gives a path that resolves to nothing, so resolve the parameter path THROUGH the schema index (`resolvePathKind(..., true)`) the way a member reference is resolved. Two things only a real build caught, both invisible to `mxcli check`: an entity-less root fell through to the VALUE branch and produced a project mxbuild cannot LOAD (*\"Type ExportValueMappingElement does not contain a constructor with a parameter of type ExportMapping\"*), because the builder decides object-vs-value on `def.Entity != \"\"`; and an element with NO association cannot be `Find` — **CE0224 \"No association selected for obtaining objects.\"** — it is `Parameter`, which is what CapitalConnector.EM_AttachedDataRequest stores on both its elements. Took the corpus from 317/327 parsing to **327/327**. Repro `mdl-examples/bug-tests/mapping-260b-last-parse-failures.mdl` |", "refs": ["#262", "ako/mxcli#260"], "ce": ["CE0224"]}
+{"area": "mdl/grammar", "date": "2026-08-28", "raw": "| A JSON structure's ARRAY ITEM element gets a derived name (`LinesItem`, `JsonObject`) that no MDL can change, and every mapping over the structure carries it — `describe` of a Studio Pro mapping then diffs on `ExposedName`. The obvious workaround, `custom name map ('lines\\|(Object)' as 'OrderLine')`, parses, executes and does **nothing** | An array's item is the anonymous `[…]` entry, so it has no JSON key; `customNameMap` is keyed on JSON keys, so the item was unreachable by construction. And an entry matching no key was applied to nothing and reported nothing, so the failed workaround was indistinguishable from success | grammar `mdl/grammar/domains/MDLDomainModel.g4` (`customNameMapping` gains `ITEM OF`), `mdl/ast/ast_jsonstructure.go` (`CustomItemNameMap`), `mdl/visitor/visitor_jsonstructure.go`, `mdl/types/json_utils.go` (`snippetBuilder.itemName`, `SnippetKeys`), `mdl/executor/cmd_jsonstructures.go` (`collectCustomItemNames`, DESCRIBE), `mdl/executor/validate_json_structure_names.go` (`MDL-JSON01`/`MDL-JSON02`) | **Do NOT infer Studio Pro's generation rule from stored documents — they are hand-edited.** Measured across 621 array elements in nine apps: 61% are the generator's `JsonObject`/`Wrapper`[+counter], 35% are a word someone chose, 4% are `<Name>Item`. The fingerprint that settles it is `JSON_AutoConfigResponse`, whose eight arrays read *in document order* `Scope, Wrapper_2..Wrapper_6, Claim, CodeChallengeMethods` — a counter with **gaps where a human renamed**; and `JSON_SensorData`'s `Array → SensorData`, a name with no relation to the array's. A version story fitted to a 9-structure sample (\"10.24 singularises, 11.4 does not\") evaporated at corpus scale. So the fix is **expressiveness, not default-matching**: no default can match a corpus that is a third hand-written, and changing the default would rewrite every stored structure's item names plus every mapping bound to one (ExposedName is a resolution key, #882). Design notes: `item of 'key' as 'Name'` rather than folding it into the existing entry, so naming an item does not require restating the array's name and adding one is a one-line diff; the same clause names a primitive array's **Wrapper**, because that wrapper IS the item; `item of 'Root'` for a root array, which has no key. DESCRIBE needs its own collector — an item's path segment is the marker `(Object)`/`(Wrapper)`, so the existing one skips it, and without it a named item was written on CREATE and silently renamed back by describe → exec. ako/mxcli#272 |", "refs": ["#882", "ako/mxcli#272"]}
+{"area": "mdl/grammar", "date": "2026-08-31", "symptom": "`DESCRIBE MICROFLOW` emits `reduce($list, expr)` (or `all(...)` / `any(...)`) and mxcli's own checker then rejects its own output: \"set 'X' calls 'reduce()', which is not a Mendix expression function [MDL044]\". Note the word **set** — the parser did not reject the call, it read the line as a Change Variable whose value happened to be a function call, and MDL044 was right about the rest", "cause": "DESCRIBE rendered an aggregate as `strings.ToLower(storedEnumValue)`, assuming every value of Mendix's `AggregateFunction` was also an MDL keyword. Mendix has eight, the grammar had five. Underneath sat a quieter defect: Mendix stores a Reduce's seed and result type in `ReduceInitialValueExpression` / `ReduceReturnDataType` and the semantic model had no field for either, so a grammar-only fix would have round-tripped the syntax while deleting the fold", "file": "`mdl/grammar/MDLLexer.g4` (REDUCE/ANY/INITIAL + the `keyword` rule so they stay usable as identifiers), `mdl/grammar/domains/MDLMicroflow.g4` (`listAggregateOperation` + `reduceFoldOptions`), `mdl/ast/ast_microflow.go`, `mdl/visitor/visitor_microflow_actions.go`, `mdl/executor/cmd_microflows_builder_actions.go`, `mdl/executor/cmd_microflows_format_action.go` (`mdlAggregateKeyword`), plus all four read/write paths: `sdk/mpr/parser_microflow.go`, `sdk/mpr/writer_microflow_actions.go`, `mdl/backend/modelsdk/microflow_read_actions.go`, `mdl/backend/modelsdk/microflow_write.go`", "insight": "**A renderer that stringifies an enum outgrows its grammar silently** — the sibling `formatListOperation` switches on concrete types and cannot, which is the shape to prefer. The guard is a describe→parse loop over `microflows.AllAggregateFunctions` (`TestDescribedAggregateParsesBack`), so a ninth Mendix function fails a test rather than a user's script. **Get a reference document before believing the vendor docs**: Mendix's reference guide says a return type is \"not applicable\" to All/Any, but Studio Pro writes `ReduceReturnDataType` as Boolean on both, and `Attribute` as `\"\"` when unused — all three activities now re-serialize byte-identically to Studio Pro's. `mx check` is no help here (0 errors before and after); the controls are the origin/main parse (`reduce`/`all`/`any` → Change Variable, with `sum` → aggregate as the positive control) and reverting the write path (`TestReduceFoldReachesStorage` then reports the two keys missing). #1004", "refs": ["#1004"], "rules": ["MDL044"]}
diff --git a/.claude/skills/fix-issue/findings/mdl-other.jsonl b/.claude/skills/fix-issue/findings/mdl-other.jsonl
new file mode 100644
index 0000000000..7dc32ef07d
--- /dev/null
+++ b/.claude/skills/fix-issue/findings/mdl-other.jsonl
@@ -0,0 +1,52 @@
+{"area": "mdl/settingsoverlay", "date": "2026-07-30", "symptom": "Any `ALTER SETTINGS` (any section) reports success but the Default configuration's **Custom settings** are gone, **Tracing** is reset, and every **constant override** shows blank in Studio Pro — Integer/Long constants then fail the build", "cause": "The configuration was re-serialized from `model.ServerConfiguration`, which carries only the modelled fields, so CustomSettings/Tracing/OpenAdminPort/OpenHttpPort were dropped, the list version markers downgraded 3→2, and overrides were written with a flat `Value` instead of the nested `SharedOrPrivateValue` the platform reads", "file": "`mdl/settingsoverlay/settingsoverlay.go` (`Configurations`, `ServerConfiguration`, `ConstantValues`) — called by both `mdl/backend/modelsdk/settings_write.go` and `sdk/mpr/writer_settings.go`", "insight": "Overlay onto the raw document instead of rebuilding: write only the fields the read path populates, take each list's marker from what is stored, and update a constant override in the slot it already occupies (nested if nested, flat if flat). New override → nested. New configuration → clone a sibling's shape, empty its collections, mint a fresh `$ID`. Refuse the write when `RawParts` is empty. Repro `mdl-examples/bug-tests/801-alter-settings-preserves-configuration.mdl`. Issue #801", "refs": ["#801"]}
+{"area": "mdl/linter", "date": "2026-07-31", "symptom": "A custom Starlark lint rule can't detect a **microflow-datasource** widget (e.g. a ListView with no DB pushdown) — `widget.microflow_ref` is unavailable, so a rule keyed on it returns zero hits at any threshold, even though `CATALOG.WIDGETS.MicroflowRef` is populated", "cause": "The linter's `Widget` projection (struct + `Widgets()` query + Starlark dict) dropped `MicroflowRef`/`NanoflowRef` — the catalog records them but they never reached the rule tier", "file": "`mdl/linter/context.go` (`Widget` struct, `Widgets()` SELECT+Scan) + `mdl/linter/starlark.go` (`widgetToStarlark`)", "insight": "Carry `MicroflowRef`/`NanoflowRef` through from the catalog and expose `microflow_ref`/`nanoflow_ref` on the Starlark widget struct (mirroring `entity_ref`). Doc: `.claude/skills/mendix/write-lint-rules.md` widget field table. Test `TestWidgets_ProjectsMicroflowNanoflowRef`. traceops #35", "refs": ["#35"]}
+{"area": "mdl/linter", "date": "2026-07-01", "symptom": "`mxcli report` (and `lint`) hangs for many minutes on a large project — appears to deadlock after \"Catalog ready\", 130-byte banner-only output, process pinned at ~140% CPU (not blocked → not a lock deadlock)", "cause": "O(N²) BSON re-decode: six lint rules loop `for mf := range ctx.Microflows()` and call `reader.GetMicroflow(mf.ID)` per microflow, but the modelsdk backend's `GetMicroflow` re-lists and re-decodes EVERY microflow unit on each call. N calls × N decodes → millions of full BSON parses. Diagnose with `kill -QUIT <pid>` (GOTRACEBACK=all) — the running-goroutine stack names the stuck rule + `ListUnitsWithContainer`", "file": "`mdl/linter/context.go` (`FullMicroflow`, `LintReader`) + the six rules (`validation_feedback`, `conv_loop_commit`, `conv_split_caption`, `conv_error_handling`×2, `mpr008_overlapping_activities`)", "insight": "Add `LintContext.FullMicroflow(id)` — loads ALL microflows once via `ListMicroflows()` and serves lookups from a per-run cache (safe: lint is read-only). Swap every `reader.GetMicroflow(mf.ID)` in a loop to `ctx.FullMicroflow(mf.ID)`. Turns O(N²) into O(N); report went from >40min hang to ~5s on 3259 microflows. Issue #720", "refs": ["#720"]}
+{"area": "mdl/types", "date": "2026-06-20", "symptom": "Studio Pro crashes on export/upgrade/Save-As with `System.InvalidOperationException: Null value found in primitive property 'ImageDataStorage' of object of type 'Mendix.Modeler.CodeActions.MicroflowActionInfo'` after a Java action was created via MDL `exposed as … in …` (project opens fine; only re-serialization crashes)", "cause": "The `MicroflowActionInfo` sub-document was written in the legacy shape: `$Type` = `JavaActions$MicroflowActionInfo`, an obsolete `Icon` key, and the four icon/image bitmaps null or absent. Mendix maps `ImageData`→ the mandatory binary `ImageDataStorage`; a null/absent value crashes `UnitWriter`. **Both engines** were wrong: legacy `sdk/mpr` emitted `ImageData: null`; the default modelsdk engine used `gen/javaactions.MicroflowActionInfo` (also legacy `$Type`, no binary fields)", "file": "struct `mdl/types/javaaction_types.go` + legacy `sdk/mpr/writer_javaactions.go` (`microflowActionInfoBSON`) + `sdk/mpr/parser_javaactions.go` (`parseMicroflowActionInfo`, shared with `parser_misc.go` JS actions) + modelsdk `mdl/backend/modelsdk/java_write.go` (`patchMicroflowActionInfo`) + reads `mdl/backend/modelsdk/javascript_read.go`", "insight": "Replace `Icon string`/`ImageData string` in the struct with four `[]byte` (`IconData`/`IconDataDark`/`ImageData`/`ImageDataDark`). Emit `$Type` = `CodeActions$MicroflowActionInfo` with all four as **empty-non-null** binaries (`primitive.Binary{Subtype:0, Data:[]byte{}}`), no `Icon`. Parser reads the four binaries and **tolerates** the legacy null/`Icon` shape so corrupted units load and self-repair on rewrite. The modelsdk gen models these bitmaps as `Primitive[string]` (serialises to BSON string, can't emit `binary(0)`), so leave the gen MAI null and post-patch the top-level `MicroflowActionInfo` field via `codec.PatchBSONField` instead of editing generated code. Verify by decoding the written `.mxunit` under both engines (`grep -rlF 'MicroflowActionInfo' mprcontents/`). Issue #656", "refs": ["#656"]}
+{"area": "mdl/ast", "date": "2026-06-23", "symptom": "`CREATE JAVA ACTION`/`CREATE JAVASCRIPT ACTION` with an `Enumeration(Mod.Enum)`/`ENUM Mod.Enum` parameter or return type passes check+exec but `mxbuild`/Studio Pro fails: `Property 'Entity' of Java action parameter '…': The selected entity 'Mod.Enum' no longer exists`", "cause": "The param/return converter mapped `ast.TypeEnumeration` to an `EntityType` (entity ref), because the parser records both a bare `Module.Name` *and* the explicit `ENUM`/`Enumeration(...)` syntax as `TypeEnumeration` with no distinguishing flag, and `EnumerationType` was never emitted/serialized", "file": "AST `mdl/ast/ast_datatype.go` (`ExplicitEnum`) + visitor `mdl/visitor/visitor_helpers.go` (`buildDataType`) + converter `mdl/executor/cmd_javaactions.go` (`astDataTypeToJavaActionParamType`/`…ReturnType`) + writers `sdk/mpr/writer_javaactions.go` (`serializeInnerType`/`serializeReturnType`) and `mdl/backend/modelsdk/java_write.go` (`codeActionInnerTypeToGen`/`codeActionReturnTypeToGen`) + reads `parser_javaactions.go` (already) / `mdl/backend/modelsdk/java_read.go`", "insight": "Add `ExplicitEnum bool` to `ast.DataType`, set it in the `ENUM`/`Enumeration(...)` branch of `buildDataType` (a bare `Module.Name` stays ambiguous → entity). When `ExplicitEnum`, the converter emits `javaactions.EnumerationType{Enumeration: qn}`; both writers serialize `CodeActions$EnumerationType` (param wrapped in `BasicParameterType`) with the `Enumeration` by-name ref; modelsdk uses `genCa.NewEnumerationType().SetEnumerationQualifiedName(...)`. The legacy parser already read it; add the gen `*genCa.EnumerationType` case to the modelsdk read converters so DESCRIBE round-trips. Validate by decoding the `.mxunit` and `mx check` (build passes only after the fix). Issue #680", "refs": ["#680"]}
+{"area": "mdl/catalog", "date": "2026-07-10", "symptom": "`MOVE ENUMERATION … TO FOLDER` prints \"Moved … to new location\" but `DESCRIBE ENUMERATION` and `CATALOG.ENUMERATIONS.Folder` still show the module root (looks like a silent no-op)", "cause": "**NOT a write bug** — the move persists (the enum's `Unit.ContainerID` becomes the folder; `show enumerations` shows it correctly). Two *read* paths misreported it: (1) `buildEnumerations` hardcoded the catalog Folder to the module name (`// Folder as module name for now`) instead of `buildFolderPath` — same latent bug in `builder_microflows.go`/`builder_rest.go`/nanoflows; (2) DESCRIBE ENUMERATION emitted no `FOLDER` clause (unlike DESCRIBE PAGE), and CREATE ENUMERATION had no folder grammar to round-trip one", "file": "catalog `mdl/catalog/builder_modules.go` (+ microflows/rest) + grammar `MDLDomainModel.g4` (`enumerationOption` `FOLDER`) + AST `ast_enumeration.go` (`Folder`) + visitor `visitor_enumeration.go` + executor `mdl/executor/cmd_enumerations.go` (`execCreateEnumeration` via `resolveFolder`, `describeEnumeration` emit)", "insight": "Catalog: replace hardcoded `moduleName` Folder with `b.hierarchy.buildFolderPath(x.ContainerID)`. Grammar: add `FOLDER STRING_LITERAL` to `enumerationOption` (parity with pages' `Folder:`); place the enum via the shared `resolveFolder(ctx, moduleID, folder)`; DESCRIBE emits `) FOLDER 'path';` when `BuildFolderPath != moduleName`. **Diagnosis tip**: when a MOVE \"doesn't persist,\" check the raw `Unit.ContainerID` and `show <type>` before assuming a write bug — a hardcoded catalog column or a missing DESCRIBE clause is a read-path illusion (cf. #722). Bug-test `bug12b-enumeration-folder.mdl`; tests `TestCreateEnumerationFolderCaptured`. Bug 12b", "refs": ["#722"]}
+{"area": "mdl/exprcheck", "date": "2026-07-03", "symptom": "`set $IntVar = $a * 100 div $b;` (or `declare $I Integer = $a div $b;`) passes `mxcli check` but `mx check` rejects it with **CE0117** — Mendix integer division (`div`) yields a Decimal, so the target must be Decimal (or the result rounded)", "cause": "`mxcli check`'s expression checker (`mdl/exprcheck`) was only wired into the Starlark linter, not `mxcli check`, and `inferKind` didn't type arithmetic operators (`div`/`*`/`-`/`mod` fell through to `KindUnknown`); nothing compared a SET/declare value's kind against the Integer/Long target", "file": "`mdl/exprcheck/parser.go` (`inferKind` + `arithResult`), `mdl/exprcheck/infer.go` (`InferSourceKind`, `SourceIsArithmeticDecimal`), `mdl/executor/validate_microflow.go` (`ValidateMicroflow` → MDL041)", "insight": "Type `div`→Decimal and propagate Decimal through `+`/`-`/`*`/`mod` (`arithResult`); add **MDL041** in `ValidateMicroflow` (runs in syntax-only `check`, no project) flagging a Decimal-valued *arithmetic* expression assigned to an Integer/Long var. Narrow to arithmetic roots only via `SourceIsArithmeticDecimal` — a rounding-function result (`round(sqrt($x))`, `floor($a div $b)`) is accepted by Mendix into an Integer and must NOT be flagged (that was a false positive on `04-math-examples.mdl`). Tests: `mdl/exprcheck/infer_test.go`, `mdl/executor/validate_microflow_div_test.go`", "ce": ["CE0117"], "rules": ["MDL041"]}
+{"area": "mdl/types", "date": "2026-07-09", "symptom": "**DataGrid2** (`datagrid`) columns fail MxBuild **CE0463** \"widget definition changed\" on the **default (modelsdk)** engine — reported for custom-content columns, but actually **every** column (attribute too). Legacy is fine", "cause": "The column WidgetObject's `Properties` were serialized in **alphabetical** order (`alignment, allowEventPropagation, attribute, …`) instead of the template's `PropertyTypes` order (`showContentAs, attribute, content, dynamicText, …`). Studio Pro hashes the object structure against the type and flags CE0463 on any order mismatch. Cause: the object-list item builder (`mdl/backend/widgetobj/builder.go:274`) orders by `NestedKeyOrder`, falling back to alphabetical when empty; the **modelsdk** registry loader never captured it (`types.PropertyTypeIDEntry` had no such field), while the MPR/legacy loader did → legacy correct, modelsdk broken. Top-level widget props were unaffected (ordered by a different path), which is why only the nested column object-list broke", "file": "`mdl/types/widget_property_type.go` (`PropertyTypeIDEntry.NestedKeyOrder`) + `modelsdk/widgets/loader.go` (thread `nestedKeyOrder` through `jsonValueToBSONWithNestedObjectType`→`extractNestedObjectType`→`extractNestedPropertyTypes`, append in template array order) + `mdl/backend/modelsdk/widget_pluggable_write.go` (`convertPropTypeIDs` copies `NestedKeyOrder`)", "insight": "Mirror the `sdk/widgets` loader's existing `nestedKeyOrder` capture in the parallel `modelsdk/widgets` loader (dedup on first occurrence, append in PropertyTypes array order), add the field to `types.PropertyTypeIDEntry`, and copy it in the modelsdk `convertPropTypeIDs`. **Diagnose column-order CE0463 by mapping each column WidgetProperty's `TypePointer` → the type's `WidgetPropertyType.PropertyKey` and comparing the sequence to the template's PropertyTypes order.** Verified: modelsdk column order now equals the template (and legacy) order for both attribute and custom-content columns, and **`mxcli docker check --no-update-widgets` (raw output, no widget normalization) = 0 errors** for the report's exact pattern (attribute column + custom-content dynamictext-over-association + custom-content actionbutton with `show_page`). The custom-content child-widget subtree needed no separate fix — ordering was the whole cause. Tests: `modelsdk/widgets/nested_key_order_test.go`; bug-test `mdl-examples/bug-tests/datagrid2-custom-content-column.mdl`. **To validate CE-class MxBuild errors locally: `mxcli setup mxbuild -p app.mpr --force` then `mxcli docker check -p app.mpr --no-update-widgets`** (the `--no-update-widgets` is essential — the default runs `mx update-widgets` which auto-normalizes pluggable widgets and masks a real CE0463)", "ce": ["CE0463"]}
+{"area": "mdl/ast", "date": "2026-07-09", "symptom": "A standard widget's generic property written in **lowercase** (e.g. `dynamicclasses:` instead of `DynamicClasses:`) is silently dropped on write, though the canonical-case form persists. Documented lowercase examples (`create-page.md`) don't work", "cause": "Generic (non-tokenized) widget properties are stored in `WidgetV3.Properties` under the **user's original casing** (`visitWidgetProperty` generic branch: `Properties[id.GetText()]`). The builder reads appearance props via `GetStringProp(\"DynamicClasses\")` — an exact-case map lookup — so a lowercased key never matched. MDL property names are documented case-insensitive (mirrors `lookupProperty` in the widget engine, used by the pluggable path)", "file": "`mdl/ast/ast_page_v3.go` (`GetStringProp`)", "insight": "Make `GetStringProp` case-insensitive: exact-match fast path, then a lowercased scan (mirrors `lookupProperty`). Fixes any generic-stored standard-widget property read via `GetStringProp`/`GetDynamicClasses`, not just DynamicClasses. Test: `mdl/ast/ast_page_v3_getprop_test.go`; same bug-test as 10a. Bug 10b"}
+{"area": "mdl/exprcheck", "date": "2026-07-25", "symptom": "A microflow expression calls a function that doesn't exist (e.g. `randomInt(9)` — in some docs but not a Mendix built-in): parses, passes `mxcli check`, then fails the build with CE0117 \"Error(s) in expression\". Also: a Decimal-returning function (`random()`, `secondsBetween`, the duration `*Between` family) assigned to an Integer/Long variable fails CE0117, but `mxcli check` only caught bare `div`", "cause": "(1) The func checker only validated arity for *known* functions; an unknown call name was ignored. (2) `checkNumericAssignment` used `SourceIsArithmeticDecimal`, which fires only on arithmetic roots, so a Decimal *function* result slipped through. Also the `*Between` duration funcs were mistyped Integer in `funcTable`", "file": "`mdl/exprcheck/unknown_funcs.go` (`UnknownFunctionCalls`, `SourceRejectedForIntegerTarget`, `nearestFunc`) + `mdl/exprcheck/func_checker.go` (`funcTable` between-date return kinds) + `mdl/executor/validate_microflow.go` (`checkExprFunctions` → MDL044; `checkNumericAssignment` now uses `SourceRejectedForIntegerTarget`)", "insight": "Walk each expression for `CallExpr` names not in `funcTable` (which lists *every* built-in — a bare `name(...)` is always a built-in call) → **MDL044** with a Levenshtein/prefix \"did you mean\" hint. Extend the Decimal-into-Integer check to Decimal-returning non-rounding functions → **MDL041**. Correct `secondsBetween`/`minutesBetween`/`hoursBetween`/`daysBetween`/`weeksBetween` to Decimal (calendar variants stay Integer, millisecondsBetween stays Long). When adding a new Mendix built-in, add it to `funcTable` or MDL044 will false-positive. Bug-tests `f1-unknown-expression-function.fail.mdl`, `f2-decimal-func-into-integer.fail.mdl`. Findings #1, #2", "refs": ["#1", "#2"], "ce": ["CE0117"], "rules": ["MDL041", "MDL044"]}
+{"area": "mdl/settingsoverlay", "date": "2026-08-01", "symptom": "Any `ALTER SETTINGS` / `CREATE CONFIGURATION` corrupts a **private** constant override: the stored `Settings$PrivateValue` comes back carrying `\"Value\": \"\"`. Studio Pro then throws `System.InvalidOperationException: Sequence contains no matching element` at `MprProperty.cs:25` on open. `describe settings` separately renders the override as `value ''`, so replaying describe's own output converts it to a *shared* empty override", "cause": "A constant override's value is either a `Settings$SharedValue` (carries `Value`, lives in the shared model) or a `Settings$PrivateValue` — a **marker type with no properties at all**, meaning the value is on the developer's workstation and deliberately out of version control. The overlay assumed SharedValue and wrote `cv.Value` (always `\"\"` for a private override) into whichever node it found; the read type-asserted to `*SharedValue`, failed, and returned `\"\"` with no way to distinguish private from empty", "file": "`mdl/settingsoverlay/settingsoverlay.go` (`constantValue`, `PrivateValueType`), `mdl/backend/modelsdk/settings_read.go` (`isPrivateConstantValue`), `sdk/mpr/parser_settings.go` (`parseConstantValue`), `mdl/executor/cmd_settings.go` (`describeSettings`, `alterSettingsConstant`)", "insight": "Carry the distinction in the model (`model.ConstantValue.IsPrivate`) and **preserve, never author**: leave a PrivateValue node byte-identical, have `describe` emit a comment instead of a re-executable statement, and refuse an `alter settings constant` that would flip private→shared (drop is still allowed — it discards the whole override, which is what was asked). **Generalisable**: a polymorphic child whose variants differ in *arity* (one carries a value, one is a bare marker) cannot be overlaid by field assignment — branch on `$Type` first. Blast radius is wider than it looks: configurations are shared in version control, so one developer's unrelated edit corrupts every developer's private overrides and pushes the result. Found from a user describing their workflow, not from a filed issue"}
+{"area": "mdl/ast", "date": "2026-08-07", "symptom": "A typo in an OData property — `ReadMicroflow:` for `ReadMode:`, `ServiceNam:` for `ServiceName:` — passes `mxcli check` and `exec` reports success, but the model does not have the property. Hours can go into wondering why a published resource ignores its read microflow", "cause": "The grammar accepts any `name: value` pair inside an OData property list, and the visitor's `switch` had no `default` — so an unrecognised name was dropped between parse and AST. The ALTER path has always answered `\"unknown OData service property: %s\"`; CREATE, PUBLISH ENTITY, the client and the external entity had nothing", "file": "`mdl/ast/ast_odata.go` (`UnknownProperties` on four statements), `mdl/visitor/visitor_odata.go` (four `default:` arms), `mdl/executor/validate_odata_properties.go` (`ValidateODataProperties`, MDL-ODATA01), wired in `cmd/mxcli/cmd_check.go`", "insight": "The visitor is where the name is lost, so the visitor is where it must be recorded — a validator over the AST alone cannot see a key that was already discarded. Carry it as `UnknownProperties` and report at check time, before anything is written. The message names the property AND guesses the intended one (prefix/substring, then one edit), because a bare known-property list still leaves the reader diffing two spellings by eye. **Correction to the report**: `Pagesize:` is *not* silently dropped — the visitor lowercases before matching, so casing is never a typo, and the test pins that. Verified against every `mdl-examples/**/*.mdl` for false positives (0). Tests `mdl/executor/validate_odata_properties_test.go`. mxcli-formula1 suggested issue 8"}
+{"area": "mdl/ast", "date": "2026-08-07", "symptom": "A read-microflow-backed OData resource must declare a `System.ODataResponse` parameter and compute a count, even when the count is expensive (a full CSV scan) and nobody asked for it — with no MDL to say otherwise. Same for `$skip`/`$top` support", "cause": "`Countable`, `SkipSupported` and `TopSupported` were written as literal `true` in the BSON writer's `ODataPublish$QueryOptions`; nothing above the writer could express them", "file": "`mdl/ast/ast_odata.go` + `mdl/visitor/visitor_odata.go` (`*bool` on `PublishedEntityDef`, `odataBoolPtr`), `model/types.go`, `mdl/executor/cmd_odata.go` (`astEntityDefToModel`), `mdl/backend/modelsdk/odata_write.go` (`boolOrDefault`), `odata_read_detail.go` (`falseOnly`)", "insight": "Tri-state (`*bool`) is load-bearing: these default to **true**, so \"unset\" and \"false\" cannot share a representation or every existing script would silently turn them off. The reader maps a stored `true` back to nil (`falseOnly`) so DESCRIBE prints only what the author wrote instead of three defaults on every resource. Verified end to end on 11.12.1: `Countable: No` + a read microflow with **no** `$Response` parameter builds 0 errors, which is exactly the combination that was impossible before. Tests `cmd_odata_query_options_test.go`, `odata_write_test.go`. mxcli-formula1 #10.3", "refs": ["#10"]}
+{"area": "mdl/ast", "date": "2026-08-08", "symptom": "`execute database query … dynamic $Sql` reaches the runtime as the literal string `'$Sql'` — `Parser Error: syntax error at or near \"$\"` from the database, not from Mendix. Runtime-built SQL, and therefore query pushdown, is impossible", "cause": "The builder quoted any dynamic query not already starting with a quote — right for `dynamic 'SELECT …'`, wrong for an expression — and the AST kept one `DynamicQuery` string whichever branch of the grammar produced it, so nothing downstream could tell them apart", "file": "`mdl/ast/ast_microflow.go` (`DynamicQueryIsExpression`), `mdl/visitor/visitor_microflow_actions.go` (set it in the `expr` branch), `mdl/executor/cmd_microflows_builder_calls.go` (`dynamicQueryExpression`)", "insight": "**When a grammar has two alternatives that mean different things, the AST must record which one fired** — a shared field plus a \"does it look quoted?\" heuristic is a guess, and the workaround users find (`dynamic '' + $Sql`, which starts with a quote so the heuristic leaves it alone) is proof the heuristic is the bug. Verified by reading the stored BSON rather than by describe: `DynamicQuery\\x00\\x05\\x00\\x00\\x00$Sql` — five bytes, no quotes. Tests `cmd_microflows_dynamic_query_test.go`. mxcli-formula1 #21", "refs": ["#21"]}
+{"area": "mdl/types", "date": "2026-08-08", "symptom": "`create external entities from` a contract that restricts capabilities produces a project that will not build: `'Seasons' is marked Countable=False in the OData service, but True in the app`, `'latitude' is marked Filterable=False …` — one per restricted resource or property", "cause": "Insert/Update/Delete restrictions were parsed; **Count/Filter/Sort were not**, so the import had nothing to honour and defaulted all three to true — on the one command whose entire job is fidelity to the contract", "file": "`mdl/types/edmx.go` (`EdmEntitySet.Countable`, `NonFilterableProperties`, `NonSortableProperties` + the three `applyCapabilityAnnotations` arms), `mdl/executor/cmd_contract.go`", "insight": "An unannotated set still means countable/filterable/sortable — **silence in a contract is not a restriction**, it is OData's own default, so `nil` and `false` must stay distinguishable (`*bool`, as with the publish-side query options). The generated entity is compared against the contract at *build* time, so anything the contract can say is something the importer must be able to read. Tests `mdl/types/edmx_test.go`. mxcli-formula1 #24", "refs": ["#24"]}
+{"area": "mdl/ast", "date": "2026-08-09", "symptom": "`authentication microflow Module.Auth` on a published OData service parses, checks clean and reports `Created OData service` — then the build fails **CE0333** \"Please select a microflow to use for authentication\", and `DESCRIBE` shows `authentication Microflow` with no name. Custom authentication is unreachable from MDL, which matters because it is the only way to avoid a full BCrypt hash on every OData request (60–80% of a page turn measured)", "cause": "The grammar had accepted `MICROFLOW qualifiedName?` all along and both writers already serialized `AuthenticationMicroflow` from `svc.AuthMicroflow` — but nothing ever *assigned* it. `parseODataAuthTypes` recognised the `microflow` keyword and discarded the name, so the field was only ever populated by reading a model Studio Pro wrote. DESCRIBE then emitted it as a comment (`-- Auth Microflow: …`), so a custom-auth service could not round-trip either", "file": "`mdl/ast/ast_odata.go` (`AuthMicroflow`), `mdl/visitor/visitor_odata.go` (`parseODataAuthTypes` returns the name), `mdl/executor/cmd_odata.go` (assign on create AND modify; `odataAuthClause` for DESCRIBE), `mdl/executor/validate_odata_auth.go` (MDL-ODATA04)", "insight": "**When a feature \"silently drops\" one field, check whether the plumbing already exists at both ends** — here only the middle assignment was missing, so the fix was ~10 lines across four files rather than a new write path. The grammar already parsed the name: `at.QualifiedName()` was simply never read. **DESCRIBE emitting a value as a comment is the same defect class as dropping it** (§39): the output looks complete and replays into a model the build rejects — so the round-trip test asserts the emitted clause re-parses to the same microflow, not that it contains some text. Two Mendix rules bound the feature and are easy to hit while verifying: **CE0333** if no microflow is named (now MDL-ODATA04 at check time), and **CE6600** \"App security is off, but custom authentication is enabled\" — so a fixture project needs `alter project security level prototype` before it can prove anything. That second one is why this is NOT in the doctype gate: those projects run with security off, so any custom-auth service there fails CE6600 regardless of correctness. Verified instead by writing the service from MDL into a real project and running `mx check` (0 errors). Tests `mdl/executor/odata_auth_microflow_test.go`. mxcli-formula1 §40", "ce": ["CE0333", "CE6600"]}
+{"area": "mdl/types", "date": "2026-08-09", "raw": "| A service that correctly declares `TopSupported: No` cannot be consumed: `sql <alias> generate connector` / contract import produces an app whose external entity says `Supports $top = True`, and the **consumer** build fails **CE6630** \"'Seasons' is marked supports $top=False in the OData service, but True in the app\". The publisher is right, the contract is right, and only the generated consumer is wrong | Two layers, and the first hid the second. `applyCapabilityAnnotations` began with `if ann.Record == nil { continue }` — but `TopSupported`/`SkipSupported` are **standalone boolean terms** (`<Annotation Bool=\"false\" Term=\"Org.OData.Capabilities.V1.TopSupported\"/>`), not the record shape that `InsertRestrictions` and friends use, so the parser discarded them and `EdmEntitySet` had no field to hold them. `applyExternalEntityFields` then hardcoded `ent.SkipSupported = true; ent.TopSupported = true` — directly beside `Countable`, which *was* derived, and under a comment explaining the CE6630 mechanism the hardcode went on to trigger | `mdl/types/edmx.go` (`EdmEntitySet.TopSupported`/`SkipSupported`, `xmlCapabilitiesAnnotation.Bool`, standalone branch in `applyCapabilityAnnotations`), `mdl/executor/cmd_contract.go` (`applyExternalEntityFields`) | **The OData capabilities vocabulary has two annotation shapes, and a parser written against one silently drops the other.** Record terms (`InsertRestrictions`, `CountRestrictions`) wrap a `<Record>`; scalar terms (`TopSupported`, `SkipSupported`) carry `Bool` on the annotation element itself. The `Record == nil` guard read as \"malformed, skip\" when it actually meant \"different, valid shape\" — grep any capability parser for that guard before adding a term. **Absent must stay `true`, not `false`**: OData's own default is supported, so a tri-state `*bool` resolved as `p == nil || *p` is load-bearing — defaulting to false would invert CE6630 for every unannotated service, i.e. every service that worked before the fix. **This is the prerequisite for MDL-ODATA03's advice being followable**: the rule tells an author to declare `TopSupported: No` on a read-microflow resource, which was previously a trap that broke consumers. A fixture for this is worth capturing from a live `$metadata` rather than hand-written — the standalone shape is what made the bug, so a hand-built record-shaped fixture would have tested the wrong thing. Tests `mdl/types/edmx_test.go` (`TestParseEdmx_StandaloneTopAndSkipSupported`, plus a control proving record terms still parse), `mdl/executor/cmd_contract_capabilities_test.go`. mxcli-formula1 §42 |", "ce": ["CE6630"]}
+{"area": "mdl/types", "date": "2026-08-09", "symptom": "`create external entities from` a service where an entity set is wholly unfilterable/unsortable generates an app the contract contradicts: **28 × CE6630** on one service — \"'message' is marked Sortable=False in the OData service, but True in the app\". The publisher is right, the `$metadata` is right, only the generated consumer is wrong", "cause": "`FilterRestrictions`/`SortRestrictions` have **two shapes**, and only one was read. `applyCapabilityAnnotations` pulled `NonFilterableProperties` out of the record and ignored the record's own `Bool` property value, so `Filterable: !nonFilterable[p.Name]` evaluated `true` for every property of a set that had declared nothing filterable. This is the §42 Top/Skip bug one layer along — same vocabulary, same two-shapes cause, different term", "file": "`mdl/types/edmx.go` (`EdmEntitySet.Filterable`/`Sortable`, the `Filterable`/`Sortable` cases in `applyCapabilityAnnotations`, and the `AttrFilterable`/`AttrSortable` accessors), `mdl/executor/cmd_contract.go` (`createExternalEntities` calls the accessors)", "insight": "**Mendix picks the annotation shape by arithmetic, not preference.** It lists `NonFilterableProperties` when SOME attributes are filterable and emits a bare `<PropertyValue Bool=\"false\" Property=\"Filterable\"/>` when NONE are, because then there is no list to write — so both shapes appear in **one document** on different entity sets, and an entity exposing only a KEY reliably produces the whole-set form. A fixture with just the list shape tests the half that already worked. **After fixing one term in a vocabulary, sweep the siblings**: §42 fixed Top/Skip by teaching the parser about standalone booleans and stopped there; Filterable/Sortable had the same defect and were found only because a consumer app failed to build. Grep the whole `applyCapabilityAnnotations` switch for terms whose Bool is never read. **Put both shapes behind one accessor** (`AttrFilterable`) rather than two fields the caller must remember to AND together — the caller then cannot consult one and forget the other, which is exactly how this arose, and the nil-safe receiver deletes the `entitySet != nil` dance at the call site. Absent still means `true`: OData's default is allowed, and defaulting to false would invert CE6630 for every unannotated service. Tests `mdl/types/edmx_test.go` (`TestParseEdmx_WholeSetFilterAndSortRestrictions`, plus a control proving the list shape still parses); both controls reproduce (ignore the record Bool → the whole-set test fails with the CE6630 message; drop the check inside `AttrFilterable` → same). mxcli-formula1 §48", "ce": ["CE6630"]}
+{"area": "mdl/catalog", "date": "2026-08-09", "symptom": "A project is generated with no documentation anywhere — Java actions, Java action parameters, entities, microflows — and nothing says so. `mxcli check` and the build both pass, because documentation is never load-bearing", "cause": "`QUAL002` existed but reached only entities and microflows. Java actions were not reachable from Starlark **at all** (no `java_actions()` builtin), and a Java action's parameters were not reachable from anywhere: the catalog stored a parameter *count* and discarded each parameter's `Description`", "file": "`mdl/catalog/tables.go` (`java_action_parameters_data` + view, `CatalogSchemaVersion` bump), `mdl/catalog/catalog.go` (`Tables()` registry), `mdl/catalog/builder_modules.go` (insert parameters), `mdl/linter/context.go` (`JavaActions()` with parameters attached), `mdl/linter/starlark.go` (`java_actions()` builtin, `javaActionToStarlark`), `.claude/lint-rules/missing_documentation.star`", "insight": "**Adding a catalog table has three obligations beyond the `CREATE TABLE`.** (1) Bump `CatalogSchemaVersion` — otherwise every existing `.mxcli/catalog.db` keeps its old schema, the new query fails, the error is swallowed, and the rule silently reports *zero* of the new findings. Silent under-reporting from a stale cache is indistinguishable from a clean project. (2) Register the view in `Tables()` — `catalog_test.go` enforces this and will fail with \"add CATALOG.X so SHOW CATALOG TABLES includes it\"; let that test tell you rather than discovering it from a user. (3) Exclude Marketplace/System modules in the iterator's `WHERE COALESCE(m.Source,'') = ''`, as every sibling iterator does — reporting undocumented Community Commons actions buries the findings the user can act on. **Attach children to their parent in the projection, not as a second iterator**: a rule reporting an undocumented parameter must name the action it belongs to, and pairing them in `JavaActions()` saves every rule from re-joining. **Load the shipped `.star` from disk in tests** — an inlined copy proves the builtin works and says nothing about whether the rule uses it. **Make each target switchable via `get_option`** before widening a rule: attribute-level checks are hundreds of findings on a real domain model, so `check_attributes` defaults off while the rest default on. Watch the whitespace when writing revert controls for Starlark: a `perl` pattern with `\\t` silently matches nothing in a space-indented `.star`, so the control passes and proves nothing — it was the second attempt that failed correctly. Tests `mdl/linter/starlark_javaactions_test.go`; five controls reproduce. mxcli-formula1 (missing documentation)"}
+{"area": "mdl/linter", "date": "2026-08-09", "symptom": "QUAL002 reports ~40 platform elements (`FileDocument`, `HttpRequest`, `System`) as undocumented, burying the handful of real findings; or a whole document type (pages, workflows, constants, REST services, mappings) is never reported at all no matter how undocumented it is", "cause": "Two separate causes. (1) **Coverage**: QUAL002 only ever looked at entities and microflows — every other document type was unreachable from Starlark. (2) **The System leak**: `modules.Source` is `\"Marketplace …\"` for downloaded modules and **empty for System — exactly as it is for the user's own modules**, so the near-universal `WHERE COALESCE(m.Source,'') = ''` filter excludes Marketplace and lets all of System through", "file": "`mdl/linter/context.go` (`documentableSources`, `DocumentableElements()`, `notPlatformModule()`, `systemModuleID`), `mdl/linter/starlark.go` (`documentable_elements()` builtin), `.claude/lint-rules/missing_documentation.star` (`_DOC_KINDS`)", "insight": "**Source alone does not exclude System** — only the sentinel Id `00000000-0000-0000-0000-000000000001` does (`modelsdk/meta.SystemModuleID`). Use `notPlatformModule(alias)` — **every** `LintContext` iterator now routes through it (Entities, Microflows, Pages, Enumerations, Constants, Snippets, Widgets, DatabaseConnections, JavaActions, DocumentableElements and all three `FindUnused` kinds), and `TestIterators_ExcludePlatformModules` fails if a new one is added without it. The leak was not confined to QUAL002: on a blank 9.24 project it inflated the whole run from 8 findings to 60 — CONV001 renaming System booleans, SEC001 demanding access rules on 38 System entities, DESIGN001 splitting `QueuedTask`, MPR003 splitting the System module itself. Adding the predicate can only ever narrow a result set, so the change cannot invent a finding; prove that by diffing full lint output before/after and asserting the ADDED set is empty. **One projection beats N builtins**: a rule that wants \"every document\" should get one `documentable_elements()` sweep driven by a table, so a new Mendix document type is two rows (one in `documentableSources`, one in `_DOC_KINDS`) rather than another builtin nobody remembers to call. **The documentation column is NOT uniform** — Mendix says `Documentation` for Java actions / REST / mappings / JSON structures and `Description` for everything else; assuming one spelling silently reports the other half as undocumented (a revert control confirmed 5 kinds go dark). **Test the catalog BUILDER, not just the query**: unit tests that INSERT rows directly cannot see that a builder never populates a column, which would flood the user with false positives — an end-to-end `exec` + `lint` on a real `.mpr` is what proved the constant/entity paths actually work. Three tables (`json_structures`, `import_mappings`, `export_mappings`) use `Id INTEGER PRIMARY KEY AUTOINCREMENT` while the rest use `Id TEXT PRIMARY KEY`, so a synthetic string id is a \"datatype mismatch\" on exactly those. Beware: MDL `COMMENT` and `DOCUMENTATION` are **different fields** on an entity — `CREATE ENTITY … COMMENT 'x'` does not set documentation, `ALTER ENTITY … SET DOCUMENTATION 'x'` does; a test using the wrong one looks exactly like a write-path bug. Tests `mdl/linter/starlark_javaactions_test.go`; controls reproduce for the sweep, each kind list, the doc-column split, Marketplace (both join shapes) and System"}
+{"area": "mdl/linter", "date": "2026-08-09", "symptom": "A `LintContext` iterator suddenly yields nothing and the test says \"expected ModA entities to be yielded\" — no SQL error, no log line, just an empty result", "cause": "The iterator's query failed (typically `no such column`) and the iterator swallows it: `rows, err := ctx.db.Query(...); if err != nil { return }`. A hand-rolled test double whose schema has drifted from the real catalog view produces exactly this. Hit when platform filtering started reading `modules.Id` and `context_test.go`'s minimal `modules` table had only `(Name, Source)`", "file": "`mdl/linter/context.go` (the `if err != nil { return }` in every iterator), `mdl/linter/context_test.go` (`setupModuleFilterDB`)", "insight": "Read the failure as **\"the query broke\"**, not \"the filter is too strict\" — the two are indistinguishable from the assertion text, and the second reading sends you rewriting correct logic. Confirm by running the query by hand against the fixture DB. Test doubles that hand-roll a `CREATE TABLE` instead of using `catalog.NewFromFile` drift silently from the real schema; prefer the real schema builder for anything that joins. The swallowed error is the root problem — an iterator that cannot run its query is not the same as one with no results, and today nothing distinguishes them"}
+{"area": "mdl/linter", "date": "2026-08-09", "symptom": "A lint run reports fewer findings than expected, or a rule that clearly should fire reports nothing — and there is no error, no warning, no log line", "cause": "An iterator's catalog query failed and the failure was swallowed: `if err != nil { return }` inside an `iter.Seq[T]`, which has no error channel. The run looks successful because a linter's whole output is \"here is what I found\", and \"found nothing\" is what both a clean project and a dead query produce", "file": "`mdl/linter/context.go` (`QueryError`, `recordQueryError`, `QueryErrors`), `mdl/linter/linter.go` (`Linter.QueryErrors`), `cmd/mxcli/cmd_lint.go` (report + exit 1)", "insight": "Iterators still degrade to \"no rows\" — one broken query must not take down the run — but they now **record** the failure, and `mxcli lint` prints it and exits 1, because silently passing CI on a run that could not read the model is the worst available outcome. All 34 sites are covered: `Query` + `return`, `Query` + `continue`, bare and inline `rows.Scan` forms, `return unused` (the non-bare return that a naive regex sweep misses — `TestQueryError_AllIteratorsReport` is what caught it), and the reader-backed `ListScheduledEvents`. **Dedupe on iterator+cause**: several rules iterate the same accessor, so one broken view is otherwise reported once per rule. Keying on the iterator alone instead hides a second, distinct failure in the same accessor. When adding an error message with a remedy, **run the remedy** — the first draft here suggested `mxcli lint --refresh`, a flag that does not exist; the shipped message names `.mxcli/catalog.db` and deleting it was verified to clear the error. Tests `mdl/linter/context_queryerror_test.go`; controls: no-op recorder (every iterator goes silent) and a single reverted iterator (only that one)"}
+{"area": "mdl/scheduledevents", "date": "2026-08-11", "symptom": "Scheduled events are read-only in MDL — a project's cron cannot be scripted at all, so `mxcli new` + a script leaves you opening Studio Pro to add the one thing that makes a batch job run. Separately, `describe` of an existing one omits its schedule entirely", "cause": "Two gaps behind one request. (1) No write path: `ScheduledEventBackend` had List/Get and nothing else, and there was no grammar/AST/visitor/executor. (2) The READ was lossy in both engines — the legacy `parseScheduledEvent` never looked at `Schedule`, and the modelsdk reader went through `modelsdk/gen`, whose generated types **disagree with what Studio Pro writes** on two properties", "file": "`mdl/scheduledevents/codec.go` (new, shared by both engines), `mdl/backend/modelsdk/scheduledevent_read.go` + `sdk/mpr/scheduledevents.go` + `sdk/mpr/parser_enumeration.go` (both engines through the one codec), `mdl/grammar/domains/MDLDomainModel.g4` + `MDLCatalog.g4` + `MDLParser.g4`, `mdl/ast/ast_scheduledevent.go`, `mdl/visitor/visitor_scheduledevent.go`, `mdl/executor/cmd_scheduledevents.go`, `mdl/executor/validate_scheduled_events.go` (MDL-SCHED01)", "insight": "**The generated metamodel is not the storage's ground truth** — `modelsdk/gen` declares `Interval`/`HourOfDay`/… as **int32** where Studio Pro writes **int64**, and `StartDateTime` as a **string** where Studio Pro writes a **BSON datetime**. This is the same mismatch as #585 (a reader that asserted int32), so the pattern is now twice-confirmed: when gen and an observed document disagree about a numeric width or a date, the document is right. **A byte-level pin beats field assertions**: three whole documents are hex-embedded in `codec_test.go` and re-serialized element by element in ORDER, so key order, key SET and BSON TYPE are all covered — a field-by-field test passes happily while writing int32 and an empty enum. **`mxcli marketplace download` is the Studio Pro substitute**: Business Events and Community Commons have none, but Workflow Commons 4.11.0, OIDC SSO 4.6.0 and SAML 4.2.1 have four between them (only Day and Hour variants — the other six had to be metamodel-derived, then verified to load). **An empty string is not \"unset\" for an enum property**: the first draft wrote `IntervalType: \"\"` and `mx check` reported 0 errors, but the enumeration has no such member. **`Interval`/`IntervalType` are LEGACY siblings of `Schedule` that Studio Pro does not keep in sync** — Workflow Commons stores `0`/`Minute` beside a `DaySchedule` of 01:00 — so they are derived on CREATE and carried through untouched on MODIFY, never re-derived. **A polymorphic child must be dispatched on `$Type`, and its field sets never merged** (the ADR-0005 rule): the eight variants differ in arity, so the executor refuses a field belonging to another Repeat rather than dropping it. **Validate at check time, not only at exec** — the validation is decidable from the statement, so it runs in the no-project pass and `check` and `exec` call the SAME function. **Prove the describe round-trips by PARSING its own output** for every variant, not by asserting on strings. Idempotence came free (ADR-0008 canon elides the regenerated `Schedule` `$ID`) — verified with the `MXCLI_ALWAYS_WRITE=1` control, which changes 9 units where the normal run changes 0. Tests `mdl/scheduledevents/codec_test.go`, `mdl/executor/cmd_scheduledevents_test.go`, `mdl/visitor/visitor_scheduledevent_test.go`, `mdl/backend/modelsdk/scheduledevent_read_test.go`, example `mdl-examples/doctype-tests/scheduled-events.mdl`", "refs": ["#585"]}
+{"area": "mdl/catalog", "date": "2026-08-12", "symptom": "A microflow run only by a scheduled event is reported as unused from three directions at once: `show callers of Mod.SE_Cleanup` says `(no callers found)`, `CATALOG.GRAPH_DEAD_ASSETS` lists it, and `mxcli lint` emits `[QUAL004] Microflow 'SE_Cleanup' is not called from anywhere.` with the suggestion **\"Remove if unused\"** — on a microflow that runs nightly in production", "cause": "The catalog had no scheduled-event table and, more importantly, **no `refs` edge** from an event to the microflow it runs. Every consumer of the reference graph therefore agreed the microflow was dead. Separately, the linter's `ScheduledEvents()` iterator computed `interval_seconds` from the stored `Interval`/`IntervalType` pair", "file": "`mdl/catalog/tables.go` + `catalog.go` (new `scheduled_events`/`queues` views, registered in `Tables()`), `mdl/catalog/builder_scheduling.go` (new), `mdl/catalog/builder_references.go` (`RefKindSchedule` + `extractScheduledEventRefs`), `mdl/catalog/builder_graph.go` (`graphRefKinds`), `mdl/executor/cmd_search.go` (`callerRefKinds`), `.claude/lint-rules/orphaned_elements.star`, `mdl/linter/context.go` (`scheduleSeconds`, `Queues()`), `mdl/linter/starlark.go`", "insight": "**A missing edge is worse than a missing table** — the table is an absence a user notices, the edge is a *wrong answer* three tools state confidently, and one of them recommends deleting the file. When adding a document type that references another, add the `refs` row in the same change. **An entry point is not a caller but must count as one**: `schedule` had to go into `callerRefKinds`, `graphRefKinds` AND the QUAL004 rule — three independent consumers, none of which shares the other's list. **Derive from the live property, not its legacy twin**: `interval_seconds` came from `Interval`/`IntervalType`, which Studio Pro writes and does not keep in sync with `Schedule` (Workflow Commons stores 0/\"Minute\" beside a DaySchedule of 01:00), so a \"fires too often\" rule read a nightly job as every 0 seconds; the old tests pinned the wrong source and had to be rewritten, which is the tell. **Adding a plural keyword breaks `CATALOG.<KEYWORD>`**: `QUEUES` became a lexer token and `select * from CATALOG.QUEUES` then parsed to NOTHING — no error, no output, just silence — until `QUEUES` was added to `catalogTableName` (`COMMUNITIES` had been through this before). `SCHEDULED_EVENTS` escaped only because the underscore makes it one IDENTIFIER. **`cmd/mxcli/lint-rules/` is gitignored and regenerated** from `.claude/lint-rules/` by `make build`, exactly like `cmd/mxcli/skills/` — editing the embed dir silently reverts on the next build. **`TestTables_CoversAllViews` catches a view missing from `Tables()`**, so a new catalog table is invisible to `SHOW CATALOG TABLES` until registered. Tests `mdl/catalog/builder_scheduling_test.go`, `mdl/linter/starlark_scheduledevents_test.go`, `mdl/visitor/visitor_catalog_test.go`"}
+{"area": "mdl/regularexpressions", "date": "2026-08-12", "raw": "| A project's regular expressions are invisible to mxcli — `show regular expressions` is a parse error, they are absent from `describe`, the catalog and the project tree, and there is no way to author one — so a validation pattern shared across a domain model can only be seen in Studio Pro | No support at any layer for `RegularExpressions$RegularExpression`. The `model.RegularExpression` type existed but was **dead code**: nothing read or wrote it | `mdl/regularexpressions/codec.go` (new, shared by both engines), `mdl/backend/modelsdk/regularexpression.go` + `sdk/mpr/regularexpressions.go`, `mdl/backend/infrastructure.go`, `mdl/grammar/MDLLexer.g4` (+`REGULAR`/`EXPRESSIONS`) + `domains/MDLDomainModel.g4` + `MDLCatalog.g4` + `MDLParser.g4`, `mdl/ast/ast_regularexpression.go`, `mdl/visitor/visitor_regularexpression.go`, `mdl/executor/cmd_regularexpressions.go`, `mdl/catalog/builder_regularexpressions.go` (+ the `validate` ref edge in `builder_references.go`) | **`modelsdk/gen` had the property key wrong — the third confirmed instance.** gen binds the pattern to BSON `RegEx`; all five Studio Pro documents store `Expression`, and `generated/metamodel`'s JSON tag (`expression`) agrees with the documents. A codec built on gen writes a property the type does not carry AND reads an empty pattern from every real document — the negative control (flip `PatternKey` to `RegEx`) fails all five parse tests. The rule is now thrice-proven: **when gen and an observed document disagree, the document wins**. **A regex is the worst case for string handling**, so test the pattern round trip specifically: backslashes (not escapes), a doubled `''`, alternation, `{2,}` braces, and a `|` — assert by RE-PARSING the describe output, not by string match. **Do not equate \"Go cannot compile it\" with \"invalid\"**: Mendix validates with .NET, and the Email Connector ships `.*(?<!/)$`, which RE2 rejects — so the check is advisory and DESCRIBE says \"not verifiable\". **Check the reference direction before assuming a dead-asset bug**: unlike the scheduled-event case, `GRAPH_DEAD_ASSETS` is restricted to ENTITY/MICROFLOW/NANOFLOW/PAGE/SNIPPET, so a regex was never reported dead — the `validate` edge earns its place by answering `show references to <regex>`, and the control run proved the dead-asset framing wrong before it reached a comment. **Adjacent defect found and NOT fixed**: `create validation rule …` (regex, required, range, unique) has a grammar rule but **no AST node, no visitor and no handler** — it parses and silently writes nothing, so a regex document still cannot be bound to an attribute from MDL. `sdk/domainmodel.RegexValidationRuleInfo` and `serializeRuleInfo`'s Required-fallback are dead code reachable only once that is built (an entity rewrite PRESERVES stored rules — verified by injection, so there is no live data-loss bug there). Tests `mdl/regularexpressions/codec_test.go`, `mdl/executor/cmd_regularexpressions_test.go`, `mdl/visitor/visitor_regularexpression_test.go`, example `mdl-examples/doctype-tests/regular-expressions.mdl` |"}
+{"area": "mdl/catalog", "date": "2026-08-11", "symptom": "`show callers of <microflow>` and `show references to <page>` report \"(no callers found)\" for a document reached only from a page action button — a false negative that reads as \"safe to delete\"", "cause": "TWO independent defects behind one symptom. (1) `scanWidgetOwnRefs` collected `Entity`/`Microflow`/`Nanoflow` from a widget's raw BSON but not **`Form`**, the key a PAGE reference uses, so `widgets_data` had no page column and the refs projection had no page row. (2) `execShowCallers` filtered `RefKind = 'call'` — the kind a microflow CALL ACTIVITY produces — so the button→microflow row, which was already in the refs table, was hidden by the query", "file": "`mdl/catalog/builder_pages.go` (`scanWidgetOwnRefs` + `rawWidgetInfo.PageRef`), `mdl/catalog/tables.go` (`widgets_data.PageRef`), `mdl/catalog/builder_references.go` (projection row), `mdl/executor/cmd_search.go` (`callerRefKinds`)", "insight": "**Find the live code path before fixing anything** — `builder_references.go` has an inviting `extractWidgetRefs` with a per-widget-type switch, and it is DEAD: its only caller is its own recursion. Extending it changes nothing. The live path is a SQL projection out of `widgets_data`, and the standing `NOTE: widget-level datasource/action refs still require a parsed widget tree` comment beside it is the tell. **Separate \"the reference is missing\" from \"the query hides it\"** by reading the refs table directly: the button→microflow row was present all along, so fixing only the scanner would have closed half the issue and left the reporter's second scenario broken. **`Form` is `Page`** — the same rename behind `ShowFormAction`/`CloseFormAction` (CLAUDE.md's storage-name table); grepping for `Page` in a BSON scanner finds nothing. **One action can carry two references**: `create object … then open page` holds an entity AND a page, so collecting the entity alone still leaves the page unreferenced. **Do not widen `callers` into `references`** — `datasource`/`parameter`/`generalize` are uses of a TYPE, not invocations, and including them makes the two commands synonyms; the test pins both the included and the excluded set. Tests `builder_pages_test.go` (`TestScanWidgetOwnRefs_PageReference`), `cmd_search_callers_test.go`. upstream #773", "refs": ["#773"]}
+{"area": "mdl/ast", "date": "2026-08-13", "symptom": "An `@annotation` mxcli does not implement — `@size(600, 300)` — parses and does nothing, and layout authored through annotations silently differs from what was written", "cause": "The grammar accepts any `@name`, and `extractMicroflowAnnotations`' switch had **no default arm**, so an unrecognised name was dropped in silence. Benign for an unimplemented annotation; NOT benign for a typo of an implemented one — `@postion(10, 20)` passed `check` and discarded the position", "file": "`mdl/ast/ast_microflow.go` (`ActivityAnnotations.UnknownNames`), `mdl/ast/annotations.go` (new: `StatementAnnotations`), `mdl/visitor/visitor_microflow_statements.go` (the `default:` arm), `mdl/executor/validate_microflow.go` (`checkUnknownAnnotations`, `knownActivityAnnotations`, MDL059), `mdl/executor/validate.go` (exec-enforced)", "insight": "**A silent no-op is worse than an unimplemented feature** — the reporter filed \"`@size` is ignored\", but the same missing arm meant a typo of the annotation their whole workflow depends on threw away the layout with a clean `check`. Fix the class, not the instance. **Read the annotations generically, not through a type switch**: 15 statement types carry `Annotations`, and a hand-written switch that skips the 16th reintroduces the silent drop one level up — `StatementAnnotations` reflects, and `TestEveryActivityAnnotationsFieldIsNamedAnnotations` parses the AST package's own source for every `*ActivityAnnotations` field and asserts it is named so the accessor reaches it. **Pin a restated list against its source**: `knownActivityAnnotations` duplicates the visitor's case labels, so `TestKnownAnnotationsMatchTheVisitor` parses those labels out of the visitor and compares both directions — a name in one and not the other either rejects a working annotation or accepts a dead one. **Check a new rejection against the real corpus before believing it**: `scripts/check-skill-mdl.sh` over `.claude/skills/mendix` and `docs-site/src` (405 blocks) proved no false positives. Tests `mdl/ast/annotations_test.go`, `mdl/executor/validate_annotations_test.go`. upstream #884", "refs": ["#884"], "rules": ["MDL059"]}
+{"area": "mdl/linter", "date": "2026-08-13", "symptom": "`mxcli lint` reports MPR008 \"activities overlap\" for two nodes that live on different canvases — one inside a loop, one outside — so generated layout is flagged for an overlap that cannot happen on screen", "cause": "`collect` recursed into `LoopedActivity.ObjectCollection` and appended the children into the **same flat list** as the microflow's own canvas, then compared every pair. A LoopedActivity's children are positioned RELATIVE to the container; verified in the stored BSON — outer activity `200;230` (absolute) beside a loop child `141;130` (container-relative)", "file": "`mdl/linter/rules/mpr008_overlapping_activities.go` (`overlapPlanes`, one plane per canvas; the pair loop iterates per plane)", "insight": "**A false positive on a layout rule is worse than silence** — the rule exists to be trusted about positions. **Extract the inline logic to make the fix testable**: the rule's own test file carried a note that the overlap logic \"cannot be unit-tested without building a mock mpr.Reader\", which is why the bug had no coverage; `overlapPlanes` is a pure function over the object tree and needs no reader. **Assert both directions** — the cross-canvas pair must stop being reported AND a genuine same-canvas pair at (300,200)/(310,210) must still be, or the fix trades a false positive for a false negative. **The reporter's own numbers did not reproduce**: (141,130) vs (134,230) is dy=100 against `activityBoxHeight = 60`, so that pair never fired; the mechanism was real but the quoted evidence was not, and a constructed pair was needed to demonstrate it. **A vanished fixture reads exactly like a fixed bug** — an intermediate \"no violations\" result was the scratch project having been reaped, not the fix working; the A/B was redone with a pre-fix binary against the same rebuilt project. Tests `mpr008_overlapping_activities_test.go`. upstream #884", "refs": ["#884"]}
+{"area": "mdl/ast", "date": "2026-08-13", "symptom": "A hand-curved sequence flow does not survive a rewrite — `DESCRIBE` output is identical before and after the curve is drawn in Studio Pro, and re-running unchanged MDL straightens the edge", "cause": "Mendix stores NO waypoints. A flow's shape is two bezier control vectors on its `Microflows$BezierCurve` line (`OriginControlVector`/`DestinationControlVector`, `\"x;y\"`). Both writers already emitted them and the legacy parser already read them, but nothing could SET them, so they defaulted to `\"0;0\"` and every rebuild flattened the curve — measured by patching `\"40;-90\"` into the stored line and re-executing the same script, which returned `\"0;0\"`", "file": "`mdl/ast/ast_microflow.go` (`FlowCurve`, `ActivityAnnotations.Curve`/`InvalidCurves`), `mdl/visitor/visitor_microflow_statements.go` (`parseCurveAnnotation`, `annotationPointValue`), `mdl/executor/cmd_microflows_builder_annotations.go` (`curveByOrigin`, `applyFlowCurves`, and the `mergeStatementAnnotations` copy), `cmd_microflows_builder_graph.go` (the one call), `cmd_microflows_show_helpers.go` (`emitCurveAnnotation`), `mdl/backend/modelsdk/microflow.go` (read the Line back)", "insight": "**Check what the storage can represent before designing the syntax** — the request asked for \"edge waypoints\", which do not exist; `SequenceFlow` has two control vectors, so `@curve(from: (x, y), to: (x, y))` is the only shape that maps. Same lesson as #872's anchors. **Look for an existing annotation shape before touching the grammar**: `name: (x, y)` is already `annotationParenValue`, so `@curve` needed ZERO grammar changes. **Record against the ACTIVITY and stamp flows in one pass** — threading a curve alongside the anchor would mean editing all seven sites that create a flow (`previousStmtAnchor`, `nextFlowAnchor`, branch and loop variants) and missing one silently straightens that edge; `applyPendingAnnotations` already runs at every activity, so there is exactly one place to get right. **A new field on `ActivityAnnotations` must be copied in `mergeStatementAnnotations`** — it is an explicit field-by-field copy, so the first cut parsed the curve and wrote nothing. **Unit tests that call the function directly do NOT prove the wiring**: deleting both call sites left `TestEmitCurveAnnotation` and `TestApplyFlowCurves…` green, which is the \"a test that only passes against fixed code\" trap in its purest form — `TestCurveReachesTheFlowThroughTheBuilder` (MDL text → real builder) and `TestCurveIsEmittedByTheAnnotationEmitter` (through `emitObjectAnnotations`) fail when unwired. **Still open**: a curve drawn in Studio Pro is preserved only once the script names it, since a rebuilt flow has no stable identity to match on; DESCRIBE now surfaces it so it can be captured. Tests `mdl/executor/cmd_microflows_curve_test.go`, example `mdl-examples/bug-tests/884-annotations-and-lint-planes.mdl`. upstream #884", "refs": ["#872", "#884"]}
+{"area": "mdl/ast", "date": "2026-08-13", "symptom": "The implicit merge that closes a split — the end-if join — is placed by the layout pass and cannot be moved; it routinely lands on top of a neighbouring activity, and `@position` does not address it", "cause": "The statement's own `@position` belongs to the SPLIT, so the merge had no annotation of its own. Three split builders computed `mergeX/centerY` with no override (`addIfStatement`, `addEnumSplit`, `addStructuredInheritanceSplit`), and DESCRIBE emitted nothing for it, so even a hand-moved merge was recomputed on the next exec", "file": "`mdl/ast/ast_microflow.go` (`ActivityAnnotations.Merge`), `mdl/visitor/visitor_microflow_statements.go` (`case \"merge\"`), `mdl/executor/cmd_microflows_builder_annotations.go` (`mergePosition`, and the `mergeStatementAnnotations` copy), the three split builders, `cmd_microflows_show_helpers.go` (`emitMergeAnnotation`, `commonMergeAfter`)", "insight": "**Authoring without the DESCRIBE half is not a fix** — the first attempt shipped `@merge` writing correctly and was REVERTED, because the describer drops it and the layout pass then recomputes the merge on the next exec; that is the same round-trip data loss as #872/#881/#882, introduced by the change meant to help. **Find the relationship from data already in scope rather than threading a map**: the describer's `splitMergeMap` is not available at `emitObjectAnnotations`, and threading it would mean editing ten-plus call sites (the multi-site trap); `commonMergeAfter` walks the split's branches to the nearest merge reachable from ALL of them, using the `flowsByOrigin` and `activityMap` already passed in. **Bound any walk over a flow graph** — a retry loop makes it cyclic, so the walk carries a per-branch visited set and a node cap, pinned by `TestCommonMergeAfterTerminatesOnACycle`. **One helper for every site that places the merge**, so the override cannot be honoured at one split type and ignored at another. **Test the WIRING, not the helper**: `mergePosition` and `emitMergeAnnotation` called directly pass with every call site removed — `TestMergeReachesTheCanvasThroughTheBuilder` (MDL text → real builder) and `TestMergeIsEmittedByTheAnnotationEmitter` (through `emitObjectAnnotations`) fail when unwired, verified by removing each. Tests `mdl/executor/cmd_microflows_merge_test.go`, example `mdl-examples/bug-tests/884-annotations-and-lint-planes.mdl`. upstream #884", "refs": ["#872", "#881", "#882", "#884"]}
+{"area": "mdl/types", "date": "2026-08-18", "symptom": "`ALTER PAGE SET <prop> ON <grid>.<col>` fails with `column property \"X\" not found` for a property the very same tool writes happily inside `CREATE PAGE`. `check --references` passes the statement that `exec` rejects, so the disagreement only surfaces at write time", "cause": "Two hand-written alias tables for one widget schema, drifted. The create path (`mdl/executor/widget_defs.go` `itemPropertyAliases`) aliased `DynamicCellClass` → `columnClass`; the ALTER path (`mdl/backend/pagemutator/mutator.go` `columnPropertyAliases`) kept its own copy and did not — the file contained zero occurrences of the string", "file": "`mdl/types/widget_item_aliases.go` (new — `ItemPropertyAliases` moved here), `mdl/executor/widget_defs.go` (now a reference), `mdl/backend/pagemutator/mutator.go` (`resolveColumnPropertyKey`, `settableColumnProperties`)", "insight": "Delete the second table rather than adding the missing row: resolve the MDL name against the schema keys the **document itself declares** (case-insensitively), falling back to the one shared alias table for genuine renames. A property the create path can write is then one ALTER can write, by construction. Case-only differences (`Sortable`→`sortable`) need no entry at all, which keeps the shared table down to real aliases. The not-found error now lists the settable keys read off that grid, so it is right for the widget version installed rather than the one mxcli was built against. **Generalisable**: two tables describing one external schema will drift; the fix is one table or none, never a third. mendixlabs/mxcli#919", "refs": ["mendixlabs/mxcli#919"]}
+{"area": "mdl/xpathrefs", "date": "2026-08-17", "symptom": "After a `rename attribute`, `mx check` reports **CE0161 \"Error(s) in XPath constraint.\"** at every retrieve, widget data source or entity access rule whose constraint named the attribute — and, if the attribute had a `READ *` access rule, **CE0066 \"Entity access is out of date\"** on the domain model", "cause": "Two different causes with the same trigger. (a) XPath names an attribute as a **bare step** (`[Status = 'Open']`), which the qualified-name reference scanner cannot see — and which a scan for the bare name must not touch, since the same three letters are a string literal here, a function name there, and another entity's attribute somewhere else. (b) `UpdateEntity` re-derives an access rule's members from the attributes it can match, so renaming the attribute in the model left the old member orphaned; the reference scan then renamed the orphan into a **duplicate** of the new member", "file": "`mdl/xpathrefs/` (new: `rewrite.go`, `scan.go`), `mdl/executor/xpath_rename_model.go`, `mdl/executor/xpath_rename.go`, `mdl/executor/rename_attribute_entity_rules.go`, `mdl/executor/cmd_entities.go`", "insight": "(a) **XPath needs no type inference** — a constraint's target entity is known *structurally* (a retrieve names its `Entity`, a widget data source its `EntityRef.QualifiedName`, an access rule the entity it sits inside), and every further hop is an association or entity named in the path. Resolve each bare step to its owning entity, then **edit one identifier token textually**; do NOT re-render the parsed tree, which would churn spacing in constraints the rename has no business touching and would corrupt any constraint the parser and renderer disagree about. **The load-bearing safety check is a count invariant**: `visitor.ParseXPathConstraint` runs with ANTLR's error listeners removed, so it recovers and can return a tree that silently omits part of its input (`[LastName = 'L' FirstName]` parses; the trailing step is simply absent) — require the lexical occurrence count and the walked occurrence count to agree, or refuse. Unresolvable → report and leave alone, never guess: for a *mutating* consumer the checking world's \"unresolved → assume nothing → catch less\" inverts into \"unresolved → change nothing\". (b) Fix the entity's own by-name references (`MemberAccess.AttributeName`, `ValidationRule.AttributeID`, range `Min/MaxAttributeQualifiedName`) **in the model before `UpdateEntity`**, not by leaving them to the scan afterwards. **Trap that cost an hour**: the stored `$Type` of a domain model entity node is `DomainModels$EntityImpl`, not `DomainModels$Entity` (that is the metamodel's name for a *reference target*) — checking the latter matched nothing and made every access rule look like a cautious refusal instead of a bug. Controls on Mendix 11.13.0 with `mdl-examples/bug-tests/910-rename-attribute-xpath-constraints.mdl`: same script without the rename = 0 errors, with the rename pre-fix = 3× CE0161 then 1× CE0066, post-fix = 0. mendixlabs/mxcli#910 (problem 2, XPath half)", "refs": ["mendixlabs/mxcli#910"], "ce": ["CE0066", "CE0161"]}
+{"area": "mdl/exprcatalog", "date": "2026-08-18", "symptom": "The expression type checker reports nothing, ever. `mdl/exprcheck` is a complete checker — parser, type lattice, function table, hints registry, slot resolver, and a `Context` with two tiers — and a suite of semantic rules (E001 enum-vs-string-literal, E009 slot-type mismatch, …) that never fire on any real project. `mxcli check --references` is green on a script with obvious type errors", "cause": "Three silent absences, each of which alone reduces the whole thing to a no-op. (a) **Nothing implemented `exprcheck.CatalogReader`** — `grep -rn \"exprcheck.CatalogReader\"` outside the package returned zero hits — so every invocation ran with a nil `Catalog` and `Context.IsSemanticEnabled()` was false. (b) Three of the five lookups had **no data in the catalog**: `attributes_data.DataType` is the bare kind (`\"Enumeration\"`, losing which one), `enumerations_data` stored `ValueCount` but not the values, `microflows_data` stored `ParameterCount` but not the parameters. (c) The adapter's `exprSource` read **only `ast.SourceExpr`**, and the visitor attaches one to some slots and not others — measured on a fixture, neither a CREATE's nor a CHANGE's enum value carried one, so the walk had nothing to parse", "file": "`mdl/exprcatalog/` (new), `mdl/catalog/tables.go` + `builder_modules.go` + `builder_microflows.go` (schema 10), `mdl/exprcheck/adapters/check.go` (`WithSourceFunc`, trim, `CheckNanoflow`), `mdl/executor/typecheck.go` (new), `cmd/mxcli/cmd_check.go`", "insight": "Implement the seam as a **memoized index loaded once** (four queries), not SQL per lookup. **Bump `CatalogSchemaVersion`** when adding a column the checker reads: without it a cached catalog answers \"unknown\" for every lookup, which the checker reads as \"cannot tell\" and skips — a green run that checked nothing, i.e. the original bug wearing a fresh cache. Keep the **E0xx codes** rather than remapping: the code in the message must be the code you can look up. **Generalisable, and the reason this sat undetected**: a seam with zero implementations is invisible to the compiler and to tests that mock it — when auditing an interface, grep for *implementations* (`var _ Iface = `, or the interface name outside its own package), not for callers; and when a checker's failure mode is \"unknown → skip\", every missing input looks exactly like a clean project. **Verify against a real project, never a mock** — all three defects survive a mocked test. Controls: nil reader → 0 violations, default source func → 0 violations, fixed → 2 (CREATE and CHANGE). False-positive probe: all 21 microflows of a 11.13.0 app described back to MDL and re-checked → 0 findings. **Known depth limit**: `AttributePathExpr` still infers `KindUnknown`, so `if $obj/Status = 'Open'` is NOT caught — only slot-qualified positions (create/change members) are. That is the proposal's open Tier-2 item, not a regression"}
+{"area": "mdl/catalog", "date": "2026-08-17", "symptom": "Lint CONV010 flags **every** `ACT_` microflow that shows a page, closes one, or calls a sub-microflow — 11 false positives out of 13 findings, burying the real ones", "cause": "The rule's `ALLOWED_ACTIONS` held the Mendix **storage** names (`ShowFormAction`, `CloseFormAction`); the catalog labels an action with its **SDK** name, derived from the parsed Go type in `getMicroflowActionType` (`ShowPageAction`, `ClosePageAction`, `MicroflowCallAction`). The allowlist matched nothing", "file": "`.claude/lint-rules/conv010_act_microflow_content.star`, `mdl/catalog/builder_microflows.go`", "insight": "List the SDK names (both spellings is cheap insurance). The storage-name split is the same one in CLAUDE.md's `$Type` table — it bites rule authors because the catalog deliberately does **not** use storage names. `mdl/catalog/lint_rule_vocabulary_test.go` pins the allowlist to what `getMicroflowActionType` actually returns, so the rule cannot drift from the labeller again. Copy the rule into the target project's `.claude/lint-rules/` when testing: `mxcli lint -p <proj>` prefers the **project's** copy over the embedded one, so editing the repo's copy alone changes nothing"}
+{"area": "mdl/catalog", "date": "2026-08-17", "symptom": "Lint QUAL004 reports a live microflow as \"not called from anywhere\" (page datasource, widget button, calculated attribute), or a navigation-only page as orphaned", "cause": "The rule counted only the `call` and `schedule` reference kinds. The builder emits `datasource`, `action` and `calculate` for microflows, and `home_page` / `login_page` / `menu_item` for pages — all ignored. The page half was masked by `ENTRY_PAGE_PATTERNS`, which happens to cover the pages most likely to be navigation targets", "file": "`.claude/lint-rules/orphaned_elements.star`, `mdl/catalog/builder_references.go`", "insight": "Count every kind that means \"this runs\" / \"this opens\", via the `MICROFLOW_ENTRY_KINDS` / `PAGE_ENTRY_KINDS` lists. `TestQUAL004CountsEveryEntryPointKind` fails when one goes missing and `TestQUAL004EntryKindsAreRealRefKinds` when one is misspelled. Adding a new `RefKind` that means reachability means adding it to the right list"}
+{"area": "mdl/exprcheck", "date": "2026-08-18", "symptom": "`mxcli check -p app.mpr` passes a microflow containing `if $obj/Status = 'Open'` — comparing an enumeration attribute to a string literal, the first example in the type-checking proposal and the shape people actually write. The same mistake written as a create or change member *is* caught, which makes the gap look arbitrary", "cause": "Two causes, both invisible. (a) **`inferKind` returned `KindUnknown` for every `AttributePathExpr`**, so `$obj/Attr` typed to nothing and every rule downstream of it stayed quiet. `exprcheck.Scope` is `Lookup(name) (TypeKind, bool)` — it can say \"$P is an Object\" but not *which* entity, so there was nowhere to put the answer; the adapter computed a variable→entity map (`buildVarEntityScope`) and used it only to label a slot path, never passing it to the checker, and it covered body-introduced variables but **not parameters** — the ordinary case. (b) Even resolved, nothing fired: **E001 keys off the SLOT** (`CreateItem.Value:Entity.Attr`), which exists for an assignment and not for a comparison", "file": "`mdl/exprcheck/interfaces.go` (`EntityScope`, `Context.Entities`), `mdl/exprcheck/parser.go` (`attributePathKind`, `pathTargetEntity`, `checkEnumComparedToString`), `mdl/exprcheck/adapters/` (`walkFlow`, `addParamEntities`, `entityScope`), `mdl/exprcatalog/` (`AssociationTarget`)", "insight": "Put the object side in its **own seam** (`EntityScope`: `VariableEntity` + `AssociationTarget`) beside `Scope` rather than widening either it or `CatalogReader` — `CatalogReader`'s shape is what stays re-syncable from the upstream fork. **A multi-hop expression path is not an XPath path**: XPath spells the intermediate entity (`[Assoc/Entity/Attr]`) so a walk can read it off, while an expression does not (`$O/Mod.Assoc/Attr`), so every hop must resolve through the association index. For (b), emit the **same code and message** from the comparison as from the slot — one defect should not have two names depending on where it was spotted. **Generalisable**: when a checker is silent, separate \"did the input resolve\" from \"is there a rule for this shape\" before touching either — here resolution and detection were both missing, and fixing only one would have looked like the fix failed. Verify with a **probe corpus that actually exercises the construct**: 21 microflows described back to MDL contained 40 attribute-path lines including an association hop, and were clean before and after, which is what makes \"no false positives\" mean something. Controls: path→`KindUnknown` restored, `Entities` dropped from the Context, and `addParamEntities` removed each fail a distinct test. **Still open**: a *terminal* association step (`$Order/Mod.Order_Lines`) types to unknown — Object vs List depends on the association's kind and direction, and guessing costs false positives"}
+{"area": "mdl/microflowgraph", "date": "2026-08-20", "symptom": "`DESCRIBE MICROFLOW` emits MDL that is **not equivalent** to the microflow: a branch's activities are missing from the output, and re-executing the description builds a different flow. Reported as \"roundtrip for @merge does not work\" plus a separate complaint about the diagram coming back tangled", "cause": "The graph is not **properly nested**. MDL's `IF/THEN/ELSE` is a single-entry/single-exit block; a Mendix microflow is an arbitrary graph, and when a branch re-enters a sibling branch's path there is no nesting that means the same thing. The describer walks it as a tree anyway. Measured on the reporter's graph: `log` ran on `¬c1 ∨ c2` and was described as `c1 ∧ c2` — with their actual expressions (`not(true)` on both decisions) the original **always** logs and the description **never** does, i.e. the exact inverse, not a near-miss. The tangled diagram is the *same* cause: `findSplitMergePointsForGraph` and `commonMergeAfter` are two independent merge-finders that agree on every nested graph and disagree here (merge2 vs merge1), so the emitted `@merge(x,y)` places the merge before an activity that structurally follows it", "file": "`mdl/microflowgraph/structure.go` (`Analyze` — post-dominators + branch-body overlap); `mdl/linter/rules/flow_irreducible_graph.go` (MDL-FLOW01); `irreducibleGraphWarnings` in `mdl/executor/cmd_microflows_show.go`", "insight": "**Reconstruct the reporter's graph from the coordinates in their own output** before touching code — `@position`/`@merge` values pin the shape exactly, and `commonMergeAfter` reproducing their `@merge(-200,173)`/`@merge(100,173)` byte-for-byte is what confirmed the reconstruction was right rather than merely plausible. **Do not reuse the describer's join search in the detector**: there are already two implementations and they disagree on exactly the graphs being detected, so a detector built on either inherits whichever is wrong. Post-dominance is self-contained (`pdom(n) = {n} ∪ ⋂ pdom(succ)`, universe-initialised so it converges on the cyclic graphs retry loops create) and makes a describer/detector disagreement a *signal*. Classification: overlap with **one** entry point is a shared suffix (recombinable — the guards fold, `¬c1 ∨ c2`), **two or more** is genuine crossing (interleaved — needs activity duplication or a synthetic boolean per Böhm-Jacopini, so it is refused). **The false positive is worse than the bug** — flagging ordinary nesting would warn on nearly every microflow — so pin the shapes most likely to trip it: `if` with no `else`, an inner split whose join *is* the outer's, branches that both return, and error-handler flows (excluded, or every activity with one gets flagged). **A rule that never runs and a rule that finds nothing look identical**: prove the wiring with a forced-fire control (temporarily append a finding per microflow, lint a real project, confirm the count, revert) — `mxcli lint` reporting \"No issues found\" on a blank app is also just marketplace modules being excluded. Rendering it faithfully needs a label form; Mendix gives no field to hang one on (`Microflows$ExclusiveMerge` stores only `RelativeMiddlePoint` and `Size` — confirmed against `generated/metamodel`, `modelsdk/gen` and real 11.13 documents), but labels only need to be deterministic, not stored. Issue #923; design in `docs/11-proposals/PROPOSAL_structured_microflow_description.md`", "refs": ["#923"]}
+{"area": "mdl/catalog", "date": "2026-08-20", "symptom": "`SHOW REFERENCES TO <entity>` reports **0 pages, 0 widgets** for an entity that is demonstrably used on a page, and `SEARCH` cannot find content that is in the model. The entity is used inside a **List View specialization template** (one template per specialization of the list view's generalization — Studio Pro only; MDL has no surface for it)", "cause": "`Templates` was not a recognised widget-container key. `extractWidgetsRecursive` knew `Widgets`, `Rows`/`Columns`, `FooterWidgets`, `TabPages`, pluggable `Object.Properties[].Value.Widgets` and NavigationList `Items[].Widgets` — not `Templates` — so nothing inside a template reached the widgets table, and the refs projection is built from that table. `Templates` was also missing from `widgetChildKeys`, so the **same omission had a second, opposite effect**: the list view's own ref scan descended into its templates and, returning the lexicographically smallest candidate, recorded a template's specialization as the list view's datasource entity", "file": "`mdl/catalog/builder_pages.go` (`extractWidgetsRecursive`, `widgetChildKeys`)", "insight": "Walk each template as a container in its own right — `extractWidgetsRecursive(tplMap)` — so its row carries the specialization it renders and its children are indexed like any other nested widgets, **and** add the key to `widgetChildKeys` so the parent stops absorbing them. **Both halves or neither**: recursion alone leaves the wrong-entity displacement in place, and the key alone hides the contents without indexing them. `widgetChildKeys` and the recursion are two sides of one contract — a key in one and not the other is a bug in a specific direction, so audit them as a pair. (`Items` is correctly asymmetric and must stay that way: a nav item's own `Form`/`Entity` belongs to the NavigationList because items are not emitted as rows, and the walk already stops at the item's `Widgets`.) **Generalisable**: two omissions of the same key in complementary walkers partly mask each other — a stray ref still leaks through — which is why this reads as intermittent rather than absent. mendixlabs/mxcli#940", "refs": ["mendixlabs/mxcli#940"]}
+{"area": "mdl/exprcheck", "date": "2026-08-21", "symptom": "`mxcli check -p` reports **\"Unexpected token after expression — … possible missing space between keywords\"** with an EMPTY location and a hint about glued keywords like `emptyor`, on a script that parses fine without `-p` and executes correctly. Related: `declare $b Boolean = Mod.Rule(...)` passes check and is **CE0117** \"Error(s) in expression\" on mxbuild, and `show callers of` a rule finds nothing", "cause": "Three separate gaps around the one construct MDL spells as `Module.Name(...)`. (a) `mdl/exprcheck` does not model a qualified call, so the trailing `(` was left on the stream and reported as leftover — it fired on the VALID decision form as much as the invalid ones, so it carried no signal and named a typo that was not there. (b) A Mendix expression has no user-callable functions at all — its library is built-in and unqualified — so a qualified call in a VALUE position is CE0117 whether it names a rule, a microflow or a Java action, and both engines wrote the literal text. (c) A rule is not an activity: Mendix evaluates one only as a decision's condition, and the reference extractor walked only action activities, so a rule called from a decision had no callers", "file": "`mdl/exprcheck/parser.go` (`parseQualifiedCall`, reached from `parseIdentLed`) + `ast.go` (`CallExpr.Qualified`) + `unknown_funcs.go` (skip qualified); `mdl/executor/validate_qualified_call.go` (MDL066) wired from `validate_microflow.go`; `mdl/executor/cmd_microflows_builder.go` (`buildSplitCondition` refuses a non-rule); `mdl/catalog/builder_references.go` (`collectRuleCalls`); tests `mdl/exprcheck/qualified_call_test.go`, `mdl/executor/validate_qualified_call_test.go`, `mdl/catalog/builder_rule_refs_test.go`", "insight": "**A diagnostic that fires on the correct form too is worse than none** — it trains the author to ignore the checker, and here it also masked the real defect in the same script. **Exempt only the position that is actually legal**: the decision condition is the single place a bare qualified call is valid MDL (mxcli stores it as a `RuleSplitCondition`), so MDL066 skips `if` and nothing else — a `while` condition has no rule-split form and is flagged. **Split the check by what it needs**: whether a qualified call is illegal *here* is project-less (no built-in Mendix expression function has a dot in its name), while whether the name in a decision is a RULE needs the backend — so the first is a linter rule and the second is a flow-builder refusal, each with its own control. **Do not let the new node reach the unknown-function checker**: `UnknownFunctionCalls` feeds MDL044's did-you-mean, and a qualified name has no near built-in, so it would emit nonsense on the legal form; `CallExpr.Qualified` marks it and the walker skips it. Not fixed: rules are still not catalog OBJECTS, so a microflow called only from inside a rule's body is reported dead by QUAL004 / GRAPH_DEAD_ASSETS — adding the object type without also indexing rule bodies would report every rule itself as dead, so it needs both halves at once. Issue mendixlabs/mxcli#939", "refs": ["mendixlabs/mxcli#939"], "ce": ["CE0117"], "rules": ["MDL044", "MDL066"]}
+{"area": "mdl/exprcheck", "date": "2026-08-24", "symptom": "`mxcli check`/`exec` reports **MDL041** \"assigning a Decimal expression to Integer variable\" on arithmetic that mxbuild builds at **0 errors** — `round(floor($a div 3)) * 3` is refused while the same expression without the `* 3` is accepted. Since `exec` refuses to write when any rule errors, the model's own `describe` output cannot be fed back to `exec`, and anything built on that round trip (mutation harnesses, generators) silently applies nothing", "cause": "`round`/`floor`/`ceil` were declared `ret: KindDecimal` in `funcTable` and exempted from the check only when the call was the WHOLE right-hand side. As soon as the rounded value became an operand, the inner `div`'s Decimal taint propagated back out through the very function that exists to stop it. The same root-only shortcut let the genuinely Decimal two-argument `round($a div $b, 2)` through, and `abs`/`max`/`min` — which preserve their operands' kind — were false positives on every Integer argument", "file": "`mdl/exprcheck/func_checker.go` (`funcSig.retByArity`/`retFromArgs`/`retFor`, the Math table), `mdl/exprcheck/parser.go` (`inferKind` CallExpr arm, `callArgsResult`), `mdl/exprcheck/unknown_funcs.go` (`SourceRejectedForIntegerTarget`; `roundingFuncs` deleted); test `mdl/exprcheck/round_returns_integer_test.go`; repro `mdl-examples/bug-tests/sudoku-49-mdl041-rounding-arithmetic.mdl`", "insight": "Give the function table a return kind that is right at **every** call site instead of exempting a name at the root: arity-dependent for `round` (1 arg Integer, 2 args Decimal), Integer for `floor`/`ceil`, operand-derived for `abs`/`max`/`min`. Then the rule just asks `inferKind`, and `arithResult` propagates it through the surrounding arithmetic for free. **Measure the table against mxbuild, one row at a time** — `mxcli exec --no-check` writes the expression, `mx check` judges it — and include the bare `$a div 3` control, or a table of \"0 errors\" proves only that the validator never fires. Cheaper alternative deliberately NOT taken: downgrading MDL041 to a warning so it cannot block `exec`. **The generalisable trap: making a checker authoritative (refuse-before-write) turns every false positive from an annoyance into a blocked workflow** — the rules behind such a gate have to be at least as accurate as the tool they are protecting you from, and this one was measurably less accurate than `mx check` on 10 of 18 probes. Sudoku finding #49", "refs": ["#49"], "rules": ["MDL041"]}
+{"area": "mdl/catalog", "date": "2026-08-24", "symptom": "`search '<text>'` finds nothing that lives only in a **nanoflow, rule, JSON structure or mapping**, even right after `refresh catalog source`; `CATALOG.SOURCE` holds only ENTITY / ENUMERATION / MICROFLOW / SNIPPET / PAGE", "cause": "Two lists maintained in different packages drifted. `buildSource` (catalog) already collected nanoflows, rules and workflows, but `captureDescribeParallel`'s dispatch (executor) had no `rule` case and routed `\"nanoflow\"` to `describeMicroflow`, which searches `ListMicroflows()` only and so returns NotFound for every nanoflow. The worker loop then discarded both errors — `if err == nil && text != \"\" { ... }` — so the types produced zero rows and reported nothing. Measured: 114 collected, 100 inserted, the 14 dropped being exactly the 13 nanoflows + 1 rule", "file": "`mdl/catalog/builder_source.go` (`buildSource`, `runDescribes`), `mdl/executor/cmd_catalog.go` (`describeDispatch`)", "insight": "Keep the type names as constants in `catalog.SourceObjectTypes` and make the executor's dispatch a table asserted against that list, so a collector added without a dispatch case fails a test instead of silently indexing nothing. **Pin each mapping by function identity** (`runtime.FuncForPC`) — a presence-only check passes the nanoflow bug, because the wrong function is still a function. Return describe failures instead of dropping them and report them grouped by type: a whole type failing is a wiring bug, one document failing is a property of that document. Verify at the catalog layer, not via `mxcli check` — the defect needs a project, so a `.fail.mdl` cannot express it (see the Makefile's `check-mdl` note). Repro `mdl-examples/bug-tests/912-catalog-source-all-doctypes.mdl`. Issue #912", "refs": ["#912"]}
+{"area": "mdl/translations", "date": "2026-08-24", "symptom": "Nothing visibly wrong: `create translations` writes a translation that builds at 0 errors and describes back correctly, but the `Texts$Translation` elements it minted carry `$ID`s of a shape Studio Pro never produces", "cause": "`mdl/translations` minted its own id — 16 raw bytes from `crypto/rand` — instead of going through `types.GenerateID`/`types.UUIDToBlob` like every other element mxcli writes. Mendix stores an element id as a **.NET Guid**: mixed-endian, so the RFC-4122 version nibble lands at byte **7** and the variant bits at byte **8**. Raw bytes satisfy that 1 time in 64. Measured on a stock 11.13.0 app: **44,002 of 44,002** element ids are well-formed on that reading (version 4 or 5, variant `10b`), including all **1,650** translation ids the marketplace modules ship; after `mxcli exec translations.mdl`, **1 of 27** written ids was. `mx check` is silent — a Guid parses any 16 bytes — and so is DESCRIBE, because the id is never shown", "file": "`mdl/translations/text.go` (`newElementID`), against `mdl/types/id.go` (`GenerateIDErr`, `UUIDToBlob` — which is where the byte swap lives)", "insight": "Mint through `types.GenerateIDErr` + `types.UUIDToBlob`. Assert the **form**, not the presence: draw ~200 ids and require version nibble 4 at byte 7 and variant `10b` at byte 8, so a raw-random implementation cannot pass by luck (`TestNewElementID_IsAUUIDInMendixByteOrder`). Note the two measurement traps: decoding with `bson.M` (or any Go map) **loses key order**, so \"is `$ID` first\" cannot be asked that way — use `bson.D`/`bson.Raw`, or Python, whose dicts preserve insertion order; and read the version nibble at byte **7**, not 6 — at byte 6 Mendix's own ids look like uniform noise, which reads as \"Mendix does not care\" and inverts the conclusion. The paired control is the whole project: 100% conforming before the run and after the fix, 3.7% for the new ids in between. Repro `mdl-examples/bug-tests/translation-id-form.mdl`"}
+{"area": "mdl/linter", "date": "2026-08-25", "symptom": "Lint reports a clean project under rules that never ran: `--list-rules` omits the bundled Starlark rules, `-r <id>` prints `No issues found.` for a rule that did not load (or never existed), and `mxcli report` scores high. Typically when `.claude/` sits at the repo root and the `.mpr` is in a subfolder", "cause": "Three separate silences. (a) Discovery was `filepath.Dir(<the .mpr>) + /.claude/lint-rules`, so rules were found only beside the .mpr — one `.claude/` at the repo root loaded **zero** Starlark rules (measured 19 vs 48). (b) `--rules` is an allowlist applied by disabling everything it does not name, and the ids were never validated, so an unmatched id disabled all rules and the run reported success. (c) Load failures went to stdout via `fmt.Printf` and were not returned, and the directory-level error was discarded by `if err == nil`", "file": "`mdl/linter/lintrules_discovery.go` (`FindLintRulesDir`, `UnknownRuleIDs`, `MatchesRuleID`), `mdl/linter/starlark.go` (`LoadStarlarkRulesFromDir`), `cmd/mxcli/cmd_lint.go`, `cmd/mxcli/cmd_report.go`, `mdl/executor/cmd_lint.go`", "insight": "Walk up from the project for `.claude/lint-rules/`, stopping **at the repo root** — continuing to the filesystem root would let a stray `.claude/` in `$HOME` or `/tmp` supply rules to every project beneath it, which is worse than finding none because the run looks green under someone else's rules. Validate `-r` ids and exit non-zero naming the directory rules came from; match case-insensitively, since `-r conv009` previously disabled everything. Return load failures instead of printing them, and print to **stderr**. **Beware the miscount**: CONV011-CONV014 are Go built-ins, not bundle rules, so \"4 of my 29 loaded\" really means 0 of 29 and there is no stale-file bug to chase. Fix `cmd_report.go` in the same pass — it had the identical lookup and emits a score. Not expressible as a `.fail.mdl` (needs a directory layout and a project; `check-mdl` runs without one), so the guards are unit tests. Repro `mdl-examples/bug-tests/904-lint-rules-discovery.mdl`. Issue #904", "refs": ["#904"]}
+{"area": "mdl/types", "date": "2026-08-25", "raw": "| An array of **primitives** — `\"tags\": [\"a\",\"b\"]` — cannot be mapped, and `describe` leaks the storage markers (`= categories/(Wrapper)` with `Value = (Value)`), which does not parse | Mendix models it as a **Wrapper** element binding one entity per item, with the primitive on a value child at the `(Value)` marker; 34 of the 327 demo-app documents contain one. Two independent causes: mxcli's **JSON structure builder** wrote the wrong PATHS for a primitive array — wrapper at `…\\|tags\\|(Object)`, value at `…\\|(Object)\\|` with a trailing empty segment — so nothing could resolve against it; and the mapping builders stepped from an array to a hardcoded `\\|(Object)` | `mdl/types/json_utils.go` (`buildElementFromRawArray`), `mdl/executor/mapping_customhandler.go` (`arrayItemOf`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`, and `elementTypeForKind` / `isMappingObjectKind` in all four writers | **No new syntax**: an array of primitives is written like any other array and the wrapper level is GENERATED, the same way the item level is (#248, #262). Step from an array to its **actual** child rather than a hardcoded marker — `\\|(Object)` for objects, `\\|(Wrapper)` for primitives — which is what `arrayItemOf` is for. **\"Wrapper\" is an OBJECT element kind**: both writers dispatched on `Kind == \"Object\" \\|\\| Kind == \"Array\"`, so it serialized as a Value with no attribute and mxbuild reported **CE5015** \"Element '(Object)/tags/(Wrapper)' is not a Value element\" — the same trap on the DESCRIBE side, where the export printer's object branch was missing both `Wrapper` AND `Array`, printing `texts = ` and dropping the subtree. Fix the structure builder FIRST: the mapping is unreachable until the markers exist, and the two look like one bug. `(Value)` is a marker, not a member name — DESCRIBE prints the element's ExposedName (`Value`), which is what re-executing resolves against. Repro `mdl-examples/bug-tests/268-primitive-array-wrapper.mdl`, tests `mdl/executor/mapping_wrapper_test.go`. Issue #268 |", "refs": ["#248", "#262", "#268"], "ce": ["CE5015"]}
+{"area": "mdl/types", "date": "2026-08-25", "raw": "| An array of **primitives** — `\"tags\": [\"a\",\"b\"]` — cannot be mapped, and `describe` leaks the storage markers (`= categories/(Wrapper)` with `Value = (Value)`), which does not parse | Mendix models it as a **Wrapper** element binding one entity per item, with the primitive on a value child at the `(Value)` marker; 34 of the 327 demo-app documents contain one. Two independent causes: mxcli's **JSON structure builder** wrote the wrong PATHS for a primitive array — wrapper at `…\\|tags\\|(Object)`, value at `…\\|(Object)\\|` with a trailing empty segment — so nothing could resolve against it; and the mapping builders stepped from an array to a hardcoded `\\|(Object)` | `mdl/types/json_utils.go` (`buildElementFromRawArray`), `mdl/executor/mapping_customhandler.go` (`arrayItemOf`), `mdl/executor/cmd_import_mappings.go` + `cmd_export_mappings.go`, and `elementTypeForKind` / `isMappingObjectKind` in all four writers | **No new syntax**: an array of primitives is written like any other array and the wrapper level is GENERATED, the same way the item level is (#248, #262). Step from an array to its **actual** child rather than a hardcoded marker — `\\|(Object)` for objects, `\\|(Wrapper)` for primitives — which is what `arrayItemOf` is for. **\"Wrapper\" is an OBJECT element kind**: both writers dispatched on `Kind == \"Object\" \\|\\| Kind == \"Array\"`, so it serialized as a Value with no attribute and mxbuild reported **CE5015** \"Element '(Object)/tags/(Wrapper)' is not a Value element\" — the same trap on the DESCRIBE side, where the export printer's object branch was missing both `Wrapper` AND `Array`, printing `texts = ` and dropping the subtree. Fix the structure builder FIRST: the mapping is unreachable until the markers exist, and the two look like one bug. `(Value)` is a marker, not a member name — DESCRIBE prints the element's ExposedName (`Value`), which is what re-executing resolves against. Repro `mdl-examples/bug-tests/mapping-268-primitive-array-wrapper.mdl`, tests `mdl/executor/mapping_wrapper_test.go`. Issue ako/mxcli#268 |", "refs": ["#248", "#262", "ako/mxcli#268"], "ce": ["CE5015"]}
+{"area": "mdl/types", "date": "2026-08-26", "symptom": "A JSON payload with a member named `owner`, `class`, `int`, `changedDate` or any other Java keyword makes `create json structure` produce a project mxbuild REFUSES to build: **CE9524** \"JSON element '(Object)/owner' has an invalid custom name 'Owner'. Custom name should start with a letter or underscore followed by either letters, digits or underscores.\"", "cause": "`resolveExposedName` prefixes an underscore for names Mendix reserves — Studio Pro's own scheme, keeping the key's ORIGINAL case (`_id`, `_object` in OpenAI_API.JSON_OpenAI_Response) — but the list held only `{Id, Type}`. Every other reserved name went through capitalised and was rejected at build time, with nothing before that warning: `mxcli check` passes and `exec` succeeds", "file": "`mdl/types/json_utils.go` (`reservedExposedNames`, `resolveExposedName`)", "insight": "**Do not trust the CE message to name its own rule** — 'Owner' matches the character pattern it quotes perfectly. Probe instead: one structure per candidate name, one `mx check`, read the rejected list off the output. Measured on mxbuild 11.13: **53 Java keywords and literals**, the four system attribute names (Owner/ChangedDate/CreatedDate/ChangedBy), plus CurrentUser and Guid. It is **not** the entity-member reserved list — `Type` and `Id` are ACCEPTED here (they stay in the map only because Studio Pro avoids them, which is why the list is \"what Studio Pro avoids\", a superset of \"what mxbuild rejects\"). Match **case-insensitively**: Mendix's check is, since `class` derives `Class`, which is not literally a keyword and is still rejected. The author cannot rename a member of an external payload, so deriving a valid name is the only fix — refusing at check time would make the construct unusable. A customNameMap entry still wins, so a structure read back from a project keeps the name it already carries. Repro: `create json structure X snippet '{\"owner\": \"o\"}'`, then `mx check`. Tests `mdl/types/json_exposed_name_test.go`. Issue ako/mxcli#300", "refs": ["ako/mxcli#300"], "ce": ["CE9524"]}
+{"area": "mdl/types", "date": "2026-08-26", "symptom": "A JSON payload with a member named `owner`, `changedDate`, `createdDate` or `changedBy` produces a project mxbuild refuses to build: **CE9524** \"JSON element '(Object)/owner' has an invalid custom name 'Owner'. Custom name should start with a letter or underscore followed by either letters, digits or underscores.\"", "cause": "`create json structure` derives an ExposedName for every element (Studio Pro does too — 0 of 211 fixture elements have an empty one), and the derivation capitalises the initial. For a member Mendix reserves as a system attribute the derived name collides and Mendix rejects it. **The message is a red herring**: 'Owner' matches the character pattern it quotes perfectly; the real rule is the system-name collision. Isolated with a three-structure probe — `owner` and `changedDate` fail, `holder` passes", "file": "the JSON structure builder in `mdl/types/json_utils.go`; the reserved list already exists as `mendixSystemAttributeNames` in `mdl/executor/cmd_enumerations.go`", "insight": "`owner` is an ordinary member name in real REST payloads, so this is reachable from a plain `create json structure ... snippet`. Do not trust CE-message wording to name its own trigger — probe it: three one-line structures separated the system-name collision from the character pattern in one mx check. Found while building a runtime test app, not by any unit test. Filed separately", "ce": ["CE9524"]}
+{"area": "mdl/exprcheck", "date": "2026-08-27", "symptom": "`mxcli check -p app.mpr` reports `Unexpected token after expression — … (possible missing space between keywords)` with **no rule id, no file and no line**, on an expression containing a doubled apostrophe. Nothing is glued and no keyword is involved. `exec`, `DESCRIBE` and `mx check` all accept it", "cause": "`''` is how the Mendix expression language escapes an apostrophe inside a string literal (CLAUDE.md states the rule), but exprcheck's lexer scanned to the next `'` with no notion of an escape — so `'a''b'` lexed as TWO strings, `parseOr` consumed the first, and the second was reported as a leftover token", "file": "`mdl/exprcheck/lexer.go` (the `case c == '\\''` arm); the leftover report is `mdl/exprcheck/parser.go`", "insight": "Consume a **doubled** quote as part of the literal; a single one ends it. Keep the unterminated case emitting `TokError` — a lexer that just swallows to end-of-input passes every escape test while accepting a broken literal, so assert that control at the lexer. **It only reproduces WITH `-p`**: exprcheck runs when a project is supplied and `make check-mdl` runs without one, which is why this repo's own MDL gate never saw it across six of the reporter's builds — an `mdl-examples/` script alone would NOT have caught it. The message is a red herring by construction: the leftover reporter cannot know why a token is left over, so any lexer gap surfaces as \"glued keywords\". ako/mxcli-ledger #131", "refs": ["#131"]}
+{"area": "mdl/types", "date": "2026-08-27", "symptom": "A JSON member with any character outside `[A-Za-z0-9_]` — `$type` (43 occurrences in the demo apps), `research%3Aread`, `https%3A//…` — makes `create json structure` produce a project mxbuild refuses to build (**CE9524**); and the structure root carries `MinOccurs 0` where Studio Pro writes `1`", "cause": "`resolveExposedName` only CAPITALISED the member name, never sanitised it, so an invalid character reached the stored ExposedName. Separately `rootMinOccurs` was pinned to 0 with a documented reason: writing 1 used to make every mapping bound to the structure fail **CE5015** \"Attribute 'MinOccurs' does not match schema element\" because the mapping serializers hardcoded 0", "file": "`mdl/types/json_utils.go` (`sanitizeExposedName`, `resolveExposedName`, `rootMinOccurs`)", "insight": "**The MinOccurs blocker was removed by a different fix**: #277/#279 made every mapping element mirror the bound schema element, so both sides now agree and the root can carry the 1 — check whether a documented \"cannot change this\" still holds before accepting it, because the constraint may have been fixed elsewhere. Do not revert one without the other; they are cross-validated and CE5015 is what disagreement looks like. The sanitising rule is Studio Pro's, read off CRS_ModelSimulator: every character outside `[A-Za-z0-9_]` becomes `_`, then the initial is capitalised (`confidence(No)` → `Confidence_No_`, `first(Importance)_Payload (kg)` → `First_Importance__Payload__kg_`); a LEADING DIGIT is prefixed rather than replaced, since the name must start with a letter or underscore and `1st` → `_st` would lose a character. Unlike the reserved-name case (#300), CE9524's message is accurate here. **The array-item naming in the same issue was NOT reproduced, deliberately**: Studio Pro produces both real singularisation (`Data`→`Datum`, `Categories`→`Category`) and a flat `JsonObject`/`JsonObject_2` across the nine pinned structures, and it is not a collision fallback — nothing named `Embedding` exists in the structure whose item is `JsonObject`. There is no single rule to copy, so picking one would match some real documents and break others. Repro `mdl-examples/bug-tests/mapping-272-json-structure-metadata.mdl`, tests `mdl/types/json_exposed_name_test.go`. Issue ako/mxcli#272", "refs": ["#277", "#279", "#300", "ako/mxcli#272"], "ce": ["CE5015", "CE9524"]}
+{"area": "mdl/offlinepaths", "date": "2026-08-27", "symptom": "Adding an offline navigation profile makes a build fail with **CE6206** (\"Attribute paths with multiple steps cannot be used on pages that are accessible through an offline-based navigation\") in pages the statement never mentioned", "cause": "An offline profile restricts every page it can REACH to at most one association hop. The pages were valid before; creating the profile is what invalidated them, and mxcli writes multi-step paths happily and said nothing", "file": "`mdl/offlinepaths/scan.go` (the stored-document scan), `mdl/executor/offline_profile_warning.go` (the report), `mdl/types/navigation_profile_kind.go` (`IsOfflineProfileKind`)", "insight": "**The threshold is TWO hops, not \"any indirect reference\"** — one hop is explicitly allowed, pinned by a control inside one page where mxbuild flags column 2 of 2 and accepts column 1. Scan for the stored `DomainModels$AttributeRef` whose `EntityRef.Steps` holds ≥2 steps, keying on `$Type` and not on a table of widget property names — a DataGrid2 column's binding is nested several levels inside a `CustomWidgets$WidgetValue`, so a property-name scan reports a clean project for the widget people actually use. Do NOT match every `IndirectEntityRef`: a data source that navigates an association is a different element and CE6206 does not reject it. Report as a **warning**, never a refusal — reachability needs the whole page graph (home pages, menu items, and every page those open), which mxcli does not walk, and the end-to-end control shows mxbuild at 0 errors while the flagged page is unreachable and CE6206 the moment the profile's home page points at it. ako/mxcli-maintenance", "ce": ["CE6206"]}
+{"area": "mdl/types", "date": "2026-08-28", "symptom": "`rename entity` / `rename module` reports success but prints no \"Updated N reference(s)\" line, and the next `mx check` fails **CE0174** \"Cannot resolve object name 'MyFirstModule.Period'\" on a view entity", "cause": "A view's OQL is the ONE place a qualified name is stored **embedded in a sentence** rather than as a property of its own. Both engines' rename walkers match a string that *equals* the old name or *begins with* it — correct for a BY_NAME property, and blind to `from MyFirstModule.Period as p` mid-query", "file": "`mdl/types/oql_rename.go` (`RewriteOQLQualifiedName`), wired at the `Oql` key in `mdl/backend/modelsdk/infrastructure_write.go` (`replaceQNInDocCounted`) and `sdk/mpr/writer_rename.go` (`replaceStringsInDoc`)", "insight": "**Ask where each reference is STORED, not just which documents reference it** — a scan built for whole-string properties silently covers 0 of the embedded ones, and reports 0, which reads like \"nothing referenced it\". Scope the rewrite to the `Oql` key: a blanket substring replace across every string reaches documentation and expressions, where a similar-looking name is not a reference. Three name-shaped ways it goes wrong, all covered by tests: a **longer name starting with the old one** (`M.PeriodDetail`) must not move, a **quoted** reference must stay quoted (bare is CE0174 — quoting is how a view names an entity called after an OQL reserved word), and a **module rename arrives as a prefix pair** (`\"Old.\" -> \"New.\"`) with no entity half to split, so it needs its own path or module rename stays broken while entity rename looks fixed. Where a query-local alias is spelled exactly like the module, the rewrite **declines** rather than guessing — 0 references reported is a visible non-event, a corrupted query is not. Both engines, one shared rewrite. ako/mxcli-captrack", "ce": ["CE0174"]}
+{"area": "mdl/translations", "date": "2026-08-30", "raw": "| `create or modify translations in <Module> for <lang>` reports success (\"Set 212 nl_NL translation(s) across 20 document(s)\") and the app's pages switch language while the **menu does not** | `mdl/translations/outofscope.go` (new), `mdl/executor/cmd_translations.go`, `cmd/mxcli/syntax/features_misc.go` | The **navigation is a project-level document**, not a module one, so `in <Module>` never reaches it. Measured on the reporting project: 151 strings scoped against 546 unscoped, and re-running the same file unscoped landed 65 more across 22 further documents. Nothing warned — the document count was the only tell, and only if you knew what number to expect. A scoped run now names **the file's own entries** it did not reach (`translations.OutOfScope`), not \"the project has other strings\", which is true of every scoped run and would warn forever — the per-module workflow is exactly what the scoping exists to support. Second, load-bearing half: those entries were previously swept into the **drift** warning, whose premise (\"no text has this as its source\") is *false* about them — they matched, out of scope. They are subtracted from it, so \"the text may have been deleted\" is only said where it is true. Controls: an unscoped run of the same file reports nothing new and lands the strings; a key matching nothing anywhere is still reported as drift. Reported as ledger #137 |", "refs": ["#137"]}
diff --git a/.claude/skills/fix-issue/findings/mdl-visitor.jsonl b/.claude/skills/fix-issue/findings/mdl-visitor.jsonl
new file mode 100644
index 0000000000..b5ddf97143
--- /dev/null
+++ b/.claude/skills/fix-issue/findings/mdl-visitor.jsonl
@@ -0,0 +1,29 @@
+{"area": "mdl/visitor", "date": "2026-07-30", "symptom": "`alter entity … add <name>: <type>` (missing the `attribute` keyword) fails with an opaque `no viable alternative at input 'add<Name>'`", "cause": "ALTER ENTITY requires the `attribute` keyword (SQL-shaped); the raw ANTLR error doesn't say so", "file": "`mdl/visitor/visitor.go` (`enhanceErrorMessage` / `addMissingAttributeRe`)", "insight": "Source-aware hint: when the offending line is `add <word>:` and `<word>` isn't a real clause keyword (attribute/column/index/event/value/…), append the correct `add attribute <name>: <type>` form. Gated to the primary \"no viable alternative\" error. Test `TestAlterEntityMissingAttributeKeywordHint`. traceops #16", "refs": ["#16"]}
+{"area": "mdl/visitor", "date": "2026-07-01", "symptom": "`create enumeration … (\"Value\" = 'Caption')` fails with cryptic `mismatched input '=' expecting ')'`; user blames the *quotes*", "cause": "Not a quoting bug — enum value names quote fine (`enumValueName` accepts `QUOTED_IDENTIFIER`). The `=` is invalid: MDL enum values are `Value 'Caption'` (or `Value caption 'Caption'`), no equals sign", "file": "`mdl/visitor/visitor.go` (`enhanceErrorMessage`/`looksLikeEnumEquals`)", "insight": "Add an error hint keyed on `mismatched input '=' expecting ')'` (specific to enum value lists — attribute-default `=` gives a different message) pointing at the `=`. Clarify in `check-syntax.md` that captions use `Name 'Caption'`, never `=`"}
+{"area": "mdl/visitor", "date": "2026-07-25", "symptom": "A genuine parse error on a short lowercase MDL keyword/identifier (`mismatched input 'on'`, `'in'`, `'as'`, `'to'`, `'by'`, …) is misdiagnosed with the \"unescaped apostrophe\" hint, sending the user to look for a quote that isn't there", "cause": "`looksLikeUnescapedApostrophe` matched **any** 1–4 char lowercase token as a contraction leftover, so real short keywords tripped it", "file": "`mdl/visitor/visitor.go` (`looksLikeUnescapedApostrophe`, `contractionSuffixes`)", "insight": "Match only the fixed contraction-suffix set (`s`/`t`/`d`/`m`/`re`/`ve`/`ll` — the leftovers from it's/don't/he'd/I'm/you're/we've/you'll), not arbitrary short lowercase words. Real apostrophe errors still hint; `on`/`in`/`as`/`to`/`by` no longer do. Findings #4", "refs": ["#4"]}
+{"area": "mdl/visitor", "date": "2026-07-29", "symptom": "Microflow `set $x = <expr>` passes `mxcli check` but `mx check` reports a generic CE0117: (#17) `/` used as division (`$Dec / 2`), (#18) a decimal literal loses its fraction (`2.0` → `2`, breaks Decimal typing), or (#19) a small decimal becomes scientific notation (`0.000001` → `1e-06`, which Mendix rejects)", "cause": "(#18/#19) the value is re-serialized from the AST when `shouldPreserveExpressionSource` returns false and the AST serializer is lossy for decimals (`%v` on a float64 drops `.0` and uses sci-notation). (#17) **MDL division is `div`, not `/`** — `/` is the member-access separator, so `/`-as-division is a user error that mxcli silently wrote instead of flagging. **Do NOT preserve source on `/`** — that source-freezes every legit association path (`$Order/Assoc/Name` → regressed `TestAssociationNavParsing`)", "file": "`mdl/visitor/visitor_microflow_statements.go` (`shouldPreserveExpressionSource`); `mdl/executor/validate_microflow.go` (`checkDivisionSlash`/`exprHasSlashDivision`, MDL045)", "insight": "(#18/#19) preserve raw source only when the expression contains a **decimal literal** (`.` adjacent to a digit) — same philosophy as the XPath-where path. (#17) add **MDL045**: walk the expression tree for a `BinaryExpr` with operator `/` (`$Dec / 2`, `(...) / $x`) and reject with \"use `div`\". The variable/variable form `$Dec / $Dec2` parses as a member-access path (the `$` on the RHS is stripped), so the visitor narrowly preserves source when a `/` is immediately followed by `$` (a real association path never has `$` after `/`) and MDL045 flags it by scanning the preserved source for a `/ $` **outside string literals** (`exprHasSlashDollarDivision` / `sourceHasSlashDollarDivision`). **Round-2 gap (ledger #17 re-test): the `$a / $b` division must be caught even when EMBEDDED in a larger expression** — `$a / $b + 1`, `round($a / $b)`, `$a / $b * 100` — where it degrades to a member-path `AttributePathExpr` nested under a `BinaryExpr`/`FunctionCallExpr`, so the structural `/`-BinaryExpr walk (which only sees literal division) misses it. The earlier `exprIsSlashDollarDivision` matched only when the SourceExpr **directly** wrapped an AttributePathExpr, so embedded division slipped through silently. Fix: walk the tree for any `SourceExpr` and scan its raw source for `/ $` with a string-literal-aware scanner (skips `'path/$x'`). [verification round: the `$a / $b` form must be caught by bare `check`, not deferred to `--references`.] **Lesson: `/` is overloaded (path separator vs the division a user *wanted*) — a blanket source-preserve on `/` corrupts the common case to rescue the rare misuse; reject the misuse explicitly instead. And an operator misuse that \"degrades to a path\" can hide anywhere in an expression tree, not just at its root — detect it from source, walking every sub-expression.** Tests: `TestShouldPreserveExpressionSource_Decimals`, `TestValidateMicroflow_SlashDivision` (incl. embedded cases + string-literal guard); repros `mdl-examples/bug-tests/ledger-17-19-expression-serialization.mdl` (pass) + `ledger-17-slash-division.fail.mdl` (MDL045, incl. embedded). Ledger findings #17–19 (round 2)", "refs": ["#17", "#18", "#19"], "ce": ["CE0117"], "rules": ["MDL045"]}
+{"area": "mdl/visitor", "date": "2026-06-20", "symptom": "Quoted where-clause `where '[Title=''abc'']'` (with `''` escapes) fails `mx check` CE0161 \"Error(s) in XPath constraint.\" on every retrieve/datasource — but inline `where [Title='abc']` is clean. `mxcli exec` reports no error", "cause": "The quoted string un-quoted correctly to `[Title='abc']`, but the visitor preserved the **raw** token (outer quotes + doubled `''`) as the constraint source; the builder then bracket-wrapped it → `['[Title=''abc'']']`. Affected the microflow retrieve and page datasource `expression`-form paths (the `grant … where '…'` path was fine — it uses `unquoteString` directly)", "file": "`mdl/visitor/visitor_microflow_statements.go` (`buildRetrieveWhereExpression`) + `mdl/visitor/visitor_page_v3.go` (`bracketedXPathFromExpr`, datasource WHERE)", "insight": "When the whole WHERE clause is a bare string `LiteralExpr`, use its **unquoted** `.Value` as the constraint source (bracket-wrap only if it isn't already `[...]`); don't re-serialize via `xpathExprToString`/preserve-raw-source (which re-doubles the `''`). Verify both forms store identically with `mx check` = 0 errors. Issue #642", "refs": ["#642"], "ce": ["CE0161"]}
+{"area": "mdl/visitor", "date": "2026-06-30", "symptom": "`PopupWidth: 0` / `PopupHeight: 0` rejected (\"must be a positive number\") on CREATE or ALTER PAGE; user can't make an auto-size pop-up", "cause": "0 is actually Studio Pro's **default** for pop-up dimensions (auto-size) — verified live on 11.12: a pg-created PopupLayout page stores 0/0 and `mx check` = 0 errors. Two validators rejected ≤0, and both writers coerced ≤0→600, so even an allowed 0 became 600", "file": "`mdl/visitor/visitor_page_v3.go` (`popupDimensionValue`) + `mdl/backend/pagemutator/mutator.go` (`coercePopupDimension`) + `mdl/executor/cmd_pages_builder_v3.go` (builder default) + `sdk/mpr/writer_pages.go` & `mdl/backend/modelsdk/page_write.go` (`popupDimension`) + `mdl/executor/cmd_pages_describe.go`", "insight": "Relax both validators to reject only **negative**; default the builder to **0** (not 600, matching Studio Pro); drop the `≤0→600` coercion in both writers (clamp only negatives to 0); have DESCRIBE suppress only the real default 0 (emit an explicit 600). No `*int` needed — 0 is a valid stored value. Bug-test `mdl-examples/bug-tests/713-popup-zero-dimensions.mdl`. Issue #713", "refs": ["#713"]}
+{"area": "mdl/visitor", "date": "2026-06-20", "symptom": "`Visible: [Attr != '']` / `Editable: […]` on a widget (CONTAINER, textbox, …) → CE0117 \"Error(s) in expression.\" in Studio Pro on the legacy engine, and silently *ignored* on the modelsdk engine", "cause": "Two bugs (NOT BSON structure): (1) the expression was emitted with a bare attribute reference (`Name != ''`) — a Mendix client expression must root attributes in the widget data context (`$currentObject/Name != ''`); (2) the modelsdk codec hardcoded `ConditionalVisibilitySettings` to null, dropping the expression entirely", "file": "`mdl/visitor/visitor_page_v3.go` → `buildConditionalExpression`/`conditionalExprToString`; `mdl/backend/modelsdk/widget_write.go` → `applyWidgetBase` + TypeDefaults", "insight": "(1) For `VISIBLE`/`EDITABLE` xpath constraints, build the xpath AST and serialize via `conditionalExprToString`, which prefixes bare `IdentifierExpr` / non-variable-rooted `XPathPathExpr` with `$currentObject/` (leaves `$…`-rooted paths, literals, functions, enum qualified-names untouched). Do **not** apply this to datasource `where` clauses (those are real XPath). (2) In `applyWidgetBase`, type-assert `SetConditionalVisibilitySettings`/`SetConditionalEditabilitySettings` and emit a settings element when the model has one; register `Forms$ConditionalVisibilitySettings`/`…EditabilitySettings` TypeDefaults (`NullFields: Attribute,SourceVariable`; `MandatoryLists: Conditions[,ModuleRoles]`) so the null-when-unset slots stay null (the encoder only fills NullFields when not already emitted). **ALTER PAGE** had the same gap (`SET Visible = [expr]` parsed as a `propertyValueV3` array and silently no-op'd): add `VISIBLE/EDITABLE EQUALS xpathConstraint` alternatives to `alterPageAssignment` (regen grammar), route to `VisibleIf`/`EditableIf` in `buildAlterPageAssignment` (reusing `buildConditionalExpression`), and add `VisibleIf`/`EditableIf` cases to `setRawWidgetPropertyMut` (`mdl/backend/pagemutator/mutator.go`) that build the settings node via `setWidgetConditionalSettingMut` (rejecting editability on non-input widgets). The shared mutator covers both engines. Verify both engines with `mx check` = 0 errors. Issue #627", "refs": ["#627"], "ce": ["CE0117"]}
+{"area": "mdl/visitor", "date": "2026-06-21", "symptom": "`visible: [$currentObject/Status = Mod.Enum.Value]` stored as `… = 'Value'` (string) → MxBuild CE0117 \"Error(s) in expression\" (v0.13.0 regression; both engines)", "cause": "`conditionalExprToString` (added with #627) sent a qualified-enum `QualifiedNameExpr` to its `default` case → `xpathExprToString`, which converts a 3-part enum name to a string literal. Correct for an XPath *datasource* constraint (DB level), WRONG for a *client* visibility/editability expression (compares to the qualified enum value)", "file": "`mdl/visitor/visitor_page_v3.go` → `conditionalExprToString`", "insight": "Add an explicit `*ast.QualifiedNameExpr` case returning `e.QualifiedName.String()` (the qualified literal) before the `default`. Leaves the datasource `where` path (`buildXPathString`/`xpathExprToString`) untouched, so DB-level enums still stringify to `'Value'`. Applies to CREATE and ALTER (both use `conditionalExprToString`). Verify the datasource enum still stores `'Value'` and the visibility enum stays qualified; `mx check` = 0", "refs": ["#627"], "ce": ["CE0117"]}
+{"area": "mdl/visitor", "date": "2026-05-23", "raw": "| `DESCRIBE` of a document type omits a property the user set in the CREATE (e.g. enum-level `/** doc */` vanishes after a roundtrip; `CREATE OR REPLACE` silently runs as plain CREATE for some types) — even though the AST struct has the field, the model has the field, the writer serialises it, and DESCRIBE prints it | Visitor never copied the parsed value into the AST struct — every layer below the visitor is wired but the visitor's `ExitCreateXxxStatement` is missing the assignment | `mdl/visitor/visitor_<type>.go` → `ExitCreateXxxStatement` | Diff the visitor against a known-good sibling (e.g. enumeration vs constant). Standard wiring: `stmt.Documentation = findDocCommentText(ctx)` for doc-comments; `if createStmt.OR() != nil && (createStmt.MODIFY() != nil \\|\\| createStmt.REPLACE() != nil) { stmt.CreateOrModify = true }` for OR MODIFY/REPLACE. When adding a new CREATE statement, grep `mdl/visitor/visitor_constant.go` and copy these two blocks verbatim. Issue #393 |", "refs": ["#393"]}
+{"area": "mdl/visitor", "date": "2026-07-02", "symptom": "A **quoted** association/attribute name in a microflow `SET`/`Change` target (`SET $x/Module.\"Assoc\" = $y`, following the \"always quote identifiers\" guidance) passes `mxcli check` and `exec` but corrupts the `.mpr` — Studio Pro/MxBuild fails to load with `StorageLoadException: … 'Module.\"Assoc\"' is not a valid AttributeIdentifier`. The unquoted form (`SET $x/Module.Assoc = $y`) is fine", "cause": "The SET target was captured via `ap.GetText()` (raw source, quotes intact) and later sliced on `/` into the member name; `resolveMemberChange` then compared the quoted `\"Assoc\"` against the unquoted domain-model `a.Name`, never matched, and wrote the quoted string verbatim into `AttributeQualifiedName`. Attributes in `CREATE (…)` were unaffected because that path unquotes per-segment", "file": "`mdl/visitor/visitor_microflow_statements.go` (`buildSetStatement`) + `mdl/visitor/visitor_microflow_actions.go` (`buildAttributePathFromContext`, `attributePathTargetText`) + `mdl/executor/cmd_microflows_builder_actions.go` (`resolveMemberChange`, `isValidMemberIdentifier`)", "insight": "Build the SET target from the structured path with each qualified-name segment unquoted (`getQualifiedNameText`, not `qn.GetText()`), so `Target` is normalized (`$x/Module.Assoc`) at parse time for every downstream consumer (check + exec). Defense-in-depth: `resolveMemberChange` rejects a non-empty member name that isn't a valid identifier (`isValidMemberIdentifier`) so a leaked quote errors instead of corrupting. Tests: `mdl/visitor/visitor_microflow_set_quoted_test.go`, `mdl/executor/cmd_microflows_member_identifier_test.go`. Repair a corrupted microflow in place with `CREATE OR REPLACE MICROFLOW …` (unquoted form)"}
+{"area": "mdl/visitor", "date": "2026-07-08", "symptom": "A **quoted** attribute/association name inside an *expression* — a microflow decision/`if`/`while`/`return` (`if $Expense/\"Justification\" != empty`), a widget `contentparams` entry (`contentparams: [{1} = \"Amount\"]`), a `visible:`/`editable:` expression (`visible: [ \"Amount\" > 1000 ]`), or an **XPath database datasource WHERE** (`datasource: database from M.E where [ \"Status\" = 'Submitted' ]`) — passes `mxcli check` (and `--references`). The first three fail MxBuild \"Error(s) in expression\"; the **datasource WHERE is the worst variant** — it *also* passes MxBuild, then **silently returns zero rows at runtime** because Mendix reads the quoted `\"Status\"` as the string literal `'Status'`, making the constraint `'Status' = 'Submitted'` always false. The unquoted form is fine. Sibling of the SET/Change-**target** row above, but for expression contexts (the \"always quote identifiers\" guidance is parser-safe, not platform-safe here)", "cause": "Two sub-causes. (a) Expression contexts stored the **raw source text verbatim** — `SourceExpr.Source` from `extractOriginalText` (microflow), `expr.GetText()` (contentparams), the serialized visibility string. (b) The **inline-bracket XPath** path built member names via `buildXPathQualifiedName` (`words[i].GetText()`, no unquote) → an `IdentifierExpr{Name:\"\\\"Status\\\"\"}` that `xpathExprToString` re-emits verbatim. Either way the quotes leaked, whereas binding contexts route each identifier through `unquoteIdentifier`. The general (non-XPath) expression AST was already unquoted", "file": "`mdl/visitor/visitor_helpers.go` (`stripExpressionIdentifierQuotes`) + `mdl/visitor/visitor_microflow_statements.go` (`buildSourceExpression`, `buildXPathSourceExpression`, `buildRetrieveWhereExpression`) + `mdl/visitor/visitor_page_v3.go` (`buildConditionalExpression`, `buildParamAssignmentV3`) + `mdl/visitor/visitor_xpath.go` (`buildXPathQualifiedName`)", "insight": "Strip double-quote/backtick identifier quotes at the source. For raw-text slots: `stripExpressionIdentifierQuotes` (tracks single-quote string state incl. `''` escapes, so `'he said \"hi\"'` is untouched — safe because in Mendix expr/XPath only identifiers are double-quoted). For the inline-bracket XPath AST: `unquoteIdentifier` each `xpathWord` in `buildXPathQualifiedName` (root fix, feeds datasource WHERE + inline retrieve + conditional visibility); guard the `empty`/`true`/`false` special-value switch to fire only on the **unquoted** form so a quoted `\"empty\"` stays a member name. `dbSource.XPathConstraint = ds.Where` verbatim, so the visitor value is the persisted BSON constraint. Not caught by the expression **type** checker (`PROPOSAL_expression_type_checking.md`) — it works on the clean AST, not the raw string, and is microflow-scoped. Tests: `mdl/visitor/visitor_expr_quoting_test.go`; bug-test `mdl-examples/bug-tests/expr-quoted-identifiers.mdl`"}
+{"area": "mdl/visitor", "date": "2026-07-11", "symptom": "`IF … ELSIF … ELSE … END IF` silently drops every ELSIF arm on write — DESCRIBE round-trips `if … else …` with the middle arms gone (read path unchanged by the fix ⇒ the arm was absent from the stored model — dropped on write); no error from `check`/`exec` (both engines)", "cause": "`buildIfStatement` read only `exprs[0]`/`bodies[0]` and the trailing ELSE body; the grammar's `(ELSIF expression THEN microflowBody)*` pairs were never visited", "file": "`mdl/visitor/visitor_microflow_statements.go` (`buildIfStatement`)", "insight": "Lower each ELSIF arm into a nested `IfStmt` in the ELSE branch of the arm before it (built innermost-first) — Mendix has no native elsif, nested exclusive splits are the canonical shape. Guarded by visitor tests (chain, no-else, plain-if regression) + `mdl-examples/bug-tests/745-elsif-arms-dropped.mdl`. Issue #745", "refs": ["#745"]}
+{"area": "mdl/visitor", "date": "2026-07-26", "raw": "| `retrieve … where [Seq = $Game/MoveSeq + 1]` fails with a bare `mismatched input '+' expecting ']'` — no hint that Mendix XPath can't compute values (this is a Mendix limitation, not an mxcli bug) | Mendix XPath constraints take a literal/token/variable/path on the value side, never an arithmetic expression; the parse error named the token but not the cause | `mdl/visitor/visitor.go` (`enhanceErrorMessage`, `looksLikeXPathArithmetic`/`xpathArithmeticRe`) | Do NOT add grammar support (mxbuild would still reject the XPath). Add an error hint keyed on `mismatched input '<+|*|div|mod>' expecting ']'` (`expecting ']'` only occurs inside a `[…]` constraint) explaining the limitation and the workaround: compute into a variable first, then compare. Also documented in `xpath-constraints.md`. Bug-test `mdl-examples/bug-tests/f8-xpath-arithmetic.fail.mdl`. Findings #8 |", "refs": ["#8"]}
+{"area": "mdl/visitor", "date": "2026-07-29", "symptom": "**Attribute-over-association navigation in a microflow EXPRESSION** (`$T/Mod.Assoc/Attr` in a Change Variable / if-condition / return) passes `mxcli check` but `mx check` fails with **CE0117** \"Error(s) in expression\". Trips hardest when the module or entity name ends in a digit (`L48.`, `Account2.`) or when a decimal literal co-occurs (`$T/Mod.Assoc/Bal + 2.0`). Studio Pro supports this pattern", "cause": "Mendix expression syntax needs the **target-entity step** in the path (`$T/Mod.Assoc/Mod.Entity/Attr`); the builder inserts it via `resolveAssociationPaths`→`resolvePathSegments`. Two bugs skipped that insertion: (1) `shouldPreserveExpressionSource` treated a `.` **preceded by a digit** as a decimal literal, so a name segment ending in a digit froze the whole expression's source and bypassed resolution (source is written verbatim); (2) a **legitimately** source-frozen expression (real decimal / whitespace) also bypassed resolution, so association nav + decimal in one expression broke even for non-digit modules", "file": "`mdl/visitor/visitor_microflow_statements.go` (`shouldPreserveExpressionSource` + `dotIsQualifiedNameSeparator`/`isIdentByte`); `mdl/executor/cmd_microflows_builder.go` (`resolveAssociationPaths` SourceExpr arm + `collectAttributePaths`)", "insight": "(1) A `.` is a decimal point only when its adjacent digit run is a standalone number — NOT when the preceding token contains a letter/underscore (a qualified-name segment). `dotIsQualifiedNameSeparator` walks back over ident chars; a letter/`_` means name, not decimal. (2) For a source-preserved `SourceExpr`, still rewrite association paths **inside the raw source**: for each `AttributePathExpr`, `expressionToString(orig)` vs `expressionToString(resolve(orig))`; if they differ, `strings.ReplaceAll` in the source. Keeps decimal/whitespace fidelity AND inserts the entity step. Tests: `TestShouldPreserveExpressionSource_Decimals` (digit-module cases); example `mdl-examples/bug-tests/ledger-48-assoc-nav-digit-module.mdl`. **Verified: `mx check` → 0 errors on 11.12.1** for plain nav, if-then-else enum compare, and decimal-mixed. **Lesson: a heuristic that keys on a single character (`.`→decimal) collides with other grammar (qualified names); and \"preserve source\" and \"resolve semantics\" are in tension — a frozen source still needs its association paths fixed.** Ledger finding #48 (root cause)", "refs": ["#48"], "ce": ["CE0117"]}
+{"area": "mdl/visitor", "date": "2026-07-29", "symptom": "`set $Match = contains($Hay, $Needle)` over two **String** values was serialized as a **List operation** activity 'Contains', so string `contains(haystack, needle)` was unusable: a pre-declared Boolean `$Match` collided (**CE0111** \"Duplicate variable name\"), and a String input to a list op is otherwise rejected (CE0023/CE0097). `contains` in an IF condition worked (stayed an expression)", "cause": "`contains` is overloaded — a LIST operation `contains(list, object)` **and** a STRING function `contains(haystack, needle)` — but the visitor unconditionally rewrote `set $x = contains(...)` into a `ListOperationStmt`, **dropping literal arguments** (`extractVariableName` returns \"\" for a literal). A list operation CREATES its output variable; the string function assigns to a pre-declared one", "file": "`mdl/visitor/visitor_microflow_statements.go` (`buildSetStatement` CONTAINS case + `isPlainVariableArg`) + `mdl/executor/cmd_microflows_builder_actions.go` (`addListOperationAction`) + `mdl/executor/cmd_microflows_builder_validate.go` (ListOperationStmt case)", "insight": "**Write-path fix, two parts.** (1) Visitor: a literal/computed argument means the string function unambiguously → fall through to `MfSetStmt` (a Change Variable value expression); both-plain-variables stays a `ListOperationStmt` (ambiguous, kind unknown at parse). (2) Flow builder: when `declaredVars[InputVariable] == \"String\"`, emit a **Change Variable** action carrying `contains($In, $Second)` instead of a `ContainsOperation`; the validate pre-pass mirrors this (validate the target IS declared, don't flag CE0111 duplicate). Genuine list form (list var + object var) unchanged. Tests `TestContainsOverloadParsing` (visitor), `TestBuildContains_StringVsList` (builder); example `mdl-examples/bug-tests/ledger-53-string-contains.mdl`. **Verified: `mx check` → 0 errors on 11.12.1** for literal-arg, two-String-var, and genuine-list forms. Ledger finding #53", "refs": ["#53"], "ce": ["CE0023", "CE0097", "CE0111"]}
+{"area": "mdl/visitor", "date": "2026-07-29", "symptom": "`set $At = find($Raw, '\"id\":\"')` — the STRING function `find(haystack, needle)` (substring index) — was serialized as a List operation activity 'Find by expression', so a pre-declared `$At` collided (**CE0111** \"Duplicate variable name 'At'\"). String `find()` was unusable. Same overload trap as #53 (contains)", "cause": "`find` is overloaded — the LIST operation `find(list, condition)` (filter by a boolean condition) and the STRING function `find(haystack, needle)` → index — but the visitor unconditionally rewrote `set $x = find(...)` into a `ListOperationStmt` (list find), and a list op CREATES its output variable", "file": "`mdl/visitor/visitor_microflow_statements.go` (`buildSetStatement` FIND case + `isStringLiteralArg`) + `mdl/executor/cmd_microflows_builder_actions.go` (`addListOperationAction`) + `mdl/executor/cmd_microflows_builder_validate.go` (ListOperationStmt case)", "insight": "**Write-path fix, mirrors #53.** (1) Visitor: a **string-literal** second argument (you never filter a list by a bare string literal) means the string function → fall through to `MfSetStmt`; a boolean condition or both-plain-variables stays a `ListOperationStmt`. (2) Flow builder + validate pre-pass: when `declaredVars[InputVariable] == \"String\"`, emit a **Change Variable** carrying `find($in, <arg1>)` (arg1 is stored in the stmt's `Condition`) instead of a list FindOperation, and validate the target as a pre-declared SET (no CE0111). The contains and find String-input handling now share one branch. Tests `TestFindOverloadParsing` (visitor), `TestBuildContains_StringVsList` find cases (builder); example `mdl-examples/bug-tests/ledger-63-string-find.mdl`. **Verified: `mx check` → 0 errors on 11.12.1** for literal-arg, two-String-var, and genuine-list-condition forms. Ledger finding #63", "refs": ["#53", "#63"], "ce": ["CE0111"]}
+{"area": "mdl/visitor", "date": "2026-08-06", "symptom": "Quoted identifiers inside a `create import mapping { }` / `create export mapping { }` body produce **CE1613** \"The selected entity `'Mod.\"Entity\"'` no longer exists\" on every reference, while the same quoting works everywhere else. `mxcli exec` reports success with no warning", "cause": "The mapping-body builders read entity/association names with `ctx.QualifiedName().GetText()`, which returns **raw parse text including the quotes**, instead of `buildQualifiedName` (which strips them via `identifierOrKeywordText`, as the rest of the visitor does)", "file": "`mdl/visitor/visitor_import_export_mapping.go` (`buildImportRootElement`, `buildImportChild`, `buildExportRootElement`, `buildExportChild` — five sites: root entity, nested association + entity, value-transform converter)", "insight": "Route every qualified name through `buildQualifiedName(...).String()`. **The error message names the bug**: `'Mod.\"Entity\".RouteId'` mixes a *quoted* entity with an *unquoted* attribute, because the attribute half already went through `identifierOrKeywordText` — when a stored name is half-stripped, one of the two readers is raw. **Generalisable — the shape to look for**: `GetText()` on a parser context is almost always wrong for a name; it is the raw source slice, so any lexical decoration (quotes, whitespace) survives into the model. Grep for `.GetText()` next to `QualifiedName` whenever a reference looks right in the script but not in the .mpr. Repro `mdl-examples/bug-tests/842-mapping-quoted-identifiers.mdl`; verified end-to-end (`mx check` 11.13.0: 3 errors → 0). Issue #842", "refs": ["#842"], "ce": ["CE1613"]}
+{"area": "mdl/visitor", "date": "2026-08-09", "symptom": "A `--` comment written between two operands of a Mendix expression ends up **inside** the expression; the build fails **CE0117** \"Error(s) in expression\". `mxcli check` passes and `DESCRIBE` round-trips the comment, so nothing before mxbuild objects", "cause": "`extractOriginalText` reads the raw input stream between two token positions — which is exactly what preserves an expression's spacing, and also drags in every token the lexer sent to a hidden channel. MDL's `--` and `/* */` are `-> skip`, so they never appear in `ctx.GetText()` but always appear in the source slice", "file": "`mdl/visitor/visitor_helpers.go` (`stripMDLComments`, `extractExpressionText`), applied at the six microflow-expression sites in `visitor_microflow_statements.go` / `visitor_microflow_actions.go`", "insight": "**The ANTLR trap: `ctx.GetText()` excludes hidden tokens, a source-interval slice includes them.** Any code reaching for original text to preserve formatting inherits every comment in that span. **Replace a comment with whitespace, never with nothing** — `1 --c\\n+ 2` must not become `1+ 2`, and `'a'--c\\n'b'` must not weld into one token. **Respect single-quoted strings**: a Mendix string may legitimately contain `--` or `/*`, and stripping those corrupts the value (tested both, plus the `''` escape that keeps a string open). **Left OQL alone on purpose** — `visitor_entity.go` uses the same helper for view-entity queries, where `--` is legitimate SQL comment syntax; stripping it would change a different language's meaning. **The unit test alone would not have caught a wiring mistake**: it still passed with `extractExpressionText` bypassed, and only the mxbuild run (1 error → 0, same script, same project) proved the call sites were converted. Tests `visitor_strip_comments_test.go`, repro `mdl-examples/bug-tests/comment-in-expression.mdl`. mxcli-formula1 §34 / suggested issue 11", "ce": ["CE0117"]}
+{"area": "mdl/visitor", "date": "2026-08-13", "symptom": "`mxcli check` on a script containing `log 'msg' with ()` **panics** — `runtime error: invalid memory address or nil pointer dereference` at `mdl/visitor.buildTemplateParams`. Any command that parses the file dies, so there is no diagnostic at all, only a stack trace", "cause": "The grammar requires at least one `templateParam`, so `with ()` is a syntax error — but ANTLR error-recovers by handing the walker a `TemplateParamContext` with **no index token** rather than by skipping the rule. `buildTemplateParams` called `paramCtx.NUMBER_LITERAL().GetText()` on it", "file": "`mdl/visitor/visitor_microflow_actions.go` (`buildTemplateParams`)", "insight": "**A visitor walks error-recovered trees, so grammar-guaranteed tokens are not guaranteed at the walker.** \"The rule requires it\" is a statement about valid input; recovery synthesises contexts that satisfy no rule. Guard at the dereference, not by tightening the grammar. The other 11 `NUMBER_LITERAL().GetText()` sites in `mdl/visitor/` were checked and all already nil-guard — this was the only bare one, so no sweep was needed. **The control test is the point**: a guard that `continue`s on nil passes the crash test while silently dropping every parameter, so assert a well-formed `with ({1} = …, {2} = …)` still yields both. Tests `mdl/visitor/parser_batch_findings_test.go` (`TestLogEmptyTemplateParamsIsAnErrorNotAPanic`, `TestLogTemplateParamsStillBuild`); the crash becomes `line 3:20 mismatched input ')' expecting '{'`. Reported in mxcli-chat FINDINGS §55"}
+{"area": "mdl/visitor", "date": "2026-08-15", "symptom": "A microflow computes a **different number than the expression says**, while `mxcli check`, `mx check` and the build are all green. An additive chain comes back from `DESCRIBE MICROFLOW` with its `+` and `-` exchanged — `$A - $B + 1` stored as `$A + $B - 1`. All-plus and all-minus chains are fine, as is `-` against `*`", "cause": "`buildAdditiveExpression` read `AllPLUS()` and `AllMINUS()` as two separate token lists and emitted **every plus before every minus**, discarding source order. The precise rule is \"the chain is re-sorted, all `+` ahead of all `-`\" — sharper than \"a `-` followed by a `+` swaps\", and it predicts which cases survive", "file": "`mdl/visitor/visitor_microflow_expression.go` (`buildAdditiveExpression`)", "insight": "**The fix already existed 20 lines below**: `buildMultiplicativeExpression` walks `GetChildren()` in order and builds its operator list correctly, so the additive case is that pattern copied — no new mechanism. The corruption is in the **stored model**, not in DESCRIBE: `strings` on the `.mxunit` shows the swapped text, which is why the running app computes it. A rewritten expression is perfectly valid, so no validator can catch this class — the only test that works is round-trip equality, not \"does it apply cleanly\". **The control cases carry the weight**: `$A - $B - 1` and `$A + $B - 1` pass both before and after, so a test built only from failing cases would have passed against code that sorted all minuses first instead. Verified by reverting the fix and confirming exactly the four swapped cases fail. Test `mdl/visitor/visitor_additive_order_test.go`; example `mdl-examples/bug-tests/additive-operator-order.mdl`. Reported in mxcli-ledger FINDINGS #105", "refs": ["#105"]}
+{"area": "mdl/visitor", "date": "2026-08-18", "symptom": "A `show`/`list` command **exits 0, prints nothing, and does nothing** — `mxcli -c \"show page Mod.Home\"` looks like a page with no content, `show connections` looks like no connections are open. No error, no parse failure, no output. Indistinguishable from a legitimately empty result, which is why it survives: the answer is plausible", "cause": "The grammar alternative exists (`showOrList PAGE qualifiedName`, `showOrList CONNECTIONS`, `showOrList NOTEBOOKS`) but `ExitShowStatement` has **no `else if` branch for it**, so the visitor appends no statement and the program runs zero statements. Not a handler bug — the AST node is never created. `create notebook … begin end` is the same shape (grammar with no AST/visitor/executor anywhere)", "file": "`mdl/visitor/visitor_query.go` (`ExitShowStatement`), `mdl/grammar/domains/MDLCatalog.g4`, `mdl/ast/ast_query.go`, `mdl/executor/executor_query.go`", "insight": "Either wire a visitor branch or delete the grammar alternative — an unimplemented command must fail loudly. `SHOW PAGE X` became an alias for `DESCRIBE PAGE` (matching `SHOW ENTITY`), `SHOW CONNECTIONS` wired to `sql.Manager.List()`, `SHOW NOTEBOOKS` removed. **A structural grep cannot find these**: `ctx.PAGE()` *does* appear in `ExitShowStatement` — for the unrelated `SHOW ACCESS ON PAGE` branch — so a token search reports the broken alternative as covered. The guard (`TestEveryShowAlternativeProducesAStatement`) instead synthesizes a probe from each grammar alternative and asserts a statement comes out. **Ordering trap when adding a branch**: `SHOW DATABASE CONNECTIONS` also matches `CONNECTIONS()`, so a new `CONNECTIONS` branch placed first swallows it and answers a stored-document query with live session state — guard with `ctx.DATABASE() == nil`. Found while auditing mxcli against Studio Pro's document-type list. **Follow-up**: the notebook grammar (`createNotebookStatement`, `notebookOptions`, `notebookPage`, `alterNotebookAction`, the `SHOW NOTEBOOKS` alternative, and the `NOTEBOOK`/`NOTEBOOKS` lexer tokens) was removed outright — all four of `create`/`alter`/`drop`/`show notebook` were silent no-ops with no Go code behind any of them. Dead grammar is not inert: it *accepts input and discards it*. Removing the tokens also frees `notebook` as an ordinary identifier. **Control for a broad grammar change**: sweep every `mdl-examples/**/*.mdl` through `mxcli check` before and after and diff the failure sets — 15 scripts fail either way, so the raw count proves nothing and only the set difference does"}
+{"area": "mdl/visitor", "date": "2026-08-18", "symptom": "A `CREATE DATABASE CONNECTION` whose query uses a `$$…$$` dollar-quoted SQL **and** a `parameter … default '…'` stores the **parameter's default as the query body**. `describe` shows `sql 'sales'` where the SELECT should be, the SQL text is absent from the BSON entirely, and `mx check` reports 0 errors on both engines", "cause": "`buildDatabaseConnection` took `STRING_LITERAL(0)` as the SQL before falling back to `DOLLAR_STRING`. When the SQL is a dollar string, `STRING_LITERAL(0)` is the first parameter's DEFAULT — so the query body was overwritten by it. The parameter-index logic ten lines below already compensates (`if qc.DOLLAR_STRING() != nil { slIdx = defaultIdx }`); the SQL extraction did not", "file": "`mdl/visitor/visitor_dbconnection.go`", "insight": "Check `DOLLAR_STRING()` FIRST, then fall back to `STRING_LITERAL(0)`. **Isolate by bisecting the clause combination**, not by reading: `parameter d: String` alone kept the SQL, `parameter d: String default 'x'` destroyed it — that one-clause difference names the cause immediately. When two sites in one function index the same token stream, they must agree about the offsets; a comment on one is not enough"}
+{"area": "mdl/visitor", "date": "2026-08-20", "symptom": "Import and export mappings (and a dozen other doctypes — queues, scheduled events, regular expressions, workflows, menus, image collections, Java/JavaScript actions, database connections, data transformers, the AI-agent documents) have **no `FOLDER` clause on `create` at all**, so they can only ever be created at the module root. `DESCRIBE` on one that Studio Pro filed away emits no folder either, so a describe → re-exec round trip recreates it unfiled", "cause": "The clause was simply never added to those grammar rules; `CreateImportMappingStmt` had no `Folder` field and the executor hardcoded `containerID := module.ID`", "file": "grammar: 16 create rules across `MDLParser.g4`, `MDLDomainModel.g4`, `MDLMicroflow.g4`, `MDLService.g4`, `MDLWorkflow.g4`, `MDLAgent.g4`; AST `Folder` field on each `Create*Stmt`; visitors; executors (`containerForDocument` + `applyDocumentFolder`); DESCRIBE emitters via `describeFolderClause`", "insight": "Put the clause in **one place per statement — straight after the qualified name** — rather than matching each rule's local style. Pages/snippets (`Folder: 'path'` property) and microflows (`folder 'path'` before `begin`) already disagree, and a third convention per doctype would make the syntax unlearnable. **Watch for rules that already contain a direct `STRING_LITERAL`**: `createWorkflowStatement` read DISPLAY / DESCRIPTION / DUE DATE by *counting* `AllSTRING_LITERAL()` in order, so a folder path — now the rule's first string — silently became the display name and shifted every later clause by one. Fix by **labelling the tokens in the grammar** (`display=STRING_LITERAL`) and reading `ctx.GetDisplay()`, not by placing the new clause last: positional counting is wrong for *any* combination of optional clauses, not just this one. Same for `createDataTransformerStatement`, whose source path was `ctx.STRING_LITERAL()`. Control: revert the workflow visitor to positional and `TestWorkflowHeaderClausesAreReadByLabel` reports `DisplayName = \"Private/Filed\"`. The executor side is uniform — `containerForDocument(ctx, moduleID, s.Folder, existingContainer)` encodes the precedence (named folder → current placement → module root) once, so no handler decides it again. Verify the round trip by replaying a DESCRIBE **into a module where the document does not exist** — replaying over the original says \"Unchanged\" whether or not the clause survived. Tests `mdl/visitor/visitor_folder_clause_test.go` (all 16 doctypes); repro `mdl-examples/bug-tests/932-folder-on-modify.mdl`. Issue #932", "refs": ["#932"]}
+{"area": "mdl/visitor", "date": "2026-08-21", "symptom": "`DELETE_BEHAVIOR PREVENT` (or `DELETE_IF_NO_REFERENCES`, or `DELETE_AND_REFERENCES`) reports `Modified association` and stores `DeleteMeButKeepReferences`, destroying whatever the association had — and `DESCRIBE ASSOCIATION` emits `delete_behavior DELETE_CASCADE`, which the parser then rejects", "cause": "`buildDeleteBehavior` read only `db.CASCADE()`; the other four of the rule's five tokens fell through to the zero value `ast.DeleteKeepReferences`. A **legal** behaviour, so nothing below could tell it had been substituted. Underneath it, `ALTER ASSOCIATION SET` built the stored value as `DeleteBehaviorType(s.DeleteBehavior.String())`, and `String()` spells prevent `\"DeleteIfNoReferences\"` where Mendix writes `\"DeleteMeIfNoReferences\"` — so fixing the visitor alone put an **out-of-domain enum** on disk", "file": "`mdl/visitor/visitor_helpers.go` (`buildDeleteBehavior`), then `mdl/executor/cmd_associations.go` (`storageDeleteBehavior`)", "insight": "Read **every** token the grammar rule admits — a `default:` arm returning a plausible value turns a parse gap into silent data loss. Route all storage conversions through one function; a `String()` returning storage-ish names is a trap, not an encoder. Emit from DESCRIBE only spellings the lexer has (`DELETE_AND_REFERENCES`, not `DELETE_CASCADE`) and prove it by feeding the output back through `visitor.Build`. **`mx check` is not the oracle here**: measured on mxbuild 11.6.6, a project carrying `DeleteIfNoReferences` builds with 0 errors exactly like a correct one — only Studio Pro refuses it, so assert the stored value is one of Mendix's three, not merely the one you asked for (upstream #901)", "refs": ["#901"]}
+{"area": "mdl/visitor", "date": "2026-08-24", "symptom": "`index \"Idx\" on (A, B)` written inside `create entity`'s attribute parentheses fails to parse with `missing ':' at '\"Idx\"'` plus an unrelated \"unescaped apostrophe\" hint — reading as though indexes were unsupported there. Separately, the standalone `create index Idx on Mod.Entity (A);` reports `Syntax OK (0 statements)` and `exec` writes nothing, silently, even when the entity does not exist", "cause": "Two halves of one gap. The index syntax exists but belongs AFTER the closing paren (`entityBody: LPAREN attributeDefinitionList? RPAREN entityOptions?`), so inside it the index name parses as an attribute missing its type, and the short leftover tokens then trip the apostrophe heuristic. The standalone `createIndexStatement` rule had been in the grammar since indexes were added **with no listener behind it** — `grep -rn CreateIndexStatement mdl/visitor/ mdl/ast/ mdl/executor/` returned nothing", "file": "`mdl/visitor/visitor.go` (`misplacedIndexRe`, the hint branch, `errorListener.deduplicateHint`), `mdl/visitor/visitor_entity.go` (`ExitCreateIndexStatement`), `mdl/visitor/visitor_helpers.go` (`buildIndexColumns` extracted from `buildIndex`); tests `mdl/visitor/misplaced_index_hint_test.go`", "insight": "Key the hint off the **source line**, not the ANTLR message — the token error lands on the index name, so the message never mentions `index` (the `bareNotRe` precedent). Discriminate against the valid standalone form by what sits between `ON` and `(`: the misplaced form has the paren directly there, the standalone one names the entity. **Lower the standalone statement to the ALTER one** rather than growing a second write path — it means exactly `alter entity … add index`, and the index name is discarded in both, because a Mendix index is identified by its columns (`ast.Index` has no Name field). **A cascade repeats a hint under every error it caused** — one misplaced index yields four errors on one line — so suppress a hint already shown for that line; per line, not globally, or the same mistake made twice in a file is explained once. **A grammar rule with no listener is worse than a missing one**: it answers \"Syntax OK\" and does nothing. Sudoku finding #4", "refs": ["#4"]}
+{"area": "mdl/visitor", "date": "2026-08-25", "symptom": "A new `DROP <thing>` statement **parses, exits 0, and does nothing** — `mxcli check` passes, the CLI prints no output, and the model is untouched", "cause": "`ExitDropStatement` in `mdl/visitor/visitor_entity.go` opens with `names := ctx.AllQualifiedName(); if len(names) == 0 { return }` — a silent early return for \"most DROP statements have at least one\". Any DROP form addressed by something OTHER than a qualified name (a string literal, a position, an index) is swallowed there before its branch is reached. `DROP CONFIGURATION` is handled above the guard for exactly this reason; a new one must be too", "file": "`mdl/visitor/visitor_entity.go` (`ExitDropStatement` — put the branch ABOVE the qualified-name guard and `return` from it); example `mdl-examples/doctype-tests/40-domain-model-annotations.mdl`", "insight": "**Symptom is silence, not an error**, so a test that only checks \"the script parses\" passes. Exercise a new DROP end to end against a real project and assert the thing is GONE — `mxcli check` cannot see this class at all. The same guard shape (an early `return` keyed on the *usual* argument) is worth grepping for in any other Exit* dispatcher that grew a name-less alternative"}
+{"area": "mdl/visitor", "date": "2026-08-27", "symptom": "An attribute parses in `create entity` but the same name is rejected in a `grant … read (…) / write (…)` list, and mxcli's hint offers three RENAMES (`Title_`, `_Title`, `MyTitle`) — so a stored attribute gets renamed to work around a parser keyword", "cause": "The hint never mentioned quoting, which is the actual remedy and is right there in the raw ANTLR message's expectation set (`{IDENTIFIER, QUOTED_IDENTIFIER}`). Renaming an attribute that already exists is a schema change; quoting is free and keeps the name", "file": "`mdl/visitor/visitor.go` (`reservedKeywordHint`, `hintedKeywordSet`), `mdl/types/reserved_words.go` (`IsPlatformReserved`)", "insight": "**Two kinds of reserved word, and conflating them is expensive in both directions.** An MDL PARSER keyword is escaped by quoting and the model keeps the name. A name the PLATFORM reserves is not — the check strips the quotes and rejects the bare name (CE7247/MDL021), so advising quoting there produces something that parses and then fails the build. Branch on `types.IsPlatformReserved`. Measured when this was written: **38 of 41** hinted keywords are rescued by quoting, and exactly **3** (`Type`, `Default`, `Owner`) are not — the old blanket-rename advice was wrong for the 38 and right for the 3 by accident. The platform lists moved to `mdl/types` because the validator (`mdl/executor`) and the hinting (`mdl/visitor`) both need them and neither may import the other. Any test asserting the hint recommends quoting needs a **control that the quoted form actually parses**, or it passes against advice that does not work. ako/mxcli-maintenance §5", "ce": ["CE7247"], "rules": ["MDL021"]}
+{"area": "mdl/visitor", "date": "2026-08-31", "raw": "| A `RETRIEVE … WHERE a = $Var/Attr AND b = $Var/Attr` passes `mxcli check` and the build fails **CE0161** \"Error(s) in XPath constraint\" — but the same statement with **literals** on both sides of the same uppercase `AND` builds fine | `mdl/visitor/xpath_operators.go` (new, `NormalizeXPathOperators`), called from `mdl/visitor/xpath_format.go` | XPath 1.0 spells `and`/`or`/`not` in **lower case only**; MDL's lexer accepts any case (`AND: A N D;`). mxcli lowercased the operator on **one of two rendering paths**: `expressionToXPath` does it while walking the parse tree, but `buildRetrieveWhereExpression` freezes the **raw source** whenever the clause contains a `/` — which every variable path has — and `expressionToXPath`'s `SourceExpr` case hands that text back verbatim. So the casing survived exactly when a path was present, which is why the reporter's literal-only reproducer built cleanly and the report looked not-reproducible. **The correlation was the whole difficulty**: a workaround found under time pressure records what you changed, not what was wrong. Fixed at `FormatXPathConstraint`, the single choke point all three constraint writers share (retrieve, page data source, entity access rule — the latter two measured as broken the same way before the fix), and **before** its width test, because the short branch returns the caller's own bytes. The replacement is token-based and literal-aware for two reasons that are each a worse bug than the one being fixed: rewriting inside `'A AND B'` silently changes which rows match, and an identifier that merely contains the letters (`Brand`, `Andrew`, `NOTES`, `Order_Andon`, `Module.Handover`) is not an operator. `div`/`mod` are deliberately excluded — nothing in MDL emits them, and a rewrite nothing needs can only be wrong. Example `mdl-examples/bug-tests/f1-80-xpath-operator-case.mdl`. Unrelated and pre-existing, found alongside: `$currentUser/...` in a **page** data source constraint is CE0161 regardless of operator case. Reported as mxcli-formula1 FINDINGS §80 |", "ce": ["CE0161"]}
+{"area": "mdl/visitor", "symptom": "`Height: n` on a domain-model annotation is a bare parse error (\"mismatched input 'Height' expecting {POSITION, CAPTION, WIDTH}\"), which reads like a missing mxcli feature and gets reported as one. Filed as a feature request to expose annotation height.", "cause": "Not an mxcli gap: Mendix stores no annotation height. DomainModels$Annotation has exactly Caption, ExportLevel, Location and Width, so the note auto-sizes to its caption and there is nowhere to write a height. Adding the property would mean inventing a key the platform does not have.", "file": "`mdl/visitor/visitor.go` (`looksLikeAnnotationProperty`, `annotationHeightRe`, the two branches in `enhanceErrorMessage`); syntax topic `cmd/mxcli/syntax/features_domain_model.go`; type doc `mdl/ast/ast_annotation.go`; tests `mdl/visitor/annotation_height_hint_test.go`.", "insight": "`generated/metamodel` alone CANNOT settle \"does this property exist\" — it is an 11.6.0 snapshot, and the report was against 11.12.2, so a property added later would be invisible to it. Four sources were needed and three of them are cheap: `mx dump-mpr` (Mendix's own serializer) emits the four keys on real projects; `mx convert -p` is the decisive one, because it rewrites the model through Mendix's OWN object model and would materialise a property that merely had a default and was not stored — it added nothing; and the published Model SDK's domainmodels.Annotation lists caption/exportLevel/location/width. An absent key in stored BSON proves nothing on its own (it may just be unwritten), which is why dump-mpr alone is not enough. When a feature cannot exist, the deliverable is a parse error that SAYS so and names the levers that do exist (Width changes the wrapping and therefore the height; `ALTER ENTITY … SET POSITION` moves what the note overlaps) — the reporter's real goal was reachable already. Key the hint on the `expecting {POSITION, CAPTION, WIDTH}` token set, not on the word \"Height\": a page widget's Height is valid MDL, and a name-keyed hint would misfire on it (control: TestWidgetHeightIsNotAnnotationHinted).", "refs": ["#1014"], "date": "2026-09-01"}
diff --git a/.claude/skills/fix-issue/findings/modelsdk.jsonl b/.claude/skills/fix-issue/findings/modelsdk.jsonl
new file mode 100644
index 0000000000..f35fd504f9
--- /dev/null
+++ b/.claude/skills/fix-issue/findings/modelsdk.jsonl
@@ -0,0 +1,16 @@
+{"area": "modelsdk/codec", "date": "2026-06-30", "symptom": "`DESCRIBE microflow` on the **modelsdk** engine renders a branching microflow as `if cond then end if;` — the entire then/when body is dropped (legacy engine renders it fully). Affects projects Studio Pro saved with the older single-case storage", "cause": "The split's branch case is stored under the BSON storage name `NewCaseValue` (single child), but (1) the codec had no `CaseValue`→`NewCaseValue` alias so it was never decoded, and (2) the adapter read only the plural `CaseValuesItems()`, not the singular `CaseValue()`", "file": "`modelsdk/codec/decoder.go` (`fieldAliases`) + `mdl/backend/modelsdk/microflow.go` (`caseValueFromGen`/`mapGenCaseValue`)", "insight": "Add `\"CaseValue\": \"NewCaseValue\"` to `fieldAliases` (mirrors `Type`↔`NewType`); read the singular `g.CaseValue()` first, then the plural list, mapping `EnumerationCase`/`InheritanceCase`. A round-trip MDL bug-test can't reproduce it (the write path emits the new format) — covered by codec + adapter unit tests"}
+{"area": "modelsdk/widgets", "date": "2026-07-19", "symptom": "**CE0463 \"widget definition changed\" at an `Image` widget** on Mendix 11.7+ (`mx check` without `update-widgets`) — a plain mxcli-authored Image, no custom config. `update-widgets` clears it (and on v2 destroys `mprcontents/`, so it's a data-loss trap)", "cause": "NOT a version stamp, Type `$ID`s, property order, or missing properties (all ruled out empirically). The embedded `image.json` carried a **spurious default value**: a `WidgetValue.Image` pointing at `Atlas_Core.Content.Mendix` (Atlas's Mendix logo), captured when the template was extracted from a project that had it set. The installed 11.12 Image widget expects that field empty, so MxBuild flags the definition as changed", "file": "`modelsdk/widgets/templates/mendix-11.6/image.json` + `sdk/widgets/templates/mendix-11.6/image.json` (line ~63)", "insight": "Clear the stale default: `\"Image\": \"Atlas_Core.Content.Mendix\"` → `\"Image\": \"\"` in both engine templates. **Diagnosis method for this whole CE0463 class**: dump the widget BSON, `mx update-widgets` on a COPY, dump again, diff the `CustomWidgets$CustomWidget` subtree **order-independently** (canonicalise key order + mask `$ID`/`TypePointer` blobs). Reordering and generic instance chrome (`LabelTemplate`, `Appearance.DesignProperties`) are cosmetic — a *passing* widget gets reordered/those-added too; the real cause is whatever value/structure survives that normalisation. Other hand-extracted templates likely hide similar stale defaults (audit with the same diff). Repro `mdl-examples/bug-tests/image-ce0463-stale-default.mdl`. DataGrid2 custom-content CE0463 (#600) is a *separate*, more complex delta — same method, own fix", "refs": ["#600"], "ce": ["CE0463"]}
+{"area": "modelsdk/element", "date": "2026-08-10", "symptom": "A project becomes unopenable after an mxcli write — Studio Pro / `mx check` fails with `System.Collections.Generic.KeyNotFoundException: The given key '<guid>' was not present in the dictionary` at `StreamingBsonUnitReader.ResolvePostponedProperties`. `mx check` on the *previous* revision is clean, and only some document types break (microflows/nanoflows yes, pages/navigation no)", "cause": "An element's `$ID` was rewritten without rewriting the references that point at it. Mendix's loader defers reference resolution and then looks the target up by ID, so a pointer holding a discarded ID is a dangling reference. Hit by `element.PreserveIDs` (reverted in `f1371f71`), which recursed through `ChildProperty`/`ChildListProperty` and called `SetID`, but **pointers are not child properties** — `Microflows$SequenceFlow.OriginPointer`/`DestinationPointer` are primitive properties holding an `element.ID` (`modelsdk/gen/microflows/types.go` `InitFromRaw`), invisible to a child-walk", "file": "`modelsdk/element/preserve_ids.go` (reverted), `modelsdk/gen/*/types.go` (`InitFromRaw` shows which properties are ID-valued)", "insight": "**Never rewrite an element ID without rewriting every reference to it in the same pass.** `ResolvePostponedProperties` in the stack trace means exactly this: a stored ID has no owner. The document types that survive are the ones with few internal cross-references (a page's widget tree is containment, a microflow's is a graph), so **\"pages are fine\" is not evidence the approach is safe**. Better than a fixup pass: seed the rebuild with the stored IDs so pointers are computed correctly from the start. **Verification lesson**: the local test project had entities, an association, an enumeration and constants but *no microflow*, so `mx check` reported 0 errors on a model that could not exercise the bug — a green `mx check` only covers the constructs the fixture actually contains. `make test-integration` (which needs mxbuild, ~20 min) caught it via `TestMxCheck_DoctypeScripts`; unit tests alone did not. Run it before claiming a write-path change is safe"}
+{"area": "modelsdk/canon", "date": "2026-08-10", "symptom": "Re-running an MDL script against a project that is already in sync rewrites the `.mxunit` files anyway — `git status` is dirty, Studio Pro shows version-control changes, and three consecutive runs of one script give three different tree hashes across 143 documents while nothing semantic moves", "cause": "No write path compared against what was stored. `create or replace` rebuilds the document from the MDL and overwrites unconditionally, and every sub-element in that rebuild is a new object whose `$ID` comes from `GenerateID()` — a random UUID. The output was a function of the script **and a random source**, so byte stability was unreachable by any amount of care in the builders", "file": "`modelsdk/canon/` (`Digest`, `Equal`, `Reconcile`), wired at the two storage choke points: `modelsdk/mpr/writer_core.go` (`reconcileWithStored`, covering `updateUnit` and `WriteTransaction.WriteUnit`) and `sdk/mpr/writer_units.go` (`updateUnit`)", "insight": "**Compare a canonical form, not bytes** — the rebuilt bytes always differ, so a byte comparison skips nothing. Canonicalisation replaces every element `$ID` with its index in a deterministic containment walk; you do **not** need to know which properties hold references, because the set of element IDs comes from the walk and any occurrence of one of those IDs anywhere is a reference by definition. **Bias every failure path toward writing**: a false \"different\" costs a redundant write (yesterday's behaviour), a false \"equal\" silently discards the user's intent. **Skipping is safer than writing, not just cheaper** — the stored IDs are the ones every pointer inside that unit already agrees with, which is precisely what PR #125 broke by rewriting them. **Wire every choke point, both engines**: `codec.Store.SaveUnit`/`FlushUnits` reach storage through `WriteTransaction.WriteUnit`, not `UpdateRawUnit`, and which engine ran is an `--engine` flag users must not be able to see in a diff. **A control is mandatory**: assert that with `MXCLI_ALWAYS_WRITE=1` the same write *does* churn, or the test passes against a build that never had the fix. Tests `mdl/backend/modelsdk/microflow_idempotence_test.go`, `sdk/mpr/writer_elision_test.go`, `modelsdk/canon/canon_test.go`. ADR-0008", "refs": ["#125"]}
+{"area": "modelsdk/canon", "date": "2026-08-10", "symptom": "A microflow's `StableId` is a different GUID after every mxcli write, so a microflow always differs from itself and no amount of no-op elision can settle it. Downstream: every `callMicroflow` entry in `deployment/model/operations.json` gets a new `operationId` on each build", "cause": "`microflow_write.go` registered `StableId` as a `codec` `FreshGUIDField`, minting a fresh GUID per write. It is the one field on a microflow whose *stated purpose* is not to change: Mendix declares it `ModelPropertyAttribute(\"StableId\", RetentionType.DesignTime)` with `IsIdentifier = true`, seeds it once via the one-time `MicroflowStableIdConversion`, and transplants it across a marketplace module update in `PackageUtils.RescueStableIDs`", "file": "`modelsdk/canon/identity.go` (`identityFields`, `CarryIdentity`) — the stored value is carried onto the rebuilt document before the comparison, so an otherwise-unchanged microflow compares equal and is elided", "insight": "**Establish that a property is an identity before adding a row to `identityFields`** — do not assume it from the name. The method that settled this one: strict-boundary `strings` scan of every runtime jar (a substring match gives false positives — `newPersistableIds` contains `stableId`); `monodis` the modeler assembly and read the `ModelPropertyAttribute` blob; look for an `IOneTimeConversion` named after the field; search the packaging assembly for a get→set pair; then build with `mxbuild --target=deploy` and reproduce the derivation against `deployment/`. That last step is what proved the value escapes the model: `operationId == base64(uuid5(projectId, StableId).bytes_le)`, 10 of 10 exact. **Carry only a key both documents already have** — never invent one, and dispatch on the stored `$Type` (CLAUDE.md, overlay writes). **Identity preservation is not gated by `MXCLI_ALWAYS_WRITE`**: that flag turns off eliding a write, not preserving what the document is. Tests `modelsdk/canon/identity_test.go`, `sdk/mpr/writer_elision_test.go`. ADR-0008"}
+{"area": "modelsdk/gen", "date": "2026-08-13", "symptom": "`create validation rule …` parses and silently writes nothing, so a regex document cannot be bound to an attribute from MDL at all — every form (regex, range, required, unique, expression) reports success and leaves the model untouched", "cause": "Three layers, one visible symptom. (1) The grammar rule existed with **no AST node, no visitor and no handler**. (2) Its shape was unimplementable: an `EXPRESSION` rule type Mendix does not have, an **inline** regex literal where Mendix stores a **reference to a document**, and strict `<`/`>` bounds Mendix cannot represent. (3) Underneath, `modelsdk/gen` bound `RegExRuleInfo`'s reference to BSON `RegularExpression` where Studio Pro stores `RegExIdentifier`, so the rule could not have been written even with the statement wired up", "file": "`modelsdk/gen/domainmodels/types.go` (`STORAGE-NAME OVERRIDE` on `initRegExRuleInfo` **and** `InitFromRaw`), `mdl/backend/modelsdk/domainmodel.go` (`ruleInfoFromGen`) + `domainmodel_write.go` (`ruleInfoToGen` now takes the whole rule), `sdk/domainmodel/domainmodel.go` (regex ref is a qualified NAME not an ID; Range gained the attribute-bound fields), `mdl/grammar/domains/MDLDomainModel.g4`, `mdl/ast/ast_validationrule.go`, `mdl/visitor/visitor_validationrule.go`, `mdl/executor/cmd_validationrules.go`, `mdl/executor/cmd_entities_describe.go`", "insight": "**Correcting `modelsdk/gen` IS available** — this supersedes the previous row's \"no `supplements.json` or `cmd/modelsdk-codegen` in this tree, so correcting gen is not currently available\". Neither path has ever existed here (`git log --all` empty) and `/reference/` is gitignored, but four `STORAGE-NAME OVERRIDE` precedents already hand-patch `init<Type>`, and `TestGeneratedCodeIsFormatted` exists because gen gets hand-edited. **`generated/metamodel` is the arbiter**: `cmd/codegen` emits the storage name as the json tag (`json:\"regExIdentifier\"`) while gen kept the SDK name — an audit of all 570 cross-checkable types found **65 with at least one wrong key**, and the three with independent evidence (`RegularExpression.Expression`, `Attribute.GUID`, this one) were all flagged correctly. **Patch BOTH the encode and decode literal**: reverting only `init` gave a document that writes `RegularExpression` and reads `RegExIdentifier`, whose symptom is a confusing entity-rewrite refusal rather than a bad file. **The control is the proof**: same script, key reverted → `CE0135 \"No regular expression specified\"` on mxbuild 11.13; with the fix → 0 errors and `RegExIdentifier` on disk. **A rule type is not a rule** — `ruleInfoToGen(ruleType string)` could never rebuild a RegEx (its reference) or a Range (its bounds), so it was widened to the whole rule and the reader taught to carry the payload; a bare RuleInfo of the right `$Type` is a silent downgrade wearing the right name. **Check for a bound that is not a literal**: a Range may point at another ATTRIBUTE, which MDL cannot author and a literals-only reader would have dropped on the next rewrite. **Do not add a second spelling for something already authorable** — Required/Unique stay attribute constraints (`not null error '…'`), refused here with a pointer. **Fixing an unimplementable grammar is free when nothing could depend on it**: every old form parsed and did nothing, so the shape was replaced rather than preserved. Tests `modelsdk/gen/domainmodels/storagename_test.go`, `mdl/backend/modelsdk/validationrule_test.go`, `mdl/visitor/visitor_validationrule_test.go`, `mdl/executor/cmd_validationrules_test.go`, example `mdl-examples/doctype-tests/validation-rules.mdl`", "ce": ["CE0135"]}
+{"area": "modelsdk/canon", "date": "2026-08-19", "symptom": "Studio Pro's version-control view shows an **entire** nanoflow/microflow as changed after editing one activity argument; `git diff` on `mprcontents/` is unreadable. A change and its revert leave a semantically identical document that shares no element IDs with the original. Separately, re-running an already-applied script prints `Modified …`/`Replaced …` for files it did not touch", "cause": "Two independent things. (a) `create or replace` rebuilds the document and every sub-element gets a freshly random `$ID`; elision (ADR-0008) only covers the case where *nothing* changed, so a real change wrote a whole new identity set — measured 36 of 37 on a nanoflow, 21 of 22 on a microflow. (b) The `Modified …` lines are printed by the handler right after `ctx.Backend.Update*`, which returns nil whether or not storage elided the write", "file": "`modelsdk/canon/transplant.go` (`TransplantIDs`, called from `Reconcile` in `identity.go`); `mdl/executor/report_mutation.go` + `mdl/backend/writestats.go`", "insight": "Match the incoming document against the stored one and reuse its `$ID`s: `$Type` + shape one level down (`Action=Microflows$LogMessageAction`) + `Name` as the LCS match key, positional fill in the gaps, then substitute **in place over every 16-byte binary** — a pointer is a primitive property a containment walk never sees, and any occurrence of one of the document's element IDs *is* a reference (the same insight `canon` rests on). **The correctness bar is lower than it looks**: a wrong match only makes a diff bigger, since every reference moves with the element; the one real failure is two elements sharing an `$ID`, so guard it explicitly (`dropCollisions`, run to a fixed point) and verify the resulting id set by read-back. **Do not touch `GUID`** — that is the database's identity and was already preserved (measured 8 of 8 through `ALTER ENTITY ADD ATTRIBUTE`). **A key built from content is the trap**: it stops an element matching itself the moment someone edits it, which is the case being fixed — key on shape and name only. **Watch for the control you invalidate**: `MXCLI_ALWAYS_WRITE=1` no longer changes the written bytes (identities are carried), so `TestWriteMicroflowTwice_ControlChurnsWhenElisionOff` became unprovable and had to move down a layer to the raw codec output (`TestRebuildChurnsSubElementIDs`); from the shell, control on mtimes rather than hashes. For the reporting half, downgrade the verb only on **positive** evidence (unit writes offered since the last report, none landed) so a mutation that never reaches unit storage — a theme file, a mock backend — reads exactly as before. Measured on the reporter's own project: 37/37 identities kept, diff down to the one changed line, insert/delete mints only the genuinely new elements, `mx check` unchanged at its 1 pre-existing error, both engines"}
+{"area": "modelsdk/gen", "date": "2026-08-20", "symptom": "`mx create-module-package` aborts on a module mxcli created with **`Exception occurred: Unable to cast object of type 'Newtonsoft.Json.Linq.JValue' to type 'Newtonsoft.Json.Linq.JObject'`** at `MprProperty.Init` → `MprUnit.get_Contents` → `MprDocumentHasher.Write`, while `mx check` reports **0 errors**. Removing the widget the reporter blamed changes nothing", "cause": "`Forms$Page.AllowedModuleRoles` was written with typed-array marker **3** by the modelsdk (default) engine. The marker tells Mendix's reader what the entries ARE, and the entries are qualified-name **strings** — so a NON-EMPTY list under marker 3 is a JValue where the reader wants a JObject. The empty list never crashed (nothing to mis-cast), which is why only a module whose page carries a role hit it: `create module` auto-creates a `User` role and grants it. The legacy engine (`sdk/mpr/writer_security.go`) has always written 1", "file": "`modelsdk/gen/pages/types.go` (`initPage`, the `allowedRoles` line — LIST-MARKER OVERRIDE next to the existing STORAGE-NAME OVERRIDE); `modelsdk/property/reference.go` (`NewByNameRefListV3`, whose comment asserted the opposite)", "insight": "**Minimise before believing the reporter's attribution.** #931 blamed an Accordion; `create module MMin; create page MMin.P { DYNAMICTEXT }` reproduces the identical exception with no pluggable widget in the project — and the same crash appears on a binary built from `origin/main`, which is the control that proves it pre-existing rather than introduced by the fix in the same branch. **`mx check` is not a safety net for storage shape**: it read this project fine at all three security levels while the exporter could not. **Check the comment's premise before honouring it** — this marker was deliberately 3 because a comment said 1 caused CE0557 \"even when roles are set\"; measured at Off, Prototype and Production, marker 1 is 0 errors and exports, marker 3 is 0 errors and crashes. Note the repair is not retroactive: idempotent writes leave an existing page alone, so a project keeps the bad marker until each page is rewritten. Issue mendixlabs/mxcli#931", "refs": ["#931", "mendixlabs/mxcli#931"], "ce": ["CE0557"]}
+{"area": "modelsdk/canon", "date": "2026-08-21", "symptom": "A workflow write is never elided: re-running an unchanged `ALTER WORKFLOW` (or any workflow rewrite) produces a different `.mpr` every time, so Studio Pro shows a version-control change on every run even though nothing was edited", "cause": "Every `Workflows$*` element — activities, outcomes, boundary events, and the workflow root — carries a `PersistentId`, and **both** engines mint a fresh GUID for it on every write (`addFreshPersistentID` in modelsdk, a literal `idToBsonBinary(generateUUID())` in legacy) while **neither** reads the stored value back. A rebuilt document therefore never equals the stored one, so `canon.Reconcile`'s no-op elision could not fire for a workflow", "file": "`modelsdk/canon/persistentid.go` (`CarryPersistentIDs`, wired into `Reconcile` in `identity.go`); tests `modelsdk/canon/persistentid_test.go`; blind-spot note in `mdl/backend/modelsdk/identity_drift_test.go`", "insight": "Carry it in **canon**, not in the writers: one place covers both engines and every nested type, and the writers keep minting fresh for genuinely new elements (which is correct — the carry only applies where a stored counterpart exists). `canon.identityFields`/`CarryIdentity` are **not** the right home — they only reach **top-level** properties of the document root, and `PersistentId` sits on elements arbitrarily deep in the flow tree; reuse `TransplantIDs`' structural pairing instead, and keep the traversal identical to `pairer`'s or one element's `$ID` and `PersistentId` could come from two different stored elements. **`TestFreshGUIDFieldsHaveAnIdentityDecision` does not catch this class**: it sees only properties registered via the codec's `FreshGUIDFields`, and a writer that mints a GUID by hand is invisible to it. Verify by **byte-comparing the `.mpr` across repeated no-op runs on both engines** (`MXCLI_ENGINE=legacy`), not by reading the code — and keep a control that a real edit still writes, or the carry has become a way of losing writes. Issue #949", "refs": ["#949"]}
+{"area": "modelsdk/gen", "date": "2026-08-21", "symptom": "`SHOW PROJECT SECURITY` prints no **Guest User Role** on the default engine while `MXCLI_ENGINE=legacy` prints it for the same project — and the documented Starlark fields `anonymous_user_role` / `role.is_anonymous` resolve to `\"\"` / never, so a lint rule asking \"what can anonymous visitors read\" matches nothing", "cause": "`modelsdk/gen` bound `Security$ProjectSecurity.GuestUserRoleName`; every Studio Pro document stores **`GuestUserRole`** (likewise `AdminUserRoleName` → `AdminUserRole`). Both were on the known-mismatch ledger, unfixed. The legacy parser reads the right key, which is why the engines disagreed", "file": "`modelsdk/gen/security/types.go` (`initProjectSecurity`), ledger rows struck from `modelsdk/gen/keyaudit_test.go`", "insight": "**A `property.Primitive` decodes AND encodes under one bound name** (`Get()` passes `p.name` to the decode func; the encoder reads the same), so unlike the pages precedents this needs **one** literal, not two — check the property kind before hunting for a second site in `InitFromRaw`. **The read bug was the quiet half; the write bug was fatal.** gen preserved the stored `GuestUserRole` as an unknown-key passthrough, so existing writes lost nothing — but calling `SetGuestUserRoleName` would have added a *second* key beside it, which Studio Pro refuses to open (`Sequence contains no matching element` at `MprProperty.cs`) while mxbuild tolerates it. Measure the encode side before concluding a passthrough makes the key safe. Control for the whole fix: rewrite the stored role under the pre-fix key and `mx check` reports **CE0133** (6 errors vs 5) — i.e. without the override the guest-access feature would have shipped writing a project that cannot build. Tests `modelsdk/gen/security/storagename_projectsecurity_test.go`. Issue #924", "refs": ["#924"], "ce": ["CE0133"]}
+{"area": "modelsdk/mpr", "date": "2026-08-23", "symptom": "A batch write through `codec.Store.SaveUnit` / `FlushUnits` reports success while a unit's `.mxunit` on disk still holds the old bytes — the `Unit` row's `ContentsHash` describes contents nobody can read. On Windows the trigger is a file held open without `FILE_SHARE_DELETE` (an editor, an indexer, a sync client), which makes `os.Rename` fail with \"Access is denied\"; the CLI's own `ALTER`/`CREATE` paths are unaffected because they go through `Writer.updateUnit`, which has always failed hard", "cause": "`WriteTransaction.Commit` committed the SQLite transaction FIRST and then renamed the temp files, logging a warning and continuing when a rename failed — so the database moved on and the disk did not, and `nil` told every caller the write had landed. #954", "file": "`modelsdk/mpr/writer_core.go` (`Commit`), mirrored in `sdk/mpr/writer_core.go`", "insight": "Rename the files into place BEFORE committing the transaction, moving each replaced file aside as `<unit>.mxunit.bak` so a later failure can put it back; on any failure undo the renames, drop the temps and roll the transaction back. Test it by removing a pending temp file between `WriteUnit` and `Commit` — a portable stand-in for the lock — and assert BOTH that `Commit` errors and that the DB hash still matches the file, since an error alone passes against a version that reports the failure and still leaves the DB ahead", "refs": ["#954"]}
+{"area": "modelsdk/canon", "date": "2026-08-24", "symptom": "Rewriting a document **deletes every language but one**: a `describe page` → `exec` round-trip drops a page's Dutch title from the entire project, and `show languages` counts fall. `mx check` reports 0 errors before and after", "cause": "A Mendix text is a `Texts$Text` holding one `Texts$Translation` child per language, and MDL carries **one string** — `Title: 'My Account'` — so a rebuilt document has exactly one child and the rest are gone. The legacy reader compounds it: `extractTextFromBson` returns the first non-empty text and ignores `LanguageCode` entirely", "file": "`modelsdk/canon/translations.go` (`CarryTranslations`), `modelsdk/canon/identity.go` (`Reconcile`'s carry chain)", "insight": "Carry the stored translations onto the rebuild, in the same chain as the other things a rebuild would lose (identity, element `$ID`s, `PersistentId`) — so **both engines get it from one place** (`sdk/mpr/writer_units.go` and `modelsdk/mpr/writer_core.go` both call `canon.Reconcile`). Pair texts **by containment path when the two documents hold texts at exactly the same paths** (exact, and the only way to carry a text whose source the statement CHANGED), else **by source string**. A mis-pair here is NOT benign the way `TransplantIDs`' is — that rewrites every reference with the id, whereas copying a translation onto the wrong text injects a translation of a different string — so positional pairing is abandoned entirely if one path differs rather than applied where it fits. **Append the stored `Texts$Translation` sub-document verbatim**, not a freshly built one: without its `$ID` the canonical form differs and no-op elision can never fire. Ambiguous source (two stored texts share a source, disagree on the translation) → carry nothing. **`mx check` is not the oracle** — a model missing a translation is valid; count `Texts$Translation` elements or use `show languages`. Controls: remove the call from `Reconcile` → nl_NL 335 → 328 on one page, and `TestReconcile_TranslatedDocumentRoundTripsUnchanged` fails. Repro `mdl-examples/bug-tests/translations-preserved-on-rewrite.mdl`. PROPOSAL_translations.md slice 1"}
+{"area": "modelsdk/canon", "date": "2026-08-24", "symptom": "A `create or replace translations` run reports removing N translations and they are all **still there** afterwards", "cause": "`canon.Reconcile` carries the stored translations onto every write (PROPOSAL_translations slice 1), which is right for a REBUILD — MDL carries one string per text and the other languages were never expressible — and exactly wrong for a targeted PATCH, where a missing translation was removed on purpose. The two are indistinguishable from the bytes", "file": "`modelsdk/canon/identity.go` (`Reconcile`'s `ContentsOwnTranslations` option), `modelsdk/mpr/writer_core.go` (`UpdateRawUnitOwningTranslations`), `mdl/translations/project.go`", "insight": "Only the CALLER knows which case it is, so the write declares it. A path that patches stored bytes uses `UpdateRawUnitOwningTranslations`; a rebuild uses the ordinary write and keeps the carry. Threaded as a **variadic** `canon.Option` so every existing caller is untouched. The test must show the default DOES carry before showing the option suppressing it, or it proves nothing. Related: a new `Texts$Translation` needs a real 16-byte `$ID` as its **first** property — Mendix fails the build with *\"Expected '$ID' as the first property of a storage object, but got '$Type'\"*, which no assertion about the translation's value catches; it took `mx check` on a patched project to find. Repro `mdl-examples/doctype-tests/translations.mdl`. PROPOSAL_translations slices 2-4"}
+{"area": "modelsdk/widgets", "date": "2026-08-24", "symptom": "**CE0463 on every page carrying a File Uploader**, whatever is on it — an action-free one with nothing but its `datasource:` fails identically. The widget the #956 action-slot work was *about*, and the one it never exercised", "cause": "**Two independent causes, and each alone still fails.** (A) The widget XML's `defaultType` — the KIND of a default, `defaultType=\"CallNanoflow\"` on the create* actions, `defaultType=\"Association\"` on the datasources — was never parsed, so all six landed as `DefaultType: \"None\"`. It is part of the widget DEFINITION, exactly like the stale `onChange` of #716. (B) `uploadMode`'s declared default never reached the visibility evaluator, because a primitive mapping carries the XML default in `PropertyMapping.Value` while `widgetValueMap` read only `.Default` (populated for selections alone). With the condition unknown, `hiddenUnnamedProperties` correctly refuses to guess — so `associatedImages` was not pruned, the one `datasource:` clause fanned out into BOTH datasource properties, and the pruned one carried a value. File Uploader is the only widget in a stock 11.13.0 app that declares any `defaultType` (6 properties; every other bundled widget declares 0), which is why one widget was unwritable while the rest were fine", "file": "(A) `modelsdk/widgets/mpk/mpk.go` + `sdk/widgets/mpk/mpk.go` (`PropertyDef.DefaultType`, `xml:\"defaultType,attr\"`), `modelsdk/widgets/augment.go` + `sdk/widgets/augment.go` (`defaultTypeOf`); (B) `mdl/executor/validate_widgets.go` (`widgetValueMap`)", "insight": "**`mx update-widgets` on a COPY is the oracle when there is no Studio Pro** — and when one IS reachable, `ped_check_errors` over the written documents is the real verdict, with the same page written by the pre-fix binary as the control (it reports the CE0463 text and a `/layoutCall/arguments/0/widgets/0/widgets/0` location; the fixed 17 documents report \"No errors found.\"). `pg_read_page` then shows the editor's own view — on the pre-fix page it lists BOTH `associatedFiles` and `associatedImages` under `uploadMode: \"files\"`, which is the fanout, and on the fixed one only the active half. It is Studio Pro's own normalizer: run it, confirm it clears the error, then diff its output against yours — a 2,650-path document diff whose *only* differences are the cause. Diff by property NAME, never by index: the two dumps order top-level keys differently and a positional flatten reports ~60 spurious differences that hide the 6 real ones. Widget properties are keyed by `TypePointer` into `Type.ObjectType.PropertyTypes`, so resolve the pointer to its `PropertyKey` first or the diff is unreadable. Two more findings from the same measurement, both still open: mxcli writes widget-action `ParameterMappings` with list marker **3** where Studio Pro writes **2** (and omits the sibling `Variable`/`OutputMappings` keys) — accepted by both mxbuild 11.13 **and Studio Pro**, which resolves every mapping to the right parameter (checked live over PED), so it is a diff-churn item rather than a correctness one; and the visibility extractor misses a `hidePropertiesIn` call inside a **ternary branch** (`cond ? hide([…]) : hide([…])`), as opposed to the ternary *array element* #233 fixed — so `createImageAction` carries no uploadMode rule, MDL-WIDGET10 cannot warn, and wiring it in files mode is a CE0463 the script author gets no help with. Repro `mdl-examples/bug-tests/956-fileuploader-six-action-slots.mdl`. Issue #956", "refs": ["#233", "#716", "#956"], "ce": ["CE0463"]}
+{"area": "modelsdk/meta", "date": "2026-08-28", "symptom": "`GRANT` on an entity that extends **System.Image** fails the build with **CE1613** \"The selected association 'System.Thumbnail_Image' no longer exists\" at the access rule — and `describe entity` renders that rule without any broken member, so nothing inside mxcli shows it", "cause": "The virtual System module carries entities that exist only in the **runtime's** metamodel, not in the System module Studio Pro shows. They arrived with the block marked \"extracted from MDP (Phase 3)\". `Thumbnail_Image` is owned by BOTH ends, so System.Image counted as an owner through the CHILD side and every specialization inherited an access-rule member for it", "file": "`modelsdk/meta/system_module.go` (`RuntimeOnly`, `ModelerSystemEntities`, `ModelerSystemAssociations`), consumed by `mdl/backend/modelsdk/system_module_read.go`; the inheritance walk that reads it is `mdl/executor/cmd_security_write.go` (`inheritedAssociations`)", "insight": "**The legacy engine is a free control here**: its System list (`sdk/mpr/system_module.go`) never had the MDP block, so the same script under `--engine legacy` writes a clean rule — which pins the defect to the data rather than to the GRANT path reading it. Establish what the modeler actually has by MEASURING, not by reasoning about names: one microflow per candidate retrieving from `System.<Name>`, then one `mx check`. All eleven MDP rows came back CE1613 while the controls (Image, FileDocument, Session) came back clean, so the probe discriminates. Flag rather than delete — the runtime rows were harvested deliberately and a storage backend speaking to the runtime metamodel wants them — and DERIVE the association filter from the entity flag (an association is runtime-only exactly when one of its ends is), because two hand-kept lists drift and the one that falls behind writes a dangling by-name reference. Unrelated pre-existing gap found alongside: `extends <anything>` is never reference-validated, for System or for a same-module name.", "ce": ["CE1613"]}
+{"area": "modelsdk/canon", "date": "2026-08-28", "symptom": "`mx check` fails with **`InvalidOperationException: … Duplicate Guid in unit page 'M.P'. Object types: Translation, Translation`** and the project will not LOAD at all — and every later edit of that page reports the same thing", "cause": "Two elements in one unit share an `$ID`. \"Guid\" in Mendix's message is the element `$ID`, not a `GUID` property — a `Texts$Translation` stores exactly four keys (`$ID`, `$Type`, `LanguageCode`, `Text`) and has no GUID of its own", "file": "`modelsdk/canon/duplicates.go` (`DuplicateElementIDs`, `DuplicateElementIDError`), wired at all four write choke points: `modelsdk/mpr/writer_core.go` (`insertUnit`, `updateUnit`) and `sdk/mpr/writer_units.go` (same two)", "insight": "**A guard is worth shipping without a root cause.** The reporter lost ~1h to one of these, proposed two causes, tested both, and withdrew both (ako/mxcli-captrack #2) — the trigger is still unknown. Refusing at the write turns an unopenable project into one message, and breaks the thing that made it expensive: the corruption is **STICKY**, so once a unit carries duplicate ids every later edit inherits them and each subsequent write looks like the culprit. Restore before re-testing, or the second experiment measures the first one's damage. Check BEFORE `canon.Reconcile`, not after — an elided write is not a safe one, only one that did not happen this time. Two controls are mandatory and both are cheap: **pointers are not duplicates** (an element's id is referenced by primitive properties like `ParentPointer` all over a normal document — counting those refuses every write), and a **normal translated page** with two translations differing only in id must still be accepted. False-positive control run at scale: **0 flagged out of 33,645 units across 90 projects**. Do NOT \"repair\" by deduplicating — an `$ID` is a pointer target, so choosing which element keeps its identity silently re-points references (ADR-0008).", "refs": ["#2"]}
diff --git a/.claude/skills/fix-issue/findings/other.jsonl b/.claude/skills/fix-issue/findings/other.jsonl
new file mode 100644
index 0000000000..70a928b841
--- /dev/null
+++ b/.claude/skills/fix-issue/findings/other.jsonl
@@ -0,0 +1,16 @@
+{"area": "scripts", "date": "2026-07-02", "symptom": "Docs/skills document MDL that doesn't parse (drift): `ALTER ENTITY X ADD (a, b)` / `DROP (a)` / `MODIFY (a)` / `RENAME a TO b`, `ALTER ENUMERATION … REMOVE VALUE`, `CREATE CONSTANT … TYPE X;` (no default), `DELETE_BEHAVIOR <invalid>`", "cause": "Docs were written against a SQL-DDL mental model, never `mxcli check`-validated. Correct forms: `ADD ATTRIBUTE a: type` (one action/statement), `DROP ATTRIBUTE a`, `MODIFY ATTRIBUTE a: type`, `RENAME ATTRIBUTE a TO b`, `DROP INDEX <name>`; `DROP VALUE`; enum `ADD VALUE X CAPTION 'y'` (CAPTION keyword required for ALTER, unlike CREATE); a constant `DEFAULT` is mandatory; delete-behavior ∈ {DELETE_AND_REFERENCES, DELETE_BUT_KEEP_REFERENCES, DELETE_IF_NO_REFERENCES, CASCADE, PREVENT}", "file": "`scripts/check-skill-mdl.sh` + `make check-skill-mdl` (CI)", "insight": "The guard extracts DDL statements from `.claude/skills/mendix/` **and** `docs-site/src/` and runs `mxcli check`; keeps this class of drift from recurring. Run it after editing any MDL example"}
+{"area": "unfiled", "date": "2026-05-18", "symptom": "Nightly `mx check` reports `CE0117 \"Error(s) in expression.\" at Log message activity 'Log message (warning)'` on Mendix 10.24.19+ but not 10.24.16 or 11.x", "cause": "Mendix 10.24.19 tightened expression validation: `toString(<string>)` is now a type error (toString expects a non-string input). An example called `toString($OrderNumber)` where `$OrderNumber` was already a string parameter", "file": "The offending `log warning ... with ({1} = toString($stringVar))` — find via `~/.mxcli/mxbuild/{ver}/modeler/mx check`, then bisect with `drop microflow ...` until CE0117 disappears", "insight": "Remove the redundant `toString()` wrapper around already-string values. Only wrap non-string values (integers, decimals, dates, enums) in `toString()`. The Mendix 11.x parser is more lenient and lets this slide, but 10.24.19+ rejects it", "ce": ["CE0117"]}
+{"area": "examples/doctype-tests", "date": "2026-07-26", "symptom": "The **nightly** matrix (Mendix 10.24 / 11.6 / 11.12) fails only on **10.24**: `TestMxCheck_DoctypeScripts/15c-fragment-bindings-examples` → `Execution error: failed to build page: building block not found: Atlas_Web_Content.List_Cards` (both engines). 11.6/11.12 pass; unit tests + push-test (single-version) pass. Looks like a \"design property on 10.24\" issue but isn't", "cause": "`15c` demonstrates `use building block Atlas_Web_Content.List_Cards`, an Atlas UI building block that ships in **11.x but is absent from the 10.x Atlas** (the example comment wrongly said \"present in every standard Mendix app\"). The example had **no `-- @version:` gate**, so on a 10.24 project the whole file ran and mxbuild couldn't resolve the block. (12-styling gates its design-property section at line 186; 31 gates the whole file at line 1 — both already skip on 10.24)", "file": "`mdl-examples/doctype-tests/15c-fragment-bindings-examples.mdl`", "insight": "Add `-- @version: 11.0+` immediately before the `create page … P002_Rebound_Block` block (its last statement) so `filterByVersion` skips only the building-block demo on 10.x; the fragment-binding statements above stay ungated and keep 10.24 coverage. Verified: 15c passes on **10.24** (10 lines skipped, 0 errors) and still runs+passes the section on **11.6.3** (0 errors). **Diagnosis pattern**: a nightly-only, version-specific doctype failure = an example using a construct (building block, widget, syntax) that doesn't exist in the oldest matrix version and lacks a `-- @version:` gate; reproduce locally with `MX_BINARY=~/.mxcli/mxbuild/<ver>/modeler/mx go test -tags integration -run TestMxCheck_DoctypeScripts/<file>`"}
+{"area": "examples/doctype-tests", "date": "2026-07-27", "raw": "| Same nightly pattern, **CE6083** this time: `TestMxCheck_DoctypeScripts/15b-fragment-slots-examples` fails only on **10.24** (both engines) — `[CE6083] \"Design property Card style is not supported by your theme\"` at every `cardWrap` container. `Card style` is an **Atlas v3 design property (11.x); the 10.x Atlas theme doesn't define it** | The shared `define fragment Card` used `designproperties: ['Card style': on]` and is instantiated by every page in the file, so a `-- @version:` gate would have to gate the whole file (killing 10.24 coverage of the slot feature the example is actually about). Unlike 15c's building block, the design property was **incidental** to the example | `mdl-examples/doctype-tests/15b-fragment-slots-examples.mdl` | **Drop the incidental v3 design property**, keep `class: 'card'` (Atlas card styling works on every version) — the example demonstrates content *slots*, not design properties (those live in 12-styling, gated 11.0+). Verified: 15b passes on 10.24 **and** 11.6.3 (0 errors, both engines). **Gate vs remove rule**: if the version-specific construct IS the point of a self-contained section → `-- @version:` gate it (15c); if it's incidental and in a shared/expanded definition → remove it and use a cross-version equivalent (15b). **Proactive sweep** after any such fix: `grep -lE 'designproperties|use building block' mdl-examples/doctype-tests/*.mdl` and confirm each usage is either gated or version-safe (note the doctype test skips `*.test.mdl`/`*.tests.mdl`) |", "ce": ["CE6083"]}
+{"area": "web/themes", "date": "2026-08-07", "symptom": "A sidebar navigation label renders truncated — \"All tasks\" shows as \"All task\" — under every theme (`signal`, `ledger`, `console`) and both variants, so switching theme does not help. Measured on the live DOM as `scrollWidth=56` inside `clientWidth=48`", "cause": "Atlas's **closed** sidebar is an icon rail: `--navsidebar-width-closed: 48px` in Atlas's own `themesource/atlas_core/web/themes/_theme-default.scss`. The label is wider than the rail, and the closed rail expects an *icon*, not text. No mxcli theme sets any navigation width — the themes map colours — which is exactly why every theme reproduces it", "file": "`.claude/skills/mendix/theme-styling.md` (documented; no code change)", "insight": "**A fix was written, verified, and reverted** — record the reason: adding `text-overflow: ellipsis` to the nav item helps only where Atlas also sets `white-space: nowrap`; elsewhere the label wraps to two readable lines, and the rule turns `All / tasks` into `All / t…`. Screenshotted both ways against the real compiled CSS. The answer belongs to the app (give nav items icons — what the rail is for — or keep the sidebar open), not to a theme that would impose it on every app. **Generalisable**: when a reported symptom traces to an upstream layout constant, reproduce the geometry against the real compiled CSS (48px container, real class names, Playwright measurement) — it takes minutes, tells you whose constant it is, and shows when the \"obvious\" CSS fix is a regression. mxcli-todo #19d", "refs": ["#19"]}
+{"area": "examples/bug-tests", "date": "2026-08-08", "symptom": "The `split type` docs and examples teach a shape that fails the build: `case Spec` + `else`, with no branch for the base entity → **CE0090** \"The 'X' value should be configured for an outgoing flow\". `mxcli check` passes, so the drift survived; `mdl-examples/bug-tests/365` and `475` both shipped it, and 475's own header claimed \"mx check reports 0 errors\"", "cause": "`else` on an inheritance split serializes as `Microflows$NoCase` and IS accepted, so it looks like it covers the remainder — but it does not satisfy type coverage. The base entity needs its own `case`", "file": "`.claude/skills/mendix/write-microflows.md` (Type Split section) + `mdl-examples/bug-tests/365-…`, `475-…`", "insight": "Cover EVERY type including the base; `else` is then redundant. Also give the split somewhere to go: branches converge on a merge continuing to the end event, so a non-void microflow needs a `return` after `end split;` (else MDL003 + **CE0067**). Matrix verified on 11.6.6 AND 11.13.0: `specs+base` 0 errors, `specs+base+else` 0 errors, `specs+else only` CE0090. **When repairing a bug-test fixture, preserve the scenario it pins** — 475 tests \"exactly ONE non-split branch continues\", so its added base case must TERMINATE; an empty (falling-through) body would make two branches continue and silently retire the regression. Confirmed after the edit that the post-split activity still renders outside both case bodies and the describe→exec roundtrip is mxbuild-clean. Known cosmetic artifact: DESCRIBE emits an empty `else` block that was never authored; it re-parses and builds clean", "ce": ["CE0067", "CE0090"], "rules": ["MDL003"]}
+{"area": "internal/marketplace", "date": "2026-08-11", "symptom": "`mxcli marketplace versions <id>` shows exactly ten versions for every content item, and asking for an older version reports it as not published — `marketplace diff` then refuses a module that was installed from a version the API plainly has", "cause": "`Client.Versions` made one unpaged request. `/v1/content/{id}/versions` returns **10** items when given no paging parameters and caps `limit` at **20**, so everything older fell off the end. Data Widgets has 131 published releases; mxcli could see 10", "file": "`internal/marketplace/client.go` (`Versions`, `versionPageSize`, `maxVersionPages`)", "insight": "Walk `offset` in `versionPageSize` steps until a page comes back short. **The cap is not the same as the `/v1/content` cap** (100), so reusing `pageSize` here silently truncates at 20 — probe the real endpoint rather than assuming one paging convention per API. **A count that is exactly a round number is the tell**: ten versions for every single item is a page size, not a release history. The mock in `TestVersions_WalksEveryPage` clamps `limit` the way the server does, so a client that asks once and trusts the answer fails it"}
+{"area": "docs-site/src", "date": "2026-08-18", "symptom": "An OQL `ORDER BY` on a **DateTime** looks ignored: `order by DealtAt desc limit 5` returns old rows while `order by Id desc` returns genuinely new ones, and the wrong answer is **stable across runs** — so it reads as a platform bug rather than a data problem, and the natural workaround becomes \"order by Id for recency\"", "cause": "**Not an mxcli bug, and not a Mendix bug.** Mendix emits the ordering with no null placement, so the database default applies: on PostgreSQL `DESC` means **NULLS FIRST**, and rows whose attribute was never set head the result. Stability is what makes it convincing and wrong — a degenerate sort key is exactly as repeatable as a correct one, so \"stable, therefore not a tie-break artifact\" does not discriminate", "file": "Nothing to change in mxcli — `ExecuteOQL` passes the query verbatim and `parseOQLFeedback` preserves row order. Docs only: `docs-site/src/tools/oql.md`, `.claude/skills/mendix/write-oql-queries.md`", "insight": "Measured on **Mendix 11.13.0** with PostgreSQL statement logging on, which is the method to reuse: `ALTER SYSTEM SET log_statement='all'`, run the query, read the SQL the runtime actually sent. With four distinct non-null timestamps the emitted SQL is `… ORDER BY \"x\".\"dealtat\" DESC LIMIT $1` and the result is correctly ordered — the ordering is **not** dropped. Adding two rows with an empty DealtAt reproduces the reported symptom exactly, and running Mendix's own emitted SQL by hand with `NULLS LAST` fixes it. **Generalisable**: when a query returns a wrong-but-stable answer, suspect a degenerate sort key before suspecting the engine; and when a bug report blames a layer, check whether that layer is even in the path — here the same finding also reported the column being *dropped from the projection*, whose known mechanism is a null in the first row, which was direct evidence for the real cause sitting unread in the report. mxcli-sudoku FINDINGS #39 (second half)", "refs": ["#39"]}
+{"area": "internal/marketplace", "date": "2026-08-18", "symptom": "`mxcli marketplace search 'Database Replication'` returns **No results** for a module that is right there; `search replication` finds it", "cause": "`filterItems` matched the packaged name (`DatabaseReplication`) and publisher verbatim. Packaged names have no spaces, and `Content` carries no display-name field, so the name as written everywhere matched nothing", "file": "`internal/marketplace/client.go` (`normalizeSearchTerm`)", "insight": "Fold case and drop separators (space, hyphen, underscore, dot) on **both** sides before matching, so the written name and the packaged name meet in the middle. Adding a display-name field was not an option — the API does not return one. **Generalisable**: when a search matches an identifier that was mechanically derived from a human name, normalise to the derivation, or every user has to guess the derivation. mxcli-dbreplication F7"}
+{"area": "unfiled", "date": "2026-08-18", "symptom": "A two-column card layout renders as one column and the CSS is provably correct — it is on the wrong element", "cause": "Mendix wraps a repeating widget's children in an intermediate element (`ul` for a list view, `.mx-dataview-content` for a data view), so `display: grid` on the widget's own class has exactly **one** grid item", "file": "`.claude/skills/mendix/migrate-design-prototype.md`", "insight": "Put the grid on the element that holds the repeated children (`.my-cards > ul`), and `min-width: 0` on the child so a wide table does not push the track. The skill already used `> ul > li` in one example but never stated the rule, which is why the same project hit it **twice in two different widgets**. **Generalisable**: an example that happens to be right teaches nothing — if a selector's shape is load-bearing, say why. mxcli-owid #15, #41", "refs": ["#15", "#41"]}
+{"area": "scripts", "date": "2026-08-17", "raw": "| A skill claims a construct is unsupported that the grammar accepts (and documents the working form elsewhere in the same file) — an agent writes valid MDL, hits the contradicting claim, and undoes it. Seen for `case … end case` in `write-microflows.md` (supported at §CASE Statements, \"not supported\" under UNSUPPORTED Syntax), with `check-syntax.md`, `MDL_QUICK_REFERENCE.md`, three `docs-site` pages and the generated project CLAUDE.md (a third shape, `CASE $Var/Attr AS x WHEN Enum.Value`) all disagreeing | Nothing validates prose claims against the grammar. `scripts/check-skill-mdl.sh` extracts fenced blocks but deliberately **skips microflow bodies** (fragment-heavy), so every syntax claim about microflow statements is unguarded. The wrong \"WRONG:\" example also used string-literal case values, which fail for their own reason — making the claim look confirmed | Docs only: `.claude/skills/mendix/write-microflows.md` + `check-syntax.md`, `docs/01-project/MDL_QUICK_REFERENCE.md`, `docs-site/src/language/control-flow.md` + `appendixes/{quick-reference,common-mistakes}.md`, `cmd/mxcli/init_claudemd.go` (the generated table) | Settle it against the binary before editing, one variant per claim (`bin/mxcli check` on the documented form, the quoted form, the qualified form, the `AS` form, the `else` form) — a \"WRONG\" example that fails for an unrelated reason is not evidence. Then fix **every** surface: grep `end case\\|END CASE` across `.claude/`, `docs/`, `docs-site/` and `cmd/mxcli/*.go`, not just the file in the report (7 surfaces, the issue named 3). Pin both directions in `mdl-examples/bug-tests/` — `907-case-enum-split-is-supported.mdl` (must pass) and `907-case-enum-split-invalid-forms.fail.mdl` (must fail) — so `make check-mdl` catches drift back. Issue #907 |", "refs": ["#907"]}
+{"area": "docs-site/src", "date": "2026-08-17", "symptom": "Docs disagree on whether an enumeration may be written as a string literal — the skills say \"NEVER use a string literal\", docs-site uses `Status = 'Draft'` in a dozen CREATE/CHANGE examples and calls it \"plain strings when the context is unambiguous\". Following either one wholesale is wrong, and `mxcli check` passes **both** the good and the bad form, so the build is where you find out", "cause": "It is context-dependent and nobody had measured it. A string is accepted wherever the slot is **already enum-typed**; in an **expression** it is a String compared to an Enumeration", "file": "Docs only: `.claude/skills/mendix/write-microflows.md` (Enumeration Comparisons), `docs-site/src/language/{control-flow,expressions}.md`, `docs-site/src/reference/microflow/create-microflow.md`", "insight": "Measure per context on a real project before touching a single example — one microflow per construct, `mxcli docker check` read per construct (`mxcli new EP --version 11.13.0 --skip-build`, then `exec` + `docker check`). Verified on 11.13.0: **CE0117** for `if $O/Status = 'Draft'` and for `'x' + $O/Status`; **clean** for `change`/`create` member values, attribute `DEFAULT 'Draft'`, XPath `[Status = 'Draft']`, and `getCaption()`/`toString()` in a concat. So fix **only** comparisons and concatenations — a sweep-and-replace over every `Status = '…'` would have \"corrected\" ~10 of 12 sites that are fine. No `.fail.mdl` is possible (check passes the failing form; the type checker is still a proposal — `docs/11-proposals/PROPOSAL_expression_type_checking.md`), so the verdicts live in `mdl-examples/bug-tests/enum-string-literal-contexts.mdl`, which pins the ACCEPTED forms and builds clean (control: adding it to a probe project left the error count unchanged at the 2 deliberate failures)", "ce": ["CE0117"]}
+{"area": "examples/doctype-tests", "date": "2026-08-19", "symptom": "The nightly fails on ONE Mendix matrix version only, in `TestMxCheck_DoctypeScripts`, with `Execution error: this project does not store the model setting <X>` — while the same script passes on every newer version", "cause": "The example script set a model setting that version does not have. Measured: a blank 10.24 stores 11 model settings and a blank 11.6.6 stores 12, `DecimalScale` being the only difference. mxcli's refusal is CORRECT — Studio Pro will not open a model carrying a property its version does not define, and mxbuild does not catch it — so the bug is the ungated example, not the guard. The refusal covers the WHOLE statement, so one version-specific setting takes every portable setting in the same `alter` down with it", "file": "`mdl-examples/doctype-tests/14-project-settings-examples.mdl`; guard in `mdl/executor/doctype_version_gating_test.go`", "insight": "Split the version-specific setting into its own statement inside a `-- @version: N.N+` section, closed with `-- @version: any`. **Put the `/** */` doc comment INSIDE the gated section**: a block comment is a documentation comment bound to the statement after it, so gating the statement while leaving the comment outside orphans it and the script dies with `no viable alternative at input '/**...'` — reported at the NEXT statement, tens of lines away, which reads like an unrelated syntax error. `--` line comments are free-standing and safe either side. Isolate which setting is at fault by exec'ing them one at a time against a blank project of that version (`mx create-project` in a SHORT path — a long one dies with PathTooLongException). `TestDoctypeScriptsParseAfterVersionFiltering` now parses every doctype script under each nightly matrix version without needing mxbuild, so a mis-gated script fails in seconds on push instead of hours later in one nightly job"}
+{"area": "generated/metamodel", "date": "2026-08-19", "raw": "| A REST call's `body mapping Mod.EMM from $var` is written with the variable under a key Mendix does not read, an empty `ContentType`, and an action-level `RequestHandlingType` of `Custom` that contradicts its own `Microflows$MappingRequestHandling` sub-element. A form-data body is dropped entirely by DESCRIBE, so describe → edit → exec silently produces a call that posts nothing | `generated/metamodel` is decisive: `MicroflowsMappingRequestHandling` owns exactly three properties — `contentType` (enum Json\\|Xml), `mappingId`, `mappingVariableName`. mxcli wrote `ParameterVariable`, which the type does not own, and omitted `MappingVariableName`; its own READER had known the right key since #843 and the writer was never corrected. `RequestHandlingType` was hardcoded `\"Custom\"` in both engines regardless of handler. `FormDataRequestHandling` / `AdvancedRequestHandling` can be parsed and not written, so a rewrite dropped them | `mdl/backend/modelsdk/microflow_write.go` (`requestHandlingTypeOf`, the Mapping case) and `sdk/mpr/writer_microflow_actions.go` (`restRequestHandlingTypeOf`, same case); guard `mdl/executor/validate_rest_request_handling.go` wired from `cmd_microflows_create.go`; tests `mdl/backend/modelsdk/microflow_restbody_test.go`, `mdl/executor/validate_rest_request_handling_test.go` | **A reader that compensates for a writer hides the writer's bug** — the `MappingVariableName` fallback made DESCRIBE round-trip correctly while every document mxcli wrote carried the wrong key. When a reader has a \"the real key is X\" comment, check that the writer agrees. **An unknown property is worse than a wrong value**: mxbuild tolerates it and Studio Pro refuses to open the document, so a green build proves nothing (same rule as the overlay section in CLAUDE.md). **Ask for one Studio Pro example per variant** — four microflows covering Custom/Mapping/FormData/Binary settled the discriminator question that a single example had left as \"unverified, so leave it alone\"; guessing the other five enum values from one measured case would have been a coin flip. **Parse-but-cannot-write is a data-loss path, not a gap**: DESCRIBE omits what the writer cannot express, so the omission looks like faithful output — refuse the rewrite (ADR-0005), and make the guard's allow-list the writable set so it stops refusing the moment a type becomes expressible. Not fixed: the legacy engine encodes `MappingId` as binary where Studio Pro stores a qualified-name string |", "refs": ["#843"]}
+{"area": "model", "date": "2026-08-25", "raw": "| A multi-segment member in an **inline REST** mapping (`\"Title\" = \"fields/Title\"` inside `Response:`/`Body: MAPPING`) passes every gate — `mxcli check`, `exec`, `mx check`, `describe` — and the column is **empty at runtime** | The inline REST serializer is a SEPARATE code path from the mapping documents, and it appended the member text verbatim: `jsonPath + \"\\|\" + m.ExposedName` stores `(Object)\\|fields/Title`, one member whose NAME contains a slash, where Mendix stores `(Object)\\|fields\\|Title`. Nothing converted `/` to `\\|` on this path. Confirmed against four Studio Pro-authored inline response mappings in the demo apps, which all store full pipe paths (`(Object)\\|results\\|bindings\\|(Object)\\|caseId\\|value`) | `model/mapping_paths.go` (`InlineMappingPath`, `InlineMappingExposedName`), `sdk/mpr/writer_rest.go` (`serializeInlineMappingElement`), `mdl/backend/modelsdk/consumed_rest_write.go` (`restInlineMappingElementToGen`), `mdl/executor/cmd_rest_clients.go` (`inlineMemberName`) | **The document fixes do not reach this.** The mapping census (`PROPOSAL_mapping_coverage.md`) classifies mapping DOCUMENTS only and does not mention the inline form, so none of #248/#262–#268 improved it as a side effect — a reader who sees multi-segment paths documented as working will reasonably try one here. Store the pipe path and put the **last segment** in `ExposedName` (Studio Pro's own derivation uniquifies against siblings — `caseId\\|value` becomes `CaseId_Value` but `graphData\\|value` in the same document becomes plain `Value` — so it is not reproducible from the path and does not need to be; ExposedName is a label, JsonPath is what binds). **Fixing the path breaks DESCRIBE in the same motion**: the printer emitted `ExposedName`, which now holds only the last segment, so it produced `\"Title\" = \"Title\"` — output that parses, re-executes and binds the wrong member. Derive the member from the stored JsonPath relative to the enclosing element and drop the generated `(Object)`/`(Array)`/`(Wrapper)` markers. Both engines have their own copy of this serializer; patch both or they drift. Repro `mdl-examples/bug-tests/rest-inline-mapping-paths.mdl`, tests `sdk/mpr/writer_rest_inline_mapping_test.go`. mxcli-rest FINDINGS #36 |", "refs": ["#248", "#262", "#268", "#36"]}
+{"area": "web/dist", "date": "2026-08-30", "raw": "| After `mxcli test … --local`, an app another `mxcli run --local` is serving goes blank while still answering HTTP 200 (~1.7 KB, the Mendix SPA shell); the runtime log shows `Connector: 404 - file not found for file: dist%2Findex.js` and `deployment/web/dist` is gone | `cmd/mxcli/testrunner/localapp_options.go`, `cmd/mxcli/testrunner/runner_local.go` (`localTestDeployDir`), `cmd/mxcli/testrunner/runner.go` (`checkScratchDeploymentExists`) | A local test run already used its own ports and its own `<project>_test` database — the code comment says why, verbatim — but shared the **deployment directory**, which is the one the *browser* reads. A headless test boot does not bundle the web client, so its build left the running app serving the shell over a 404: tests pass, run keeps running, app is blank, nothing reported at either end. **Detection was not the fix**: the two processes use different ports by design, so no port check can see it, and a lock file would only turn a silent blanking into a refusal. The test boot now builds into `<project>/.mxcli/deployment-test/` — gitignored, already where the test runtime log lives — which makes the collision impossible. Note booting a runtime against the shared directory damages it even **without** a rebuild (the packaging step removes the bundle — FINDINGS §35, `ReportLostWebClientBundle`), so \"reuse the dev loop's tree read-only\" is not an alternative. Consequence to wire: `--skip-build` used to mean \"reuse deployment/\" and now has nothing until tests have run once, so it is refused with the reason rather than failing inside the runtime boot against a path the user never chose. Reported as mxcli-formula1 FINDINGS §62 |"}
diff --git a/.claude/skills/fix-issue/findings/sdk.jsonl b/.claude/skills/fix-issue/findings/sdk.jsonl
new file mode 100644
index 0000000000..128289889e
--- /dev/null
+++ b/.claude/skills/fix-issue/findings/sdk.jsonl
@@ -0,0 +1,40 @@
+{"area": "sdk/mpr", "date": "2026-08-01", "symptom": "Every popup opened by an **mxcli-authored** button or Show Page action shows a **blank caption** — just the `×` — while Studio Pro / marketplace popups in the same project are fine. Also: `show page M.P with title = 'X'` is silently ignored", "cause": "`Forms$FormSettings` / `Forms$PageSettings` `TitleOverride` was written as an **empty** `Microflows$TextTemplate` instead of `null`. An empty template is not the absence of an override — it overrides the title with the empty string. The same unconditional write also discarded `ShowPageAction.OverridePageTitle`, so an authored override never reached BSON (`grep -rn OverridePageTitle` matched only the struct field and its assignment)", "file": "`sdk/mpr/writer_microflow_actions.go` (`titleOverrideValue`), `sdk/mpr/writer_widgets_action.go`, `mdl/backend/modelsdk/microflow_write.go` (`showPageFormSettingsToGen`), `mdl/backend/modelsdk/widget_write.go` (`formSettingsToGen` + the `Forms$FormSettings`/`Forms$PageSettings` defaults)", "insight": "Emit `null` when there is no override and a populated `TextTemplate` when there is. **Beware two traps.** (1) The old comments claimed TitleOverride \"must be non-nil\", reasoning by analogy from #295, which was about `Forms$PageVariable` — a different field; the repo's own `debug-bson.md` already documented `TitleOverride: nil` as correct. When a comment cites an issue as justification, check that the issue is about the same field. (2) `codec.RegisterTypeDefaults` **overwrites rather than merges**, so two registrations for one `$Type` resolve silently by init order — a `NullFields` entry added next to the microflow writer was clobbered by the one in `widget_write.go` and the null never appeared. Grep for duplicate registrations before debugging a default that \"does not apply\". Repro `mdl-examples/bug-tests/812-showpage-title-override.mdl`. Issue #812", "refs": ["#295", "#812"]}
+{"area": "sdk/mpr", "date": "2026-04-21", "symptom": "`describe` shows `$var = list operation ...;`", "cause": "Missing parser case", "file": "`sdk/mpr/parser_microflow.go` → `parseListOperation()`", "insight": "Add `case \"microflows$XxxType\":` returning the correct struct"}
+{"area": "sdk/microflows", "date": "2026-04-16", "symptom": "Compile error: `undefined: microflows.XxxOperation`", "cause": "Missing SDK struct", "file": "`sdk/microflows/microflows_actions.go`", "insight": "Add struct + `func (XxxOperation) isListOperation() {}` marker"}
+{"area": "sdk/mpr", "date": "2026-04-21", "symptom": "`TypeCacheUnknownTypeException` in Studio Pro", "cause": "Wrong `$type` storage name in BSON write", "file": "`sdk/mpr/writer_microflow.go`", "insight": "Check the storage name table in CLAUDE.md; verify against `reference/mendixmodellib/reflection-data/`"}
+{"area": "sdk/mpr", "date": "2026-04-16", "symptom": "CE0066 \"Entity access is out of date\"", "cause": "MemberAccess added to wrong entity", "file": "`sdk/mpr/writer_domainmodel.go`", "insight": "MemberAccess must only be on the FROM entity (`ParentPointer`), not the TO entity — see CLAUDE.md association semantics", "ce": ["CE0066"]}
+{"area": "sdk/widgets", "date": "2026-04-16", "symptom": "CE0463 \"widget definition changed\"", "cause": "Object property structure doesn't match Type PropertyTypes", "file": "`sdk/widgets/templates/`", "insight": "Re-extract template from Studio Pro; see `sdk/widgets/templates/README.md`", "ce": ["CE0463"]}
+{"area": "sdk/mpr", "date": "2026-04-16", "symptom": "Parser returns `nil` for a known BSON type", "cause": "Unhandled `default` in a `parseXxx()` switch", "file": "`sdk/mpr/parser_microflow.go` or `parser_page.go`", "insight": "Find the switch by grepping for `default: return nil`; add the missing case"}
+{"area": "sdk/widgets", "date": "2026-06-21", "symptom": "`exec` of a pluggable widget from a bundled multi-widget `.mpk` fails \"no definition for widget … (run 'mxcli widget init')\" even after init (e.g. only AreaChart of Charts.mpk registers)", "cause": "`ParseMPK`/`getWidgetIDFromMPK` read only `WidgetFiles[0]`; a bundled `.mpk` (Charts) holds many widgets so only the first is registered/augmented", "file": "`sdk/widgets/mpk/mpk.go` (`ParseMPKAll`/`ParseMPKWidget`, `FindMPK`) + def-gen loops in `mdl/executor/widget_defs.go` + `mdl/catalog/builder_widget_definitions.go` + `cmd/mxcli/cmd_widget.go`", "insight": "Parse every widgetFile (`ParseMPKAll`); register all ids in `FindMPK`; augment the specific id (`ParseMPKWidget`); bump `WidgetDefGeneratorVersion` so existing projects regenerate. Issue #679. (Per-series datasource + chart CE0463 are separate, still open.)", "refs": ["#679"], "ce": ["CE0463"]}
+{"area": "sdk/pages", "date": "2026-06-18", "symptom": "`buttonstyle: <value>` passes `mxcli check` but the button renders btn-default in Studio Pro (silent at build) — typically a mis-cased value (`Primary`) or one Mendix doesn't have (`secondary`, `link`)", "cause": "Visitor stored the style verbatim and the executor cast it straight to `pages.ButtonStyle`; only an empty value got a default, so any unknown string was written as-is and MxBuild degraded it", "file": "`sdk/pages/pages_widgets_action.go` (`CanonicalButtonStyle`) + `mdl/executor/cmd_pages_builder_v3_widgets.go` (button builder) + `mdl/executor/validate_widgets.go` (`validateStaticWidget`)", "insight": "Normalize case-insensitively against the metamodel `PagesButtonStyle` set (Default/Primary/Success/Warning/Danger/Info/Inverse); reject unknown values as MDL-WIDGET02 at check time and in the executor. Issue #672", "refs": ["#672"]}
+{"area": "sdk/widgets", "date": "2026-05-15", "symptom": "CE3637 \"A data view cannot listen to the selection of Gallery 'X', because it is not available here.\" on a master-detail page generated from MDL", "cause": "Gallery's `itemSelectionMode` pluggable-widget property was hardcoded to `clear` in the def.json; Mendix requires `toggle` for selection-listeners (DataViews bound via `DataSource: selection X`) to see the gallery's selection", "file": "`sdk/widgets/definitions/gallery.def.json`", "insight": "Change the `itemSelectionMode` mapping from `value: \"clear\"` to `source: \"ItemSelectionMode\", default: \"clear\"` so MDL can write `gallery X (Selection: Single, ItemSelectionMode: toggle)`. The V3 engine's generic mapping path (`widget_engine.go` `resolveMapping` default case → `GetStringProp`) reads the value automatically — no grammar changes needed. Also add `ForceFullObjects: false` to `Forms$ListenTargetSource` serializer in `sdk/mpr/writer_widgets_display.go`", "ce": ["CE3637"]}
+{"area": "sdk/mpr", "date": "2026-05-16", "symptom": "CE0463 \"widget definition changed\" on every pluggable widget that contains a caption/template parameter (gallery, datagrid2 captions, dynamictext with ContentParams) on Mendix 11.9 — cascades into CE3637 on master-detail pages", "cause": "`serializeClientTemplateParameter` emitted `Forms$FormattingInfo` with a `TimeFormat: \"HoursMinutes\"` field, but the FormattingInfo reflection schema only declares CustomDateFormat / DateFormat / DecimalPrecision / EnumFormat / GroupDigits — the extra field made Studio Pro mark the embedded WidgetType as drifted", "file": "`sdk/mpr/writer_widgets.go` `serializeClientTemplateParameter` + `mdl/backend/mpr/widget_builder.go` (mirror copy of the same FormattingInfo block)", "insight": "Drop the `TimeFormat` entry from both writers. Verify by diffing your BSON against a Studio Pro-saved page's FormattingInfo block — if you see keys outside the reflection schema, that's the trigger", "ce": ["CE0463", "CE3637"]}
+{"area": "sdk/mpr", "date": "2026-05-22", "symptom": "`describe`/catalog reports a numeric BSON field (Length, MinOccurs, MaxOccurs, MaxLength, FractionDigits, TotalDigits, Interval, NumberOfPagesToClose, …) as `0` / `unlimited` even though Studio Pro shows a real value", "cause": "BSON numeric width mismatch — Studio Pro writes the field as `int64`, but the parser asserted `raw[\"X\"].(int32)` so the type assertion failed silently and the field defaulted to its zero value", "file": "`sdk/mpr/parser_*.go` — grep for the field name; the fix point is the narrow assertion", "insight": "Replace narrow type assertions on BSON numeric fields with the existing `extractInt(raw[\"X\"])` helper (`sdk/mpr/parser.go`). It handles int32/int64/int/float64. When a non-zero default must survive a missing field, gate with `if _, ok := raw[\"X\"]; ok { … = extractInt(...) }`. Sweep `grep -n '\\.(int32)' sdk/mpr/parser_*.go` and ignore matches whose comment says \"marker\" (BSON-array-prefix probes are intentional). Issues #583, #585", "refs": ["#583", "#585"]}
+{"area": "sdk/mpr", "date": "2026-05-27", "symptom": "Studio Pro shows a dropdown / property as its default value even though MDL set it explicitly (e.g. CREATE ODATA CLIENT with `ConfigurationMicroflow:` set, but the \"Configuration source\" dropdown reads \"Constants only\")", "cause": "The BSON key mxcli writes isn't what Studio Pro reads — either the key name is wrong, or multiple dropdown options actually share a single field discriminated by something other than the key name (return type of a referenced microflow, sibling property, etc.)", "file": "The `serializeXxx` function in `sdk/mpr/writer_*.go` for the affected document type", "insight": "(1) Ask the user to duplicate the offending object in Studio Pro and **explicitly pick each dropdown option** on the duplicate(s). An unconfigured duplicate just looks like \"Constants only\" and tells you nothing about which field the option uses. (2) Re-dump the duplicates from `mprcontents/**/*.mxunit` **after every Studio Pro change** — cached `/tmp/svc-*.json` files go stale the instant the user edits the project (see [[feedback-refresh-bson-dumps]]). (3) Diff against mxcli's output to find the renamed key. (4) Don't assume one-state-per-key. The OData \"Configuration microflow\" / \"Headers microflow\" case stores BOTH options in the single `ConfigurationMicroflow` BSON field — Studio Pro picks the dropdown label from the referenced microflow's return type. When a discriminator like that exists, have both MDL keywords write to the same model field. Issues #573, #587 and 2026-05-27 unify-config-microflow fix", "refs": ["#573", "#587"]}
+{"area": "sdk/widgets", "date": "2026-07-09", "symptom": "An **invalid enumeration value** on a pluggable-widget object-list sub-property passes `mxcli check` but silently defaults in Studio Pro/mxbuild — e.g. a Maps marker `LocationType: 'coordinates'` (real values are `address`/`latlng`) defaults to `address` → CE \"a dynamic marker requires an address\"; a chart series `Interpolation: 'wobbly'` degrades. The value is dropped with no diagnostic", "cause": "The def.json never captured a property's enumeration member keys, so `check` had nothing to validate against. (This is *not* a persistence bug — a **valid** enum value round-trips fine.)", "file": "mpk parser `sdk/widgets/mpk/mpk.go` (`PropertyDef.EnumValues` from `<enumerationValues>`) + `mdl/executor/widget_defs.go` (`ItemPropertyMapping.EnumValues`, bump `WidgetDefGeneratorVersion`) + validator `mdl/executor/validate_widgets.go` (`validateObjectListItemEnums`)", "insight": "Capture `<enumerationValue key=…>` keys into `PropertyDef.EnumValues` at all three PropertyDef build sites; carry into `ItemPropertyMapping.EnumValues`; add **MDL-WIDGET08**: for each object-list-item enum sub-property present in the AST, flag a value (case-insensitive) outside the member set, listing the valid values. Thread the parent's `ObjectListMapping` into `validateWidgetTreeIn` (was just the container-keyword set). Tests: `TestValidateObjectListItemEnums`, `TestParseMPK_CapturesEnumValues` (the MDL-WIDGET08 check needs project context/`-p`, so it can't be a `.fail.mdl` — `make check-mdl` runs those syntax-only; example `32-pluggable-widget-object-lists-v010.mdl` OL06/OL07 exercise the valid `latlng` path end-to-end). NOTE: top-level (non-object-list) widget enum props aren't validated yet — `PropertyMapping` doesn't carry `EnumValues`. Bug 9a follow-up"}
+{"area": "sdk/mpr", "date": "2026-07-06", "symptom": "A page whose widget has a **conditional visibility/editability** setting fails to **load** on **Mendix 11.12** — `StorageLoadException: Conditional editability settings … has an invalid value '' for property Attribute. The text '   ' is not a valid AttributeIdentifier` (the `'   '` is `\\x03\\x00\\x00\\x00` = an int32 list marker; sometimes the value is the object's own `$Type` string). **Both engines**, ≤ 11.11 tolerated it. Reproduces only in the full doctype gate, not minimally — a red herring: it looked like `mx update-widgets` (harness step) was the cause, but the corruption is on disk from mxcli. My pymongo scans missed it because the value is a non-string type / the reader mis-parses", "cause": "mxcli serialized `Forms$ConditionalVisibilitySettings` / `ConditionalEditabilitySettings` `Attribute` as **BSON null** when there's no attribute-based condition. Studio Pro writes the **empty string `\"\"`** (Attribute is a BY_NAME `AttributeIdentifier`). 11.12's stricter streaming reader rejects the null and mis-reads the following bytes. Found by comparing a Studio-Pro-authored settings node (`str \"\"`) against mxcli's (`NoneType`)", "file": "legacy: `sdk/mpr/writer_widgets.go` (`serializeConditionalVisibility`/`serializeConditionalEditability`); modelsdk: `mdl/backend/modelsdk/widget_write.go` (RegisterTypeDefaults) + new `codec.TypeDefaults.EmptyStringFields`", "insight": "Emit `Attribute: \"\"` not null. Legacy: change the `bson.D` value. Modelsdk: move `\"Attribute\"` from `NullFields` to the new `EmptyStringFields` (encoder emits `\"\"`). **Diagnosis pattern**: when mx reports a corrupt value that pymongo *can't see on disk*, and the value looks like a `$Type` string or `\\x03\\x00\\x00\\x00`, suspect a wrong BSON *type* for a field (null where a string is required) that the streaming reader mis-aligns — compare field types against a Studio-Pro-authored node, don't just compare key presence. Repro: `mdl-examples/bug-tests/conditional-settings-attribute-empty-1112.mdl`"}
+{"area": "sdk/mpr", "date": "2026-07-06", "symptom": "A CLOSE PAGE microflow/nanoflow activity (`close page;`) fails `mx check` on **Mendix 11.12** with `CE0117 \"Error(s) in expression\"` at the Close page activity — **legacy engine only** (modelsdk passes; ≤ 11.6 tolerated it). Any annotation (`@caption`/`@color`/`@position`) on the activity reliably exposes it", "cause": "The legacy `sdk/mpr` writer serialized the `Microflows$CloseFormAction` page-count under the field name `NumberOfPagesToClose`, but the metamodel storage name is `NumberOfPages` (the codec/modelsdk already used it — found by diffing the two engines' BSON: `legacy=NumberOfPagesToClose, modelsdk=NumberOfPages`). 11.12 doesn't recognise the old name, so the real `NumberOfPages` field is absent → defaults to an empty expression → CE0117", "file": "`sdk/mpr/writer_microflow_actions.go` (`*microflows.ClosePageAction` case) + `sdk/mpr/parser_microflow_actions.go`", "insight": "Write `NumberOfPages` (not `NumberOfPagesToClose`); the reader accepts both (`NumberOfPages` first, legacy `NumberOfPagesToClose` fallback) for round-trip fidelity on existing projects. **Diagnosis pattern**: a CE that says \"invalid/empty expression\" on an activity with no visible expression usually means a *renamed/missing* field defaulting to empty — diff the passing engine's BSON against the failing one to spot the field-name drift. Repro: `mdl-examples/bug-tests/close-page-numberofpages-1112.mdl`", "ce": ["CE0117"]}
+{"area": "sdk/mpr", "date": "2026-07-06", "symptom": "On **Mendix 11.12**, `mx check` fails to load projects on the **legacy** engine for several doctypes (`01-domain-model`, `10-odata`, `14-project-settings`, `22-published-rest`) with `System.InvalidOperationException: Expected '$ID' as the first property of a storage object, but got 'X'` at `StreamingBsonUnitReader`. The bad first-key varies run-to-run (`ThemeModuleOrder`, `EnableRspackBundler`, `Oql`, `MarkAsUsed`, `PopupResizable`…) — the tell-tale of random map-key order. modelsdk passes; ≤ 11.11 tolerates any order", "cause": "Several legacy `sdk/mpr` writers preserve round-trip fidelity by carrying parsed subtrees as Go maps (`ProjectSettings.RawParts`, ref-marking `raw`, rename `raw`, domain-model `raw`) and marshalling them back. `bson.Marshal` emits **map keys in random order**, so `$ID` only lands first by luck. 11.12 rejects any storage object whose first key isn't `$ID`. The earlier `$ID`-first fix (bson.D reorder in writer_domainmodel/security) missed every map-passthrough site", "file": "`sdk/mpr/writer_settings.go` (+ `writer_refs`, `writer_rename`, `writer_domainmodel`, `writer_odata`, `writer_rest`, `writer_customblob`, `writer_security`, `writer_modules`, `writer_microflow`, … — all unit-boundary marshals) via new `sdk/mpr/writer_order.go`", "insight": "Wrap every unit-boundary `bson.Marshal(doc)` in `marshalUnitIDFirst(doc)` = `bson.Marshal(bsonutil.HoistStorageID(doc))`. **Use the non-sorting `HoistStorageID`, NOT `OrderStorageValue`**: `OrderStorageValue` *sorts* the non-`$ID` keys, which corrupts template-derived pluggable-widget/datagrid page trees (mx then aborts with `got 'LabelTemplate'`, regressing `29-datagrid`/`33-alter-page`). `HoistStorageID` only lifts `$ID`/`$Type` to the front and preserves every other key's order → no-op on already-correct writers, fixes only the map-passthrough ones. **Do NOT normalize `writer_pages.go` or the page/workflow mutators** — their output is already `$ID`-first and they embed delicate widget maps the hoist would sort-corrupt. Verify on 11.12 with the doctype gate; regression-check `29`/`33` specifically. (Left unfixed: `03-page` LabelTemplate — a separate pre-existing issue where on-disk bytes read `$ID`-first yet mx still objects)"}
+{"area": "sdk/widgets", "date": "2026-07-02", "symptom": "A `NUMBERFILTER` in a DataGrid column passes `mxcli check` but corrupts the `.mpr`: MxBuild / Studio Pro **fails to load** the whole project on **Mendix 11.12** with `System.InvalidOperationException: Type …CustomWidgets.WidgetProperty does not contain a constructor with a parameter of type …CustomWidgets.WidgetValue` at `StreamingBsonUnitReader.ConstructObject`. `TEXTFILTER`/`DATEFILTER`/`DROPDOWNFILTER` in identical grids load fine; ≤ 11.11 loads even the number filter. Isolating it needs dropping widgets one-by-one under `mx check`", "cause": "The embedded `datagrid-number-filter.json` template authored its 3 placeholder / screen-reader `Forms$ClientTemplate` blocks with **markerless empty arrays** — `\"Items\": []` and `\"Parameters\": []`. Every Mendix list serializes with a leading marker int (`Texts$Text.Items`→`[3]`, `ClientTemplate.Parameters`→`[2]`, `Widgets`/`Objects`→`[2]`); a bare `[]` has no marker. 11.12's stricter streaming reader mis-parses the markerless array and mis-associates the following bytes, so a nested `WidgetValue` lands where the reader is constructing a `WidgetProperty`. The template shape is otherwise identical to the working filters — the only diff is the missing markers (the blocks had hand-authored `dd2b3c4d…` placeholder IDs, i.e. not cleanly extracted from Studio Pro)", "file": "`sdk/widgets/templates/mendix-11.6/datagrid-number-filter.json` **and** `modelsdk/widgets/templates/mendix-11.6/datagrid-number-filter.json` (both engines embed their own copy)", "insight": "Add the marker int to every empty `TextTemplate` array: `\"Items\": []`→`\"Items\": [3]`, `\"Parameters\": []`→`\"Parameters\": [2]`. Rebuild (`go:embed`), re-exec, verify with `scripts/mx-check.sh --version 11.12.0` (0 errors; regression-check 11.9 still clean). Guard: `TestTemplates_NoMarkerlessEmptyArrays` (in both `sdk/widgets` and `modelsdk/widgets`) walks every embedded template and fails on any bare `[]` — a Mendix list must always carry its marker. Repro: `mdl-examples/bug-tests/datagrid-numberfilter-array-marker.mdl`. **Diagnosis tip**: when a widget \"passes check, fails 11.12 load\" with the WidgetProperty/WidgetValue constructor error, suspect a markerless empty array in the template (shape-diff the failing widget's template against a working sibling; the smoking gun is `[]` vs `[<int>]`)"}
+{"area": "sdk/pages", "date": "2026-07-07", "symptom": "A widget's `DynamicClasses: '<expr>'` passes `mxcli check` but is silently dropped on write — `describe page` shows `Class` but no `DynamicClasses`; on `alter page ... set DynamicClasses` a core widget instead hard-errors \"widget has no pluggable Object\"", "cause": "`DynamicClasses` (a `Forms$Appearance` string, sibling of `Class`) was unwired at every layer: parked in the generic Properties map, never read by `applyWidgetAppearance`, no `BaseWidget` field, both writers hardcoded `DynamicClasses: \"\"`, mutator had no case (fell to the pluggable-property setter), and describe never surfaced it", "file": "`sdk/pages/pages_widgets.go` (`BaseWidget.DynamicClasses`) + `mdl/ast/ast_page_v3.go` (`GetDynamicClasses`) + `mdl/executor/cmd_pages_builder_v3.go` (`applyWidgetAppearance`) + `mdl/executor/widget_engine.go` (`isBuiltinPropName`) + both writers (`sdk/mpr/writer_widgets.go` `serializeAppearance`; `mdl/backend/modelsdk/widget_write.go` `newAppearance`) + describe (`cmd_pages_describe*.go`) + `mdl/backend/pagemutator/mutator.go` (`case \"DynamicClasses\"`)", "insight": "Carry it on `BaseWidget` (the appearance path — one place — covers core + pluggable widgets since `applyWidgetAppearance` runs for both); thread it through the appearance serializer of **both** engines (it's just a sibling string of `Class`); add a mutator `case \"DynamicClasses\"` writing `Appearance.DynamicClasses`; add a read at each `appearance[\"Class\"]` site + an emit in `appendAppearanceProps`. Add `\"DynamicClasses\"` to `isBuiltinPropName` so the pluggable explicit-property pass skips it and the unknown-property guard permits it. Bug-test `mdl-examples/bug-tests/widget-dynamicclasses.mdl`; `mx check` = 0 on both engines."}
+{"area": "sdk/pages", "date": "2026-07-07", "symptom": "A widget's conditional visibility set via the **string / static-boolean** form — `Visible: '<expr>'`, `set Visible = \"<expr>\"`, or `Visible: false` — passes `check`+`exec` but is silently dropped (only the `[ … ]` bracket form worked)", "cause": "The visitor routes a bracket constraint to `Properties[\"VisibleIf\"]` (consumed by `applyConditionalSettings`) but any other value to `Properties[\"Visible\"]`, which nothing consumed; the ALTER mutator's `case \"Visible\"` wrote a bare `Visible` string (a DataGrid2-column alias) that Studio Pro ignores on a general widget. A page widget has **no** plain boolean Visible field — visibility is always `ConditionalVisibilitySettings`", "file": "`sdk/pages/pages_widgets.go` (`StaticVisibleExpression`) + `mdl/executor/cmd_pages_builder_v3.go` (`applyConditionalSettings`) + `mdl/backend/pagemutator/mutator.go` (`case \"Visible\"`)", "insight": "Add `pages.StaticVisibleExpression(v)` mapping the value to a client expression: `false`→`\"false\"`, an expression string passes through (caller roots it; the bracket form auto-roots), `true`/`\"\"`→\"no settings / clear\". CREATE's `applyConditionalSettings` reads `Properties[\"Visible\"]` as a fallback after `VisibleIf`; the ALTER mutator's `case \"Visible\"` builds the `ConditionalVisibilitySettings` node via `setWidgetConditionalSettingMut` (or clears it to nil for `true`). Both engines: CREATE via the shared model→`applyWidgetBase`, ALTER via the shared raw-BSON mutator. describe converges every form to the canonical `Visible: [expr]`. NB datagrid **column** visibility is a separate `columnPropertyAliases` path — untouched. Bug-test `mdl-examples/bug-tests/widget-visible-expression.mdl`; `mx check` = 0 on both engines."}
+{"area": "sdk/pages", "date": "2026-07-09", "symptom": "A `dynamictext`/`datagrid` **contentparams**/**captionparams** entry that navigates an association (`[{1} = Module.Assoc/Attr]`, e.g. `Expense_Employee/Name`) passes `mxcli check --references` but fails MxBuild \"Value of text template parameter {1} … No value specified.\" A **direct** attribute (`[{1} = Title]`) persists fine — the drop is specific to association navigation", "cause": "The value string (`Module.Assoc/Attr`) reached the AttributeRef serializer, which rejects any path with `< 2` dots (the association hop has 1 dot; `/Attr` is navigation, not counted) → **null AttributeRef** → CE0402. Nothing built the association-step structure Mendix needs. Verified against a Studio-Pro-authored page: the binding is a `DomainModels$AttributeRef` whose `Attribute` is the FINAL attr (`Module.Employee.Name`) and whose `EntityRef` is a `DomainModels$IndirectEntityRef` of `DomainModels$EntityRefStep{Association, DestinationEntity}` hops", "file": "`sdk/pages/pages_widgets_display.go` (`ClientTemplateParameter.AttributeRefSteps`, `AttributeRefStep`) + `mdl/executor/cmd_pages_builder_v3.go` (`resolveTemplateAssociationPath`, `associationEndpoints`) + `mdl/backend/modelsdk/widget_write.go` (`attributeRefWithStepsToGen`) + `mdl/executor/cmd_pages_describe_output.go` (`associationTemplateParamPath`)", "insight": "**modelsdk engine only.** Resolver splits the path into association hop(s) + final attribute, resolves each association's destination entity from the domain model (ParentID=FROM, ChildID=TO; direction from the context entity), and stores `AttributeRef`=final attr QN + `AttributeRefSteps`. The writer emits `AttributeRef.EntityRef` via `entityRefToGen` (reused from microflows — identical `IndirectEntityRef`/`EntityRefStep` storage names); the `< 2 dots` guard no longer trips since the final attr is 2-dot. DESCRIBE reconstructs `Assoc/Attr` from `EntityRef.Steps`. Legacy engine still drops it (out of scope). Generated BSON is byte-structurally identical to Studio Pro. **Non-String final attribute needs NO `toString()`** — verified against Studio Pro, an association-navigated param uses `AttributeRef` + `FormattingInfo` (DecimalPrecision/DateFormat/EnumFormat) for any type; the `toString()` wrapping is only the *direct*-attribute path's behavior. Do not \"fix\" the assoc path to wrap non-String — that diverges from Studio Pro. Tests: `mdl/backend/modelsdk/widget_template_assoc_test.go`, `mdl/executor/cmd_pages_describe_assoc_test.go`; bug-test `mdl-examples/bug-tests/dynamictext-contentparam-association.mdl`", "ce": ["CE0402"]}
+{"area": "sdk/mpr", "date": "2026-07-24", "symptom": "A **compound** (nested) design property authored inline on a widget — `designproperties: ['Card style': on, 'Spacing': ['margin-bottom': 'Large', 'margin-top': 'Medium']]`, e.g. the Atlas `Spacing` group, and any block copied in via `use building block` — is silently dropped on write: `check`, `exec`, **and `mx check`** all pass, but the nested styling is simply gone (only the flat toggle/option props survive). The **legacy** builder write path. Sibling of #668, which fixed the describe **read** side but not this CREATE write path", "cause": "`serializeDesignProperties` switched on `p.ValueType` with cases for `toggle`/`option`/`custom` and a `default: continue` that dropped `compound` entirely. A compound property's value is itself a set of sub-properties stored in a `Forms$CompoundDesignPropertyValue`, whose `Properties` list has the SAME marker-prefixed `Forms$DesignPropertyValue` shape as the outer array — but nothing serialized it, so the whole entry (key included) vanished", "file": "`sdk/mpr/writer_widgets.go` (`serializeDesignProperties`)", "insight": "Add a `case \"compound\"` emitting `{$ID, $Type: Forms$CompoundDesignPropertyValue, Properties: serializeDesignProperties(p.Compound)}` — recurse into the sub-entries, which the marker-prefixed array handling already covers. The AST (`DesignPropertyEntryV3.Nested`), visitor (`buildDesignPropertyEntryV3`), and builder (`astDesignPropToValue` → ValueType `\"compound\"`, `Compound`) all already produced the nested model; only the serializer's terminal switch dropped it. Verified: `mxcli docker check` = 0 errors on 11.12.1 (authoritative) + write→describe round-trip preserves `Spacing` on **both** engines. Test `TestSerializeDesignProperties_Compound` (`sdk/mpr/writer_widgets_test.go`); bug-test `mdl-examples/bug-tests/compound-designproperties.mdl`. **Diagnosis pattern**: when a value passes every check *including `mx check`* yet the construct is absent, suspect a terminal `default: continue`/`default:` drop in a type-switched serializer — the value never reaches BSON, so nothing downstream can complain", "refs": ["#668"]}
+{"area": "sdk/mpr", "date": "2026-07-09", "symptom": "A **list** widget (listview/datagrid/gallery) reverse-navigating an association (`datasource: $currentObject/Module.Assoc` on a Customer showing its Orders) passes `mxcli check` but fails MxBuild **CE8812** \"A grid association path must result in a list.\" — **only** when the association is `owner both` **and** its FROM entity has another association. Default-ownership references work; a DataView (to-one) over the same reverse works", "cause": "**Not an mxcli encoding bug** — the `Forms$AssociationSource` + `EntityRefStep{Assoc, DestinationEntity}` is correct (verified via `bson dump`). It's correct MxBuild behavior: `owner both` on a plain `type reference` makes the reverse navigation **to-one**, so a *list* widget over it is invalid (a DataView is fine). The single-ref-vs-multi-ref inconsistency (single owner-both allows the reverse listview; adding a sibling association flips it to-one) hints at a **separate, unfixed `owner both` domain-model serialization quirk** — not yet root-caused (needs a Studio-Pro owner-both reference for comparison)", "file": "domain-model writer (`sdk/mpr/writer_domainmodel.go` / `mdl/backend/modelsdk/domainmodel_write.go` association owner/navigability) — **investigate before adding any check**", "insight": "**No check added** (deliberately — the condition isn't statically precise and isn't always-wrong; adding one would repeat the MDL-WIDGET08 over-rejection mistake). Guidance only: use `default` ownership for a normal to-one reference (reverse is then to-many, list widgets work); reserve `owner both` for `ReferenceSet`. Documented in `generate-domain-model.md` (Owner Options). Diagnose CE8812 by dumping the widget source (encoding is usually right) then checking the association's `owner` — bisect the domain model, not the page. **Method note:** bisected this with `mxcli docker check --no-update-widgets` over a fresh test-project copy per variant", "ce": ["CE8812"]}
+{"area": "sdk/pages", "date": "2026-07-11", "symptom": "An `actionbutton`/`linkbutton` `icon:` property is silently dropped on write (flagged `MDL-WIDGET07` \"property `icon` … will be silently dropped\") — no way to give a button an icon, so the button renders without one. `linkbutton` (Link render mode) itself already worked", "cause": "The button builder read Caption/Action/ButtonStyle but never the `icon` property, and the `Forms$ActionButton` codec default nulls the `Icon` field. Nothing built the Mendix icon element", "file": "`sdk/pages/pages_widgets_action.go` (`Icon` struct + `IconTypeIconCollection`) + `mdl/executor/cmd_pages_builder_v3_widgets.go` (`buildButtonV3` reads `icon`) + `mdl/backend/modelsdk/widget_write.go` (`iconToGen`, wired into the `ActionButton` case) + describe (`cmd_pages_describe_parse.go` `extractIconRef`, `cmd_pages_describe_output.go` emit) + `validate_widgets.go` (`staticWidgetKnownProps` += `Icon`)", "insight": "Build the modern **icon-collection** icon: `icon: 'Atlas_Core.Atlas_Filled.pencil'` → `Forms$IconCollectionIcon{Image: QN}` (verified against a Studio-Pro button — storage `$Type` is `Forms$`, not `Pages$`; no typed gen struct, so build it via `newElem`/`addStr`). `g.SetIcon(...)` overrides the null-Icon default. DESCRIBE reconstructs `Icon:` from the element's `Image`; add `Icon` to the known-props list so MDL-WIDGET07 stops warning. A non-existent icon name is (correctly) rejected by MxBuild with **CE1613** \"selected custom icon … no longer exists\". Tests: `TestBuildButtonV3_Icon`, `TestOutputWidgetMDLV3_ButtonIcon`; bug-test `mdl-examples/bug-tests/602-button-icon.mdl`. Issue #602", "refs": ["#602"], "ce": ["CE1613"]}
+{"area": "sdk/pages", "date": "2026-08-01", "symptom": "A **DataView** property parses, passes `mxcli check`, and has no effect — `FormOrientation: Vertical` (#762) or `showFooter: true` (#813). `FormOrientation` works under `--engine legacy`", "cause": "Two different causes that look identical. (a) `FormOrientation` has no BSON field: Studio Pro's radio **is** `LabelWidth` (0=Vertical, 3=Horizontal default). Only the legacy writer translated it; the modelsdk writer emitted `LabelWidth` solely when set explicitly, so the orientation was read into the model and dropped — the #812 shape, a model field no active-engine writer reads. (b) `ShowFooter` was only ever set implicitly by a `footer { … }` block; the property sat in the validator allow-list, so it parsed and was discarded", "file": "`sdk/pages/pages_widgets_data.go` (`ResolvedLabelWidth`), `mdl/backend/modelsdk/widget_write.go`, `sdk/mpr/writer_widgets_display.go`, `mdl/executor/cmd_pages_builder_v3_widgets.go`", "insight": "Put the derivation **on the model** (`ResolvedLabelWidth`) so both writers share one definition instead of one owning it, and emit `LabelWidth` unconditionally. For the property, read it explicitly and let it win over the implicit block in both directions. **Trap**: `WidgetV3.GetBoolProp` is case-SENSITIVE and accepts only a real `bool`, unlike `GetStringProp` — so `showFooter: true` read as `false` even after the key was found. Coerce from the looked-up value and refuse a nonsense one instead of defaulting to false. Repro `mdl-examples/bug-tests/762-813-dataview-properties.mdl`. Issues #762, #813", "refs": ["#762", "#812", "#813"]}
+{"area": "sdk/pages", "date": "2026-08-01", "symptom": "Every mxcli-authored page carries a container nobody asked for — a `Forms$DivContainer` named `conditionalVisibilityWidget<N>` wrapping the page's top-level widgets. Creating a single button yields a button **and** a container", "cause": "The builder wrapped each non-empty layout placeholder, because `pages.LayoutCallArgument` declared a **single** `Widget` field while the BSON `Forms$FormCallArgument` carries a **`Widgets` array**. The wrapper existed only to squeeze N widgets through a 1-widget field — never a BSON requirement", "file": "`sdk/pages/pages_parameters.go` (`LayoutCallArgument.Widgets`), `mdl/executor/cmd_pages_builder_v3.go`, `sdk/mpr/writer_pages.go`, `mdl/backend/modelsdk/page_write.go`, `mdl/backend/mcp/page.go`", "insight": "Make the field a list and place widgets directly. **Check the claim against Mendix's own output before believing a comment**: ours said the wrapper is what \"mxcli (and Studio Pro) adds\", but `Administration.Account_Overview` in a `mx create-project` app has *two* top-level widgets in one placeholder and zero wrappers — same reasoned-by-analogy error as #812/#295. Corroborating signal that a construct is wrong: DESCRIBE already unwrapped it as a \"phantom CONTAINER\" and the catalog skipped it as \"transparent\" — three places working around something that should not be created. **Keep those readers**: projects authored before the fix still contain wrappers. Repro `mdl-examples/bug-tests/760-no-placeholder-wrapper.mdl`. Issue #760", "refs": ["#295", "#760", "#812"]}
+{"area": "sdk/pages", "date": "2026-08-06", "symptom": "A widget datasource bound to a **parameterized** microflow/nanoflow (`datasource: microflow Mod.MF(Name: $x)`) fails with **CE1571** \"No argument has been selected for parameter 'X'\". `mxcli check` and `exec` both report success; `describe page` shows the microflow but no arguments", "cause": "The grammar parsed the arguments into `DataSourceV3.Args`, but the builder never read them and `pages.MicroflowSource` had **no field to hold them**, so they were dropped between AST and model. The writer's `microflowSettingsToGen(d.Microflow, nil)` passed a literal `nil` at all three datasource sites, with a comment asserting datasources never carry mappings — true when only actions could take arguments, stale once the grammar accepted them on a datasource", "file": "`sdk/pages/pages_datasources.go` (`MicroflowSource`/`NanoflowSource` gain `ParameterMappings`), `mdl/executor/cmd_pages_builder_v3.go` (`flowArgsToParameterMappings`, shared with the action path), `mdl/backend/modelsdk/widget_write.go` (three sites pass `d.ParameterMappings`)", "insight": "Reuse the action path's `$`-variable-vs-expression rule rather than writing a second one — the two must agree or the same argument binds through different BSON fields depending on where it appears. **Generalisable — the shape to look for**: a hardcoded `nil` argument whose comment explains *why* the data can't exist is a dated assumption; when the grammar grows a construct, grep for the `nil`s that were correct before it. **Also check the model type can hold the value at all** — here the AST parsed it and the writer would have written it, but the struct in between had no field, so nothing was \"dropped\" by any single line. **Remaining gap**: `describe page` does not yet emit the mappings, so a describe → exec round-trip still loses them (read-back only; the write path is correct). Repro `mdl-examples/bug-tests/835-datagrid-microflow-datasource-params.mdl`; verified end-to-end (`mx check` 11.13.0: CE1571 → 0 errors). Issue #835", "refs": ["#835"], "ce": ["CE1571"]}
+{"area": "sdk/mpr", "date": "2026-08-08", "symptom": "`create or modify odata service` silently revokes the service's access; the next build fails with \"At least one allowed role must be selected for the published OData service to be accessible.\" Re-granting fixes it until the next modify", "cause": "`serializePublishedODataService` never wrote `AllowedModuleRoles`. The document is serialized wholesale and written with `updateUnit`, so a field the serializer omits is not left alone — it is deleted. The grants were read correctly and carried through the executor, then dropped one layer down", "file": "`sdk/mpr/writer_odata.go` (`AllowedModuleRoles`, marker 1 / BY_NAME, matching the working `GRANT` path's `makeMendixStringArray`); stale executor comment corrected in `mdl/executor/cmd_odata.go`", "insight": "**A wholesale re-serialization deletes every field it does not write, so the writer's field list is a data-retention policy.** Audit it against the parser, not against the struct — the round trip is the contract. **Where you look decides what you conclude**: an earlier pass looked for this loss at model level, found the value present and carried, and recorded \"reported but does not reproduce\" — the loss only exists after the BSON round trip, so a model-level check could never have seen it. When a report says a value disappears, reproduce at the persistence boundary before disbelieving it. For the marker, copy the shape from the code path that already works (`GRANT` writes marker 1 and builds fine) instead of reasoning from an unrelated type. Tests `writer_odata_test.go`; the control (field omitted again) reproduces the empty-grants document. mxcli-formula1 §26"}
+{"area": "sdk/mpr", "date": "2026-08-09", "symptom": "`publish entity … (TopSupported: No)` (or `SkipSupported`/`Countable`) parses, `DESCRIBE` reads it back as `No`, and the published `$metadata` still advertises `true`. A client then believes paging works when nothing implements it", "cause": "`serializeEntitySet` hardcoded all three `QueryOptions` to `true`, ignoring the `*bool` fields the model already carried — the AST/model/DESCRIBE half of the feature shipped without the writer half", "file": "`sdk/mpr/writer_odata.go` (`boolOrTrue`, entity-set `QueryOptions`)", "insight": "**A capability annotation on a microflow-backed resource is load-bearing, not decorative.** Mendix applies *no* query options to a read-microflow resource — it hands the request over and returns what comes back — so the annotation is the only thing a client has to go on, and an over-claim is not cosmetic: the client reads a whole collection believing it is a page. **Check the writer whenever a property round-trips correctly through DESCRIBE**: DESCRIBE reads the model, so a model-only feature describes perfectly and publishes wrong, and the round-trip test everyone reaches for cannot see it. A tri-state `*bool` needs an explicit nil policy at the boundary (`nil` = the platform default, only an explicit `false` opts out) or the pointer is pointless. Tests `writer_odata_test.go`; the control (hardcoded true) reproduces the over-claim. mxcli-formula1 §20"}
+{"area": "sdk/mpr", "date": "2026-08-11", "symptom": "`show modules` reports a module as having pages it does not have (Atlas_Web_Content: 46), while `show pages in module <that module>` correctly reports 0. `describe <a page template>` emits `create or modify page` with an **empty body**, and anything comparing describe output judges every template unchanged", "cause": "`listUnitsByType` matched on a type **prefix**, and Mendix storage names nest: `Forms$Page` is a prefix of `Forms$PageTemplate`, so `ListPages` swept in all 46 templates. The modelsdk backend then replicated it deliberately (\"match legacy\"), so both engines agreed on the wrong answer. The empty body is a second, hidden consequence: a template's widgets hang off `LayoutCall` and the page describe path reads `FormCall`", "file": "`sdk/mpr/reader_units.go` + `modelsdk/mpr/reader_units.go` (exact match), `mdl/backend/modelsdk/page.go` (`ListPages`/`ListPageTemplates`), `mdl/catalog/tables.go` + `builder.go` + `catalog.go` (the `page_templates` table, `objects` row, `Tables()` entry), `mdl/executor/describe_auto_test.go` (`notAutoDescribable`)", "insight": "**A count that is exactly a round module's worth is a type-matching bug, not an off-by-one.** **Do not fix a conflation by deleting the type from the index** — 46 documents nothing can enumerate is worse than 46 filed wrong, because nothing reports their absence; give the type its own table and let it report *unknown*. **Adding a catalog type touches five registries, not four**: the `*_data` table, the `objects` view union, the builder call, the describe-kind map (or `notAutoDescribable`), and `Catalog.Tables()` — `TestTables_CoversAllViews` is what catches the fifth. **A cosmetic-looking miscount can hide a silent false negative**: this was filed as \"wrong count in `show modules`\" and was really \"the marketplace differ clears 46 elements it never read\". Tests `sdk/mpr/reader_units_type_test.go`, `mdl/backend/modelsdk/page_test.go`. Still open: no `DESCRIBE PAGE TEMPLATE` handler"}
+{"area": "sdk/versions", "date": "2026-08-11", "symptom": "`show features` lists nothing for agents or MCP, so `create agent` / `create model` on a pre-11.9 project runs without complaint. Reported alongside it: \"`CREATE MODEL` can only author one provider — the writer assigns `MxCloudGenAI` unconditionally\"", "cause": "Two different things, and only the first was real. **The version gap**: the `agent_documents` area did not exist in `sdk/versions/mendix-11.yaml`, so `checkFeature()` had nothing to consult. **The provider claim was wrong**: the writer's assignment is `if m.Provider == \"\"` — a default, not an override. `Provider: OpenAI` parses, writes and round-trips through `describe model`; so does `Provider: TotallyMadeUp`", "file": "`sdk/versions/mendix-11.yaml` (new `agent_documents` area), `mdl/executor/cmd_agenteditor_models.go` + `cmd_agenteditor_write.go` (four `checkFeature` gates), `.claude/skills/mendix/agents.md` + `version-awareness.md`", "insight": "**Read the assignment's guard before believing \"hardcoded\"** — `if x == \"\" { x = default }` and `x = default` are one character apart in a grep and opposite in meaning; the round-trip test settles it in a minute. **Agent doctypes are the one version gate with no downstream safety net**: the documents are custom blobs, mxbuild contains no agent-editor strings at all, so an ungated project builds green and fails only when Studio Pro opens it. **Do not invent the provider allowlist** — the enum lives in a Studio Pro *extension*, not in `generated/metamodel` and not in mxbuild, so a guessed list would reject values Mendix accepts; document that nothing validates it instead. Test `TestAgentDocumentsAreGated`. Reported in mxcli-formula1 FINDINGS §53"}
+{"area": "sdk/domainmodel", "date": "2026-08-11", "symptom": "An association's line anchors — where the connector attaches to the entity boxes in the domain model editor — are absent from `DESCRIBE ASSOCIATION`, and manual adjustments made in Studio Pro do not survive an mxcli round trip", "cause": "`DomainModels$Association.ParentConnection`/`ChildConnection` (the string `\"x;y\"`) were **hardcoded** to `\"0;50\"`/`\"100;50\"` in BOTH writers and never read by either parser. Because every association write rebuilds the whole element, this was not an omission but active destruction: a documentation-only `alter association … set comment` reset them", "file": "`sdk/domainmodel/connection.go` (new: `ParseConnectionPoint`/`FormatConnectionPoint`, `Default*Connection`), `sdk/domainmodel/domainmodel.go` (fields → `*model.Point`), `sdk/mpr/parser_domainmodel.go` + `sdk/mpr/writer_domainmodel.go`, `mdl/backend/modelsdk/domainmodel.go` + `domainmodel_write.go`, `mdl/executor/cmd_associations.go` (`describeConnectionPoints`)", "insight": "**A feature request that says \"X is not exposed\" may be hiding \"X is destroyed\"** — check the write path before scoping the read path. The A/B that settled it: a blank 11.13 app's own `Administration.AccountPasswordData_Account` stores `0;54/100;54`, so a Studio-Pro-authored association is a free fixture for \"did mxcli overwrite this?\" — no Studio Pro needed. **Learn the value's constraints from the LOADER, not from the shape**: hand-patch and run `mx check` — `\"0.5;50\"` dies with `StorageLoadException` (integers required) while `\"0;500\"` and `\"-20;50\"` load with 0 errors (no range check), so out-of-range values must round-trip untouched. **A zero value is not an absent value** — `{0,0}` is a real anchor (top-left), which forces the field to be a POINTER; a plain `model.Point` cannot distinguish \"unset\" from \"top-left\" and would silently rewrite it. **Fix both engines**: they share the semantic model, and a fix in one is invisible to a user on the other. **Emit unauthorable data as a COMMENT** — DESCRIBE output must stay re-executable, and inventing syntax (`@anchor(parent: bottom-left, …)`) would bake in a vocabulary the storage does not have: the pair is CONTINUOUS, not 8 named anchors (observed x values 0 9 11 17 18 47 49 50 65 77 78 84 87 100). **The marketplace is the sample** when you need to know what Studio Pro actually writes: `mxcli marketplace download <id>` gives real Mendix-authored models, and a module .mpk holds either a raw BSON `project.mpr` or an MPR v1 SQLite one — 88 coordinate pairs from three modules turned \"looks like percentages\" into a measurement (all 0..100; 85 of 88 pin one coordinate to exactly 0 or 100). **Rule a unit out from the model, not the values**: pixels is impossible because `DomainModels$EntityImpl` stores only `Location` and NO size — the box is sized by the editor from the name and attribute list, so a pixel anchor would have nothing to measure against. Not applicable to `CrossAssociation`, which has no connection properties and crashes Studio Pro if given them (#50). Tests `sdk/domainmodel/connection_test.go`, `mdl/backend/modelsdk/association_connection_test.go`, `sdk/mpr/writer_domainmodel_test.go`, example `mdl-examples/bug-tests/872-association-line-anchors.mdl`. upstream #872", "refs": ["#50", "#872"]}
+{"area": "sdk/mpr", "date": "2026-08-25", "symptom": "Every **annotation on a domain model** — the note boxes Studio Pro draws on the canvas — disappears when anything rewrites that domain model on `--engine legacy`. Adding one entity to a blank app's MyFirstModule takes its annotation count from 1 to 0 and the caption vanishes from the project. `mx check` reports **0 errors**: an annotation is decorative, so nothing below Studio Pro can see the loss. The default (modelsdk) engine preserves them", "cause": "Two defects. (1) `sdk/mpr/writer_domainmodel.go` hardcoded `{Key: \"Annotations\", Value: bson.A{int32(3)}}` — the bare empty typed array — regardless of what the domain model held, while the parser read them into `dm.Annotations` perfectly well. (2) `parseAnnotation` read `Location` only as a BSON sub-document, but Studio Pro stores it as the **string** `\"60;240\"`, the same convention an entity's Location uses — so even before the write threw them away, every position had already read back as (0,0), and `Width` was never read at all", "file": "`sdk/mpr/writer_domainmodel.go` (`serializeDomainModelAnnotation`, the `annotations` array), `sdk/mpr/parser_domainmodel.go` (`parseAnnotation`); tests `sdk/mpr/domainmodel_annotation_test.go`", "insight": "**A collection the parser reads but the writer hardcodes is invisible to every round-trip test that only checks the parser.** Grep the writers for `bson.A{int32(3)}` written as a literal value rather than built from a slice — that shape is the bug. **A blank Mendix app is a free reference document**: MyFirstModule ships with a real Studio Pro-authored annotation, which is where the `\"x;y\"` string shape came from — no need to ask anyone to author one. There is **no colour property**: a domain model holds exactly four child collections (Annotations, Associations, CrossAssociations, Entities) and `DomainModels$Annotation` is Caption/ExportLevel/Location/Width, so a \"coloured section box\" is this element in Studio Pro's own styling, not stored state. A test fixture ID must be a **real UUID** — `idToBsonBinary` cannot round-trip a made-up string, which reads as an identity bug that isn't one"}
+{"area": "sdk/mpr", "date": "2026-08-25", "symptom": "A nested `Body: MAPPING` on a consumed REST operation makes the project **impossible to open** — mxbuild throws `System.AggregateException … (Export Object Mappings cannot have ObjectHandling set to 'Create')` instead of reporting an error", "cause": "The inline serializer passed the literal `\"Create\"` for every nested child regardless of namespace, so an EXPORT object element got an illegal handling. This is not a check error: it is thrown while **loading** the model, before any check runs, so `mx check` cannot even reach the project — and `mxcli check` and `exec` both accept it", "file": "`sdk/mpr/writer_rest.go` + `mdl/backend/modelsdk/consumed_rest_write.go` (`nestedInlineHandling`, `nestedInlineBackup`)", "insight": "Nested export elements are `Find` with backup `Error`, which is what Studio Pro stores on an export mapping DOCUMENT — there is no inline export body anywhere in the demo corpus to pin against (**0** `Rest$ImplicitMappingBody` across 9 packages), so the document form is the reference and mxbuild loading the project is the control. Keep a control test for the IMPORT direction in the same file: nested import elements legitimately stay `Create`, and a fix that flips both is wrong. Note the asymmetry when reproducing: a build error you can see is a *better* failure than this one — always confirm the project LOADS, not just that the check is green. Repro `mdl-examples/bug-tests/rest-inline-mapping-paths.mdl`, test `TestInlineExportBodyNestedHandling`. mxcli-rest FINDINGS #37", "refs": ["#37"]}
+{"area": "sdk/mpr", "date": "2026-08-25", "symptom": "A microflow calling a consumed REST operation with a path parameter (`send rest request Mod.RC.Op with ($id = …)`) makes the project **impossible to open** — mxbuild aborts with `The type cache does not contain a type with qualified name Microflows$ParameterMapping` from `StreamingBsonUnitReader`", "cause": "Both writers hardcoded `Microflows$ParameterMapping` as the `$Type` of each entry in `Microflows$RestOperationCallAction.ParameterMappings`. **No such Mendix type exists.** `generated/metamodel` is the arbiter — `MicroflowsRestOperationCallAction.ParameterMappings` is `[]*MicroflowsRestOperationParameterMapping` — so the storage name is `Microflows$RestOperationParameterMapping`. The sibling `QueryParameterMappings` was already correct, which is why only path parameters trip it", "file": "`sdk/mpr/writer_microflow_actions.go` (`serializeRestOperationCallAction`), `mdl/backend/modelsdk/microflow_rest_write.go` (`restOperationCallActionToGen` **and** its `codec.RegisterListMarker`)", "insight": "A STORAGE-NAME OVERRIDE in the `$Type` sense, and the most dangerous shape of it: the failure is at **load**, before any check, so `mx check` never reaches the model and reports the exception instead of an error list — and `mxcli check` and `exec` both accept it happily. **Patch the list-marker registration as well as the `newElem`**, or the codec decodes under the old name. Found only by trying to BOOT an app (`run --local`), not by any static gate — the same lesson as the inline-mapping paths above: when a construct's symptom is \"the runtime does the wrong thing\", the runtime is the only honest test. Repro: any microflow with `send rest request … with (…)`; covered by `mdl-examples/bug-tests/rest-inline-mapping-paths.mdl`'s companion runtime probe. Reported indirectly via mxcli-rest FINDINGS #36's repro", "refs": ["#36"]}
+{"area": "sdk/pages", "date": "2026-08-26", "symptom": "A layout mxcli wrote renders with **no topbar bar and no sidebar rail** — the widgets are all there and in the right regions, but unstyled. `mx check` is 0 errors and the BSON looks right", "cause": "The layout's own `Forms$Appearance.Class` was empty. Atlas scopes **24** of its layout rules to `.layout-atlas` and its variants, and every Atlas layout with chrome carries one (`layout-atlas layout-atlas-responsive-topbar`, `…-responsive-default`; only `PopupLayout` is bare). `CREATE LAYOUT` had no `class:` property at all, so every layout it wrote was unstyled", "file": "`sdk/pages/pages.go` (`Layout.Class`/`Style`), `mdl/backend/modelsdk/layout_write.go`, `mdl/executor/cmd_pages_layout_v3.go` (header property), `mdl/backend/modelsdk/page.go` (`appearanceClassOf`, so DESCRIBE round-trips it)", "insight": "**A CSS class on a layout is API, not decoration** — it is how the design system's rules find the layout at all. No check mxcli or mxbuild has can see this: the document is valid, the build is clean, and the difference is only visible in a browser next to the layout being replaced. That comparison *is* the test (`.claude/skills/verify-in-runtime.md`). The same reasoning applies to the flex design properties on `topbar-content`: Atlas sets the flex direction as a design property rather than in the class, so a container without them stacks its children in the corner"}
+{"area": "sdk/mpr", "date": "2026-08-28", "symptom": "A mapping's `with xml schema Module.NoSuchThing` is accepted by `mxcli check`, by `check --references` AND by `exec`, and the build fails with **CE1613** \"The selected XML schema 'X' no longer exists\" at the import/export mapping. The JSON twin's fix (ako/mxcli#259 first half) left the same hole at `check -p`", "cause": "The reference was written to BSON verbatim; nothing listed XML schemas, so nothing could resolve it. The JSON half refused only in the executor's create path, which `check` never reaches — `check --references` runs `validateWithContext`, a different switch", "file": "`sdk/mpr/reader_types.go` (`ListXmlSchemas`), `mdl/backend/mapping.go` + `mpr`/`modelsdk`/`mock` impls, `mdl/executor/mapping_customhandler.go` (`resolveXmlSchemaSource`, exec tier), `mdl/executor/validate_mapping_sources.go` (check tier, covers BOTH schema kinds)", "insight": "**A corpus grep said there was no reference document; it was wrong, and HOW it was wrong is the lesson.** `grep -rl \"XmlSchemas\" <extracted app>` returned 0 for all 9 demo apps, but that can only work for **MPR v2**, where units are files under `mprcontents/`. The one app that HAS them (OneHarness, 3 documents) is **MPR v1**: its units live in the SQLite `Unit.Contents` blob and are not greppable from the file. The grep silently answered \"does any file contain this string\" instead of \"does any project contain this document\" and returned 0 for a reason unrelated to the question. Read units through `mprbson.units()` or the reader, never by grepping the tree. Corrected numbers: 3 XML schemas in 1 of 9 apps, vs 36 message-definition collections and 250 JSON-backed mappings. The synthetic-unit measurement below stands, and the reader is now also verified against those 3 real documents.** PLANT a synthetic unit instead and let mxbuild identify it: a temporary `_test.go` in `sdk/mpr` calling `AddRawUnit(id, moduleID, \"Documents\", \"XmlSchemas$XmlSchema\", …)` with `{Name, Documentation, Excluded, ExportLevel, Entries, FilePath}` moved the mapping's error from CE1613 \"no longer exists\" to **CE0292 \"Please import an XSD file.\" at XML schema 'XGap.Probe_Xsd'** — mxbuild naming, by module and name, the document it had just found. That is the whole proof of both the `$Type` string and the `Name` key, and it agrees with `modelsdk/gen/xmlschemas`'s codec registration and `gen/mappings/refs.go`'s `Target`. **FAIL OPEN on an empty list**: with no `create xml schema` and only 1 of 9 apps holding any, an empty list is the ordinary case, so refusing on it would break every XML mapping to catch nothing — and a wrong `$Type` would then degrade to today's behaviour rather than a regression. Match on the **qualified** name; a bare-name match accepts `A.Foo` because `B.Foo` exists, which is the dangling reference all over again. Fix the check tier by adding a validator beside `validateIconRefs` (same class: \"MxBuild otherwise reports the typo as CE1613\") rather than a `scriptContext` field — a script that creates a structure then maps over it is the commonest shape and must not be flagged. ako/mxcli#259", "refs": ["ako/mxcli#259"], "ce": ["CE0292", "CE1613"]}
+{"area": "sdk/pages", "date": "2026-08-28", "symptom": "`editable: Never` on a widget in `CREATE PAGE` has no effect — the field is editable in the browser, while `mxcli check`, `mxcli exec` and `mx check` are all clean, and `describe page` shows nothing either way", "cause": "The property was parsed and validated but nothing carried it to the writers, which hardcoded `SetEditable(\"Always\")` for TextBox, TextArea, CheckBox, DatePicker and RadioButtons. The semantic model had no field for it at all", "file": "`sdk/pages/pages_widgets.go` (`BaseWidget.Editable`, `CanonicalEditability`, `WidgetEditability`), `mdl/executor/cmd_pages_builder_v3.go` (`applyConditionalSettings`), `mdl/backend/modelsdk/widget_write.go`, `sdk/mpr/writer_widgets.go`, `mdl/executor/cmd_pages_describe_{parse,output}.go`", "insight": "**The isolating control is ALTER**: `ALTER PAGE … SET Editable = Never ON w` always wrote it correctly, which proves the value is representable and only the CREATE path loses it — run that before touching the writers. Put the field on `BaseWidget`, not on each input widget: one field covers all twelve editable types and MDL-WIDGET20 already refuses the property on the rest. `EDITABLE IF` must WIN over a plain `editable:` — the conditional settings element is what makes the enum `Conditional`, so honouring both writes an enum contradicting the element beside it. **`describe` must emit it too**, or a describe/diff compares equal while the document is wrong; it lived in the CheckBox case alone, so hoist it to `appendAppearanceProps`. **Pluggable widgets are NOT fixed by this** — no `.def.json` maps `editable` and the stored `CustomWidgets$CustomWidget` has no `Editable` key, so a combobox is reported (MDL-WIDGET21) rather than dropped; do not \"fix\" it by calling `SetEditable` on the gen CustomWidget, which is an inert sink. ako/mxcli-maintenance-2"}
+{"area": "sdk/mpr", "date": "2026-08-31", "raw": "| Every page menu item in an **mxcli-authored navigation profile** loses the page's own title, and `mx check` reports one **CW0263 \"Empty template\"** warning per item while errors stay at 0 (16 of them on a real 11.12.3 app) | `Forms$FormSettings.TitleOverride` written as an **empty** `Microflows$TextTemplate` instead of `null` — the #812 defect above, in the three writers #812 did not touch. An empty template is an override to `\"\"`, not the absence of one. Unlike the ShowPage/button paths there is nothing to preserve: `types.NavMenuItemSpec` has no title field, so MDL cannot author a navigation title override and the value is unconditionally null | `sdk/mpr/writer_navigation.go` (`buildFormSettingsBson`), `mdl/backend/modelsdk/navigation_write.go` (`navFormSettingsBson`), `modelsdk/mpr/nav_patch.go` (`navpBuildFormSettingsBson`) | Emit `{Key: \"TitleOverride\", Value: nil}` in all three. **Grep the builder's callers before concluding a navigation fix is menu-only** — each of the three is also the profile's **login page** builder (`writer_navigation.go:116`, `navigation_write.go:127`, `nav_patch.go:122`, plus `navigation_profile_add.go:108`), so one edit per engine covers both `Forms$FormAction` and `LoginPageSettings`, and a fix aimed only at menu items would have missed half the emitters. Verify against a **Studio Pro document already in the project**, not against the warning count: a blank app's own navigation unit stores `TitleOverride = null` on both the login settings and the home menu item. Read it with `f=$(grep -ral NavigationDocument app/mprcontents \\| head -1)` — `grep -a` is required, a `.mxunit` is raw BSON and plain `grep -rl` skips it as binary — then `strings -a \"$f\" \\| grep -c TextTemplate`: **4 before (3 page items + login page), 0 after**, with `grep -c TitleOverride` staying at 4 so the key is still written. Measured on 11.12.0 on both engines. These three paths are raw `bson.D` → `bson.Marshal` → `UpdateRawUnit`, so #812's second trap (a `codec.RegisterTypeDefaults` `NullFields` entry clobbered by another registration for the same `$Type`) cannot apply — which also means a shape assertion on the builder is the only unit-level guard there is. Repro `mdl-examples/bug-tests/989-navigation-title-override.mdl`. PR #989 |", "refs": ["#812", "#989"]}
+{"area": "sdk/mpr", "date": "2026-08-31", "symptom": "A document mxcli writes carries a different **typed-array marker** (the leading `int32` of a Mendix array) than the equivalent Studio Pro document — e.g. every list in a `CREATE OR REPLACE NAVIGATION` profile was `1` where Studio Pro writes `2` or `3`. No error, no warning, no build failure: it renders and opens", "cause": "The writers hand-build `bson.A{int32(1)}` per list. The marker is a **per-field constant**, not a function of the list's contents (`Forms$FormSettings.ParameterMappings` is `2` in 816 empty and 306 non-empty documents alike), so it cannot be derived — it has to be read off real documents", "file": "`sdk/mpr/writer_navigation.go` + `mdl/backend/modelsdk/navigation_write.go` + `modelsdk/mpr/nav_patch.go` (`navMarker*` / `navpMarker*` constants), `mdl/backend/modelsdk/navigation_profile_add.go`, `modelsdk/codec/defaults.go` (`RegisterListMarker`) for the codec paths", "insight": "**Census, don't reason.** Walk every `.mxunit` on the machine, tabulate `(parent $Type, field, marker, empty?)`, and take the value the Studio Pro documents carry — 19,078 files across 54 projects settled five of six navigation fields outright. **`int32(1)` is NOT invalid**, whatever `debug-bson.md` used to say: a Marketplace `.mpk` mxcli has never touched uses it for `CustomWidgets$WidgetValueType.AllowedTypes` (212k occurrences) and `Forms$Page.AllowedModuleRoles`. Believing otherwise turns a per-field mismatch into a phantom corruption bug and sends the fix in the wrong direction. Where the census has no observation, **find a document that has one** rather than picking: `HomeItems` was `2` in all 51 stored profiles but every one was empty, and `navigation_profile_add.go` wrote `3` from a PED session that could not be re-run. ako/TestApp settled it — a Studio Pro-authored profile whose `HomeItems` holds two `Navigation$RoleBasedHomePage` elements at marker **2**, the non-empty case the census could not reach. One project with the feature actually configured beats any amount of reasoning about empty lists. Verify by dumping the written document and the project's own pristine reference and diffing the marker column, not by `mx check`, which is silent on all of it"}
diff --git a/.claude/skills/maintain-wiki.md b/.claude/skills/maintain-wiki.md
index 4783ef187d..f5887e8a3c 100644
--- a/.claude/skills/maintain-wiki.md
+++ b/.claude/skills/maintain-wiki.md
@@ -22,7 +22,7 @@ Six page categories. Anything outside these belongs somewhere else.
    SDK, Mendix Studio Pro), what is intentionally not implemented.
 5. **Glossary / vocabulary bridge** — Mendix ↔ mxcli ↔ BSON terminology.
 6. **Bug-pattern taxonomy** — *categories* of recurring failure modes that
-   link out to symptom-table rows in `.claude/skills/fix-issue.md`.
+   link out to findings in `.claude/skills/fix-issue/findings/*.jsonl`.
 
 ## What the wiki is NOT for
 
@@ -35,7 +35,7 @@ home instead.
 | MDL syntax tables | `docs/01-project/MDL_QUICK_REFERENCE.md` |
 | What a function does | source code |
 | Step-by-step task procedure | `.claude/skills/<task>.md` |
-| Specific bug fix recipe | symptom table in `.claude/skills/fix-issue.md` |
+| Specific bug fix recipe | `.claude/skills/fix-issue/findings/*.jsonl` |
 | Proposal status, PR / issue numbers, roadmap | proposal frontmatter; GitHub |
 | Latest design proposal | `docs/11-proposals/` |
 | Architecture decision record | `docs/13-decisions/` (ADRs) |
@@ -119,30 +119,22 @@ Rules:
 - **The Sources column lists what was actually read**, not what was relevant.
   This is the audit trail; a reviewer can verify synthesis is grounded.
 - **Write the row as the final step of every sync.** No exceptions. Same
-  discipline as the symptom-table append in `fix-issue.md`.
+  discipline as appending a finding under `fix-issue/findings/`.
 
 ## Seed topic pages
 
-Start with these. Stubs are fine; the structure matters more than initial
-content. Adding pages outside the seed list requires a stated reason it
-isn't better served by an existing page or a different doc artifact.
-
-| Path | Category | Frames |
-|------|----------|--------|
-| `architecture/mdl-execution.md` | architecture | grammar → AST → visitor → executor → backend → MPR writer |
-| `architecture/mpr-read-write.md` | architecture | MPR v1/v2, BSON round-trip, write safety |
-| `architecture/widget-engine.md` | architecture | def.json, WidgetRegistry, V3 builders |
-| `models/association-pointers.md` | mental-model | why `ParentPointer` = FROM, `ChildPointer` = TO |
-| `models/element-identity.md` | mental-model | `$ID` vs `GUID` vs `StableId`; the unit as identity boundary |
-| `models/storage-vs-qualified-names.md` | mental-model | BSON `$type` vs SDK qualified name |
-| `models/version-gating.md` | mental-model | feature registry, `min_version`, `checkFeature()` |
-| `rationale/mdl-as-sql.md` | rationale | why MDL is SQL-shaped, design principles (cites ADRs) |
-| `rationale/backend-abstraction.md` | rationale | why the executor never imports `sdk/mpr` for writes (cites ADRs) |
-| `positioning/vs-typescript-sdk.md` | positioning | gap analysis, intentional differences |
-| `glossary.md` | glossary | Mendix ↔ mxcli ↔ BSON term bridge |
-| `bug-patterns/bson-numeric-width.md` | bug-pattern | int32/int64 mismatches (links #583, #585 rows) |
-| `bug-patterns/visitor-wiring-gaps.md` | bug-pattern | parsed-but-not-stored (links #393 row) |
-| `bug-patterns/widget-type-object-drift.md` | bug-pattern | CE0463 family |
+The page list lives in [`maintain-wiki/pages.md`](maintain-wiki/pages.md) — the
+wiki's table of contents. Stubs are fine; the structure matters more than initial
+content. Adding a page outside it requires a stated reason it isn't better served
+by an existing page or a different doc artifact.
+
+It is a **table and nothing else**, in its own file, with `merge=union` in
+`.gitattributes`. That is deliberate: every wiki sync appends a row, so two
+parallel syncs would otherwise collide on one line and the work would have to be
+serialised — which is exactly what happened to the five bug-pattern PRs, and how
+13 pages went missing when the stack merged into itself. Union is safe here and
+is NOT safe on this file, which is prose: union keeps both sides of an edited
+prose line silently.
 
 ## Adding a new page
 
@@ -151,8 +143,9 @@ Before creating `docs-wiki/<new>.md`:
 1. Confirm the topic does not fit an existing page.
 2. Confirm it isn't better served by a skill (procedure), the user manual
    (how-to), source code (implementation), or proposal frontmatter (state).
-3. Add it to the seed table above as part of the same sync run, with its
-   category. The seed table is the wiki's table of contents.
+3. Add a row to [`maintain-wiki/pages.md`](maintain-wiki/pages.md) as part of
+   the same sync run, with its category. That file is the wiki's table of
+   contents.
 
 ## Final checklist
 
@@ -161,4 +154,4 @@ Before creating `docs-wiki/<new>.md`:
 - [ ] `last-synced:` updated to current HEAD SHA
 - [ ] `sources:` reflects what was actually read this run
 - [ ] `SYNC_LOG.md` row appended
-- [ ] Seed table updated if a new page was added
+- [ ] `maintain-wiki/pages.md` updated if a new page was added
diff --git a/.claude/skills/maintain-wiki/pages.md b/.claude/skills/maintain-wiki/pages.md
new file mode 100644
index 0000000000..b498096dc6
--- /dev/null
+++ b/.claude/skills/maintain-wiki/pages.md
@@ -0,0 +1,40 @@
+| Path | Category | Frames |
+|------|----------|--------|
+| `architecture/mdl-execution.md` | architecture | grammar → AST → visitor → executor → backend → MPR writer |
+| `architecture/mpr-read-write.md` | architecture | MPR v1/v2, BSON round-trip, write safety |
+| `architecture/widget-engine.md` | architecture | def.json, WidgetRegistry, V3 builders |
+| `architecture/mcp-backend.md` | architecture | the MCP/PED backend: hybrid local-read / live-PED-write, dirty-set router, session tracking |
+| `models/association-pointers.md` | mental-model | why `ParentPointer` = FROM, `ChildPointer` = TO |
+| `models/element-identity.md` | mental-model | `$ID` vs `GUID` vs `StableId`; the unit as identity boundary |
+| `models/ped-mutation-constraints.md` | mental-model | the counter-intuitive PED invariants: simplified constructors, leaf-only sets, acceptance is not validity |
+| `models/storage-vs-qualified-names.md` | mental-model | BSON `$type` vs SDK qualified name |
+| `models/version-gating.md` | mental-model | feature registry, `min_version`, `checkFeature()` |
+| `rationale/mdl-as-sql.md` | rationale | why MDL is SQL-shaped, design principles (cites ADRs) |
+| `rationale/backend-abstraction.md` | rationale | why the executor never imports `sdk/mpr` for writes (cites ADRs) |
+| `positioning/vs-typescript-sdk.md` | positioning | gap analysis, intentional differences |
+| `glossary.md` | glossary | Mendix ↔ mxcli ↔ BSON term bridge |
+| `bug-patterns/bson-numeric-width.md` | bug-pattern | int32/int64 mismatches (links #583, #585 findings) |
+| `bug-patterns/visitor-wiring-gaps.md` | bug-pattern | parsed-but-not-stored (links #393 finding) |
+| `bug-patterns/widget-type-object-drift.md` | bug-pattern | CE0463 family |
+| `bug-patterns/describe-round-trip-gaps.md` | bug-pattern | DESCRIBE as a second, unvalidated MDL implementation: won't-parse / drops / invents / destroys |
+| `bug-patterns/unloadable-model-writes.md` | bug-pattern | writes that break LOAD rather than validation — no CE code, whole project down |
+| `bug-patterns/silent-property-drop.md` | bug-pattern | a property parses, passes every check, and never reaches the model |
+| `bug-patterns/check-mxbuild-drift.md` | bug-pattern | `mxcli check` as a model of mxbuild, drifting in both directions |
+| `bug-patterns/platform-semantics-gaps.md` | bug-pattern | legal MDL, illegal Mendix — expression / XPath / variable-scope rules the grammar cannot carry |
+| `bug-patterns/duplicate-resolver-drift.md` | bug-pattern | one question answered in two places, and the two disagree |
+| `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 |
diff --git a/.claude/skills/mendix/README.md b/.claude/skills/mendix/README.md
index 2e0ffd04e1..68abbccf24 100644
--- a/.claude/skills/mendix/README.md
+++ b/.claude/skills/mendix/README.md
@@ -79,6 +79,7 @@ Page-specific patterns:
 | [migrate-design-prototype](migrate-design-prototype/SKILL.md) | Turn a Claude Design prototype into a themed Mendix app | Reproducing a design handoff/prototype as an SCSS theme + styled pages |
 | [debug-bson](debug-bson/SKILL.md) | BSON debugging | Troubleshooting SDK issues |
 | [analyze-runtime](analyze-runtime/SKILL.md) | Analyze runtime behavior — logs, metrics, traces, catalog, and cross-source joins | Profiling a slow page/microflow, finding what hits the DB, correlating cost with model shape |
+| [upgrade-mendix-version](upgrade-mendix-version/SKILL.md) | Move a project to a newer Mendix version headlessly | Raising the Mendix version; a build says the project version does not match MxBuild |
 
 ---
 
@@ -117,6 +118,8 @@ Load skills based on the task:
 | "Build/apply a theme from a design" | `migrate-design-prototype`, `theme-styling` |
 | "Why is this slow / profile the app / what hits the database" | `analyze-runtime`, `run-local` |
 | "Trace / metrics / flame chart / correlate cost with model" | `analyze-runtime` |
+| "Upgrade Mendix version / move to 11.x" | `upgrade-mendix-version` |
+| "Project version does not match MxBuild" | `upgrade-mendix-version` |
 
 ### For Error Recovery
 
diff --git a/.claude/skills/mendix/create-page/SKILL.md b/.claude/skills/mendix/create-page/SKILL.md
index c84df99aa5..a9a839d18e 100644
--- a/.claude/skills/mendix/create-page/SKILL.md
+++ b/.claude/skills/mendix/create-page/SKILL.md
@@ -355,6 +355,31 @@ The following features are NOT implemented in mxcli and require manual configura
 > DYNAMICTEXT spacer (Content: ' ')
 > ```
 
+### IMAGE needs a source
+
+An `image` widget shows an entry from an **image collection** by default, and the
+entry is named as three parts — `Module.Collection.ImageName`:
+
+```sql
+image imgLogo (Image: 'MyFirstModule.Images._1', Width: 48, Height: 48)
+```
+
+`show image collections` lists the collections; `describe image collection
+MyFirstModule.Images` lists the images inside one.
+
+An `image` with that (default) source and no `Image:` builds into a model mxbuild
+refuses — *"No image selected."* — so `mxcli check` reports it as **MDL-WIDGET22**
+before you spend a build on it. A name that does not resolve is reported by
+`mxcli check --references`, which is cheaper than mxbuild's CE1613 *"The selected
+image … no longer exists."*
+
+The two other sources take no collection entry:
+
+```sql
+image imgRemote (ImageType: imageUrl, ImageUrl: 'https://example.com/logo.svg')
+image imgIcon   (ImageType: icon)
+```
+
 ### Binding across modules and to audit members
 
 An attribute path may cross module boundaries, including into the platform's
@@ -427,7 +452,7 @@ All shorthand widgets (IMAGE, COMBOBOX, GALLERY, DATAGRID, etc.) are pluggable w
 
 ```sql
 -- Shorthand (common properties only)
-image imgLogo (width: 48, height: 48)
+image imgLogo (Image: 'MyFirstModule.Images._1', width: 48, height: 48)
 
 -- Full PLUGGABLEWIDGET syntax (all properties available)
 pluggablewidget 'com.mendix.widget.web.image.Image' imgLogo (
diff --git a/.claude/skills/mendix/test-microflows/SKILL.md b/.claude/skills/mendix/test-microflows/SKILL.md
index fea85e2515..cf55472aef 100644
--- a/.claude/skills/mendix/test-microflows/SKILL.md
+++ b/.claude/skills/mendix/test-microflows/SKILL.md
@@ -40,20 +40,36 @@ mxcli test tests/ -p app.mpr --local     # no daemon needed
 mxcli test tests/ -p app.mpr             # Docker
 ```
 
-`--local` uses its own ports (app 8081, admin 8091), its own `<project>_test`
-database and its own deployment tree (`.mxcli/deployment-test/`), so a
-`mxcli run --local` dev loop can keep serving the same project while the tests
-run — the tests never write into the database you are looking at in the browser,
-and never rebuild the directory that browser's page is served from. The database
-and the deployment tree are created on first use.
-
-The deployment tree is the one that used to be shared, and the failure was silent:
-a headless test boot does not bundle the web client, so rebuilding the dev loop's
-`deployment/` left the running app answering **HTTP 200 with a blank page** —
-Mendix's SPA shell over a 404 for `/dist/index.js`. Tests passed, the run kept
-running, nothing was reported at either end. Because of that, `--skip-build` now
-reuses the *test* tree and is refused (with the reason) until the suite has run
-once without it.
+`--local` uses its own ports (app 8081, admin 8091) and its own `<project>_test`
+database, so a `mxcli run --local` dev loop can keep serving the same project
+while the tests run — the tests never write into the database you are looking at
+in the browser. The database is created on first use.
+
+The **deployment directory is shared**, and not by choice: mxbuild always writes
+it to `<app dir>/deployment` and has no option to move it. That used to blank the
+running app — a headless test boot does not bundle the web client, and the boot's
+packaging pass deletes `deployment/web/dist`, so the app answered **HTTP 200 with
+a blank page** (Mendix's SPA shell over a 404 for `/dist/index.js`) while the
+tests passed and nothing was reported at either end. The bundle is now copied
+aside before the boot and put back after, so the dev loop keeps the exact bundle
+it built.
+
+**The compiled Java is shared too, and that one is not fixable — only reportable.**
+A test run recompiles the project into `deployment/run/bin`, the classpath the
+running app's JVM is holding open. Measured: every class file is rewritten (new
+inode, identical content). A JVM loads classes lazily, so one the app has not
+reached yet can afterwards fail with `NoClassDefFoundError` — and the microflows
+behind it then answer **HTTP 200 with an empty body** rather than an error, so the
+app looks half-working. Only Java-backed resources are affected, which is why it
+does not look like the test run did it.
+
+mxcli warns when it sees a dev loop serving the same project (`run --local`
+records itself in `.mxcli/run-local.json`, removed on exit). **If something the
+app serves stops returning data after a test run, restart that app.** That is the
+whole remedy.
+
+One thing left that has not been measured: both runtimes share `deployment/data/`.
+No damage observed; if you see something odd, run them one at a time and say so.
 
 ### Constants
 
diff --git a/.claude/skills/mendix/upgrade-mendix-version/SKILL.md b/.claude/skills/mendix/upgrade-mendix-version/SKILL.md
new file mode 100644
index 0000000000..efbef9bdb6
--- /dev/null
+++ b/.claude/skills/mendix/upgrade-mendix-version/SKILL.md
@@ -0,0 +1,178 @@
+---
+name: upgrade-mendix-version
+description: "Move a project to a newer Mendix version headlessly, with no Studio Pro. Use when raising a project's Mendix version, when a build complains the project version does not match MxBuild, or before adopting a newer runtime. Covers the one check that decides whether a converter must run, and the two green false successes that upgrade nothing."
+---
+
+# Upgrading a Mendix version without Studio Pro
+
+## Why this needs a skill
+
+Both ways of getting it wrong **look like success**:
+
+| what you do | what you see | what is true |
+|---|---|---|
+| `mxbuild --loose-version-check` | `BUILD SUCCEEDED` | the project is still on the old version |
+| `UPDATE _MetaData SET _ProductVersion` | the project reports the new version, and mxcli agrees | every unit is read against the wrong schema |
+
+Neither prints a warning. The first is not hypothetical — it is what happened to
+the project that reported this, and it took going back to look at the version
+column to notice that a successful build had upgraded nothing.
+
+## The check that decides everything
+
+A `.mpr` is SQLite. The version lives in one table, `_MetaData`, with columns
+`_FormatVersion`, `_ProductVersion`, `_BuildVersion` and `_SchemaHash`.
+
+Use Python rather than the `sqlite3` CLI: `python3` ships with a `sqlite3`
+module, while the CLI is frequently absent (it is not in the mxcli devcontainer).
+
+```bash
+mprhash() { python3 -c "import sqlite3,sys
+print(*sqlite3.connect(sys.argv[1]).execute(
+  'SELECT _ProductVersion,_SchemaHash FROM _MetaData').fetchone(), sep='  ')" "$1"; }
+
+mprhash app.mpr
+```
+
+```
+11.13.0  {SHA256}5Fk35jOyzj+cWnJe9ZkGWQjMEzsge3nIzS2zxH9jp6M=
+```
+
+For the version alone, mxcli says it on connect — no SQL needed:
+
+```
+Connected to: /path/App.mpr (Mendix 11.14.0)
+```
+
+One `UPDATE` would make the project *claim* the new version. Whether that is an
+upgrade or a corruption is decided by the **fourth column**:
+
+1. Create a blank project at the target version (or use a project you already
+   have there) and read its `_SchemaHash`.
+2. Compare it with the project's.
+   - **Same** → the model schema did not change. The version is a label.
+   - **Different** → the schema changed, so units stored against the old one
+     would be read against the new. A converter must run.
+
+`_SchemaHash` is a property of the **Mendix version, not of the project** —
+which is what makes this usable. Measured across two unrelated projects and two
+machines: a 517-unit application and a blank app, both at 11.13.0, carry
+byte-identical hashes, and the same holds at 11.14.0. So a reference value can be
+recorded and reused rather than rebuilt each time.
+
+```
+11.13.0   {SHA256}5Fk35jOyzj+cWnJe9ZkGWQjMEzsge3nIzS2zxH9jp6M=
+11.14.0   {SHA256}o9B9S8lorV9RD5gY9B6j1bJp4ALW87u4newnreIbRAg=
+```
+
+Two values are not a rule. Treat the table as a cache to check against, and
+**re-derive the target version's hash from a blank project the first time you go
+to a version that is not listed** — one command, and it is the only thing that
+actually answers the question.
+
+## Doing it
+
+`mx convert` is the converter. It sits beside `mxbuild` in the toolset, and
+mxcli does not wrap it.
+
+```bash
+# 1. Cache the target toolchain.
+mxcli setup mxbuild --version 11.14.0        # ~/.mxcli/mxbuild/11.14.0/modeler/
+
+# 2. Get the reference hash for the target version, if you do not have it.
+mx create-project --app-name Ref --output-dir /short/path
+mprhash /short/path/Ref.mpr
+
+# 3. Convert a COPY first, never the project.
+cp -a MyApp /short/MyApp-probe
+mx convert --in-place /short/MyApp-probe
+
+# 4. Verify the copy before touching anything real.
+mprhash /short/MyApp-probe/App.mpr     # must equal the reference from step 2
+mx check /short/MyApp-probe/App.mpr
+
+# 5. Only now, the real project.
+mx convert --in-place MyApp
+```
+
+Converting a copy first, confirming its hash matches the reference, and only then
+touching the real project is what makes this safe rather than lucky. Step 4 is
+the whole point: it is the difference between "the conversion ran" and "the
+conversion produced what the target version expects".
+
+## Verifying MPR v2 survived
+
+`mx convert` preserves MPR v2 — which is not a given. Its siblings
+`mx update-widgets` and `mx rename-design-properties` collapse a v2 project into
+a single-file v1 `.mpr` and delete `mprcontents/` as a side effect, one-way. That
+is the whole reason `mxcli fix widgets` exists.
+
+**Check the storage format, not the unit count.** Measured on an 11.13 → 11.14
+conversion: `.mxunit` files went **391 → 386** while v2 was perfectly intact. A
+conversion may legitimately drop or merge units, so an unchanged count is a
+coincidence, not the invariant. What actually distinguishes preserved from
+collapsed:
+
+```bash
+[ -d MyApp/mprcontents ] && echo "v2 intact"     # a collapse deletes this
+stat -c%s MyApp/App.mpr                          # v2: tens of KB. v1: tens of MB
+```
+
+On the measured run: `mprcontents/` present, `.mpr` 73,728 bytes.
+
+## Traps
+
+**`mx convert` takes the app DIRECTORY, not the `.mpr`.** Pointing it at the file
+fails with a message that reads like the project is missing:
+
+```
+Conversion failed: The app directory '/path/App.mpr' does not exist.
+```
+
+**`--loose-version-check` suppresses the check, it does not run a converter.**
+Verified: after invoking mxbuild with the flag, `_ProductVersion` and
+`_SchemaHash` are untouched. A green build proves nothing about the version.
+
+**A runtime version and its tooling move together.** The upgrade may break the
+tools around it, and the failure need not mention a version at all. On
+11.13 → 11.14 it surfaced as:
+
+```
+Error: bundling web client: no rollup.config.mjs in .../deployment/web
+       (run a serve Deploy build first)
+```
+
+— because 11.14's MxBuild bundles the web client itself, so the separate rollup
+step has nothing left to configure. Deleting `deployment/` and rebuilding does
+not help; a newer mxcli is what fixes it. **When something breaks right after an
+upgrade and names no version, suspect the toolchain before the model.**
+
+**`mx create-project` needs a short output path.** It fails with
+`System.IO.PathTooLongException` under a deeply nested directory, during package
+extraction — the message names a path length, not the real constraint.
+
+## What generalises, and what does not
+
+Most version-pair specifics will be wrong next time. The web-client bundling
+change is 11.13 → 11.14 and will not recur; the two hashes above are facts about
+two releases, not a pattern.
+
+What generalises is the decision procedure — **`_SchemaHash` decides label vs
+convert** — plus the three traps: convert takes a directory, `--loose-version-check`
+upgrades nothing, and the tooling moves with the runtime. Check the specifics
+against your own versions rather than trusting them.
+
+## After the upgrade
+
+Re-run whatever the project relies on that is not covered by `mx check`, because
+a clean check is not evidence the app still works. On the reporting project the
+thing worth being anxious about was a non-standard database connection type not
+in Mendix's own picker; it survived, and a full sync cycle proved it. Pick your
+own equivalent — the integration nobody would notice breaking — and exercise it.
+
+## Related
+
+- `run-local` — booting the app after an upgrade; the toolchain mismatch above
+  surfaces there first.
+- `debug-bson` — if the converted model behaves oddly, and for why `mx convert`'s
+  bare error *count* is not evidence about a model.
diff --git a/.claude/skills/mendix/write-microflows/reference/data-operations.md b/.claude/skills/mendix/write-microflows/reference/data-operations.md
index 3c4ca3fd64..f5793e4cb9 100644
--- a/.claude/skills/mendix/write-microflows/reference/data-operations.md
+++ b/.claude/skills/mendix/write-microflows/reference/data-operations.md
@@ -145,6 +145,40 @@ retrieve $Page from Sales.Order where [Status = 'Open']
 Note the clause order there is `limit` then `offset` — the reverse of `range`'s
 argument order, because each mirrors the Mendix editor it comes from.
 
+### `filter` / `find` test one item at a time — `$currentObject`
+
+A FILTER/FIND predicate is an expression Mendix evaluates once per item, with
+the item bound to **`$currentObject`**. That is the only iterator name there is:
+
+```mdl
+$Pending = filter($Orders, $currentObject/Status = 'Pending');
+$Large   = filter($Orders, $currentObject/Amount > 1000);
+$Match   = find($Orders, $currentObject/OrderNumber = $Wanted);
+```
+
+A **bare attribute name** means the same thing — mxcli resolves it against the
+list's entity and writes `$currentObject/Attr`:
+
+```mdl
+$Open = filter($Orders, Status != 'Closed');   -- stored as $currentObject/Status
+```
+
+Two things are refused rather than passed through to the build:
+
+- a bare name that is **not** a member of the list's entity (this used to reach
+  mxbuild as `CE0117 "Error(s) in expression."`);
+- any **other** iterator name — `filter($L, $item/Amount > 0)` is `MDL-LISTOP01`,
+  pre-empting `CE0109 "Undefined variable 'item'"`.
+
+`$item` is still fine when it is genuinely in scope, which is how the O(N) lookup
+idiom is written: inside `loop $item in $L`, `find($Others, Key = $item/Key)`
+navigates the **loop's** variable on the right-hand side.
+
+**`sort` is not an expression.** It takes attribute names directly, so a bare
+attribute is the only spelling — `sort($Orders, CreateDate desc)`. Writing
+`$currentObject/` there is wrong.
+
+
 ### `contains` is overloaded — string vs list
 
 `contains(a, b)` is both a **string** function (`contains(haystack, needle)` → substring test) and a **list** operation (`contains(list, object)` → membership test). mxcli picks the right serialization automatically:
@@ -159,6 +193,43 @@ set $Found = contains($Items, $Item);
 ```
 
 The distinction: a **literal or computed** second argument is always the string function. When both arguments are plain variables, the input variable's declared type decides — a **String** input becomes the string function (Change Variable, so declare the Boolean first), anything else stays a list operation (which creates its own output variable, so leave it undeclared). Getting the declare wrong is what triggers `CE0111 "Duplicate variable name"`.
+
+### Aggregates — all eight, including `reduce`, `all` and `any`
+
+An Aggregate list activity folds a list into one value. `count` takes only the
+list; the rest take either an **attribute** or an **expression** over
+`$currentObject`.
+
+```mdl
+$Count   = count($Orders);
+$Total   = sum($Orders.Amount);              -- attribute form
+$Total   = sum($Orders, $currentObject/Amount * 1.21);  -- expression form
+$Avg     = average($Orders.Amount);
+$Min     = minimum($Orders.Amount);
+$Max     = maximum($Orders.Amount);
+
+-- Boolean predicates over every item. No seed, always Boolean.
+$AllPaid = all($Orders, $currentObject/Paid);
+$AnyLate = any($Orders, $currentObject/DueDate < [%CurrentDateTime%]);
+
+-- REDUCE folds with a running total. $currentResult is the accumulator.
+$Discounted = reduce(
+  $Orders,
+  $currentResult + $currentObject/Amount * 0.9,
+  initial: 0,
+  returns: Decimal
+);
+```
+
+**`reduce` needs `initial:` and `returns:` and neither can be inferred.** Mendix
+stores both beside the expression, and the fold is meaningless without a seed
+and a result type — so MDL makes them mandatory rather than guessing. `all` and
+`any` take neither: they never accumulate, and always fold to Boolean.
+
+Do not reach for `reduce` where `sum` will do. It exists for folds Mendix has no
+dedicated function for — running a string together, or carrying a value forward
+that depends on the previous item.
+
 ## Database Operations
 
 ### RETRIEVE Statement
diff --git a/.gitattributes b/.gitattributes
index 9ef51b5e7c..6b3a3fd091 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -54,13 +54,30 @@ bun.lock binary
 
 # Append-only knowledge files use git's union merge driver.
 #
-# Every bug fix appends a row to the symptom table in fix-issue.md, so two
-# concurrent fixes always collide on the same line — five resolution rounds in
-# one week. Moving the insertion point from the top of the table to the bottom
-# did not help: both sides still append to the same place, so the collision
-# moved with it.
+# Every bug fix appends one finding, so two concurrent fixes write to the same
+# place. "union" tells git to keep BOTH sides of a conflicting hunk instead of
+# raising a conflict, which is exactly right for a file of independent
+# line-oriented records where order carries no meaning.
 #
-# "union" tells git to keep BOTH sides of a conflicting hunk instead of raising
-# a conflict. That is exactly right for a file that is only ever appended to and
-# is looked up by matching a symptom, so row order carries no meaning.
-.claude/skills/fix-issue.md merge=union
+# It sits on findings/*.jsonl, NOT on fix-issue.md. It used to cover the whole
+# skill file, back when the findings were a Markdown table inside it — and union
+# applies file-wide, so two branches editing the same PROSE line would have kept
+# both silently. The note that shipped with it said as much and named this fix.
+#
+# Note what union does NOT do: GitHub's server-side merge does not run merge
+# drivers, so a PR still shows the conflict and still has to merge main locally.
+# Sharding by area is what actually reduces collisions.
+.claude/skills/fix-issue/findings/*.jsonl merge=union
+
+# docs-wiki/SYNC_LOG.md is append-only by its own stated rule ("Append only.
+# Never edit historical rows."), so two syncs appending a row each is the same
+# situation as two fixes appending a finding. Without this, every parallel wiki
+# PR conflicts on one line and the work gets serialised for no reason — which is
+# what happened to the five bug-pattern PRs.
+docs-wiki/SYNC_LOG.md merge=union
+
+# The wiki's page list. A table and nothing else, in its own file precisely so
+# union is safe on it: every sync appends a row, and without this two parallel
+# syncs collide on one line. The prose that used to surround it stays in
+# maintain-wiki.md, where union would be a hazard rather than a help.
+.claude/skills/maintain-wiki/pages.md merge=union
diff --git a/.github/workflows/push-test.yml b/.github/workflows/push-test.yml
index 3dd87bbb6c..f23df9d01d 100644
--- a/.github/workflows/push-test.yml
+++ b/.github/workflows/push-test.yml
@@ -86,6 +86,16 @@ jobs:
         # honouring the pre-existing-failure SKIP list). Previously this step only
         # iterated doctype-tests/, so bug-test regression fixtures had no CI gate.
         run: make check-mdl
+      - name: Check bug findings
+        # One JSON object per line, an area, a date, and either the four
+        # structured fields or a raw row. DuckDB rejects a whole file on one bad
+        # line, so a typo in an appended finding takes out every query over that
+        # area. Also prints how far docs-wiki/bug-patterns/ has fallen behind.
+        run: make check-findings
+      - name: Check wiki page list
+        # The table of contents must describe the wiki, both directions. It
+        # drifted for three months before anyone noticed.
+        run: make check-wiki-pages
       - name: Check skill MDL blocks
         run: ./scripts/check-skill-mdl.sh ./bin/mxcli .claude/skills/mendix
       - name: Check docs-site MDL blocks
diff --git a/CLAUDE.md b/CLAUDE.md
index 03d8043551..b9efce96af 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -557,14 +557,14 @@ mxcli uses a layered documentation system — each artifact type has a single ca
 | User manual | `docs-site/src/` | hand-edited | How to use mxcli / MDL |
 | Concept wiki | `docs-wiki/` | `/mxcli-dev:wiki-sync` | Synthesized brain — framing and connecting only |
 | Skill | `.claude/skills/` | hand-edited | Step-by-step procedure for a recurring task |
-| Symptom table | `.claude/skills/fix-issue.md` | append on every bug fix | Bug symptom → file → fix recipe |
+| Bug findings | `.claude/skills/fix-issue/findings/*.jsonl` | append on every bug fix | Bug symptom → file → fix recipe (evidence; grep or DuckDB, never read whole) |
 | Load-bearing rule | this file | hand-edited | Always-in-context invariants and routing |
 
 **State stays in its native home.** Proposal status, PR / issue numbers, roadmap, version registries — these live only where they're authoritative (proposal frontmatter, GitHub, the `sdk/versions/*.yaml` files). The wiki and CLAUDE.md may cite this state but never mirror it.
 
 **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 row to the symptom table; a diagnosis *starts* at `docs-wiki/bug-patterns/`, which digests those rows into failure classes, and drills into the table only for the specific instance. The table is append-only evidence — grep it, never read it whole. Its digest is currently thin (3 pattern pages against 600+ rows, none re-synced since the initial synthesis), 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. Coverage is **computed, never quoted**: `make digest-status` reports pattern pages, findings, and per-area coverage. A figure written into prose here is stale the next time anyone appends a finding — the previous version of this sentence claimed 83% for an area that had since doubled. 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).
 
@@ -573,8 +573,8 @@ mxcli uses a layered documentation system — each artifact type has a single ca
 When reviewing pull requests or validating work before commit, verify these items:
 
 ### Bug fixes
-- [ ] **Fix-issue skill consulted** — start at [`docs-wiki/bug-patterns/`](docs-wiki/bug-patterns/) for the failure *class*, then `grep -i` the symptom table in `.claude/skills/fix-issue.md` for the *instance*; match before opening files. **Do not open the table whole — it is ~1 MB.** A pattern-page miss means the finding has not been digested yet, never that it has not been seen
-- [ ] **Symptom table updated** — new symptom/layer/file mapping added to `.claude/skills/fix-issue.md` if not already covered. Append at the END of the table — for readable diffs, not for merging: conflicts are handled by the `merge=union` driver in `.gitattributes`, which keeps both sides when two fixes append at once. (Insert position alone never fixed this; moving rows from the top to the bottom just moved the collision.) The table is looked up by matching a symptom, not read in order, so position carries no meaning
+- [ ] **Fix-issue skill consulted** — start at [`docs-wiki/bug-patterns/`](docs-wiki/bug-patterns/) for the failure *class*, then `grep -i` `.claude/skills/fix-issue/findings/*.jsonl` for the *instance*; match before opening files. A pattern-page miss means the finding has not been digested yet, never that it has not been seen
+- [ ] **Finding recorded** — one JSON line appended to `.claude/skills/fix-issue/findings/<area>.jsonl` if the symptom is not already covered, and `make check-findings` passes (it prints how far `docs-wiki/bug-patterns/` has fallen behind; `make digest-status` breaks it down by area). **If the class of failure keeps recurring, sync its pattern page** — the digest is on-demand and nothing else asks for it, which is how it went three months without a sync. Write the *insight* (what would have made it cheaper to find, what measurement settled it), not the changelog. `merge=union` in `.gitattributes` keeps both sides when two fixes append at once; order carries no meaning, since these are looked up by matching a symptom
 - [ ] **Test written first** — failing test exists before implementation (parser test in `sdk/mpr/`, backend mutation test in `mdl/backend/mpr/`, executor handler test in `mdl/executor/` using `MockBackend`)
 - [ ] **Verified at the layer the symptom lives in** — a test proves something about the layer it exercises and nothing more. Parser/grammar → unit test. BSON we write → unit test on the encoded document. Files on disk after `mx` runs → integration test (`-tags integration`). **The rendered app's behaviour or appearance → `.claude/skills/verify-in-runtime.md`** (boot with `run --local`, assert in Playwright). A page can serialize to valid-looking BSON, pass `mx check`, build cleanly, and still render wrong — that was #812.
 - [ ] **Fix proven to be the cause** — revert the fix (or stub the guard) and confirm the test fails with the reported symptom. A test that only passes against fixed code has not been shown to detect anything; two bugs this week had a green suite while live (#812 a clobbered `RegisterTypeDefaults`, #808 an integration test that had only ever skipped)
@@ -793,7 +793,7 @@ Regenerate after modifying `MDLLexer.g4`, `MDLParser.g4`, or any `domains/*.g4`
 These rules apply whenever generating microflow or nanoflow MDL. Violations are caught by `mxcli check`.
 
 1. **NEVER create empty list variables as loop sources.** If processing imported data, accept the list as a microflow parameter — `declare $Items list of ... = empty` followed by `loop $item in $Items` is always wrong.
-2. **NEVER use nested LOOPs for list matching.** Loop over the primary list and use `$match = FIND($TargetList, key = $item/key)` for an O(N) in-memory lookup. A plain `retrieve … where` **cannot** filter a list variable (only a database/association source), so `retrieve $match from $TargetList where …` is a parse error — use `FIND`/`FILTER`. Nested loops are O(N^2).
+2. **NEVER use nested LOOPs for list matching.** Loop over the primary list and use `$match = FIND($TargetList, key = $item/key)` for an O(N) in-memory lookup. A plain `retrieve … where` **cannot** filter a list variable (only a database/association source), so `retrieve $match from $TargetList where …` is a parse error — use `FIND`/`FILTER`. Nested loops are O(N^2). The `$item` there is the enclosing loop's iterator and stays valid — MDL-LISTOP01 flags a predicate variable that is *not in scope*, not the name. Inside the predicate itself, the item under test is `$currentObject` (a bare attribute name resolves to it).
 3. **Use append logic when merging**, not overwrite: `$Existing/Field + '\n' + $New/Field` inside an `if $New/Field != empty` guard.
 4. **Read `.claude/skills/patterns-data-processing.md`** for delta merge, batch processing, and list operation patterns.
 
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index c2daa36ff1..e5784708dd 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -334,7 +334,7 @@ local install.
 **Keep a `FINDINGS.md`** at the repo root as you go — one entry per surprise or
 defect: the exact MDL, the command, the error, the Mendix + mxcli versions, and how
 you verified it. A finding that reproduces against a real `mx check` is often enough
-to drive a fix straight into a symptom row in `.claude/skills/fix-issue.md`. The full
+to drive a fix straight into a finding under `.claude/skills/fix-issue/findings/`. The full
 workflow is documented in
 **[Developing on the Web (Claude Code)](https://mendixlabs.github.io/mxcli/tutorial/claude-code-web.html)**.
 
diff --git a/Makefile b/Makefile
index 34fd607a1f..540a079925 100644
--- a/Makefile
+++ b/Makefile
@@ -35,7 +35,7 @@ GO_BUILD_FLAGS = -trimpath
 # Clean version for VS Code extension (must be valid semver: major.minor.patch)
 VSCE_VERSION = $(shell echo "$(VERSION)" | sed 's/^v//; s/-.*//' | grep -E '^[0-9]+\.[0-9]+\.[0-9]+$$' || echo "0.0.0")
 
-.PHONY: build build-debug size release clean test engine-diff test-mdl check-mdl check-skill-mdl check-tunnel-deps check-widget-versions grammar completions sync-skills sync-skill-packs sync-commands sync-lint-rules sync-changelog sync-all docs documentation docs-site docs-serve vscode-ext vscode-install source-tree sbom sbom-report lint lint-go lint-ts fmt vet
+.PHONY: build build-debug size release clean test engine-diff test-mdl check-mdl check-skill-mdl check-findings check-wiki-pages digest-status check-tunnel-deps check-widget-versions grammar completions sync-skills sync-skill-packs sync-commands sync-lint-rules sync-changelog sync-all docs documentation docs-site docs-serve vscode-ext vscode-install source-tree sbom sbom-report lint lint-go lint-ts fmt vet
 
 # Helper: copy file only if content differs (avoids mtime updates that invalidate go build cache)
 # Usage: $(call copy-if-changed,src,dst)
@@ -265,6 +265,23 @@ check-skill-mdl: build
 # Guard: the embedded tunnel (chisel) must stay out of the Windows/macOS builds.
 # See docs/13-decisions/0009-tunnel-is-linux-only.md. Needs no build — it reads
 # the dependency graph — so it is cheap to run before pushing.
+# Validate the bug-finding shards: one JSON object per line, an area, and either
+# the four structured fields or a raw row. DuckDB rejects a whole file on one bad
+# line, so a typo in an appended finding takes out every query over that area.
+check-findings:
+	@scripts/check-findings.sh
+
+# How far docs-wiki/bug-patterns/ has fallen behind the findings it digests.
+# Advisory, always exits 0 — see the header in the script for why.
+digest-status:
+	@scripts/digest-status.sh
+
+# The wiki's page list must describe the wiki, both directions. It drifted for
+# three months before anyone noticed, because a table of contents has no failure
+# mode of its own.
+check-wiki-pages:
+	@scripts/check-wiki-pages.sh
+
 check-tunnel-deps:
 	@./scripts/check-tunnel-deps.sh
 
diff --git a/cmd/mxcli/cmd_test_run.go b/cmd/mxcli/cmd_test_run.go
index e31ce41eaf..de05418f3b 100644
--- a/cmd/mxcli/cmd_test_run.go
+++ b/cmd/mxcli/cmd_test_run.go
@@ -211,6 +211,14 @@ Examples:
 			os.Exit(1)
 		}
 
+		// A --local run that BUILDS recompiles the project's Java into the
+		// classpath a concurrent `mxcli run --local` is holding open, which can
+		// leave that app answering HTTP 200 with an empty body (mxcli-formula1
+		// §81). Neither --attach nor --skip-build builds, so neither can cause it.
+		if local && !attach && !skipBuild {
+			warnIfDevLoopServing(projectPath, os.Stdout)
+		}
+
 		result, err := testrunner.Run(opts)
 		if err != nil {
 			fmt.Fprintf(os.Stderr, "Error: %v\n", err)
diff --git a/cmd/mxcli/cmd_widget_sync.go b/cmd/mxcli/cmd_widget_sync.go
index 4a59df98d4..ac6cbfc955 100644
--- a/cmd/mxcli/cmd_widget_sync.go
+++ b/cmd/mxcli/cmd_widget_sync.go
@@ -128,7 +128,17 @@ func renderSyncPlan(plan *executor.SyncPlan) {
 	}
 
 	if plan.Empty() {
-		fmt.Fprintln(out, "Every stored widget instance already matches its installed package. Nothing to do.")
+		// Say what was compared, not what was concluded. This message used to
+		// read "Every stored widget instance already matches its installed
+		// package", which a reporting project got on a widget `mx check` was
+		// reporting CE0463 on at that moment (mxcli-ledger §142) — and the two
+		// were both right, about different things. The comparison is over the
+		// stored SCHEMA (each property's declared type attributes); the value in
+		// the widget's Object is not looked at, and the CE0463 there was a value.
+		fmt.Fprintln(out, "No schema drift: every stored widget's property declarations match its installed package.")
+		fmt.Fprintln(out, "  This compares the stored property SCHEMA, not the values in each widget — a widget can")
+		fmt.Fprintln(out, "  still fail CE0463 on a value the package would not accept. Run 'mxcli fix widgets' for")
+		fmt.Fprintln(out, "  the full update.")
 		return
 	}
 
diff --git a/cmd/mxcli/devloop_recompile_warning.go b/cmd/mxcli/devloop_recompile_warning.go
new file mode 100644
index 0000000000..b1e7bda452
--- /dev/null
+++ b/cmd/mxcli/devloop_recompile_warning.go
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package main
+
+import (
+	"fmt"
+	"io"
+)
+
+// warnIfDevLoopServing tells a `mxcli test --local` run that the dev loop is
+// serving the same project, and reports whether it did.
+//
+// A test run recompiles the project's Java into `deployment/run/bin`, which is
+// the classpath that running app's JVM is holding open. mxcli cannot avoid it:
+// mxbuild's Gradle pass owns the compile, and the deployment directory cannot be
+// moved — mxbuild writes it to `<app dir>/deployment` and takes no option to
+// change it (mxcli-ledger §150). So the collision is reported rather than
+// prevented, which is the part that was missing: the reporting project spent 108
+// log lines and a wrong hypothesis about a different app before connecting the
+// two (mxcli-formula1 §81).
+//
+// It reads the handshake `mxcli run --local` already publishes for `mxcli
+// constant set --apply`, rather than a second file of its own: that one carries
+// the admin password and boot config those commands depend on, and a competing
+// writer at the same path would drop them.
+//
+// It warns rather than refuses. The warm loop exists so an app can stay up while
+// you work on it — the reporting project runs two apps that way as a matter of
+// course — and refusing would break the workflow the feature is for, to prevent
+// something whose remedy is one restart.
+func warnIfDevLoopServing(projectPath string, w io.Writer) bool {
+	if w == nil {
+		return false
+	}
+	// A missing file, a corrupt one, and a pid that is gone all come back as an
+	// error here, which is exactly the behaviour wanted: a stale handshake from a
+	// `run --local` that was killed or whose development licence expired (§60)
+	// must not warn, or the warning fires forever and stops being read.
+	hs, err := readDevLoopHandshake(projectPath)
+	if err != nil {
+		return false
+	}
+	fmt.Fprintln(w, recompileWarning(hs))
+	return true
+}
+
+// recompileWarning names the symptom, because the symptom is the part nobody
+// guesses: the app does not error, it answers 200 with nothing in it, and only
+// the resources backed by Java are affected — so half the app keeps working,
+// which is not a shape that suggests "the test run did this".
+func recompileWarning(hs devLoopHandshake) string {
+	return fmt.Sprintf(
+		"Warning: `mxcli run --local` is serving this project on port %d (pid %d).\n"+
+			"  This test run recompiles the project's Java into deployment/run/bin, which is\n"+
+			"  that app's classpath — every class file is rewritten. A class the running app\n"+
+			"  has not loaded yet can then fail with NoClassDefFoundError, and the microflows\n"+
+			"  behind it answer HTTP 200 with an EMPTY BODY rather than an error, so the app\n"+
+			"  looks half-working (mxcli-formula1 §81).\n"+
+			"  If anything it serves stops returning data, restart that app.\n"+
+			"  The deployment directory cannot be separated: mxbuild always writes it to\n"+
+			"  <app dir>/deployment.",
+		hs.AppPort, hs.PID)
+}
diff --git a/cmd/mxcli/devloop_recompile_warning_test.go b/cmd/mxcli/devloop_recompile_warning_test.go
new file mode 100644
index 0000000000..d277e06f1c
--- /dev/null
+++ b/cmd/mxcli/devloop_recompile_warning_test.go
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package main
+
+import (
+	"os"
+	"strings"
+	"testing"
+	"time"
+)
+
+// mxcli-formula1 FINDINGS §81 — the half of the shared deployment tree the
+// web-bundle fix does not cover.
+//
+// A local test run recompiles the project's Java into `deployment/run/bin`,
+// which is the classpath a live `mxcli run --local` is holding open. Measured on
+// a real 11.13 project: after one `mxcli test --local`, all 134 class files have
+// NEW INODES and byte-identical content — every one deleted and rewritten. A JVM
+// loads classes lazily, so one it has not reached yet can fail afterwards:
+//
+//	java.lang.NoClassDefFoundError: odatapushdown/QueryObject
+//
+// What that costs is diagnosis, not the breakage. The microflows behind it then
+// answer **HTTP 200 with a zero-byte body** — not a 500, not an error page —
+// while source-backed resources keep working, so half the app is fine and half
+// returns nothing. In the reporting project it surfaced as 21 of 34 tests
+// failing in a DIFFERENT app, and 108 log lines went by before anyone connected
+// it to the test run.
+//
+// mxcli cannot prevent the rewrite: mxbuild's Gradle pass owns the compile, and
+// the deployment directory cannot be moved (mxcli-ledger §150). It can say so,
+// to someone who can act on it.
+//
+// The fact needed — is a dev loop serving this project? — was ALREADY published:
+// `mxcli run --local` writes devLoopHandshake to .mxcli/run-local.json for
+// `mxcli constant set --apply`, with the pid liveness check and the
+// project-identity field this needs. A second state file was written before that
+// was noticed, and it would have CLOBBERED this one, dropping the admin password
+// and boot config that `--apply` and `--attach` depend on.
+
+func TestRecompileWarning_SaysWhatWillHappenAndWhatToDo(t *testing.T) {
+	msg := recompileWarning(devLoopHandshake{PID: 4242, AppPort: 8080})
+
+	for _, want := range []string{"8080", "recompil", "restart"} {
+		if !strings.Contains(strings.ToLower(msg), want) {
+			t.Errorf("the warning should mention %q: %s", want, msg)
+		}
+	}
+	// The symptom is the part nobody guesses, because it does not look like a
+	// failure at all.
+	if !strings.Contains(msg, "200") {
+		t.Errorf("the warning should name the symptom (HTTP 200, empty body): %s", msg)
+	}
+}
+
+func TestWarnIfDevLoopServing_FiresForALiveDevLoop(t *testing.T) {
+	p := handshakeProject(t)
+	if err := writeDevLoopHandshake(p, devLoopHandshake{
+		Project: p, PID: os.Getpid(), AppPort: 8080, AdminPort: 8090, Started: time.Now(),
+	}); err != nil {
+		t.Fatal(err)
+	}
+
+	var buf strings.Builder
+	if !warnIfDevLoopServing(p, &buf) {
+		t.Fatal("a live dev loop on the same project must be reported")
+	}
+	if !strings.Contains(buf.String(), "8080") {
+		t.Errorf("the warning did not reach the writer: %q", buf.String())
+	}
+}
+
+// CONTROL 1: silent when nothing is running. Every project that has never used
+// the warm loop runs its tests through this path, and a warning there is noise
+// on every run.
+func TestWarnIfDevLoopServing_SilentWithNoDevLoop(t *testing.T) {
+	var buf strings.Builder
+	if warnIfDevLoopServing(handshakeProject(t), &buf) {
+		t.Error("warned with no dev loop running")
+	}
+	if buf.String() != "" {
+		t.Errorf("wrote %q when there was nothing to say", buf.String())
+	}
+}
+
+// CONTROL 2 — the one that decides whether this is usable at all. A `run --local`
+// that was killed, crashed, or died with its development licence (§60, measured
+// lifetimes under six hours) leaves the file behind. Warning on that would fire
+// forever, and a warning that is always wrong teaches the reader to skip it.
+//
+// readDevLoopHandshake already refuses a dead pid; this pins that the warning
+// inherits it rather than reading the file itself.
+func TestWarnIfDevLoopServing_SilentForAStaleHandshake(t *testing.T) {
+	p := handshakeProject(t)
+	if err := writeDevLoopHandshake(p, devLoopHandshake{
+		Project: p, PID: 999999, AppPort: 8080,
+	}); err != nil {
+		t.Fatal(err)
+	}
+
+	var buf strings.Builder
+	if warnIfDevLoopServing(p, &buf) {
+		t.Errorf("warned about a dev loop whose process is gone: %q", buf.String())
+	}
+}
diff --git a/cmd/mxcli/docker/localapp.go b/cmd/mxcli/docker/localapp.go
index 65543b2bf2..a44b60072b 100644
--- a/cmd/mxcli/docker/localapp.go
+++ b/cmd/mxcli/docker/localapp.go
@@ -153,6 +153,9 @@ func StartLocalApp(opts LocalAppOptions) (*LocalApp, error) {
 	if err := checkLocalAppPortsFree(opts); err != nil {
 		return nil, err
 	}
+	if err := checkDeployDirIsBuildable(opts); err != nil {
+		return nil, err
+	}
 
 	// 1. Project version → which mxbuild and runtime to use.
 	reader, err := mpr.Open(opts.ProjectPath)
@@ -184,10 +187,13 @@ func StartLocalApp(opts LocalAppOptions) (*LocalApp, error) {
 
 	app := &LocalApp{Version: version, RuntimeLogPath: opts.RuntimeLogPath}
 
-	// Whether a browser bundle exists *before* this boot. The boot's Gradle
-	// packaging removes it, and this app is booted headless (tests), so the loss
-	// is only noticed later by whoever opens a browser (mxcli-formula1 §35).
-	hadWebClient := WebClientBundled(opts.DeployDir)
+	// The boot's Gradle packaging removes the browser bundle, and this app is
+	// booted headless (tests), so it does not build a replacement — the loss is
+	// noticed later by whoever opens a browser onto the `run --local` that is
+	// serving the same deployment directory (mxcli-formula1 §35 and §62). The
+	// directory is shared because mxbuild shares it, so the bundle is carried
+	// across the boot instead.
+	restoreWebClient := preserveWebClientBundle(opts.DeployDir)
 
 	// 4. Build, unless the caller is reusing an existing deployment.
 	if !opts.SkipBuild {
@@ -213,11 +219,12 @@ func StartLocalApp(opts LocalAppOptions) (*LocalApp, error) {
 	// 5. Boot the runtime against the deployment.
 	rt, err := StartLocalRuntime(opts.runtimeOptions(installPath))
 	if err != nil {
+		restoreWebClient()
 		app.Stop()
 		return nil, err
 	}
 	app.Runtime = rt
-	ReportLostWebClientBundle(opts.DeployDir, hadWebClient, w)
+	restoreWebClient()
 	return app, nil
 }
 
@@ -274,6 +281,39 @@ func (a *LocalApp) Stop() error {
 	return firstErr
 }
 
+// checkDeployDirIsBuildable refuses a DeployDir that this build will not write
+// to.
+//
+// mxbuild's deploy target writes to `<app dir>/deployment` and takes no option
+// to change it — measured, not inferred: `--target=deploy` on a project whose
+// deployment/ had just been deleted recreated it there, `mxbuild --help` lists
+// no deployment-path flag, and BuildRequest carries none. So DeployDir decides
+// where the RUNTIME reads while nothing decides where the BUILD writes, and
+// setting them apart points the runtime at a directory nothing populates.
+//
+// That is what `mxcli test --local` did after it was given a scratch tree of its
+// own: the runtime aborted with `Path '…/deployment-test/model/bundles' cannot
+// be resolved in base path '…/deployment-test'` for every project, whether or
+// not another app was running (mxcli-ledger §150). This states the constraint
+// instead, at the point the caller can still act on it.
+//
+// With SkipBuild there is no build to disagree with, so the caller may boot
+// against any tree they have populated themselves.
+func checkDeployDirIsBuildable(o LocalAppOptions) error {
+	if o.SkipBuild || o.DeployDir == "" || o.ProjectPath == "" {
+		return nil
+	}
+	buildDir := filepath.Join(filepath.Dir(o.ProjectPath), "deployment")
+	if filepath.Clean(o.DeployDir) == filepath.Clean(buildDir) {
+		return nil
+	}
+	return fmt.Errorf("cannot boot against %s: mxbuild always writes the deployment to %s "+
+		"and has no option to change it, so that directory would be empty.\n"+
+		"  Leave DeployDir unset to use the build's own directory, or pass SkipBuild to boot "+
+		"against a tree you populated yourself.",
+		o.DeployDir, buildDir)
+}
+
 // checkLocalAppPortsFree refuses to boot onto a port something is already
 // serving — otherwise a stale runtime is silently adopted and the caller reads
 // results from an app it did not build.
diff --git a/cmd/mxcli/docker/localapp_deploydir_test.go b/cmd/mxcli/docker/localapp_deploydir_test.go
new file mode 100644
index 0000000000..12ae9d2ebe
--- /dev/null
+++ b/cmd/mxcli/docker/localapp_deploydir_test.go
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package docker
+
+import (
+	"path/filepath"
+	"strings"
+	"testing"
+)
+
+// mxcli-ledger FINDINGS §150: `mxcli test --local` could not start a runtime at
+// all.
+//
+//	Error: local runtime: runtime admin API did not come up: runtime process
+//	exited during startup
+//	java.lang.IllegalArgumentException: Path '…/.mxcli/deployment-test/model/bundles'
+//	cannot be resolved in base path '…/.mxcli/deployment-test'
+//
+// The tree was empty of everything that matters — no model/ at all — because
+// **mxbuild's deploy target writes to `<app dir>/deployment` and takes no option
+// to change it.** Measured directly, not inferred: `mxbuild --target=deploy` on a
+// project whose deployment/ had just been deleted recreated it there, and
+// `mxbuild --help` lists no deployment-path flag (`-o/--output` names the .mda
+// for target=package). BuildRequest has no such field either — the serve API
+// exposes target, project path, mda path and the loose version check.
+//
+// So DeployDir decides where the RUNTIME reads and nothing decides where the
+// BUILD writes. Setting them apart pointed the runtime at a directory nothing
+// populates. That is now refused with the reason instead of failing inside the
+// JVM against a path the user never chose.
+//
+// The fix this replaces was tested only on the option value — four tests
+// asserting DeployDir was set, under the project, per-project, and not the dev
+// loop's — and every one passed against a build that could not start. The
+// checklist item is "verified at the layer the symptom lives in": the symptom
+// lives in what is on disk after mxbuild runs.
+
+func TestDeployDirMustBeWhereTheBuildWrites(t *testing.T) {
+	dir := t.TempDir()
+	project := filepath.Join(dir, "App.mpr")
+
+	err := checkDeployDirIsBuildable(LocalAppOptions{
+		ProjectPath: project,
+		DeployDir:   filepath.Join(dir, ".mxcli", "deployment-test"),
+	})
+	if err == nil {
+		t.Fatal("a DeployDir the build cannot write to must be refused, not booted against")
+	}
+	// The message has to name mxbuild as the constraint, or the reader goes
+	// looking for the bug in mxcli's own path handling.
+	for _, want := range []string{"mxbuild", "deployment-test", filepath.Join(dir, "deployment")} {
+		if !strings.Contains(err.Error(), want) {
+			t.Errorf("the message should name %q: %v", want, err)
+		}
+	}
+}
+
+// CONTROL 1: the directory mxbuild actually writes to is accepted. Without this
+// the guard would refuse every local boot.
+func TestDeployDirDefaultIsAccepted(t *testing.T) {
+	dir := t.TempDir()
+	opts := LocalAppOptions{ProjectPath: filepath.Join(dir, "App.mpr")}
+	opts.applyDefaults()
+
+	if err := checkDeployDirIsBuildable(opts); err != nil {
+		t.Errorf("the default deployment directory must be buildable: %v", err)
+	}
+}
+
+// CONTROL 2: with SkipBuild there is no build to disagree with, so any tree the
+// caller already populated is theirs to boot against. A guard that fired here
+// would forbid a legitimate use.
+func TestDeployDirIsFreeWhenNothingIsBuilt(t *testing.T) {
+	dir := t.TempDir()
+	if err := checkDeployDirIsBuildable(LocalAppOptions{
+		ProjectPath: filepath.Join(dir, "App.mpr"),
+		DeployDir:   filepath.Join(dir, "somewhere-else"),
+		SkipBuild:   true,
+	}); err != nil {
+		t.Errorf("--skip-build boots against whatever the caller points at: %v", err)
+	}
+}
+
+// An unset DeployDir is the default and must pass before applyDefaults has run —
+// the guard is called from StartLocalApp after defaults, but a caller reading
+// this must not have to know the order.
+func TestDeployDirUnsetIsAccepted(t *testing.T) {
+	dir := t.TempDir()
+	if err := checkDeployDirIsBuildable(LocalAppOptions{ProjectPath: filepath.Join(dir, "App.mpr")}); err != nil {
+		t.Errorf("an unset DeployDir is the build's own directory: %v", err)
+	}
+}
diff --git a/cmd/mxcli/docker/localapp_integration_test.go b/cmd/mxcli/docker/localapp_integration_test.go
new file mode 100644
index 0000000000..972c95db96
--- /dev/null
+++ b/cmd/mxcli/docker/localapp_integration_test.go
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: Apache-2.0
+
+//go:build integration
+
+package docker
+
+import (
+	"bytes"
+	"os"
+	"os/exec"
+	"path/filepath"
+	"testing"
+
+	"github.com/mendixlabs/mxcli/sdk/mpr"
+)
+
+// The end-to-end guard two projects independently asked for after
+// `mxcli test --local` stopped working for every project (mxcli-ledger §150,
+// mxcli-sudoku §51):
+//
+//	Error: local runtime: runtime admin API did not come up:
+//	       runtime process exited during startup
+//	java.lang.IllegalArgumentException: Path
+//	  '…/.mxcli/deployment-test/model/bundles' cannot be resolved in base path
+//	  '…/.mxcli/deployment-test'
+//
+// The boot was pointed at a directory the build never wrote to. mxbuild deploys
+// to `<app dir>/deployment` and has no option to move it, so redirecting the
+// runtime alone left it reading an empty tree.
+//
+// Both reports drew the same lesson, and it is about the tests rather than the
+// code: the four unit tests covering this asserted that the OPTION was set, was
+// under .mxcli/, was per-project and was not the dev loop's — and every one
+// passed against a build that could not start. Sudoku §51 names the remedy
+// exactly: "an end-to-end assertion that one `mxcli test --local` run leaves a
+// model/ directory where the runtime is told to look."
+//
+// So this asserts the ARTEFACT, not the option: after a real build, the
+// directory the runtime will be booted against contains what the runtime needs.
+// It runs the build only — booting a JVM and a database is the test runner's own
+// integration territory, and the mismatch is fully visible one step earlier.
+//
+// Requires a resolvable mxbuild (the CI integration job installs one); skips
+// otherwise.
+func TestLocalApp_BuildPopulatesTheDirectoryTheRuntimeBootsAgainst(t *testing.T) {
+	mprPath := os.Getenv("MXCLI_IT_PROJECT")
+	if mprPath == "" {
+		// No fixture given: scaffold one. `mx create-project` produces a project at
+		// the INSTALLED mxbuild's version, whose JDK may not be present — hence the
+		// override above, which lets this run against a project the machine can
+		// actually build. A test that only ever skips proves nothing.
+		mxPath, err := ResolveMx("")
+		if err != nil {
+			t.Skipf("mx not resolvable and MXCLI_IT_PROJECT unset: %v", err)
+		}
+		// NOT t.TempDir(): it names the directory after the test function, and
+		// Mendix's toolset rejects the result with PathTooLongException — which
+		// this test would then report as a skip. A short path is the fix.
+		dir, err := os.MkdirTemp("", "mxapp")
+		if err != nil {
+			t.Fatal(err)
+		}
+		defer os.RemoveAll(dir)
+
+		scaffold := exec.Command(mxPath, "create-project")
+		scaffold.Dir = dir
+		if out, err := scaffold.CombinedOutput(); err != nil {
+			t.Skipf("mx create-project failed, cannot scaffold fixture: %v\n%s", err, out)
+		}
+		mprPath = filepath.Join(dir, "App.mpr")
+	}
+	if _, err := os.Stat(mprPath); err != nil {
+		t.Skipf("no project fixture at %s: %v", mprPath, err)
+	}
+
+	// The options a headless caller (the test runner) boots with, defaults applied
+	// exactly as StartLocalApp applies them.
+	opts := LocalAppOptions{ProjectPath: mprPath, Stdout: &bytes.Buffer{}, Stderr: &bytes.Buffer{}}
+	opts.applyDefaults()
+
+	// The guard StartLocalApp runs before it builds anything. A DeployDir the
+	// build will not write to is refused rather than booted against.
+	if err := checkDeployDirIsBuildable(opts); err != nil {
+		t.Fatalf("the default options are not buildable: %v", err)
+	}
+
+	reader, err := mpr.Open(mprPath)
+	if err != nil {
+		t.Skipf("cannot open project: %v", err)
+	}
+	version := reader.ProjectVersion().ProductVersion
+	reader.Close()
+
+	serveJavaMajor, _ := ProjectJavaMajor(mprPath)
+	serve, err := StartServe(ServeOptions{
+		Version: version, JavaMajor: serveJavaMajor, Host: "127.0.0.1", Port: 6547,
+	})
+	if err != nil {
+		t.Skipf("cannot start mxbuild serve: %v", err)
+	}
+	defer serve.Stop()
+
+	build, err := serve.Build(BuildRequest{Target: TargetDeploy, ProjectFilePath: mprPath})
+	if err != nil {
+		t.Fatalf("build: %v", err)
+	}
+	if !build.OK() {
+		t.Fatalf("build failed: %s", build.Message)
+	}
+
+	// The assertion the unit tests could not make: the runtime's BasePath holds a
+	// model. `model/bundles` is the exact path the JVM named when this broke.
+	for _, want := range []string{"model", filepath.Join("model", "bundles")} {
+		path := filepath.Join(opts.DeployDir, want)
+		if _, err := os.Stat(path); err != nil {
+			t.Errorf("after a build, %s does not exist — the runtime boots against %s "+
+				"and would exit during startup: %v", path, opts.DeployDir, err)
+		}
+	}
+}
diff --git a/cmd/mxcli/docker/webclient_preserve.go b/cmd/mxcli/docker/webclient_preserve.go
new file mode 100644
index 0000000000..b4023d3e1c
--- /dev/null
+++ b/cmd/mxcli/docker/webclient_preserve.go
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package docker
+
+import (
+	"os"
+	"path/filepath"
+)
+
+// preserveWebClientBundle copies the deployment's browser bundle aside and
+// returns a function that puts it back if the boot destroyed it.
+//
+// The boot's Gradle packaging pass repopulates deployment/web and takes dist/
+// with it. A headless boot does not need the bundle and does not re-create one,
+// so a `mxcli test --local` run between a `mxcli run --local` and a browser left
+// the running app serving Mendix's SPA shell over a 404 for /dist/index.js:
+// HTTP 200, blank page, nothing reported at either end (mxcli-formula1 §62).
+//
+// Giving the test boot its own deployment tree would have made the collision
+// impossible, and is not available: mxbuild writes the deployment to
+// `<app dir>/deployment` and has no flag to move it, so the runtime booted
+// against an empty directory instead (mxcli-ledger §150). The deployment
+// directory is shared because mxbuild shares it.
+//
+// So the bundle is carried across the boot rather than protected from it. That
+// costs a copy of a few MB — against the ~30s re-bundle that made warning the
+// earlier choice — and returns the exact bundle the dev loop built, not a
+// rebuilt approximation of it.
+//
+// The restore is deliberately conservative: it writes only when the bundle is
+// gone. A boot that left one alone, or built a newer one, keeps what is there —
+// restoring a snapshot over a fresher bundle would be the same defect pointing
+// the other way.
+func preserveWebClientBundle(deployDir string) func() {
+	if !WebClientBundled(deployDir) {
+		return func() {} // nothing to lose
+	}
+	dist := filepath.Join(deployDir, "web", "dist")
+	snapshot, err := os.MkdirTemp("", "mxcli-webclient-")
+	if err != nil {
+		return func() {}
+	}
+	saved := filepath.Join(snapshot, "dist")
+	if err := copyTree(dist, saved); err != nil {
+		os.RemoveAll(snapshot)
+		return func() {}
+	}
+	return func() {
+		defer os.RemoveAll(snapshot)
+		if WebClientBundled(deployDir) {
+			return // the boot did not take it
+		}
+		if err := os.MkdirAll(filepath.Dir(dist), 0o755); err != nil {
+			return
+		}
+		_ = copyTree(saved, dist)
+	}
+}
+
+// copyTree copies a directory recursively. Symlinks are not followed — a
+// deployment's bundle is plain files, and following one would copy out of the
+// tree being snapshotted.
+func copyTree(src, dst string) error {
+	return filepath.Walk(src, func(path string, info os.FileInfo, err error) error {
+		if err != nil {
+			return err
+		}
+		rel, err := filepath.Rel(src, path)
+		if err != nil {
+			return err
+		}
+		target := filepath.Join(dst, rel)
+		switch {
+		case info.IsDir():
+			return os.MkdirAll(target, 0o755)
+		case !info.Mode().IsRegular():
+			return nil
+		default:
+			if err := os.MkdirAll(filepath.Dir(target), 0o755); err != nil {
+				return err
+			}
+			return copyFile(path, target) // check.go — preserves the source mode
+		}
+	})
+}
diff --git a/cmd/mxcli/docker/webclient_preserve_test.go b/cmd/mxcli/docker/webclient_preserve_test.go
new file mode 100644
index 0000000000..1ca48e2c04
--- /dev/null
+++ b/cmd/mxcli/docker/webclient_preserve_test.go
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package docker
+
+import (
+	"os"
+	"path/filepath"
+	"testing"
+)
+
+// mxcli-formula1 FINDINGS §62, re-fixed within what mxbuild actually allows.
+//
+// A headless boot's Gradle packaging pass deletes deployment/web/dist, so a
+// `mxcli test --local` run between a `mxcli run --local` and a browser left the
+// running app serving Mendix's SPA shell over a 404 for /dist/index.js: HTTP
+// 200, blank page, nothing reported at either end.
+//
+// The first attempt gave the test boot its own deployment tree. That cannot
+// work — mxbuild writes the deployment to `<app dir>/deployment` and has no flag
+// to move it (see localapp_deploydir_test.go) — so the runtime booted against an
+// empty directory and `mxcli test --local` stopped working entirely
+// (mxcli-ledger §150).
+//
+// The bundle is a few MB of files that the boot destroys and does not need. So
+// it is copied aside before the boot and put back after, which costs a file copy
+// instead of the ~30s re-bundle that made warning-instead-of-fixing the earlier
+// choice. The dev loop gets back the exact bundle it built.
+
+// writeBundle is in webclient_bundle_test.go — the same fixture, since this is
+// the same bundle by the same route.
+
+func TestPreserveWebClientBundle_PutsItBack(t *testing.T) {
+	deploy := t.TempDir()
+	writeBundle(t, deploy, "console.log('the dev loop built this')")
+
+	restore := preserveWebClientBundle(deploy)
+
+	// What the boot's packaging step does.
+	if err := os.RemoveAll(filepath.Join(deploy, "web")); err != nil {
+		t.Fatal(err)
+	}
+	if WebClientBundled(deploy) {
+		t.Fatal("the fixture did not reproduce the loss")
+	}
+
+	restore()
+
+	if !WebClientBundled(deploy) {
+		t.Fatal("the bundle was not restored — the running app still serves a blank page")
+	}
+	got, err := os.ReadFile(filepath.Join(deploy, "web", "dist", "index.js"))
+	if err != nil {
+		t.Fatal(err)
+	}
+	// Byte-identical, not merely present: a placeholder would render the same
+	// blank page while passing an existence check.
+	if string(got) != "console.log('the dev loop built this')" {
+		t.Errorf("restored content = %q, want the bundle the dev loop built", got)
+	}
+}
+
+// Sibling files matter as much as index.js — the bundle is a directory of
+// chunks, and a restore that brought back only the entry point would serve a
+// 404 for everything it imports.
+func TestPreserveWebClientBundle_RestoresTheWholeDirectory(t *testing.T) {
+	deploy := t.TempDir()
+	writeBundle(t, deploy, "entry")
+	dist := filepath.Join(deploy, "web", "dist")
+	if err := os.MkdirAll(filepath.Join(dist, "chunks"), 0o755); err != nil {
+		t.Fatal(err)
+	}
+	if err := os.WriteFile(filepath.Join(dist, "chunks", "a.js"), []byte("chunk"), 0o644); err != nil {
+		t.Fatal(err)
+	}
+
+	restore := preserveWebClientBundle(deploy)
+	if err := os.RemoveAll(filepath.Join(deploy, "web")); err != nil {
+		t.Fatal(err)
+	}
+	restore()
+
+	if got, err := os.ReadFile(filepath.Join(dist, "chunks", "a.js")); err != nil || string(got) != "chunk" {
+		t.Errorf("nested bundle file not restored: %v %q", err, got)
+	}
+}
+
+// CONTROL 1: a boot that did NOT destroy the bundle must be left exactly as it
+// is. Restoring a stale copy over a newer bundle would be its own bug — the
+// warm loop re-bundles on a page edit, and this must not undo that.
+func TestPreserveWebClientBundle_LeavesASurvivingBundleAlone(t *testing.T) {
+	deploy := t.TempDir()
+	writeBundle(t, deploy, "old")
+
+	restore := preserveWebClientBundle(deploy)
+	writeBundle(t, deploy, "newer, built during the boot")
+	restore()
+
+	got, err := os.ReadFile(filepath.Join(deploy, "web", "dist", "index.js"))
+	if err != nil {
+		t.Fatal(err)
+	}
+	if string(got) != "newer, built during the boot" {
+		t.Errorf("a surviving bundle was overwritten with the snapshot: %q", got)
+	}
+}
+
+// CONTROL 2: with no bundle to begin with — a fresh project, or a tree only ever
+// used headlessly — there is nothing to snapshot and nothing to restore. The
+// restore must not create an empty web/dist that then reads as "bundled".
+func TestPreserveWebClientBundle_NoBundleIsANoOp(t *testing.T) {
+	deploy := t.TempDir()
+
+	restore := preserveWebClientBundle(deploy)
+	restore()
+
+	if _, err := os.Stat(filepath.Join(deploy, "web")); !os.IsNotExist(err) {
+		t.Errorf("restore invented a web/ directory: %v", err)
+	}
+	if WebClientBundled(deploy) {
+		t.Error("an empty deployment now reports a bundle")
+	}
+}
diff --git a/cmd/mxcli/lsp_completions_gen.go b/cmd/mxcli/lsp_completions_gen.go
index 57a2a7574e..f5b2701595 100644
--- a/cmd/mxcli/lsp_completions_gen.go
+++ b/cmd/mxcli/lsp_completions_gen.go
@@ -157,6 +157,9 @@ var mdlGeneratedKeywords = []protocol.CompletionItem{
 	{Label: "AVERAGE", Kind: protocol.CompletionItemKindKeyword, Detail: "Microflow keyword"},
 	{Label: "MINIMUM", Kind: protocol.CompletionItemKindKeyword, Detail: "Microflow keyword"},
 	{Label: "MAXIMUM", Kind: protocol.CompletionItemKindKeyword, Detail: "Microflow keyword"},
+	{Label: "REDUCE", Kind: protocol.CompletionItemKindKeyword, Detail: "Microflow keyword"},
+	{Label: "ANY", Kind: protocol.CompletionItemKindKeyword, Detail: "Microflow keyword"},
+	{Label: "INITIAL", Kind: protocol.CompletionItemKindKeyword, Detail: "Microflow keyword"},
 	{Label: "LIST", Kind: protocol.CompletionItemKindKeyword, Detail: "Microflow keyword"},
 	{Label: "REMOVE", Kind: protocol.CompletionItemKindKeyword, Detail: "Microflow keyword"},
 	{Label: "EQUALS", Kind: protocol.CompletionItemKindKeyword, Detail: "Microflow keyword"},
diff --git a/cmd/mxcli/syntax/features_domain_model.go b/cmd/mxcli/syntax/features_domain_model.go
index be8dd7a473..f438c3601d 100644
--- a/cmd/mxcli/syntax/features_domain_model.go
+++ b/cmd/mxcli/syntax/features_domain_model.go
@@ -39,9 +39,13 @@ func init() {
 			"a second note instead of updating the first.\n\n" +
 			"An omitted Position or Width leaves the stored value alone. A new note gets\n" +
 			"Studio Pro's defaults: (60, 240) and width 440.\n\n" +
-			"THERE IS NO COLOUR. DomainModels$Annotation stores Caption, ExportLevel,\n" +
-			"Location and Width — a \"coloured section box\" is this element in Studio\n" +
-			"Pro's own styling, and the model has nowhere to keep a colour.",
+			"THERE IS NO HEIGHT, AND NO COLOUR. DomainModels$Annotation stores exactly\n" +
+			"Caption, ExportLevel, Location and Width. A note auto-sizes to its caption,\n" +
+			"so height follows from the wrapping and WIDTH is the only lever: narrower\n" +
+			"wraps to more lines and is TALLER, wider is SHORTER. To keep a note clear of\n" +
+			"what sits below it, move those with ALTER ENTITY … SET POSITION (x, y).\n" +
+			"Likewise a \"coloured section box\" is this element in Studio Pro's own\n" +
+			"styling — the model has nowhere to keep a colour.",
 		Example: "CREATE ANNOTATION IN Sales (\n" +
 			"  Caption: $$Orders\nEverything about an order lives here.$$,\n" +
 			"  Position: (60, 40),\n" +
diff --git a/cmd/mxcli/syntax/features_microflow.go b/cmd/mxcli/syntax/features_microflow.go
index 9aa9b9a45e..efdb3e46db 100644
--- a/cmd/mxcli/syntax/features_microflow.go
+++ b/cmd/mxcli/syntax/features_microflow.go
@@ -168,9 +168,13 @@ func init() {
 			// RANGE was authorable but absent from this topic, so the paging
 			// form could not be discovered from the CLI at all (issue #966).
 			"range", "paging", "pagination", "offset", "limit", "amount", "page",
+			"reduce", "all", "any", "fold",
+			// A CE number in the cached `syntax --json` index leads an agent
+			// debugging the build error back to the right topic (issue #1002).
+			"$currentObject", "predicate", "CE0117", "CE0109", "MDL-LISTOP01",
 		},
-		Syntax:  "$List = CREATE LIST OF Module.Entity;\nADD $Item TO $List;\nREMOVE $Item FROM $List;\n$Result = HEAD($List);\n$Result = TAIL($List);\n$Result = FIND($List, condition);\n$Result = FILTER($List, condition);\n$Result = SORT($List, attr ASC);\n$Result = UNION($L1, $L2);\n$Result = INTERSECT($L1, $L2);\n$Result = SUBTRACT($L1, $L2);\n$Result = RANGE($List, offset, amount);\n$Result = RANGE($List, offset);\n$Count = COUNT($List);\n$Sum = SUM($List.Attr);\n$Avg = AVERAGE($List.Attr);\n\n-- RANGE takes OFFSET first, then AMOUNT, and needs at least ONE of them:\n--   RANGE($L, $Offset, $Amount)  page: skip $Offset, take $Amount\n--   RANGE($L, 0, $Amount)        first $Amount\n--   RANGE($L, $Offset)           skip $Offset, take the rest\n-- RANGE($L) with no bound is CE6520 at build time (mxcli check: MDL068).",
-		Example: "$AllOrders = CREATE LIST OF MyModule.Order;\nADD $NewOrder TO $AllOrders;\n$First = HEAD($AllOrders);\n$Pending = FILTER($AllOrders, Status = 'Pending');\n$Sorted = SORT($Pending, CreateDate DESC);\n$Page = RANGE($Sorted, $Offset, $PageSize);\n$Total = SUM($AllOrders.Amount);",
+		Syntax:  "$List = CREATE LIST OF Module.Entity;\nADD $Item TO $List;\nREMOVE $Item FROM $List;\n$Result = HEAD($List);\n$Result = TAIL($List);\n$Result = FIND($List, predicate);\n$Result = FILTER($List, predicate);\n$Result = SORT($List, attr ASC);\n$Result = UNION($L1, $L2);\n$Result = INTERSECT($L1, $L2);\n$Result = SUBTRACT($L1, $L2);\n$Result = RANGE($List, offset, amount);\n$Result = RANGE($List, offset);\n\n-- Aggregates. Mendix has eight; each takes an attribute or an expression\n-- over $currentObject.\n$Count = COUNT($List);\n$Sum = SUM($List.Attr);\n$Sum = SUM($List, expression);\n$Avg = AVERAGE($List.Attr);\n$Min = MINIMUM($List.Attr);\n$Max = MAXIMUM($List.Attr);\n$AllMatch = ALL($List, boolean-expression);\n$AnyMatch = ANY($List, boolean-expression);\n\n-- REDUCE folds the list into one value. $currentResult is the running\n-- total; both INITIAL and RETURNS are required and cannot be inferred.\n$Folded = REDUCE($List, expression, initial: value, returns: Type);\n\n-- RANGE takes OFFSET first, then AMOUNT, and needs at least ONE of them:\n--   RANGE($L, $Offset, $Amount)  page: skip $Offset, take $Amount\n--   RANGE($L, 0, $Amount)        first $Amount\n--   RANGE($L, $Offset)           skip $Offset, take the rest\n-- RANGE($L) with no bound is CE6520 at build time (mxcli check: MDL068).\n\nA FIND/FILTER predicate is evaluated once per item, and Mendix binds the\nitem to $currentObject -- the same variable the aggregate expressions above\nuse, and the only iterator name there is:\n\n  FILTER($Orders, $currentObject/Amount > 0)\n\nA bare attribute name means the same thing; mxcli resolves it against the\nlist's entity and writes $currentObject/Attr. A name that is not a member\nof that entity is refused, and naming any other variable is MDL-LISTOP01.\n\nSORT is not an expression -- it takes attribute names directly, so a bare\nattribute is the only spelling there.",
+		Example: "$AllOrders = CREATE LIST OF MyModule.Order;\nADD $NewOrder TO $AllOrders;\n$First = HEAD($AllOrders);\n\n-- The item under test is $currentObject\n$Pending = FILTER($AllOrders, $currentObject/Status = 'Pending');\n$Large = FILTER($AllOrders, $currentObject/Amount > 1000);\n\n-- A bare attribute name is resolved against the list's entity\n$Open = FILTER($AllOrders, Status != 'Closed');\n\n-- SORT takes attribute names, not an expression\n$Sorted = SORT($Pending, CreateDate DESC);\n$Page = RANGE($Sorted, $Offset, $PageSize);\n$Total = SUM($AllOrders.Amount);\n$AllPaid = ALL($AllOrders, $currentObject/Paid);\n$AnyLate = ANY($AllOrders, $currentObject/DueDate < [%CurrentDateTime%]);\n$Discounted = REDUCE(\n  $AllOrders,\n  $currentResult + $currentObject/Amount * 0.9,\n  initial: 0,\n  returns: Decimal\n);",
 		SeeAlso: []string{"microflow.retrieve"},
 	})
 
diff --git a/cmd/mxcli/syntax/features_misc.go b/cmd/mxcli/syntax/features_misc.go
index e19ce8b189..9d0c26a976 100644
--- a/cmd/mxcli/syntax/features_misc.go
+++ b/cmd/mxcli/syntax/features_misc.go
@@ -1024,6 +1024,7 @@ ALTER MODULE MyModule DROP JAR DEPENDENCY 'org.duckdb:duckdb_jdbc';`,
 		Keywords: []string{
 			"execution error", "entity already exists", "type mismatch",
 			"boolean default", "view entity", "microflow validation",
+			"CE0117", "CE0109", "MDL-LISTOP01",
 		},
 		Syntax: "mxcli check script.mdl -p app.mpr --references",
 		Example: `-- Entity already exists
@@ -1035,6 +1036,15 @@ ALTER MODULE MyModule DROP JAR DEPENDENCY 'org.duckdb:duckdb_jdbc';`,
 
 -- OQL invalid association path (dot vs slash)
 -- Wrong:  WHERE l.Library.Loan_Member = m.ID
--- Right:  WHERE l/Library.Loan_Member = m.ID`,
+-- Right:  WHERE l/Library.Loan_Member = m.ID
+
+-- FILTER/FIND predicate names something that is not a member
+-- Error:  "Nonexistent" is not an attribute or association of Shop.Order
+-- Cause:  a bare name in a predicate means a member of the item under test
+-- Fix:    check it against DESCRIBE ENTITY, or write $Var for a variable
+
+-- FILTER/FIND predicate uses an iterator Mendix does not define
+-- Error:  filter($L, ...): '$item' is not defined ... [MDL-LISTOP01]
+-- Fix:    use $currentObject/Attr, or a bare attribute name`,
 	})
 }
diff --git a/cmd/mxcli/syntax/features_page.go b/cmd/mxcli/syntax/features_page.go
index 79ab07c45d..35cdd470de 100644
--- a/cmd/mxcli/syntax/features_page.go
+++ b/cmd/mxcli/syntax/features_page.go
@@ -50,12 +50,15 @@ func init() {
 			"-- Data grid filters and sort (inside a DATAGRID's FILTER block)\nDATAGRID dg (...) { COLUMN c (Attribute: A) FILTER f { TEXTFILTER tf (Attribute: A) } }\nTEXTFILTER | NUMBERFILTER | DATEFILTER | DROPDOWNFILTER | DROPDOWNSORT\n\n" +
 			"-- Inputs\nTEXTBOX name (Label: 'L', Attribute: Attr)\nTEXTAREA | DATEPICKER | COMBOBOX | CHECKBOX | RADIOBUTTONS\n\n" +
 			"-- Actions\nACTIONBUTTON name (Caption: 'C', Action: SAVE_CHANGES, ButtonStyle: Primary)\nLINKBUTTON name (Caption: 'C', Action: ...)\n\n" +
-			"-- Display\nDYNAMICTEXT name (Content: 'Hello, {1}!', ContentParams: [{1} = Name])\nTITLE name (Content: 'Heading')\nIMAGE name (ImageType: imageUrl, ImageUrl: 'https://…')\n" +
-			"--   Note: on Mendix 11.13 an authored Image reports CE0463 \"the definition of this\n" +
-			"--   widget has changed\" until you run `mxcli fix widgets -p app.mpr`, which clears it\n" +
-			"--   and preserves MPR v2 (measured: 2 errors -> 0, 393 .mxunit files unchanged).\n" +
-			"--   mxcli's embedded widget templates are the 11.6 set; `mx update-widgets` is the\n" +
-			"--   same remedy but collapses MPR v2 to v1, so prefer `mxcli fix widgets`.\n\n" +
+			"-- Display\nDYNAMICTEXT name (Content: 'Hello, {1}!', ContentParams: [{1} = Name])\nTITLE name (Content: 'Heading')\nIMAGE name (Image: 'Module.Collection.ImageName')\nIMAGE name (ImageType: imageUrl, ImageUrl: 'https://…')\n" +
+			"--   IMAGE needs a source. Its default, `ImageType: image`, shows an entry from an\n" +
+			"--   image collection, named as three parts: Module.Collection.ImageName.\n" +
+			"--   `show image collections` lists the collections, `describe image collection\n" +
+			"--   Module.Collection` the images inside one. An IMAGE with that source and no\n" +
+			"--   entry writes a model mxbuild refuses (\"No image selected.\"); MDL-WIDGET22\n" +
+			"--   reports that at check time, and a name that does not resolve is reported by\n" +
+			"--   `check --references` rather than failing the build with CE1613.\n" +
+			"--   The alternatives are the URL form above, or `ImageType: icon`.\n\n" +
 			"-- Any pluggable widget by its id (id FIRST, then the name)\nPLUGGABLEWIDGET 'com.mendix.widget.web.badge.Badge' name (value: 'x')\nCUSTOMWIDGET 'com.mendix.widget.custom.x.X' name (prop: 'x')      -- legacy spelling\n\n" +
 			"-- Accepted by the parser, NOT writable on the default engine.\n" +
 			"-- Measured on 11.13.0: each is refused with\n" +
diff --git a/cmd/mxcli/testrunner/localapp_options.go b/cmd/mxcli/testrunner/localapp_options.go
index 15ca3e3737..122a758170 100644
--- a/cmd/mxcli/testrunner/localapp_options.go
+++ b/cmd/mxcli/testrunner/localapp_options.go
@@ -4,7 +4,6 @@ package testrunner
 
 import (
 	"io"
-	"path/filepath"
 
 	"github.com/mendixlabs/mxcli/cmd/mxcli/docker"
 )
@@ -26,12 +25,13 @@ func localAppOptions(opts RunOptions, logPath string, env []string, w io.Writer)
 		AppPort:     localTestAppPort,
 		AdminPort:   localTestAdminPort,
 		ServePort:   localTestServePort,
-		// A scratch deployment tree, for the same reason as the scratch database:
-		// the default is <project dir>/deployment, which is what a concurrent
-		// `mxcli run --local` is serving the browser bundle from. Rebuilding it
-		// headless leaves that app serving a 404 for /dist/index.js — 200 and a
-		// blank page, with nothing reported at either end (FINDINGS §62).
-		DeployDir: filepath.Join(filepath.Dir(opts.ProjectPath), ".mxcli", localTestDeployDir),
+		// DeployDir is deliberately left at its default, <project dir>/deployment.
+		// It is shared with a concurrent `mxcli run --local` — unlike the ports and
+		// the database — because mxbuild writes the deployment there and has no
+		// option to move it, so a scratch tree is one nothing populates
+		// (mxcli-ledger §150). The damage that sharing used to do, a headless boot
+		// deleting the browser bundle the running app serves, is undone by
+		// StartLocalApp carrying the bundle across the boot (FINDINGS §62).
 		DB: docker.DBConfig{
 			// A scratch database, so a `run --local` dev loop can keep serving the
 			// same project while the tests run.
diff --git a/cmd/mxcli/testrunner/localapp_options_deploydir_test.go b/cmd/mxcli/testrunner/localapp_options_deploydir_test.go
index aee9087d79..dd46e7c3cf 100644
--- a/cmd/mxcli/testrunner/localapp_options_deploydir_test.go
+++ b/cmd/mxcli/testrunner/localapp_options_deploydir_test.go
@@ -3,77 +3,46 @@
 package testrunner
 
 import (
-	"os"
 	"path/filepath"
 	"strings"
 	"testing"
 )
 
-// mxcli-formula1 FINDINGS §62: `mxcli test` blanked the running app.
+// mxcli-ledger FINDINGS §150: `mxcli test --local` could not start a runtime for
+// any project.
 //
-// Both apps went black while answering HTTP 200 — 1,718 bytes, Mendix's SPA
-// shell. The runtime was fine; what it served the shell FOR was gone:
+//	java.lang.IllegalArgumentException: Path '…/.mxcli/deployment-test/model/bundles'
+//	cannot be resolved in base path '…/.mxcli/deployment-test'
 //
-//	ERROR - Connector: 404 - file not found for file: dist%2Findex.js
-//	$ ls deployment/web/dist
-//	ls: cannot access 'deployment/web/dist': No such file or directory
+// The tree had no model/ in it, because mxbuild writes the deployment to
+// `<app dir>/deployment` and has no option to move it. Giving the test boot a
+// deployment directory of its own moved where the RUNTIME reads and not where
+// the BUILD writes.
 //
-// `deployment/web/` had been rewritten by something that was not the app. The
-// culprit reproduces on demand in twenty seconds:
+// What this file used to assert is the lesson. Four tests checked that DeployDir
+// was set, was under .mxcli/, was not the dev loop's, and differed per project —
+// and all four passed against a build that could not start, because every one of
+// them was about the option value rather than about what ends up on disk. The
+// symptom lived one layer down, and nothing here looked there.
 //
-//	before:            deployment/web/dist
-//	after mxcli test:  MISSING
-//	bundle now:        404
-//
-// `mxcli test --local` rebuilt the deployment directory of a project another
-// `mxcli run` was serving, and its headless build does not bundle the web
-// client. The tests pass, the run keeps running, and the app goes blank —
-// nothing reports an error at either end.
-//
-// The design intent was already written down, one line above the constants this
-// test is about: a local test run "deliberately does not share the dev loop's
-// ports or database … a test run must neither refuse to start because of it nor
-// write its fixtures into the database the developer is looking at." The
-// DEPLOYMENT DIRECTORY was the one shared resource left off that list, and it is
-// the one the browser reads from.
-//
-// Detection was not the fix. The two processes use different ports by design, so
-// no port check can see the collision, and a lock file would only turn a silent
-// blanking into a refusal. Giving the test boot its own deployment directory
-// makes the collision impossible instead.
+// So the option is gone and the invariant is asserted instead: the test boot
+// must leave DeployDir at the build's own directory. The docker package refuses
+// anything else outright (checkDeployDirIsBuildable), which is where the
+// constraint belongs — it is mxbuild's, not the test runner's.
 
-func TestLocalTestBoot_DoesNotShareTheDevLoopDeployment(t *testing.T) {
+func TestLocalTestBoot_UsesTheDirectoryTheBuildWritesTo(t *testing.T) {
 	projectPath := filepath.Join(t.TempDir(), "App.mpr")
 	opts := localAppOptions(RunOptions{ProjectPath: projectPath}, "", nil, nil)
 
-	devLoop := filepath.Join(filepath.Dir(projectPath), "deployment")
-	if opts.DeployDir == "" {
-		t.Fatal("DeployDir is unset, so the boot defaults to the dev loop's deployment/ — " +
-			"the directory `mxcli run --local` is serving the browser bundle from")
-	}
-	if opts.DeployDir == devLoop {
-		t.Errorf("the test boot builds into %s, which is the running app's deployment directory",
-			opts.DeployDir)
+	if opts.DeployDir != "" {
+		t.Errorf("DeployDir = %q, want it unset so the boot uses %s — the only directory "+
+			"mxbuild will populate", opts.DeployDir, filepath.Join(filepath.Dir(projectPath), "deployment"))
 	}
 }
 
-// It must also be inside the project, and inside the directory mxcli already
-// owns and gitignores — a scratch build tree at the project root would show up
-// as untracked files on the developer's next `git status`.
-func TestLocalTestBoot_DeploymentLivesUnderTheMxcliDir(t *testing.T) {
-	projectPath := filepath.Join(t.TempDir(), "App.mpr")
-	opts := localAppOptions(RunOptions{ProjectPath: projectPath}, "", nil, nil)
-
-	want := filepath.Join(filepath.Dir(projectPath), ".mxcli")
-	if !strings.HasPrefix(opts.DeployDir, want+string(filepath.Separator)) {
-		t.Errorf("DeployDir = %s, want it under %s (gitignored, and already where the "+
-			"test runtime log lives)", opts.DeployDir, want)
-	}
-}
-
-// CONTROL: the separation the finding's comment already claimed must still hold.
-// A fix that moved the deployment directory but collapsed the database or the
-// ports would trade one collision for another.
+// CONTROL: the separation that IS achievable must still hold. Sharing the
+// deployment directory is forced by mxbuild; sharing the ports or the database
+// is not, and a fix that gave up on those would trade one collision for another.
 func TestLocalTestBoot_StillSeparatesPortsAndDatabase(t *testing.T) {
 	projectPath := filepath.Join(t.TempDir(), "App.mpr")
 	opts := localAppOptions(RunOptions{ProjectPath: projectPath}, "", nil, nil)
@@ -86,61 +55,34 @@ func TestLocalTestBoot_StillSeparatesPortsAndDatabase(t *testing.T) {
 	}
 }
 
-// Two projects side by side must not share the scratch tree either — the F1
-// solution runs a backend and a frontend from one repository, which is how this
-// class of collision was found in the first place.
-func TestLocalTestBoot_DeploymentIsPerProject(t *testing.T) {
-	a := localAppOptions(RunOptions{ProjectPath: filepath.Join(t.TempDir(), "Backend", "App.mpr")}, "", nil, nil)
-	b := localAppOptions(RunOptions{ProjectPath: filepath.Join(t.TempDir(), "Frontend", "App.mpr")}, "", nil, nil)
-
-	if a.DeployDir == b.DeployDir {
-		t.Errorf("both projects build into %s", a.DeployDir)
+// `--skip-build` means what it always meant — reuse the deployment the last
+// build wrote — and must not be refused. It was, for as long as the test run was
+// expected to have a tree of its own that no first run could have created.
+func TestValidateOptions_SkipBuildIsAllowed(t *testing.T) {
+	dir := t.TempDir()
+	if err := validateOptions(RunOptions{
+		ProjectPath: filepath.Join(dir, "App.mpr"),
+		Local:       true,
+		SkipBuild:   true,
+	}); err != nil {
+		t.Errorf("--skip-build reuses the project's deployment/ and must be allowed: %v", err)
 	}
 }
 
-// `--skip-build` used to mean "reuse the deployment/ tree the dev loop built".
-// It now reuses the test run's OWN tree, which does not exist until tests have
-// been run once — so the first such run must say that, rather than failing
-// somewhere inside the runtime boot with a path nobody chose.
-//
-// Reusing the dev loop's directory is not the alternative: booting a runtime
-// against it removes the browser bundle even without a rebuild, which is the
-// same §62 blanking by a different route (and was FINDINGS §35).
-func TestValidateOptions_SkipBuildWithNoScratchDeployment(t *testing.T) {
+// CONTROL: the --skip-build refusals that are real are unaffected — they are
+// about combinations that cannot work, not about what is on disk.
+func TestValidateOptions_SkipBuildStillRefusedWithWatch(t *testing.T) {
 	dir := t.TempDir()
 	err := validateOptions(RunOptions{
 		ProjectPath: filepath.Join(dir, "App.mpr"),
 		Local:       true,
 		SkipBuild:   true,
+		Watch:       true,
 	})
 	if err == nil {
-		t.Fatal("--skip-build with no previous local test run must be refused, not attempted")
-	}
-	for _, want := range []string{"--skip-build", localTestDeployDir} {
-		if !strings.Contains(err.Error(), want) {
-			t.Errorf("the message should name %q: %v", want, err)
-		}
-	}
-}
-
-// CONTROL 1: once the scratch tree exists, --skip-build is allowed again.
-func TestValidateOptions_SkipBuildWithAScratchDeployment(t *testing.T) {
-	dir := t.TempDir()
-	project := filepath.Join(dir, "App.mpr")
-	deploy := filepath.Join(dir, ".mxcli", localTestDeployDir, "model")
-	if err := os.MkdirAll(deploy, 0o755); err != nil {
-		t.Fatal(err)
-	}
-	if err := validateOptions(RunOptions{ProjectPath: project, Local: true, SkipBuild: true}); err != nil {
-		t.Errorf("an existing scratch deployment must be reusable: %v", err)
+		t.Fatal("--watch with --skip-build must still be refused")
 	}
-}
-
-// CONTROL 2: without --skip-build there is nothing to check — the build creates
-// the tree. A guard that fired here would refuse every first test run.
-func TestValidateOptions_NoSkipBuildNeedsNothingOnDisk(t *testing.T) {
-	dir := t.TempDir()
-	if err := validateOptions(RunOptions{ProjectPath: filepath.Join(dir, "App.mpr"), Local: true}); err != nil {
-		t.Errorf("an ordinary local run must not require an existing deployment: %v", err)
+	if !strings.Contains(err.Error(), "--watch") {
+		t.Errorf("the message should name --watch: %v", err)
 	}
 }
diff --git a/cmd/mxcli/testrunner/runner.go b/cmd/mxcli/testrunner/runner.go
index 400cf68a7c..54c017f014 100644
--- a/cmd/mxcli/testrunner/runner.go
+++ b/cmd/mxcli/testrunner/runner.go
@@ -224,7 +224,7 @@ func validateOptions(opts RunOptions) error {
 		return nil
 	}
 	if !opts.Watch {
-		return checkScratchDeploymentExists(opts)
+		return nil
 	}
 	if !opts.Local {
 		return fmt.Errorf("--watch requires --local: the Docker path can only re-run tests by restarting the container")
@@ -238,33 +238,6 @@ func validateOptions(opts RunOptions) error {
 	return nil
 }
 
-// checkScratchDeploymentExists refuses `--skip-build` before the test run has a
-// deployment of its own to reuse.
-//
-// A local test run builds into its own tree rather than the dev loop's
-// deployment/, because rebuilding — or merely booting a runtime against — the
-// directory a running `mxcli run --local` serves leaves that app returning a 404
-// for /dist/index.js: HTTP 200, blank page, nothing reported at either end
-// (FINDINGS §62, and §35 for the boot-only route). So "reuse what is already
-// built" now means the test tree, which does not exist until tests have run once.
-//
-// Saying that is the whole point: without it the first --skip-build run fails
-// inside the runtime boot, against a path the user never chose.
-func checkScratchDeploymentExists(opts RunOptions) error {
-	if !opts.SkipBuild || !opts.Local || opts.ProjectPath == "" {
-		return nil
-	}
-	dir := filepath.Join(filepath.Dir(opts.ProjectPath), ".mxcli", localTestDeployDir)
-	if _, err := os.Stat(filepath.Join(dir, "model")); err == nil {
-		return nil
-	}
-	return fmt.Errorf("--skip-build has nothing to reuse: %s does not exist yet.\n"+
-		"  A local test run builds into its own %s tree rather than the project's deployment/,\n"+
-		"  which `mxcli run --local` serves the browser bundle from — rebuilding that one blanks\n"+
-		"  the running app with no error at either end. Run the suite once without --skip-build.",
-		dir, localTestDeployDir)
-}
-
 // runEndpoint injects the test endpoint plus one microflow per test, boots the
 // app once, and drives the suite over HTTP.
 func runEndpoint(opts RunOptions, suite *TestSuite, timeout time.Duration, w io.Writer) (*SuiteResult, error) {
diff --git a/cmd/mxcli/testrunner/runner_local.go b/cmd/mxcli/testrunner/runner_local.go
index 32f416ba12..ff9d3ba74c 100644
--- a/cmd/mxcli/testrunner/runner_local.go
+++ b/cmd/mxcli/testrunner/runner_local.go
@@ -14,27 +14,24 @@ import (
 	"github.com/mendixlabs/mxcli/cmd/mxcli/docker"
 )
 
-// Local test runs deliberately do not share the dev loop's ports, database or
-// DEPLOYMENT DIRECTORY: `mxcli run --local` may well be serving the same project
-// (that is the point of the warm loop), and a test run must neither refuse to
-// start because of it, nor write its fixtures into the database the developer is
-// looking at, nor rebuild the directory the running app serves the browser from.
+// Local test runs deliberately do not share the dev loop's ports or database:
+// `mxcli run --local` may well be serving the same project (that is the point of
+// the warm loop), and a test run must neither refuse to start because of it nor
+// write its fixtures into the database the developer is looking at.
 //
-// The deployment directory was the one shared resource left off this list, and
-// it is the one the BROWSER reads. A headless test boot does not bundle the web
-// client, so its build left the running app serving Mendix's SPA shell over a
-// 404 for /dist/index.js — HTTP 200, blank page, no error at either end
-// (mxcli-formula1 FINDINGS §62).
+// The deployment directory is the one resource that IS shared, and not by
+// choice: mxbuild writes it to `<app dir>/deployment` and has no option to move
+// it, so a test run cannot build into a tree of its own (mxcli-ledger §150 —
+// where trying made the runtime abort on an empty directory). The damage that
+// sharing does — a headless boot's packaging pass deleting the browser bundle
+// the running app serves, leaving HTTP 200 over a blank page (mxcli-formula1
+// §62) — is undone in StartLocalApp, which carries the bundle across the boot.
 const (
 	localTestAppPort   = 8081
 	localTestAdminPort = 8091
 	localTestServePort = 6544
 	// localTestDBSuffix is appended to the project's local database name.
 	localTestDBSuffix = "_test"
-	// localTestDeployDir is the test boot's own deployment tree, under the
-	// project's .mxcli/ — gitignored, and already where the test runtime log
-	// lives, so a scratch build tree does not surface as untracked files.
-	localTestDeployDir = "deployment-test"
 )
 
 // runLocalAndCapture builds the project and boots mxcli's own runtime — no
diff --git a/cmd/mxcli/tunnelhub/auth.go b/cmd/mxcli/tunnelhub/auth.go
index 3c559ca8b5..9e2eac50aa 100644
--- a/cmd/mxcli/tunnelhub/auth.go
+++ b/cmd/mxcli/tunnelhub/auth.go
@@ -295,8 +295,9 @@ func (a *AuthConfig) handleCallback(w http.ResponseWriter, r *http.Request) {
 	a.setSessionCookie(w, login)
 	audit.Log(auditEvent(r, auditLoginOK, login))
 	// Only redirect back to our own hosts (defence against open-redirect).
-	if !a.safeReturn(ret) {
-		ret = "https://" + a.HubHost + "/"
+	if !a.isValidRedirect(ret) {
+		http.Redirect(w, r, "https://"+a.HubHost+"/", http.StatusFound)
+		return
 	}
 	http.Redirect(w, r, ret, http.StatusFound)
 }
@@ -313,9 +314,17 @@ func (a *AuthConfig) handleLogout(w http.ResponseWriter, r *http.Request) {
 	w.WriteHeader(http.StatusNoContent)
 }
 
-// safeReturn allows redirecting only to the hub host or a subdomain of the cookie
+// isValidRedirect allows redirecting only to the hub host or a subdomain of the cookie
 // domain, so a crafted `return` can't bounce the browser off-site after login.
-func (a *AuthConfig) safeReturn(ret string) bool {
+//
+// The NAME is load-bearing and so is the shape of its use in handleCallback.
+// CodeQL's go/unvalidated-url-redirection only credits a redirect validator whose
+// callee name matches (?i)(is_?)?(local_?url|valid_?redir(ect)?)(ur[li])?, and only
+// sanitizes reads the guard's true-branch dominates. Measured on 2.20.3, all four
+// combinations: this name + early return is the ONLY one that clears the alert --
+// renaming it back, or going back to reassigning `ret` and falling through to a
+// single Redirect, each independently make the (already-fixed) alert reappear.
+func (a *AuthConfig) isValidRedirect(ret string) bool {
 	u, err := url.Parse(ret)
 	if err != nil || u.Scheme != "https" {
 		return false
diff --git a/cmd/mxcli/tunnelhub/safereturn_test.go b/cmd/mxcli/tunnelhub/isvalidredirect_test.go
similarity index 93%
rename from cmd/mxcli/tunnelhub/safereturn_test.go
rename to cmd/mxcli/tunnelhub/isvalidredirect_test.go
index 19e9b0d874..5b4491702d 100644
--- a/cmd/mxcli/tunnelhub/safereturn_test.go
+++ b/cmd/mxcli/tunnelhub/isvalidredirect_test.go
@@ -28,9 +28,9 @@ func TestSafeReturnRejectsLookalikeDomains(t *testing.T) {
 	for _, c := range cases {
 		t.Run(c.name, func(t *testing.T) {
 			a := &AuthConfig{HubHost: c.hubHost, CookieDomain: c.cookieDomain}
-			got := a.safeReturn(c.ret)
+			got := a.isValidRedirect(c.ret)
 			if got != c.wantSafe {
-				t.Errorf("safeReturn(%q) with CookieDomain=%q = %v, want %v",
+				t.Errorf("isValidRedirect(%q) with CookieDomain=%q = %v, want %v",
 					c.ret, c.cookieDomain, got, c.wantSafe)
 			}
 		})
diff --git a/docs-site/src/appendixes/error-messages.md b/docs-site/src/appendixes/error-messages.md
index ae31406751..6c844a7ed8 100644
--- a/docs-site/src/appendixes/error-messages.md
+++ b/docs-site/src/appendixes/error-messages.md
@@ -103,6 +103,23 @@ on 11.9.0) [MDL-WIDGET02]
 
 The deprecated-widget catalog is hand-maintained in `mdl/executor/keyword_dispatch.go` (`LegacyWidgets`). Open an issue if you spot a native widget that should be on the list.
 
+### MDL-LISTOP01: Undefined iterator in a FILTER/FIND predicate
+
+```
+filter($L, …): '$item' is not defined in this microflow. A filter predicate is
+evaluated once per item and Mendix binds the item to '$currentObject' — no other
+iterator name exists, so mxbuild rejects this with CE0109 "Undefined variable
+'item'". [MDL-LISTOP01]
+```
+
+**Cause:** A `FILTER`/`FIND` predicate navigates from a variable the microflow never binds. Mendix evaluates the predicate once per item with the item bound to `$currentObject`, and defines no other iterator name — so `filter($L, $item/Amount > 0)` compiles to a reference to nothing.
+
+**Solution:**
+1. Use `$currentObject/` for the item under test: `filter($L, $currentObject/Amount > 0)`.
+2. Or write the attribute bare — `filter($L, Amount > 0)` — and mxcli resolves it against the list's entity and stores `$currentObject/Amount`.
+
+The rule keys on **scope, not on the name**. `$item` is perfectly valid in a predicate when it is the enclosing loop's iterator, which is how the O(N) lookup idiom is written — inside `loop $item in $L`, `find($Others, Key = $item/Key)` navigates the loop's variable and is not flagged.
+
 ## mxcli Parser Errors
 
 ### Mismatched input
@@ -160,6 +177,20 @@ Error: unresolved reference 'MyModule.NonExistent' at line 5
 
 **Solution:** Verify the referenced element exists, or create it before the referencing statement.
 
+### Bare name is not a member of the list's entity
+
+```
+Error: filter($L, …): "Nonexistent" is not an attribute or association of
+Shop.Order — a filter predicate is evaluated once per item, so a bare name must
+be a member of the list's entity (mxbuild reports CE0117 otherwise)
+```
+
+**Cause:** A bare name in a `FILTER`/`FIND` predicate can only mean a member of the item being tested. mxcli resolves it against the list's element entity and rewrites it to `$currentObject/<member>`; a name that does not resolve cannot be rewritten into anything valid.
+
+**Solution:** Check the spelling against `DESCRIBE ENTITY Shop.Order`. If you meant a variable rather than a member, write it with its `$` — a bare word is always read as a member of the iterated item.
+
+Before mxcli qualified these, the unresolvable name was written into the expression verbatim and surfaced at build time as `CE0117 "Error(s) in expression."`, with `mxcli check` reporting nothing.
+
 ## BSON Serialization Errors
 
 ### Wrong array prefix
diff --git a/docs-wiki/README.md b/docs-wiki/README.md
index 93dd5aedc6..19c3c4df66 100644
--- a/docs-wiki/README.md
+++ b/docs-wiki/README.md
@@ -16,17 +16,18 @@ If you're new to mxcli internals, read in this order:
 6. `glossary.md` — terminology bridge across Mendix / mxcli / BSON
 
 **Diagnosing a bug?** Start at [`bug-patterns/`](bug-patterns/) — the failure *classes*,
-digested from the symptom table in
-[`.claude/skills/fix-issue.md`](../.claude/skills/fix-issue.md). Grep that table for the
-specific instance afterwards; it is ~1 MB and is not meant to be read whole. Pattern
-coverage is partial, so a miss there means the finding has not been digested yet.
+digested from the findings in
+[`.claude/skills/fix-issue/findings/`](../.claude/skills/fix-issue/findings/). Grep
+those for the specific instance afterwards; they are data, not reading material.
+Pattern coverage is partial, so a miss there means the finding has not been
+digested yet.
 
 ## How this wiki is maintained
 
 - **On-demand only**, via `/mxcli-dev:wiki-sync`.
 - Rules and template: [`.claude/skills/maintain-wiki.md`](../.claude/skills/maintain-wiki.md).
 - Audit trail of every sync: [`SYNC_LOG.md`](SYNC_LOG.md).
-- New pages outside the seed list need to be added to the skill's seed table first.
+- New pages outside the list need a row in [`.claude/skills/maintain-wiki/pages.md`](../.claude/skills/maintain-wiki/pages.md) first.
 
 ## What this wiki is NOT
 
@@ -36,7 +37,7 @@ coverage is partial, so a miss there means the finding has not been digested yet
 | MDL syntax tables | `docs/01-project/MDL_QUICK_REFERENCE.md` |
 | What a function does | source code |
 | Step-by-step procedure | `.claude/skills/<task>.md` |
-| Specific bug recipe | `.claude/skills/fix-issue.md` |
+| Specific bug recipe | `.claude/skills/fix-issue/findings/*.jsonl` |
 | Proposal status / PR # / roadmap | proposal frontmatter, GitHub |
 | Architectural decision history | `docs/13-decisions/` (ADRs) |
 | Latest design proposal | `docs/11-proposals/` |
diff --git a/docs-wiki/SYNC_LOG.md b/docs-wiki/SYNC_LOG.md
index 56c9ea4843..74275c034e 100644
--- a/docs-wiki/SYNC_LOG.md
+++ b/docs-wiki/SYNC_LOG.md
@@ -31,3 +31,27 @@ not capture, because sources are upstream of the commit.
 | 2026-06-10 | models/ped-mutation-constraints.md | docs/03-development/PED_MCP_CAPABILITIES.md, mdl/backend/mcp/workflow.go, mdl/backend/mcp/domainmodel.go, mdl/backend/mcp/microflow.go | New page (outside seed list): synthesises the counter-intuitive PED invariants (simplified constructors, leaf-only sets, array-edit rules, acceptance≠validity, verify-exact-payload) learned empirically across the MCP increments; capability doc holds the facts, this holds the mental model |
 | 2026-08-11 | architecture/mpr-read-write.md | sdk/mpr/reader.go, sdk/mpr/writer_core.go, sdk/mpr/writer_units.go, sdk/mpr/parser.go, modelsdk.go, modelsdk/mpr/writer_core.go, modelsdk/canon/canon.go, modelsdk/canon/identity.go, docs/13-decisions/0008-identity-and-idempotence.md | Writes are now conditional (ADR-0008) and the page described only one engine. Added the two-engines/one-choke-point framing and the canonical-comparison model. **Corrected a pre-existing inaccuracy**: the page claimed v2 writes stage through WriteTransaction with temp files — in sdk/mpr that type has no callers and the ordinary path is a direct WriteFile; temp-file staging is the modelsdk engine. Added modelsdk sources; dropped sdk/mpr/writer_widgets.go (the BSON-convention claim is fully grounded in parser.go, and widget specifics belong to the widget-engine page) |
 | 2026-08-11 | models/element-identity.md | docs/13-decisions/0008-identity-and-idempotence.md, modelsdk/canon/identity.go, CLAUDE.md, .claude/skills/fix-issue.md | New page (outside seed list, added to seed table): the $ID / GUID / StableId distinction had no wiki home and is the invariant that cost a reverted PR. Does not fit storage-vs-qualified-names ($Type naming) or association-pointers (pointer direction); mpr-read-write is a pipeline narrative, this is the mental model. ADR holds the decision and evidence, this holds the framing |
+| 2026-08-31 | bug-patterns/describe-round-trip-gaps.md | .claude/skills/fix-issue/findings/mdl-executor.jsonl (83 describe-related records), mdl/executor/cmd_workflows.go, mdl/executor/cmd_pages_describe_pluggable.go | New page (added to seed table). Largest class in the area — 83 of 248 executor findings. Frames DESCRIBE as a second MDL implementation with no oracle (mxbuild never sees its output), and the four shapes: won't-parse, silently-drops, invents, destroys. Triggered by `make digest-status` reporting 607 of 631 findings undigested |
+| 2026-08-31 | bug-patterns/unloadable-model-writes.md | .claude/skills/fix-issue/findings/mdl-executor.jsonl (12 load-failure records), mdl/executor/validate_workflow.go, mdl/executor/validate_association_module.go | New page (added to seed table). Separates LOAD failure from validation failure: no CE code, no document named, whole project down. The recurring remedy is refusal in both passes, and `mx check` at 0 errors is not evidence the project opens |
+| 2026-08-31 | bug-patterns/silent-property-drop.md | .claude/skills/fix-issue/findings/mdl-executor.jsonl (22 silent-drop records), mdl/executor/validate_widget_props.go, mdl/executor/validate_widgets.go, modelsdk/widgets/definitions/ | New page (added to seed table). Why a typo and a real-but-unrouted property fail identically. **Corrected while syncing**: the first draft named a non-existent `validate_widget_props.go` and claimed the remedy is derived rather than enumerated — reading the real file showed both halves exist and for good reason, derived for pluggable widgets (mpk keys minus mapped keys) and a guarded hand-maintained union for built-ins, which have no mpk to subtract from |
+| 2026-08-31 | bug-patterns/check-mxbuild-drift.md | .claude/skills/fix-issue/findings/mdl-executor.jsonl (17 check-gap records), mdl/executor/validate_program.go, docs/11-proposals/PROPOSAL_check_mxbuild_gap_heuristics.md | New page (added to seed table). Both directions of drift, and why a false positive stopped being cosmetic once exec began refusing on check errors |
+| 2026-08-31 | bug-patterns/platform-semantics-gaps.md | .claude/skills/fix-issue/findings/mdl-executor.jsonl (18 records), mdl/executor/validate_microflow_ce_gaps.go, mdl/executor/validate_microflow_loop_scope.go | New page (added to seed table). Second pass over mdl/executor. Frames the seam between a permissive SQL-shaped grammar and four narrower Mendix sub-languages (expressions, XPath, the microflow variable model, entity rules), and why some rules are safe to enforce unconditionally while builder-predicting ones are not. Notes that several reports in this class were measured and closed as correct behaviour |
+| 2026-08-31 | bug-patterns/duplicate-resolver-drift.md | .claude/skills/fix-issue/findings/mdl-executor.jsonl (23 records), mdl/executor/validate_program.go, mdl/backend/backend.go | New page (added to seed table). The most common structural cause in the area: check vs exec, legacy vs modelsdk, write vs read, per-doctype copies. The tell is that the fix for the reported instance is obviously incomplete |
+| 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 0000000000..34181c2bb7
--- /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/bson-numeric-width.md b/docs-wiki/bug-patterns/bson-numeric-width.md
index 700f2dc987..20289310ea 100644
--- a/docs-wiki/bug-patterns/bson-numeric-width.md
+++ b/docs-wiki/bug-patterns/bson-numeric-width.md
@@ -3,11 +3,11 @@ title: BSON Numeric Width Mismatches
 category: bug-pattern
 last-synced: 4e185f73
 sources:
-  - .claude/skills/fix-issue.md
+  - .claude/skills/fix-issue/findings/
   - sdk/mpr/parser.go
 ---
 
-> **Do not duplicate**: the per-field fix recipes live in the `.claude/skills/fix-issue.md` symptom rows (issues #583, #585) and the `extractInt` helper signature lives in `sdk/mpr/parser.go`. This page describes the pattern only.
+> **Do not duplicate**: the per-field fix recipes live in the `fix-issue/findings/*.jsonl` records (issues #583, #585) and the `extractInt` helper signature lives in `sdk/mpr/parser.go`. This page describes the pattern only.
 
 ## What this is
 
@@ -23,6 +23,6 @@ The canonical fix is the width-agnostic `extractInt` helper in [`sdk/mpr/parser.
 
 ## See also
 
-- [fix-issue symptom table](../../.claude/skills/fix-issue.md) — the per-instance fix recipes for this pattern
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the per-instance fix recipes for this pattern
 - [[architecture/mpr-read-write]] — how the BSON reader/parser layer is structured
 - [[models/storage-vs-qualified-names]] — the other major class of read/write mismatch
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 0000000000..beea3e861e
--- /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/check-mxbuild-drift.md b/docs-wiki/bug-patterns/check-mxbuild-drift.md
new file mode 100644
index 0000000000..5a0ea65176
--- /dev/null
+++ b/docs-wiki/bug-patterns/check-mxbuild-drift.md
@@ -0,0 +1,88 @@
+---
+title: When `mxcli check` and mxbuild Disagree
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-executor.jsonl
+  - mdl/executor/validate_program.go
+  - docs/11-proposals/PROPOSAL_check_mxbuild_gap_heuristics.md
+---
+
+> **Do not duplicate**: the rule catalogue and its rationale live in
+> `PROPOSAL_check_mxbuild_gap_heuristics.md`; each rule's exact predicate and CE
+> number live in the findings and in `mdl/executor/validate_*.go`. This page
+> describes the failure class on both sides.
+
+## What this is
+
+`mxcli check` is a **model of mxbuild**, not a port of it. It runs before a
+build — often before a project even exists — so every rule is a prediction, and
+predictions drift in two directions:
+
+- **A gap.** `check` passes, `exec` writes, and the build then fails with a `CE`
+  code. The user has already changed their project before anything told them.
+- **A false refusal.** `check` rejects MDL that mxbuild accepts at 0 errors.
+
+Both appear repeatedly in the executor findings. The second used to be a mere
+annoyance and is not any more: since `exec` began refusing scripts whose check
+reports an **error**, a false positive is a blocker rather than a warning.
+
+## How it fits
+
+**Verify a rule against mxbuild, not against intuition.** Rules have been added
+on a plausible reading of a CE code and later measured to be wrong: one flagged
+format functions over association navigation as a build error and was deleted
+outright; another demanded a `return` on every path from a microflow that builds
+cleanly, because the builder synthesises one. A rule that predicts mxbuild has to
+be checked against mxbuild.
+
+**A rule reproduced from failing neighbours can still be mis-premised.** The
+deleted rule was written after reproducing several failures that shared the
+construct it flagged — and the construct was not the cause. They shared a
+*different* hidden defect, in the write path. When a write-path fix lands,
+re-validate the checks that were derived from the same symptoms; a
+correlation-based rule outlives the correlation.
+
+**Mirror the builder's own condition rather than inventing a second one.** Where
+`check` predicts something the builder decides, the two conditions must be the
+same expression, not two readings of the same intent — otherwise they drift on
+the first edit to either.
+
+**Run a new rule over `mdl-examples/` before wiring it up.** One candidate hit 4
+of 374 example files and 3 of the hits were false positives, because the rule
+read the AST while the outcome depended on what the builder synthesises. The
+corpus is the cheapest false-positive test available.
+
+**Severity is the design decision, not an afterthought.** A rule whose vocabulary
+cannot be proven complete — anything about widget properties, or about a name
+that might be legal in a context the rule cannot see — must be a *warning*, or
+it trades a silent defect for a false refusal. That only works if warnings
+genuinely do not block: an exec guard written as `if len(violations) > 0` makes
+every warning fatal, which is how a warning-severity rule silently became a
+blocker for everything it touched.
+
+**Close a gap in both passes or in neither.** A check-time rule does not protect
+a script that runs `exec` directly, and `--no-check` exists. Both call the same
+function so they cannot diverge — the convention exists because they did.
+
+**When probing a gap, probe every sibling.** A missing reference check is almost
+never one reference kind: the workflow case turned out to have *nothing*
+validated — called microflow, called workflow, user task page, targeting
+microflow, context entity, and the workflow's own module. Fixing the reported one
+leaves the class open and the next report looks new.
+
+**Grade by consequence.** The same statement can produce a recoverable build
+error or an unopenable project depending on one detail — a qualified-but-missing
+name versus an unqualified one. Those want different gates: the first needs a
+project and belongs in the reference check; the second is a static property of
+the statement and can be refused with no project at all, which is also what makes
+it testable as a `.fail.mdl` fixture in CI.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — every rule's
+  predicate, its CE code, and the measurement behind it
+- [[unloadable-model-writes]] — the failures that have no CE code because the
+  build never gets that far
+- `PROPOSAL_check_mxbuild_gap_heuristics.md` — the design rationale for
+  predicting mxbuild at all
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 0000000000..80f95ca859
--- /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/describe-round-trip-gaps.md b/docs-wiki/bug-patterns/describe-round-trip-gaps.md
new file mode 100644
index 0000000000..3cf4ff73ab
--- /dev/null
+++ b/docs-wiki/bug-patterns/describe-round-trip-gaps.md
@@ -0,0 +1,100 @@
+---
+title: DESCRIBE Round-Trip Gaps
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-executor.jsonl
+  - mdl/executor/cmd_workflows.go
+  - mdl/executor/cmd_pages_describe_pluggable.go
+---
+
+> **Do not duplicate**: the per-construct fix recipes live in the findings
+> (`grep -l describe .claude/skills/fix-issue/findings/*.jsonl`), the MDL syntax
+> in `docs/01-project/MDL_QUICK_REFERENCE.md`, and the round-trip requirement in
+> CLAUDE.md's PR checklist. This page describes the failure class only.
+
+## What this is
+
+`DESCRIBE` is a **second implementation of MDL**, written in the opposite
+direction and validated by nothing. Every construct has a writer (MDL → BSON)
+and a describer (BSON → MDL) built separately, and no mechanism forces them to
+agree. This is the single largest class of defect in the executor: **83 of the
+248 findings** for `mdl/executor` involve a describe path.
+
+The reason it accumulates is that the write path has an oracle and the read path
+does not. `mxbuild` validates the *model*, and it never sees DESCRIBE output at
+all — so a describer that drops a property produces a perfectly valid model, at
+0 errors before and after. The only thing that notices is a person replaying the
+output and finding their work gone.
+
+That matters most where the feature is used most. `describe → edit → exec` is
+mxcli's copy operation, and `DESCRIBE LAYOUT` emitting re-executable MDL is
+explicitly why there is no `COPY DOCUMENT` verb. A lossy describer is costliest
+exactly when someone is trying to reuse work.
+
+## How it fits
+
+**Four shapes, in increasing order of how long they survive.**
+
+*Won't parse.* The emitter produces text MDL's own grammar rejects — a
+reserved-word name emitted bare, an internal spelling (`call_microflow X`,
+`ReadMode: CallMicroflow:…`) that no rule accepts, `Param = $v` where the
+grammar wants `Param: $v`, a quote inside a string that was never doubled. Loud
+and cheap: running `mxcli check` on the output finds it. The recurring cause is
+that **storage form is not input form** — whenever DESCRIBE prints a value read
+back from the backend, the question is whether the *parser* accepts that
+spelling, and nothing else in the toolchain asks it.
+
+*Silently drops.* A property is written correctly, present in the `.mxunit`, live
+in the app — and absent from the description. The round trip deletes it. Output
+parses, executes, and the model stays valid, so every automated signal is green.
+
+*Invents.* The describer emits a clause the author never wrote: `comment 'Review'`
+on a jump whose caption was only ever a default, `on error rollback` on an
+activity with no error handling, a bare `else` on a split that has none. Each
+round trip accumulates another, so the model drifts toward the emitter's
+defaults. The governing rule is an **asymmetry**: omitting a value the writer
+re-derives is lossless, while emitting it is lossy in the direction that
+matters — it puts something in the user's script that they did not write. When a
+formatter renders an enum whose fallback value is also a legal authored value,
+read-back cannot invert the write; render only the values that are never
+defaults.
+
+*Destroys.* Rarest and worst — the round trip removes structure rather than
+losing a field. A list view's specialization templates went 4 → 0; an accordion
+group's contents vanished; a loop body was emitted empty because an annotation
+sat to its left. `mx check` reported 0 errors on both sides of each.
+
+**The defect is usually the copy, not the case.** Describers get written
+per-widget and per-container, so one lookup exists four or five times and some of
+the copies are wrong. Patching the switch named in the report leaves the others to
+drift again. A datasource means the same thing wherever it sits; so does an
+action slot, and so does a text template. The fix that holds is one reader and one
+renderer, with the type set taken from `generated/metamodel` rather than from the
+copies.
+
+**Fixing one half is worse than the bug.** Where a describer has two defects at
+once — say, quoting *and* a missing property — shipping the quoting fix alone
+turns unparseable output into output that parses cleanly while silently dropping
+something. That is strictly worse: a wrong page that validates.
+
+**The round trip is the only sound test**, and it has to be measured against the
+model rather than the text. A describe-to-describe text diff matched exactly on a
+page that had lost its datasource. `mx check` on the source proves nothing,
+because the lossy model is valid. Counting failures before and after hid an
+equal-sized swap of which pages failed. What works: describe → exec → describe
+byte-identical, plus `mx check` on the *rebuilt* model.
+
+One consequence worth knowing: other code re-parses DESCRIBE output.
+`use building block … (datasource: …)` matches against the rendered form, so
+fixing a renderer can break a consumer that never reads the model. Grep for
+callers of the emitter before changing what it emits.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the per-construct
+  recipes; `grep -l describe *.jsonl` reaches this class
+- [[widget-type-object-drift]] — the neighbouring class where the *written* widget
+  is wrong rather than the described one
+- `.claude/skills/verify-in-runtime.md` — for the cases where neither the model
+  nor its description is the thing that is wrong
diff --git a/docs-wiki/bug-patterns/duplicate-resolver-drift.md b/docs-wiki/bug-patterns/duplicate-resolver-drift.md
new file mode 100644
index 0000000000..01cb279764
--- /dev/null
+++ b/docs-wiki/bug-patterns/duplicate-resolver-drift.md
@@ -0,0 +1,78 @@
+---
+title: One Question, Two Answers
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-executor.jsonl
+  - mdl/executor/validate_program.go
+  - mdl/backend/backend.go
+---
+
+> **Do not duplicate**: the individual resolvers and their fixes live in the
+> findings; the backend-abstraction rationale is canonical in ADR-0002 and
+> [[backend-abstraction]]. This page describes the shape.
+
+## What this is
+
+The same question — *does this name resolve? what entity is this? is this
+property set?* — gets answered in more than one place, the answers differ, and
+the disagreement surfaces as a defect in whichever consumer asked the losing
+copy. Roughly twenty-three executor findings are this shape, which makes it the
+most common *structural* cause in the area.
+
+It is worth naming separately from the symptoms it produces, because the
+symptoms look unrelated to each other. A forward reference accepted by `check`
+and rejected by `exec`, a guard that works on one engine and is inert on the
+other, a widget property read by one describer and not its twin — all the same
+defect wearing different clothes.
+
+## How it fits
+
+**Four places the duplication keeps appearing.**
+
+*`check` versus `exec`.* The two passes historically ran different validator sets
+over the same script, so `check` could reject what `exec` wrote and `exec` could
+write what `check` rejected. They also disagreed about *order*: reference
+validation collected every definition in the script up front, making forward
+references invisible, while `exec` resolves in statement order — so "Check
+passed!" and an exec failure on the same file, with earlier statements already
+written.
+
+*Legacy versus modelsdk.* A guard that walks stored BSON can be correct on one
+engine and a silent no-op on the other, because the document reaches it in a
+different shape. The failure is invisible from either side alone: the test suite
+is green, the guard reports nothing, and nothing distinguishes "no violations"
+from "never ran".
+
+*Write path versus read path.* A property written correctly and read back by
+nobody is the [[silent-property-drop]] class; a property read by one describer
+and not by its twin is this one. Several fixes here amount to deleting a copy —
+one reader, one renderer, one resolver — and taking the type set from
+`generated/metamodel` rather than from whichever copy the report named.
+
+*Per-doctype copies.* A behaviour implemented per document type drifts by
+construction. The folder clause is the clean example: every doctype's `FOLDER`
+handling had the same bug, and the report that named one of them read as a
+doctype-specific defect.
+
+**The tell is that the fix for the reported instance is obviously incomplete.**
+When a symptom's cause is "this switch was missing a case", the next question is
+how many other switches answer the same question — the answer has repeatedly been
+two, three or five. Patching the named one closes the report and leaves the class
+open, so the next instance arrives looking new.
+
+**The durable remedy is to remove the second answer**, not to synchronise the two.
+Route both callers through one function; take the enumeration from the metamodel
+rather than a hand-maintained copy; make the check and the exec guard *the same
+function* so they cannot diverge. Where a second implementation genuinely has to
+exist — the two engines — the protection is a test that asserts the *structure*,
+such as every exported validator being reachable from the one entry point, rather
+than a test per rule.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the individual
+  resolvers, and which copy was wrong
+- [[check-mxbuild-drift]] — the special case where one of the two answers is
+  mxbuild's
+- [[backend-abstraction]] — why two engines exist at all
diff --git a/docs-wiki/bug-patterns/engine-divergence.md b/docs-wiki/bug-patterns/engine-divergence.md
new file mode 100644
index 0000000000..567adbfa82
--- /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 0000000000..d0572cb465
--- /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/flow-graph-geometry.md b/docs-wiki/bug-patterns/flow-graph-geometry.md
new file mode 100644
index 0000000000..a207e99b1f
--- /dev/null
+++ b/docs-wiki/bug-patterns/flow-graph-geometry.md
@@ -0,0 +1,72 @@
+---
+title: Generated Microflow Geometry and Wiring
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-executor.jsonl
+  - mdl/executor/layout.go
+  - mdl/executor/cmd_microflows_builder_control.go
+---
+
+> **Do not duplicate**: the measurement formulas and per-construct fixes live in
+> the findings and in `mdl/executor/layout.go`. This page describes why the class
+> is easy to get wrong and hard to notice.
+
+## What this is
+
+A microflow is a **graph with coordinates**, and mxcli generates both. Ten
+executor findings are in this class, and they split into two halves that fail
+very differently: geometry that is merely ugly, and wiring that is invalid.
+
+Neither is caught by anything automatic. A too-wide loop box builds at 0 errors —
+it is a human looking at Studio Pro who notices. A missing outgoing flow *is* a
+build error, but only sometimes, because which flows are required depends on the
+shape around them.
+
+## How it fits
+
+**Geometry: the measurement runs before the thing it measures.** A container's
+size came from a pre-pass over the AST, executed before the body was built — so
+it was a function of statement *count*, not of the activities actually placed.
+Varying only the children's size changed nothing. The related arithmetic error is
+treating `HorizontalSpacing` as a gap when it is a centre-to-centre *pitch*: the
+builder centres each activity and advances by exactly that, so adding it on top
+of each width over-measures a run of n activities by `(n-1) × ActivityWidth`.
+
+**Do not guess the advance for a compound element.** For a run of simple
+activities the span is derivable. For an `if`, a split or a nested loop it comes
+out of merge geometry, and guessing *under*-sizes the box so children land
+outside it — worse than a box that is too wide. Those runs fall back to the
+conservative measure deliberately. The containment check is the honest test:
+every child of a looped activity must lie inside the container's box.
+
+**Wiring: the invalid shapes come from branches that do not merge.** A decision
+whose non-terminal branch falls off the end of a loop body, a `break` nested
+inside an `if`, a split followed by a statement — each is a place where a
+sequence flow has to be synthesised or deferred, and getting it wrong produces
+either a missing outgoing flow (`CE0079`, `CE0089`) or a dangling reference that
+takes `mx check` down during **load**. The valid Mendix representation of
+"nothing happened, go round again" is an explicit Continue event, not an absent
+flow.
+
+**A flow that looks redundant is often load-bearing.** Removing the empty-entity
+branch of a type split to stop DESCRIBE emitting a phantom `else` failed the
+build with `CE0089`: `(empty)` and the base type cover different things, and
+`else` cannot substitute for either. That wrong fix was implemented first and
+caught only because every shape was re-run through mxbuild — not because a unit
+test failed.
+
+**The read-side twin.** Several findings here pair with a describe defect,
+because the same structure has to be recovered from coordinates on the way back
+out: a loop body was rendered empty when an annotation sat to its left, and a
+describe → exec round trip moved a Studio Pro-authored start event. Verify a
+coordinate fix against the *whole* coordinate set — dump every point before and
+after and diff — or a change that pins one element while shifting another reads
+as success.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the formulas,
+  the CE codes and the controls
+- [[unloadable-model-writes]] — where a dangling sequence flow ends up
+- [[describe-round-trip-gaps]] — the read side of the same coordinates
diff --git a/docs-wiki/bug-patterns/integration-contract-drift.md b/docs-wiki/bug-patterns/integration-contract-drift.md
new file mode 100644
index 0000000000..7e0fbb7d93
--- /dev/null
+++ b/docs-wiki/bug-patterns/integration-contract-drift.md
@@ -0,0 +1,73 @@
+---
+title: Integration Documents and the Contract They Answer To
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-executor.jsonl
+  - mdl/executor/cmd_odata.go
+---
+
+> **Do not duplicate**: the per-property fixes, EDM mappings and mapping-element
+> shapes live in the findings; the MDL spellings live in the skills and
+> `MDL_QUICK_REFERENCE.md`. This page describes what makes the area distinctive.
+
+## What this is
+
+Published OData services, consumed REST and OData clients, and import/export
+mappings all describe a document whose correctness is defined **outside the
+model** — by a schema, a `$metadata` document, or the EDM type system. Roughly
+thirty executor findings live here, and they share a property that the rest of
+the executor does not: for much of it, **neither `mxcli check` nor mxbuild is an
+oracle**.
+
+## How it fits
+
+**The validation floor is lower than elsewhere.** A database connection's `type`
+string is passed straight through, and mxbuild does not validate it either — so a
+misspelled driver builds at 0 errors and simply does not connect. A mapping
+naming a schema source that does not exist passes both checks. When neither tool
+can tell you, the only remaining signal is a runtime failure, which is why
+several findings in this class were first seen as an exception in a running app
+rather than as an error anywhere.
+
+**A silent downgrade that returns HTTP 200 is the worst available outcome.** A
+consumed operation whose file body was written as literal text sent the string
+`$Doc`, got a 200 back, and every signal a person or an agent would check said
+success. Where mxcli cannot express a construct, refusing is strictly better than
+writing a different one.
+
+**Defaults are the recurring mechanism.** These documents carry many properties
+Studio Pro sets and MDL does not mention — a service's `ServiceName` as distinct
+from its document `Name`, a published attribute's `EdmType`, an association end's
+`IsMany`, a mapping element's key flag, an activity's range and cardinality
+pointers. Each omitted default is a build error or a runtime fault at some
+distance from the statement, and several were invisible on one engine because its
+`$Type` handling filled a gap the other left open.
+
+**The type system is a real mapping, not a passthrough.** Mendix publishes
+Integer as `Edm.Int64`; a name like `name` is not a system-managed attribute and
+must not be disambiguated as if it were; `PublishAssociations` selects a
+*representation* rather than a yes/no, and choosing "as an associated object id"
+imposes a key requirement. Getting these wrong produces `CE5016`-family errors
+across every exposed member at once, which reads as one large failure rather than
+one small mapping bug.
+
+**Modify paths lag create paths.** Re-running `create or modify` on a service
+left the exposed entity sets untouched; on a client it left the cached contract
+stale, so the tool kept reporting the old entity types after the backend had
+changed. Where a create path fetches or derives something, check whether the
+modify path does too — the asymmetry is easy to introduce and invisible until
+someone edits an existing document.
+
+**A rule that can be satisfied two ways will be satisfied the wrong way.** Two
+OData advisories shared one predicate, so answering either concern silenced both:
+adding an `HttpRequest` parameter for a key lookup also silenced the paging
+warning, with no paging implemented.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the individual
+  properties, EDM mappings and mapping-element shapes
+- [[silent-property-drop]] — the same "written, then absent" shape inside pages
+- `.claude/skills/verify-in-runtime.md` — for the failures that only appear when
+  the request is actually made
diff --git a/docs-wiki/bug-patterns/keyword-collisions.md b/docs-wiki/bug-patterns/keyword-collisions.md
new file mode 100644
index 0000000000..f6fb8dd0a0
--- /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 0000000000..13e97e0a77
--- /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 0000000000..b039549895
--- /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 0000000000..be6e765177
--- /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 0000000000..1c73469c4f
--- /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/platform-semantics-gaps.md b/docs-wiki/bug-patterns/platform-semantics-gaps.md
new file mode 100644
index 0000000000..19166709a3
--- /dev/null
+++ b/docs-wiki/bug-patterns/platform-semantics-gaps.md
@@ -0,0 +1,80 @@
+---
+title: Legal MDL, Illegal Mendix
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-executor.jsonl
+  - mdl/executor/validate_microflow_ce_gaps.go
+  - mdl/executor/validate_microflow_loop_scope.go
+---
+
+> **Do not duplicate**: each rule's predicate, CE number and measured fix live in
+> the findings and in `mdl/executor/validate_microflow*.go`; the MDL syntax lives
+> in `MDL_QUICK_REFERENCE.md`. This page describes why the category exists at all.
+
+## What this is
+
+MDL is deliberately SQL-shaped and permissive: a statement is well-formed if it
+parses. Mendix's *semantics* are considerably narrower, and the narrowing has no
+syntactic marker — the same statement is well-formed MDL and an illegal model.
+This is the largest remaining class of executor finding after the read/write
+ones, and it is not a defect in any single component. It is the seam between two
+languages.
+
+## How it fits
+
+**Four sub-languages, each with rules the MDL grammar cannot carry.**
+
+*Mendix expressions.* An association path is not a value — reaching an object
+over an association has to be materialised with a `retrieve` before it can be
+passed as an argument. Word operators must be lowercase; an uppercase `AND` in a
+condition builds as `CE0117`. `dateTime()` takes numeric constants, not
+variables. Each of these is a plain expression as far as MDL is concerned.
+
+*XPath.* Mendix's dialect reaches at most **one** hop off a variable; `= empty`
+tests attributes, not associations; there is no `id` member to constrain on. A
+constraint is a string to MDL, so nothing about its shape flags any of them.
+
+*Microflow variable model.* A loop iterator is scoped to the **whole microflow**,
+not to its loop — so two loops reusing `$R` is a duplicate name (`CE0111`), while
+a reference to `$item` *after* `end loop` is out of scope (`CE0108`). Both halves
+are counter-intuitive in opposite directions, and both read as ordinary code.
+`$x = call M.F()` is a variable *creation* each time, so the natural "try A else
+try B" fallback chain is also a duplicate.
+
+*Entity and document rules.* `not null` and `unique` are validation *rules* in
+Mendix's model, which is why they are rejected on a non-persistent entity
+(`CE0070`). A `declare` maps to a Create Variable activity, which may not produce
+a list. An `else` on a type split is the `(empty)` flow — a null object — not a
+default branch, so it never catches an unlisted subtype.
+
+**None of this is discoverable from the MDL side.** The author writes something
+that reads correctly, `mxcli check` has no rule for it, `exec` writes it, and the
+build names a CE code against a construct the author believed was ordinary. The
+gap is closed one rule at a time, and each rule is a claim about the *platform*
+that has to be measured against a real mxbuild rather than reasoned from the
+error text.
+
+**The rules divide by how confidently they can be enforced**, and that decides
+where they are wired. Rules that predict a *platform* constraint — the XPath and
+expression ones — are safe to enforce unconditionally, because the constraint
+does not depend on anything mxcli generates. Rules that predict what the
+*builder* emits are not: building one such change turned up four shapes where the
+AST reads "broken" and the build disagrees, two of them in mxcli's own shipped
+examples. Those stay off the unconditional write barrier and leave `--no-check`
+as an escape hatch.
+
+**Not every report in this class is a defect.** Several were measured and closed
+as correct behaviour: quoting an identifier escapes MDL's parser keywords and not
+Mendix's *platform*-reserved member names; `else` on a type split really is the
+empty flow; `create` really is non-idempotent, in the SQL sense the language is
+modelled on. What those cases needed was a better error message or a
+documentation fix, not a code change — and telling the two apart is what the
+measurement is for.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — each rule, its
+  CE number, and the mxbuild run that established it
+- [[check-mxbuild-drift]] — what happens when one of these rules is wrong
+- [[mdl-as-sql]] — why the language is permissive by design
diff --git a/docs-wiki/bug-patterns/rewrite-drops-unauthored-state.md b/docs-wiki/bug-patterns/rewrite-drops-unauthored-state.md
new file mode 100644
index 0000000000..0844658fe8
--- /dev/null
+++ b/docs-wiki/bug-patterns/rewrite-drops-unauthored-state.md
@@ -0,0 +1,67 @@
+---
+title: Rewrites That Drop What They Did Not Author
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-executor.jsonl
+  - docs/13-decisions/0005-semantic-model-interface-currency.md
+  - docs/13-decisions/0008-identity-and-idempotence.md
+---
+
+> **Do not duplicate**: the guard-don't-drop decision is canonical in ADR-0005,
+> identity and idempotence in ADR-0008 and CLAUDE.md, and the per-document
+> recipes in the findings. This page describes the recurring failure.
+
+## What this is
+
+`CREATE OR REPLACE` and `CREATE OR MODIFY` rebuild a document from a statement
+that describes only part of it. Everything the statement does not mention — a
+queued call binding, a toolbox entry, translated captions, an index, a folder, an
+attribute's identity — has to be carried across, and each property that is not is
+lost silently. Thirteen executor findings are this, and they are unusually
+expensive because the loss is invisible at every checkpoint: the run reports
+success, `mx check` reports 0 errors, and the model is valid. It is simply
+smaller than it was.
+
+## How it fits
+
+**A model is bigger than its MDL.** Mendix documents carry state MDL has no
+spelling for, and a rebuild constructs the document from what the statement says.
+Anything else defaults. That is why the safe posture is **guard, don't drop**: a
+rewrite that would discard a construct mxcli cannot express should refuse the
+statement rather than quietly produce a smaller document.
+
+**The most expensive variant is identity, not content.** Re-minting an
+attribute's ID on every rewrite produced a document that looked identical and
+made the runtime's database synchroniser treat every column as new — rows
+survived, values gone. Nothing in the model was wrong. This is the same concern
+as `GUID` preservation and the reason `canon.Reconcile` exists; a codec that
+mints fresh identities on rebuild is a data-loss bug wearing a clean `mx check`.
+
+**Delete-then-create defeats every protection.** One replace path removed the
+stored document before writing the new one, so nothing was left for identity
+preservation or elision to reconcile against, and translated captions in every
+language reset to the source language. Whatever carrying mechanism exists, a path
+that deletes first opts out of it.
+
+**Stamping every field on both paths is the usual mechanism.** Where a create and
+an update share a field-application helper, the update overwrites settings the
+user changed by hand with values derived from somewhere else. A field set on the
+`OR MODIFY` path is also not evidence it is set on the `CREATE` path — the two
+construct the element separately, so both need checking, by grepping the struct
+literal rather than the field name.
+
+**Partial statements are the honest hazard.** `create or modify entity` with a
+subset of attributes drops the rest — 36 down to 2 in one report — which is
+arguably what "modify to this shape" means. The remedy there was not refusal but
+telling the truth loudly: diff the members, print what is being dropped, and
+point at the incremental spelling. Where the statement *is* a full replace, the
+user asked for it; where the loss is of something MDL cannot express at all, they
+did not.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the individual
+  properties and the carrying mechanism each needed
+- [[element-identity]] — `$ID` versus `GUID` versus `StableId`
+- [[mpr-read-write]] — where the write choke points are, and what elision assumes
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 0000000000..98e1b80fe9
--- /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/silent-property-drop.md b/docs-wiki/bug-patterns/silent-property-drop.md
new file mode 100644
index 0000000000..c173f19b72
--- /dev/null
+++ b/docs-wiki/bug-patterns/silent-property-drop.md
@@ -0,0 +1,92 @@
+---
+title: Properties That Parse but Never Persist
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-executor.jsonl
+  - mdl/executor/validate_widgets.go
+  - modelsdk/widgets/definitions/
+---
+
+> **Do not duplicate**: the per-widget property tables live in
+> `sdk/widgets/templates/` and the generated `.def.json`; the individual aliases
+> and rule IDs live in the findings. This page describes why the class exists.
+
+## What this is
+
+An MDL property is accepted, `mxcli check` passes, `exec` reports success,
+`mx check` reports 0 errors — and the value never reached the model. The widget
+renders, and does nothing. Twenty-two of the executor findings are this.
+
+The outcome is indistinguishable from a typo, and that is the core of the
+problem: `Contnet:` and a real-but-unrouted `DynamicCellClass:` failed in
+exactly the same silent way, so nothing in the pipeline could tell the author
+which one they had written.
+
+## How it fits
+
+**Parsing is not persisting.** A widget property crosses several independent
+hops — grammar, AST, the executor's property switch, the widget definition's
+mapping, the builder, the codec — and falling off any of them produces the same
+nothing. The grammar cannot help: `Key: value` is generic by design, because the
+parser has no idea which keys a given widget routes.
+
+**The permissive allow-list is the usual mechanism.** Widget property names were
+deliberately not rejected, so that `Label:` and `Class:` on an unfamiliar widget
+would not produce false errors. That choice quietly converts every *unrouted*
+name into a silent drop, and the cost stays invisible until a build error names a
+property the author believed they had set.
+
+**Three sources of truth compete, and the wrong one usually wins.** Pluggable
+widget mappings are generated into `.def.json` from the `.mpk`, but a
+hand-written built-in definition beats the generator — so fixing the generator
+alone changes nothing for the widgets that have one. And the generated defs are
+version-stamped and cached per project: a code-only alias addition is invisible
+until `WidgetDefGeneratorVersion` is bumped and the stale defs regenerate.
+
+**Where a vocabulary can be derived, derive it.** For pluggable widgets the
+*known but unmapped* set falls out of two artifacts already present: every
+property key the `.mpk` declares, minus everything the generated definition maps.
+That needs no per-widget knowledge and cannot go stale, and it turns one silent
+outcome into a three-way answer — an unrecognised key gets a "did you mean"
+warning, a recognised-but-unmapped key gets "this will be dropped, set it in
+Studio Pro", and a mapped key stays quiet.
+
+**Where it cannot, enumerate generously and guard the list.** Built-in widgets
+have no `.mpk` to subtract from, so their vocabulary is a hand-maintained union —
+grammar keyword properties, every key the builders consume, and every property
+`describe page` can emit. It is deliberately a union across *all* widget types
+rather than per-type, because a per-type list would produce false warnings, and
+the describe half is included so a describe → create round trip never warns about
+its own output. A manually maintained list is a maintenance risk, which is why it
+carries a drift test rather than a promise.
+
+**Warn; do not reject.** Neither the pluggable nor the built-in vocabulary can be
+proven complete, so an error would trade silent drops for false refusals. The
+same reasoning appears wherever mxcli names a *specific* alternative — those
+lists are deliberately explicit rather than inferred, because inferring them
+would mean reimplementing the engine's dispatch and getting it wrong in the other
+direction.
+
+**Wire the read at the same time as the write.** DESCRIBE is how a dropped
+property gets *found*, so a write fix without its describe counterpart leaves the
+model holding a value that the tool reports as absent — the same lossy round trip
+wearing the right answer. Several findings here are the follow-up half of a fix
+that shipped write-only.
+
+**A half-wired feature is worse than a missing one.** When the grammar already
+accepts a form, scripts using it look correct and produce models without it.
+Before assuming a spelling works, follow the whole chain: AST → model → both
+writers → both readers → describe.
+
+**And a check wired into nothing is invisible.** `exec` used to apply scripts
+that `check` rejected outright; a validator that no pass calls reports no
+violations and reads exactly like a clean project.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the individual
+  aliases, rule IDs and widget-specific spellings
+- [[describe-round-trip-gaps]] — the read-side half of the same failure
+- [[widget-type-object-drift]] — when the property *is* written and the widget
+  definition is what disagrees
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 0000000000..fc96124843
--- /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 0000000000..fa4f186472
--- /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/unloadable-model-writes.md b/docs-wiki/bug-patterns/unloadable-model-writes.md
new file mode 100644
index 0000000000..be793e7122
--- /dev/null
+++ b/docs-wiki/bug-patterns/unloadable-model-writes.md
@@ -0,0 +1,89 @@
+---
+title: Writes That Make the Project Unloadable
+category: bug-pattern
+last-synced: ced830e0
+sources:
+  - .claude/skills/fix-issue/findings/mdl-executor.jsonl
+  - mdl/executor/validate_workflow.go
+  - mdl/executor/validate_association_module.go
+---
+
+> **Do not duplicate**: the per-construct refusals and their CE numbers live in
+> the findings; the storage-name and overlay rules are canonical in CLAUDE.md.
+> This page describes the failure class and why it is graded differently from a
+> build error.
+
+## What this is
+
+A Mendix model can be wrong in two ways that look nothing alike. **Validation**
+errors — the `CE####` codes — are found by mxbuild in a model it has already
+loaded successfully: one document is wrong, the rest of the project is fine, and
+the message names the document. **Load** errors happen before validation starts.
+The `.mpr` is structurally malformed, `mx check` dies with a .NET exception and
+no error code, no document is named, and **Studio Pro will not open the project
+at all**.
+
+Twelve of the executor findings are in the second category. They are the most
+expensive defects mxcli has produced, because the blast radius is the whole
+project rather than one page, and because the diagnostic is a stack trace.
+
+## How it fits
+
+**The recurring cause is a reference whose *shape* is wrong**, not a reference
+that points at the wrong thing. Mendix reconstructs each stored property into a
+typed identifier as it loads, and a value that cannot be parsed into that type
+takes the loader down. The shapes seen so far: a one-qualifier member name
+written where an attribute reference is expected (an attribute is bare or
+`Module.Entity.Attribute`, never `Module.Name`); an unqualified entity name in a
+generalization; a literal string where the property is a `ConstantIdentifier`;
+an empty `DestinationEntity`; an index column pointing at a GUID that no longer
+exists; a sequence flow dangling from a `break`; an association whose `ParentPointer`
+addresses an element in another unit; a child appended to a list whose parent
+type has no constructor taking that parent.
+
+**`mx check` passing is not evidence that the project opens.** mxbuild's
+deserializer tolerates properties it does not recognise; Studio Pro resolves
+every stored property against its type's property list and throws when there is
+no match. A settings write with three wrong storage names built at 0 errors and
+made the unit unopenable. Where a write touches preserved BSON, only a real
+Studio Pro reference document settles the shape — which is the reasoning behind
+CLAUDE.md's overlay rules.
+
+**The remedy is almost always to refuse, not to write something else.** In each
+of these the tempting alternative turned out to be unavailable or harmful:
+minting a Constant from a literal password would bake a secret into the model as
+a design-time default; a cross-module association has no storage form at all
+(neither `Association` nor `CrossAssociation` can express a by-name *parent*);
+the correct container for a floating workflow annotation is not determinable from
+the gen model. Refusing costs the user one statement; writing costs them the
+project.
+
+**Refuse in both passes.** A check-time rule does not help a script that never
+ran `check`, and `exec` is reachable directly — the lesson that has now been
+relearned enough times to be a convention. Both call the same function, so they
+cannot drift.
+
+**Grade the two failure modes separately when a statement can produce either.**
+A qualified-but-missing name is recoverable: the project loads and the build
+reports `CE1613`. The *unqualified* form of the same name makes the `.mpr`
+unopenable. The first needs a project to detect and belongs in the reference
+check; the second is a static property of the statement and can be refused with
+no project at all — which is also what makes it catchable by a `.fail.mdl`
+fixture in CI.
+
+**Diagnosis without Studio Pro.** The .NET stack names a setter, and that
+setter's property is the lead — `EntityRefStep.set_AssociationId`,
+`MprProperty.cs`, `ResolvePostponedProperties`. From there, dump the stored unit
+and compare the property against a document Studio Pro wrote. Verifying a
+storage-name hypothesis by swapping *only* the name is the cheap control: if the
+error is byte-identical afterwards, the bug is somewhere else.
+
+## See also
+
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the individual
+  refusals, their rule IDs and their reference documents
+- [[element-identity]] — why a pointer's target and a GUID are different questions
+- [[association-pointers]] — the `ParentPointer` / `ChildPointer` inversion behind
+  the cross-module association case
+- `.claude/skills/debug-bson.md` — the workflow for comparing a written document
+  against a Studio Pro reference
diff --git a/docs-wiki/bug-patterns/visitor-wiring-gaps.md b/docs-wiki/bug-patterns/visitor-wiring-gaps.md
index c9f337d0dd..3b65149ac8 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.md
+  - .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.md` 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 symptom table](../../.claude/skills/fix-issue.md) — 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/docs-wiki/bug-patterns/widget-type-object-drift.md b/docs-wiki/bug-patterns/widget-type-object-drift.md
index 307e0f57b8..28332c3e0d 100644
--- a/docs-wiki/bug-patterns/widget-type-object-drift.md
+++ b/docs-wiki/bug-patterns/widget-type-object-drift.md
@@ -3,13 +3,13 @@ title: Widget Type / Object Drift (CE0463)
 category: bug-pattern
 last-synced: 4e185f73
 sources:
-  - .claude/skills/fix-issue.md
+  - .claude/skills/fix-issue/findings/
   - .claude/skills/debug-bson.md
   - sdk/widgets/templates/README.md
   - sdk/mpr/writer_widgets.go
 ---
 
-> **Do not duplicate**: the specific CE0463 fix recipes live in the `.claude/skills/fix-issue.md` symptom rows, the diff workflow lives in `.claude/skills/debug-bson.md`, and the template-extraction procedure lives in `sdk/widgets/templates/README.md`. This page describes the pattern only.
+> **Do not duplicate**: the specific CE0463 fix recipes live in the `fix-issue/findings/*.jsonl` records, the diff workflow lives in `.claude/skills/debug-bson.md`, and the template-extraction procedure lives in `sdk/widgets/templates/README.md`. This page describes the pattern only.
 
 ## What this is
 
@@ -25,6 +25,6 @@ A key trap: `mx check` is tolerant and passes anyway — only `mx diff` and Stud
 
 ## See also
 
-- [fix-issue symptom table](../../.claude/skills/fix-issue.md) — the per-instance CE0463/CE3637 fix recipes
+- [fix-issue findings](../../.claude/skills/fix-issue/findings/) — the per-instance CE0463/CE3637 fix recipes
 - [[architecture/widget-engine]] — how `.def.json` definitions and templates produce widget BSON
 - [[models/version-gating]] — why a field can be valid in one Mendix minor and drift in another
diff --git a/docs-wiki/models/element-identity.md b/docs-wiki/models/element-identity.md
index 77df4c6cd0..334adae160 100644
--- a/docs-wiki/models/element-identity.md
+++ b/docs-wiki/models/element-identity.md
@@ -6,7 +6,7 @@ sources:
   - docs/13-decisions/0008-identity-and-idempotence.md
   - modelsdk/canon/identity.go
   - CLAUDE.md
-  - .claude/skills/fix-issue.md
+  - .claude/skills/fix-issue/findings/
 ---
 
 > **Do not duplicate**: the rules an implementer must follow (CLAUDE.md is canonical), the decision and its measurements (see [ADR-0008](../../docs/13-decisions/0008-identity-and-idempotence.md)), the dangling-reference fix recipe (symptom table in `.claude/skills/fix-issue.md`), or the identity-field table (read `modelsdk/canon/identity.go`).
diff --git a/docs/01-project/MDL_QUICK_REFERENCE.md b/docs/01-project/MDL_QUICK_REFERENCE.md
index ce9b8a2b49..8fcdef36ae 100644
--- a/docs/01-project/MDL_QUICK_REFERENCE.md
+++ b/docs/01-project/MDL_QUICK_REFERENCE.md
@@ -509,6 +509,9 @@ it is for pages.
 | Retrieve (DB) | `retrieve $Var from Module.Entity [where condition];` | Database XPath retrieve |
 | Retrieve (Assoc) | `retrieve $list from $Parent/Module.AssocName;` | Retrieve by association |
 | Add to list | `add expression to $list;` | Also accepts existing `add $item to $list;` form |
+| Aggregate a list | `$Total = sum($list.Attr);` / `$Total = sum($list, expression);` | `count` (list only), `sum`, `average`, `minimum`, `maximum` — attribute or expression over `$currentObject` |
+| All / any | `$AllMatch = all($list, boolean-expression);` | And `any(...)`. No seed, always Boolean — Mendix stores a Boolean return type for both |
+| Reduce a list | `$Folded = reduce($list, expression, initial: value, returns: Type);` | `$currentResult` is the accumulator. `initial` and `returns` are **required** — Mendix stores both and neither is inferable, so MDL will not guess (#1004) |
 | Call microflow | `$Result = call microflow Module.Name (Param = $value);` | A Mendix **expression** cannot call anything — `declare $r Boolean = Module.Name(...)` is CE0117 (MDL066) |
 | Call a rule | `if Module.SomeRule (Param = $value) then ... end if;` | A decision is the **only** place a rule can be evaluated; there is no call activity for one. The name must resolve to a rule — a microflow there is CE0117 |
 | Call microflow on a queue | `call microflow Module.Name (Param = $value) in queue Module.Queue;` | Background execution; the queue must exist (CE1613) |
@@ -906,6 +909,14 @@ Respond in {{Language}}.$$,
 | Create collection | `create image collection Module.Name [folder 'path'] [export level 'Hidden'\|'Public'] [comment 'text'] [(image Name from file 'path', ...)];` | With or without images |
 | Create or modify | `create or modify image collection Module.Name [...];` | Preserves UUID — preferred for AI agents |
 | Drop collection | `drop image collection Module.Name;` | Removes collection and all embedded images |
+| Show an image on a page | `image imgLogo (Image: 'Module.Collection.ImageName');` | Three-part name, like an icon reference. `describe image collection` lists the names |
+
+An `image` widget's default source **is** an image collection entry, so a bare
+`image imgLogo (...)` with no `Image:` builds into a model mxbuild refuses ("No
+image selected."); `mxcli check` reports it as MDL-WIDGET22. A name that does not
+resolve is reported by `mxcli check --references` rather than by the build
+(CE1613). The other two sources are `ImageType: imageUrl, ImageUrl: '…'` and
+`ImageType: icon`.
 
 ## Icon Collections (read-only)
 
diff --git a/mdl-examples/bug-tests/1002-filter-bad-iterator.fail.mdl b/mdl-examples/bug-tests/1002-filter-bad-iterator.fail.mdl
new file mode 100644
index 0000000000..4fbdce5765
--- /dev/null
+++ b/mdl-examples/bug-tests/1002-filter-bad-iterator.fail.mdl
@@ -0,0 +1,42 @@
+-- Issue #1002 (refusals): a FILTER/FIND predicate that mxcli can prove wrong.
+--
+-- `mxcli check mdl-examples/bug-tests/1002-filter-bad-iterator.fail.mdl`
+-- reports MDL-LISTOP01 on the first microflow. Before the fix both statements
+-- passed check and produced a model mxbuild rejected — CE0109 for the unbound
+-- iterator, CE0117 for the unknown attribute.
+
+create or modify module FilterProbe;
+
+create or modify persistent entity FilterProbe.Order (
+  Status: String(50),
+  Qty: Integer
+);
+
+-- MDL-LISTOP01: Mendix binds the item to $currentObject; '$item' is undefined.
+create or replace microflow FilterProbe.BadIterator () returns Boolean
+begin
+  retrieve $L from FilterProbe.Order;
+  $R = FILTER($L, $item/Qty > 0);
+  return true;
+end;
+
+-- Refused by the executor (needs -p to resolve the entity): 'Nonexistent' is
+-- not a member of FilterProbe.Order.
+create or replace microflow FilterProbe.UnknownAttribute () returns Boolean
+begin
+  retrieve $L from FilterProbe.Order;
+  $R = FILTER($L, Nonexistent > 0);
+  return true;
+end;
+
+-- CONTROL: '$item' is fine when it IS in scope — the enclosing loop's iterator,
+-- which is how CLAUDE.md's O(N) lookup idiom is written. This must NOT be flagged.
+create or replace microflow FilterProbe.LoopIteratorIsFine ($Others: List of FilterProbe.Order) returns Boolean
+begin
+  retrieve $L from FilterProbe.Order;
+  loop $item in $L
+  begin
+    $Match = FIND($Others, Status = $item/Status);
+  end loop;
+  return true;
+end;
diff --git a/mdl-examples/bug-tests/1002-filter-find-bare-attribute.mdl b/mdl-examples/bug-tests/1002-filter-find-bare-attribute.mdl
new file mode 100644
index 0000000000..498713aae0
--- /dev/null
+++ b/mdl-examples/bug-tests/1002-filter-find-bare-attribute.mdl
@@ -0,0 +1,135 @@
+-- ============================================================================
+-- Issue #1002: a bare attribute in a FILTER/FIND predicate failed CE0117
+-- ============================================================================
+--
+-- Symptom (before fix):
+--   `filter($L, Amount > 0)` was stored as `Microflows$FilterByExpression` with
+--   the authored text verbatim. Mendix evaluates that expression once per item
+--   with the item bound to `$currentObject`, where a bare attribute name is not
+--   a valid expression — so mxbuild reported CE0117 while `mxcli check` passed.
+--
+-- This is the unfinished half of bug #343. That fix rerouted the `=` form to
+-- `Microflows$Filter` (filter BY ATTRIBUTE), which takes a member name rather
+-- than an expression. Every other predicate still fell through to the broken
+-- expression shape, so the split was on the OPERATOR and invisible to the
+-- author: `Status = 'Pending'` built and `Status != 'Pending'` did not.
+--
+-- Not a Mendix version change, despite the issue's diagnosis: the same probe
+-- produces the identical 7 errors on mxbuild 11.11.0 and 11.13.0.
+--
+-- After fix:
+--   A bare name that resolves to a member of the list's element entity is
+--   rewritten to `$currentObject/<member>`. One that does not resolve is
+--   refused by the executor (see 1002-filter-bare-unknown-attribute.fail.mdl).
+--
+-- Every microflow below builds at 0 errors.
+--
+--   mxcli exec mdl-examples/bug-tests/1002-filter-find-bare-attribute.mdl -p app.mpr
+--   mx check app.mpr      # 0 errors
+
+create or modify module FilterProbe;
+
+create or modify persistent entity FilterProbe.Order (
+  Status: String(50),
+  Amount: Decimal,
+  Qty: Integer
+);
+
+-- === CONTROLS: the '=' form, which bug #343 reroutes to filter-by-attribute. ===
+-- These built before the fix too and must keep building — a regression here
+-- means the #343 reroute was lost.
+create or replace microflow FilterProbe.A_BareEqualsReroute () returns Boolean
+begin
+  retrieve $L from FilterProbe.Order;
+  $R = FILTER($L, Status = 'Pending');
+  return true;
+end;
+
+create or replace microflow FilterProbe.B_FindBareEqualsReroute () returns Boolean
+begin
+  retrieve $L from FilterProbe.Order;
+  $R = FIND($L, Status = 'Pending');
+  return true;
+end;
+
+-- === THE BUG: a bare attribute with any other operator. CE0117 before the fix. ===
+create or replace microflow FilterProbe.C_BareDecimalGreater () returns Boolean
+begin
+  retrieve $L from FilterProbe.Order;
+  $R = FILTER($L, Amount > 0);
+  return true;
+end;
+
+create or replace microflow FilterProbe.D_BareIntegerGreater () returns Boolean
+begin
+  retrieve $L from FilterProbe.Order;
+  $R = FILTER($L, Qty > 0);
+  return true;
+end;
+
+create or replace microflow FilterProbe.E_BareStringNotEquals () returns Boolean
+begin
+  retrieve $L from FilterProbe.Order;
+  $R = FILTER($L, Status != 'Pending');
+  return true;
+end;
+
+create or replace microflow FilterProbe.F_FindBareGreater () returns Boolean
+begin
+  retrieve $L from FilterProbe.Order;
+  $R = FIND($L, Qty > 0);
+  return true;
+end;
+
+-- A compound predicate: several bare names, and a string literal that must NOT
+-- be rewritten even though it spells an attribute name.
+create or replace microflow FilterProbe.G_CompoundPredicate () returns Boolean
+begin
+  retrieve $L from FilterProbe.Order;
+  $R = FILTER($L, Qty > 0 and Status != 'Amount');
+  return true;
+end;
+
+-- === The explicit form keeps working unchanged. ===
+create or replace microflow FilterProbe.H_CurrentObjectGreater () returns Boolean
+begin
+  retrieve $L from FilterProbe.Order;
+  $R = FILTER($L, $currentObject/Amount > 0);
+  return true;
+end;
+
+create or replace microflow FilterProbe.I_FindCurrentObject () returns Boolean
+begin
+  retrieve $L from FilterProbe.Order;
+  $R = FIND($L, $currentObject/Amount > 0);
+  return true;
+end;
+
+-- === SORT is a different mechanism (SortItem, not an expression), so a bare
+-- === attribute is correct there and must be left alone.
+create or replace microflow FilterProbe.J_SortBare () returns Boolean
+begin
+  retrieve $L from FilterProbe.Order;
+  $R = SORT($L, Amount DESC);
+  return true;
+end;
+
+-- === The element entity is resolved through a parameter and through a call. ===
+create or replace microflow FilterProbe.K_ParamListBare ($Orders: List of FilterProbe.Order) returns Boolean
+begin
+  $R = FILTER($Orders, Qty > 0);
+  return true;
+end;
+
+create or replace microflow FilterProbe.GetOrders () returns List of FilterProbe.Order
+begin
+  retrieve $L from FilterProbe.Order;
+  return $L;
+end;
+
+create or replace microflow FilterProbe.L_CallListBare () returns Boolean
+begin
+  $Orders = CALL MICROFLOW FilterProbe.GetOrders ();
+  $R = FILTER($Orders, Qty > 0);
+  return true;
+end;
diff --git a/mdl-examples/bug-tests/1004-aggregate-reduce-all-any.mdl b/mdl-examples/bug-tests/1004-aggregate-reduce-all-any.mdl
new file mode 100644
index 0000000000..40101cdfd5
--- /dev/null
+++ b/mdl-examples/bug-tests/1004-aggregate-reduce-all-any.mdl
@@ -0,0 +1,93 @@
+-- ============================================================================
+-- Bug #1004: DESCRIBE emitted `reduce(...)`, which mxcli's own checker rejected
+-- ============================================================================
+--
+-- Symptom (before fix):
+--   Describing a microflow containing Mendix's Reduce aggregate produced
+--
+--     $Reduce = reduce($ContractList, $currentResult + $currentObject/Number);
+--
+--   and running that same line back through mxcli failed:
+--
+--     ✗ set 'Reduce' calls 'reduce()', which is not a Mendix expression
+--       function — the build fails CE0117 "Error(s) in expression" [MDL044]
+--
+--   Note "set": the parser did not reject `reduce(...)`, it read the line as a
+--   plain Change Variable whose value happened to be a function call. MDL044
+--   then correctly observed that Mendix has no `reduce()` expression function.
+--
+-- Root cause:
+--   DESCRIBE rendered an aggregate by lowercasing whatever Mendix had stored,
+--   which assumed every value of the AggregateFunction enumeration was also an
+--   MDL keyword. Mendix has eight; the grammar had five. Reduce, All and Any
+--   all described as MDL the parser could not read back.
+--
+--   Underneath that was a quieter defect the grammar alone would not have
+--   fixed: Mendix stores a Reduce's seed and result type in
+--   ReduceInitialValueExpression and ReduceReturnDataType, and the semantic
+--   model had no field for either — so mxcli read them as nothing and would
+--   have written them back as nothing, deleting the fold from a microflow that
+--   still passed `mx check`.
+--
+-- Measured (ako/TestApp, Mendix 11.14, Microflows.MicroflowReduce):
+--   Studio Pro writes BOTH properties on every AggregateAction, not only on
+--   Reduce — its All and Any activities each carry an empty initial value and a
+--   Boolean return type, even though Mendix's own reference guide says a return
+--   type is "not applicable" to them. Attribute is likewise stored as "" when
+--   unused. After the fix all three activities re-serialize byte-identically to
+--   what Studio Pro wrote.
+--
+-- After fix:
+--   reduce/all/any are aggregate statements. REDUCE names its seed and result
+--   type because Mendix requires both and neither can be inferred; ALL and ANY
+--   take neither, since they never accumulate and always fold to Boolean.
+--
+-- Usage:
+--   mxcli exec mdl-examples/bug-tests/1004-aggregate-reduce-all-any.mdl -p app.mpr
+--   mxcli -p app.mpr -c "describe microflow BugTest1004.MF_Aggregates"
+--
+--   The describe output must be a fixpoint under describe → exec → describe.
+--   The script is re-runnable, so a second `exec` against an in-sync project
+--   must report "Unchanged microflow" (ADR-0008) rather than rewriting it.
+-- ============================================================================
+
+create module BugTest1004;
+
+create or modify entity BugTest1004.Order (
+  Amount : decimal,
+  Paid   : boolean
+);
+/
+
+create or modify microflow BugTest1004.MF_Aggregates (
+  $Orders: list of BugTest1004.Order
+)
+begin
+  -- The five functions that always round-tripped, as the control: if these
+  -- break, the change broke aggregates generally rather than the new three.
+  $Count = count($Orders);
+  $Total = sum($Orders.Amount);
+  $Avg = average($Orders.Amount);
+  $Min = minimum($Orders.Amount);
+  $Max = maximum($Orders.Amount);
+
+  -- Boolean predicates over every item. No seed, always Boolean.
+  $AllPaid = all($Orders, $currentObject/Paid);
+  $AnyUnpaid = any($Orders, not($currentObject/Paid));
+
+  -- The fold. $currentResult is the accumulator; both extra inputs are
+  -- required, and dropping either is the silent half of this bug.
+  $Discounted = reduce(
+    $Orders,
+    $currentResult + $currentObject/Amount * 0.9,
+    initial: 0,
+    returns: Decimal
+  );
+
+  -- An expression-form aggregate, to pin that the older functions still take
+  -- one and did not get folded into the reduce path.
+  $WithVat = sum($Orders, $currentObject/Amount * 1.21);
+
+  return;
+end;
+/
diff --git a/mdl-examples/bug-tests/f1-80-xpath-operator-case.mdl b/mdl-examples/bug-tests/f1-80-xpath-operator-case.mdl
new file mode 100644
index 0000000000..301c92c168
--- /dev/null
+++ b/mdl-examples/bug-tests/f1-80-xpath-operator-case.mdl
@@ -0,0 +1,87 @@
+-- mxcli-formula1 FINDINGS §80 — uppercase AND stored verbatim into XPath.
+--
+--   ERROR at Formula1Backend, Microflow 'ZZ_AndProbe2',
+--     Retrieve object(s) activity 'Retrieve list of LiveForecast from database':
+--     Error(s) in XPath constraint.                                  (CE0161)
+--     BUILD FAILED
+--
+-- XPath 1.0 spells its operators in lower case only; MDL's lexer accepts any
+-- case (`AND: A N D;`). mxcli lowercased the operator on one of its two
+-- rendering paths and not the other, so the casing survived only in some
+-- statements — which is what made the bug look like it was about casing alone.
+--
+-- The finding is careful about that, and it is the reason this file has the
+-- shape it does. An earlier note blamed the casing, and its literal-only
+-- reproducer BUILT CLEANLY:
+--
+--   WHERE SessionKey = '1' AND AtLap = 2                  -> stored `and`, builds
+--   WHERE SessionKey = $N/SessionKey AND AtLap = $N/AtLap -> stored `AND`, CE0161
+--   ...the same with lowercase `and`                      -> builds
+--
+-- The trigger is a VARIABLE reference. `buildRetrieveWhereExpression` freezes
+-- the raw source whenever the clause contains a `/`, and every variable path
+-- has one; the frozen text is then handed to the writer verbatim.
+--
+--   mxcli exec mdl-examples/bug-tests/f1-80-xpath-operator-case.mdl -p app.mpr
+--   scripts/mx-check.sh -p app.mpr --version 11.13.0        # no CE0161
+--
+-- Expect every constraint below to be stored with a lower-case `and`.
+
+create module AndCase;
+
+create persistent entity AndCase.Forecast ( SessionKey: String(50), AtLap: Integer );
+
+-- THE REPORTED CASE: variable references either side of an uppercase AND.
+create or modify microflow AndCase.MF_VarAnd ( $Newest: AndCase.Forecast )
+begin
+  @position(130, 200)
+  retrieve $L from AndCase.Forecast
+    where SessionKey = $Newest/SessionKey AND AtLap = $Newest/AtLap;
+end;
+
+-- CONTROL 1 — literals only. This ALWAYS built, because the parse-tree renderer
+-- lowercases the operator. Without it the file would not show that the two
+-- paths used to disagree.
+create or modify microflow AndCase.MF_LiteralAnd ()
+begin
+  @position(130, 200)
+  retrieve $L from AndCase.Forecast where SessionKey = '1' AND AtLap = 2;
+end;
+
+-- CONTROL 2 — the lowercase spelling the reporting project used as a
+-- workaround. It built before and must still build.
+create or modify microflow AndCase.MF_VarAndLower ( $Newest: AndCase.Forecast )
+begin
+  @position(130, 200)
+  retrieve $L from AndCase.Forecast
+    where SessionKey = $Newest/SessionKey and AtLap = $Newest/AtLap;
+end;
+
+-- OR and NOT are lexed case-insensitively too, and are the same XPath keywords.
+create or modify microflow AndCase.MF_OrNot ( $Newest: AndCase.Forecast )
+begin
+  @position(130, 200)
+  retrieve $L from AndCase.Forecast
+    where SessionKey = $Newest/SessionKey OR NOT(AtLap = $Newest/AtLap);
+end;
+
+-- A STRING LITERAL is data, not syntax: the operator inside it must survive
+-- untouched, or the constraint quietly matches different rows — worse than the
+-- build error being fixed. Only the operator OUTSIDE the quotes is normalised.
+create or modify microflow AndCase.MF_LiteralText ( $Newest: AndCase.Forecast )
+begin
+  @position(130, 200)
+  retrieve $L from AndCase.Forecast
+    where SessionKey = 'A AND B' AND AtLap = $Newest/AtLap;
+end;
+
+-- The other two constraint writers go through the same choke point, and were
+-- broken in the same way (measured: both stored `AND` before the fix).
+create module role AndCase.User;
+GRANT AndCase.User ON AndCase.Forecast (READ *) WHERE '[AtLap = 1 AND SessionKey = ''x'']';
+
+create or modify page AndCase.P ( Title: 'p', Layout: Atlas_Core.Atlas_Default ) {
+  datagrid dg (DataSource: DATABASE AndCase.Forecast where '[AtLap = 1 AND SessionKey = ''x'']') {
+    column c (Attribute: SessionKey)
+  }
+};
diff --git a/mdl-examples/bug-tests/mapping-259-resolve-schema-sources.mdl b/mdl-examples/bug-tests/mapping-259-resolve-schema-sources.mdl
index 908f1080e8..dbb568b377 100644
--- a/mdl-examples/bug-tests/mapping-259-resolve-schema-sources.mdl
+++ b/mdl-examples/bug-tests/mapping-259-resolve-schema-sources.mdl
@@ -39,16 +39,27 @@
 --   tests instead (mdl/executor/mapping_source_resolution_test.go and
 --   sdk/mpr/reader_xmlschema_test.go).
 --
---   How the document shape was established, since no reference existed: NONE of
---   the nine demo apps in the corpus contains an XML schema. A synthetic
---   XmlSchemas$XmlSchema unit was planted instead, and mxbuild 11.13.0 asked
---   whether it was the thing it resolves against — the mapping's reference went
---   from CE1613 "The selected XML schema 'XGap.Probe_Xsd' no longer exists" to
---   CE0292 "Please import an XSD file." at XML schema 'XGap.Probe_Xsd', which is
---   mxbuild naming, by module and name, the document it had just found.
+--   How the document shape was established. First by planting a synthetic
+--   XmlSchemas$XmlSchema unit and letting mxbuild 11.13.0 identify it: the
+--   mapping's reference went from CE1613 "The selected XML schema
+--   'XGap.Probe_Xsd' no longer exists" to CE0292 "Please import an XSD file." at
+--   XML schema 'XGap.Probe_Xsd' — mxbuild naming, by module and name, the
+--   document it had just found. Since verified against THREE REAL Studio Pro
+--   documents (OneHarness: XML_ECO, XMLRequest_Diagram, XMLRequest_DiagramId),
+--   which mxcli lists with the right module and names.
 --
---   That measurement is also why the XML check FAILS OPEN on an empty list: a
---   project with no XML schemas is the ordinary case, not evidence of a typo.
+--   CORRECTION, recorded because the wrong number shipped: this file first said
+--   no demo app contained an XML schema. It is 3 documents in 1 of 9 apps. The
+--   grep that produced the zero searched the EXTRACTED FILE TREE for the type
+--   string — which can only work for MPR v2, where units are files under
+--   mprcontents/. OneHarness is MPR **v1**: its units live in the SQLite
+--   Unit.Contents blob, where the string is not greppable from the file. The
+--   grep silently answered a different question than the one asked and returned
+--   0 for a reason unrelated to the answer.
+--
+--   The conclusion is unchanged, and is why the XML check FAILS OPEN on an empty
+--   list: 8 of 9 apps have none, so an empty list is the ordinary case, not
+--   evidence of a typo.
 --
 -- Watch for:
 --   An EMPTY project and a backend that CANNOT LIST look identical from here.
diff --git a/mdl-examples/bug-tests/widget-image-collection-entry.mdl b/mdl-examples/bug-tests/widget-image-collection-entry.mdl
new file mode 100644
index 0000000000..d5ca2aefa4
--- /dev/null
+++ b/mdl-examples/bug-tests/widget-image-collection-entry.mdl
@@ -0,0 +1,64 @@
+-- mxcli-formula1 FINDINGS §142 — MDL could not say WHICH image an image widget
+-- shows, so two things went wrong at once.
+--
+-- 1. Every mxcli-authored `image` widget was incomplete. Its default source is
+--    an entry from an image collection (`ImageType: image`), and MDL had no way
+--    to name one, so the model mxbuild got was:
+--
+--      [error] "No image selected." at Image 'imgLogo'
+--
+-- 2. A describe -> rename -> exec copy of an Atlas layout came out with no
+--    brand image. `describe` emitted the widget as
+--
+--      image staticImage1 (Responsive: false)
+--
+--    because there was nothing to emit — the reference was in the stored
+--    document and had no MDL spelling.
+--
+-- Both halves are needed: the WRITE (the `image` operation on the widget
+-- engine, mapping the widget's `imageObject` property) and the READ (describe
+-- emitting `Image:`). With only the write, a round trip still loses it.
+--
+-- The name has THREE parts, like an icon reference: Module.Collection.Image.
+--
+-- Verify:
+--   mxcli exec widget-image-collection-entry.mdl -p app.mpr
+--   mxcli -p app.mpr -c "DESCRIBE PAGE IMG.ImagePage"
+--       -- must emit: image imgLogo (Image: 'MyFirstModule.Images._1')
+--   mx check -p app.mpr        -- 0 errors; before the fix, "No image selected."
+--
+-- Adjust the image reference to one this project actually has:
+--   mxcli -p app.mpr -c "show image collections"
+--   mxcli -p app.mpr -c "describe image collection MyFirstModule.Images"
+
+create module IMG;
+
+create or replace page IMG.ImagePage (
+  title: 'Image sources',
+  layout: Atlas_Core.Atlas_Default
+) {
+  -- The default source: an entry from an image collection.
+  image imgLogo (Image: 'MyFirstModule.Images._1')
+
+  -- The two sources that take no collection entry, unchanged by this fix.
+  image imgRemote (ImageType: imageUrl, ImageUrl: 'https://example.com/logo.svg')
+  image imgIcon (ImageType: icon)
+}
+
+-- Both new checks, as MDL that must FAIL `mxcli check`. Uncomment one at a time.
+--
+-- MDL-WIDGET22 — the default source with no entry ("No image selected."):
+--
+--   create or replace page IMG.NoSource (title: 'x', layout: Atlas_Core.Atlas_Default) {
+--     image imgNothing (Width: 48, Height: 48)
+--   }
+--
+-- check --references — a name that does not resolve. Before the reference check
+-- this passed `mxcli check --references` and failed the BUILD with
+--   [CE1613] "The selected image '...' no longer exists."
+--
+--   create or replace page IMG.BadRef (title: 'x', layout: Atlas_Core.Atlas_Default) {
+--     image imgTypo (Image: 'MyFirstModule.Images.NoSuchImage')  -- image not found
+--     image imgColl (Image: 'Nope.Missing.Img')                  -- collection not found
+--     image imgShape (Image: 'JustTwo.Parts')                    -- not three parts
+--   }
diff --git a/mdl-examples/bug-tests/widget-unknown-property.mdl b/mdl-examples/bug-tests/widget-unknown-property.mdl
index 6950d170b8..afde96beaa 100644
--- a/mdl-examples/bug-tests/widget-unknown-property.mdl
+++ b/mdl-examples/bug-tests/widget-unknown-property.mdl
@@ -31,5 +31,6 @@ create or replace page MyFirstModule.P_UnknownProp
   -- genuinely unknown property → MDL-WIDGET07 (no suggestion)
   dynamictext unknown ( Content: 'hi', TotallyMadeUp: 'x' )
   -- describe-vocabulary props on a native image → no warning
-  image img ( WidthUnit: pixels, Width: 36, HeightUnit: pixels, Height: 36 )
+  image img ( ImageType: imageUrl, ImageUrl: 'https://example.com/x.png',
+              WidthUnit: pixels, Width: 36, HeightUnit: pixels, Height: 36 )
 }
diff --git a/mdl-examples/doctype-tests/17-custom-widget-examples.mdl b/mdl-examples/doctype-tests/17-custom-widget-examples.mdl
index 2084762152..4bec3b8b3b 100644
--- a/mdl-examples/doctype-tests/17-custom-widget-examples.mdl
+++ b/mdl-examples/doctype-tests/17-custom-widget-examples.mdl
@@ -233,7 +233,10 @@ create page CWTest.P_Image_Basic
   layoutgrid lgMain {
     row row1 {
       column col1 (desktopwidth: 12) {
-        image imgLogo
+        -- An image needs a SOURCE. The widget's default source is an image
+        -- collection entry, which MDL cannot yet name, so the bare form builds
+        -- to "No image selected." (MDL-WIDGET22). The URL form is complete.
+        image imgLogo (ImageType: imageUrl, ImageUrl: 'https://example.com/logo.png')
       }
     }
   }
@@ -263,6 +266,8 @@ create page CWTest.P_Image_Dimensions
     row row1 {
       column col1 (desktopwidth: 12) {
         image imgBanner (
+          ImageType: imageUrl,
+          ImageUrl: 'https://example.com/banner.png',
           AlternativeText: 'Company banner',
           WidthUnit: pixels,
           width: 800,
@@ -302,9 +307,14 @@ create page CWTest.P_Image_OnClick
     layoutgrid lgMain {
       row row1 {
         column col1 (desktopwidth: 6) {
+          -- DisplayAs is NOT set here on purpose: the widget hides it unless
+          -- the source is an image collection entry, and MDL cannot name one
+          -- (MDL-WIDGET22), so this page uses the URL source. Setting DisplayAs
+          -- alongside it is CE0463, which MDL-WIDGET10 reports at check time.
           image imgTask (
+            ImageType: imageUrl,
+            ImageUrl: 'https://example.com/task.png',
             AlternativeText: 'Task image',
-            DisplayAs: thumbnail,
             WidthUnit: pixels,
             width: 300
           )
diff --git a/mdl/ast/ast_annotation.go b/mdl/ast/ast_annotation.go
index a032dea593..a15c2a21a9 100644
--- a/mdl/ast/ast_annotation.go
+++ b/mdl/ast/ast_annotation.go
@@ -14,6 +14,15 @@ package ast
 // no name, so the note is addressed by the first line of its caption. There is
 // no colour: a "coloured section box" is this element in Studio Pro's styling,
 // not stored state.
+//
+// There is also no HEIGHT (#1014). The note auto-sizes to its caption, so its
+// height is a function of the text and the width rather than stored state.
+// Measured four ways on 11.13.0, because the metamodel in this repo is an 11.6.0
+// snapshot and cannot rule out a later property on its own: `mx dump-mpr` emits
+// those four keys and no more; `mx convert -p`, which rewrites the model through
+// Mendix's OWN object model and would materialise a defaulted property, adds
+// nothing; and the published Model SDK's domainmodels.Annotation lists caption,
+// exportLevel, location and width. Width is therefore the only height lever.
 type CreateAnnotationStmt struct {
 	Module  string
 	Caption string
diff --git a/mdl/ast/ast_microflow.go b/mdl/ast/ast_microflow.go
index 9c30dba8d4..db6fde1a81 100644
--- a/mdl/ast/ast_microflow.go
+++ b/mdl/ast/ast_microflow.go
@@ -725,6 +725,8 @@ const (
 	AggregateMinimum
 	AggregateMaximum
 	AggregateReduce
+	AggregateAll
+	AggregateAny
 )
 
 func (t AggregateListOperationType) String() string {
@@ -741,6 +743,10 @@ func (t AggregateListOperationType) String() string {
 		return "MAXIMUM"
 	case AggregateReduce:
 		return "REDUCE"
+	case AggregateAll:
+		return "ALL"
+	case AggregateAny:
+		return "ANY"
 	default:
 		return "UNKNOWN"
 	}
@@ -757,7 +763,14 @@ type AggregateListStmt struct {
 	Attribute      string                     // Attribute name for SUM/AVG/MIN/MAX (empty for COUNT or expression form)
 	IsExpression   bool                       // true when Expression is used instead of Attribute
 	Expression     Expression                 // Mendix expression (when IsExpression=true)
-	Annotations    *ActivityAnnotations       // Optional @position, @caption, @color, @annotation
+
+	// REDUCE only. InitialValue seeds $currentResult; ReturnType is the type the
+	// fold produces. Mendix requires both and neither can be inferred from the
+	// expression, so REDUCE names them and the other functions leave them zero.
+	InitialValue Expression
+	ReturnType   *DataType
+
+	Annotations *ActivityAnnotations // Optional @position, @caption, @color, @annotation
 }
 
 func (s *AggregateListStmt) isMicroflowStatement() {}
diff --git a/mdl/backend/mcp/widget.go b/mdl/backend/mcp/widget.go
index f7a2b02559..5f6bc8ca70 100644
--- a/mdl/backend/mcp/widget.go
+++ b/mdl/backend/mcp/widget.go
@@ -183,6 +183,13 @@ func (w *mcpWidgetBuilder) SetPrimitive(propertyKey, value string) {
 	w.object[propertyKey] = value
 }
 
+func (w *mcpWidgetBuilder) SetImage(propertyKey, imageQN string) {
+	if imageQN == "" {
+		return
+	}
+	w.object[propertyKey] = imageQN
+}
+
 func (w *mcpWidgetBuilder) SetDataSource(propertyKey string, ds pages.DataSource) {
 	if src := customWidgetXPathSource(ds); src != nil {
 		w.object[propertyKey] = src
diff --git a/mdl/backend/modelsdk/microflow_aggregate_reduce_write_test.go b/mdl/backend/modelsdk/microflow_aggregate_reduce_write_test.go
new file mode 100644
index 0000000000..2bfe35aa99
--- /dev/null
+++ b/mdl/backend/modelsdk/microflow_aggregate_reduce_write_test.go
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package modelsdkbackend
+
+import (
+	"testing"
+
+	"github.com/mendixlabs/mxcli/sdk/microflows"
+	"go.mongodb.org/mongo-driver/bson"
+)
+
+// TestReduceFoldReachesStorage proves the half of #1004 that no amount of
+// grammar work would fix: Mendix stores a Reduce's seed and result type in two
+// properties the semantic model had no room for, so mxcli read them as nothing
+// and wrote them back as nothing. The grammar gap made `reduce(...)` fail
+// loudly; this one would have failed silently, deleting the user's fold from a
+// microflow that still passed `mx check`.
+//
+// The expected values are measured, not assumed. Studio Pro writes both keys on
+// every AggregateAction, not only on Reduce: in ako/TestApp's MicroflowReduce
+// (Mendix 11.14) the All and Any activities each carry an empty initial value
+// and a Boolean return type, even though Mendix's reference guide says a return
+// type is "not applicable" to them. Attribute is likewise written as "" when
+// unused, which is why it is asserted here rather than left absent.
+func TestReduceFoldReachesStorage(t *testing.T) {
+	proj := copyFixture(t)
+
+	b := New()
+	if err := b.Connect(proj); err != nil {
+		t.Fatalf("connect: %v", err)
+	}
+	mod, err := b.GetModuleByName("MyFirstModule")
+	if err != nil || mod == nil {
+		t.Fatalf("GetModuleByName: %v", err)
+	}
+
+	mf := &microflows.Microflow{
+		ContainerID: mod.ID,
+		Name:        "ZZ_ReduceFold",
+		ObjectCollection: &microflows.MicroflowObjectCollection{
+			Objects: []microflows.MicroflowObject{
+				actionActivity(&microflows.AggregateListAction{
+					InputVariable:      "CarList",
+					OutputVariable:     "Total",
+					Function:           microflows.AggregateFunctionReduce,
+					UseExpression:      true,
+					Expression:         "$currentResult + 1",
+					ReduceInitialValue: "0",
+					ReduceReturnType:   &microflows.DecimalType{},
+				}),
+				actionActivity(&microflows.AggregateListAction{
+					InputVariable:    "CarList",
+					OutputVariable:   "AllMatch",
+					Function:         microflows.AggregateFunctionAll,
+					UseExpression:    true,
+					Expression:       "true",
+					ReduceReturnType: &microflows.BooleanType{},
+				}),
+			},
+		},
+	}
+	if err := b.CreateMicroflow(mf); err != nil {
+		t.Fatalf("CreateMicroflow: %v", err)
+	}
+	if err := b.Disconnect(); err != nil {
+		t.Fatalf("disconnect: %v", err)
+	}
+
+	got := collectAggregateProps(t, readUnitBytes(t, proj, string(mf.ID)))
+	if len(got) != 2 {
+		t.Fatalf("stored %d aggregate actions, want 2: %#v", len(got), got)
+	}
+
+	want := []map[string]any{
+		{
+			"AggregateFunction":            "Reduce",
+			"ReduceInitialValueExpression": "0",
+			"Attribute":                    "",
+		},
+		{
+			// ALL folds a Boolean and takes no seed, so the seed is stored empty
+			// rather than omitted — matching the reference document.
+			"AggregateFunction":            "All",
+			"ReduceInitialValueExpression": "",
+			"Attribute":                    "",
+		},
+	}
+	wantReturnType := []string{"DataTypes$DecimalType", "DataTypes$BooleanType"}
+
+	for i, w := range want {
+		for k, v := range w {
+			stored, ok := got[i][k]
+			if !ok {
+				t.Errorf("aggregate %d (%s): %s missing from the stored document", i, w["AggregateFunction"], k)
+				continue
+			}
+			if stored != v {
+				t.Errorf("aggregate %d (%s): %s = %#v, want %#v", i, w["AggregateFunction"], k, stored, v)
+			}
+		}
+		rt, ok := got[i]["ReduceReturnDataType"].(bson.M)
+		if !ok {
+			t.Errorf("aggregate %d (%s): ReduceReturnDataType missing or not a document: %#v",
+				i, w["AggregateFunction"], got[i]["ReduceReturnDataType"])
+			continue
+		}
+		typeName, _ := rt["$Type"].(string)
+		if typeName != wantReturnType[i] {
+			t.Errorf("aggregate %d (%s): return type = %q, want %q",
+				i, w["AggregateFunction"], typeName, wantReturnType[i])
+		}
+	}
+}
+
+// collectAggregateProps returns one flat map per stored aggregate activity, in
+// document order.
+func collectAggregateProps(t *testing.T, raw []byte) []map[string]any {
+	t.Helper()
+
+	var doc bson.M
+	if err := bson.Unmarshal(raw, &doc); err != nil {
+		t.Fatalf("unmarshal unit: %v", err)
+	}
+
+	var out []map[string]any
+	var walk func(any)
+	walk = func(v any) {
+		switch n := v.(type) {
+		case bson.M:
+			if typ, _ := n["$Type"].(string); typ == "Microflows$AggregateAction" {
+				out = append(out, map[string]any(n))
+			}
+			for _, child := range n {
+				walk(child)
+			}
+		case bson.D:
+			m := bson.M{}
+			for _, e := range n {
+				m[e.Key] = e.Value
+			}
+			walk(m)
+		case bson.A:
+			for _, child := range n {
+				walk(child)
+			}
+		}
+	}
+	walk(doc)
+	return out
+}
diff --git a/mdl/backend/modelsdk/microflow_read_actions.go b/mdl/backend/modelsdk/microflow_read_actions.go
index 49409fb2ce..4a20ce1931 100644
--- a/mdl/backend/modelsdk/microflow_read_actions.go
+++ b/mdl/backend/modelsdk/microflow_read_actions.go
@@ -212,6 +212,11 @@ func actionFromGen(el element.Element) microflows.MicroflowAction {
 			AttributeQualifiedName: a.AttributeQualifiedName(),
 			UseExpression:          a.UseExpression(),
 			Expression:             a.Expression(),
+			// Reduce's fold: what it starts from and what it folds to. Studio Pro
+			// stores both on every AggregateAction, so a rewrite that did not read
+			// them back silently deleted the fold (#1004).
+			ReduceInitialValue: a.ReduceInitialValueExpression(),
+			ReduceReturnType:   dataTypeFromGen(a.ReduceReturnDataType()),
 		}
 		out.ID = model.ID(a.ID())
 		return out
diff --git a/mdl/backend/modelsdk/microflow_write.go b/mdl/backend/modelsdk/microflow_write.go
index 069ac0d840..20f639e0b6 100644
--- a/mdl/backend/modelsdk/microflow_write.go
+++ b/mdl/backend/modelsdk/microflow_write.go
@@ -680,8 +680,17 @@ func microflowActionToGen(action microflows.MicroflowAction) element.Element {
 		if a.UseExpression {
 			g.SetUseExpression(true)
 			g.SetExpression(a.Expression)
-		} else if a.AttributeQualifiedName != "" {
-			g.SetAttributeQualifiedName(a.AttributeQualifiedName)
+		}
+		// Written even when unused: every Studio Pro reference document carries
+		// Attribute as "". Omitting it made a freshly described Studio Pro
+		// aggregate rewrite on its first execution for no semantic reason.
+		g.SetAttributeQualifiedName(a.AttributeQualifiedName)
+		// Reduce's fold. Written for the functions a reference document shows
+		// Mendix storing them on, and otherwise only to carry back what the
+		// stored document already had (#1004).
+		if a.Function.WritesReduceProperties() || a.ReduceInitialValue != "" || a.ReduceReturnType != nil {
+			g.SetReduceInitialValueExpression(a.ReduceInitialValue)
+			g.SetReduceReturnDataType(microflowDataTypeToGen(a.ReduceReturnType))
 		}
 		g.SetOutputVariableName(a.OutputVariable)
 		return g
diff --git a/mdl/backend/mutation.go b/mdl/backend/mutation.go
index 6a93b0d93f..6f49aed60f 100644
--- a/mdl/backend/mutation.go
+++ b/mdl/backend/mutation.go
@@ -336,6 +336,10 @@ type WidgetObjectBuilder interface {
 	SetAssociation(propertyKey string, assocPath string, entityName string)
 	SetPrimitive(propertyKey string, value string)
 	SetSelection(propertyKey string, value string)
+	// SetImage points an image-typed property (e.g. the Image widget's
+	// `imageObject`) at an image collection entry, by its three-part qualified
+	// name `Module.Collection.Image`.
+	SetImage(propertyKey string, imageQN string)
 	SetExpression(propertyKey string, value string)
 	SetDataSource(propertyKey string, ds pages.DataSource)
 	SetChildWidgets(propertyKey string, children []pages.Widget)
diff --git a/mdl/backend/widgetobj/builder.go b/mdl/backend/widgetobj/builder.go
index 239bd8a3b0..f01c85209b 100644
--- a/mdl/backend/widgetobj/builder.go
+++ b/mdl/backend/widgetobj/builder.go
@@ -95,6 +95,23 @@ func (ob *Builder) SetPrimitive(propertyKey string, value string) {
 	})
 }
 
+// SetImage points an image-typed property at an image collection entry, by its
+// three-part qualified name (`Module.Collection.Image`).
+//
+// The Image widget's `imageObject` is the case this exists for: it holds the
+// image the widget shows, and without it the default `ImageType: image` writes a
+// model mxbuild refuses with "No image selected." It is also what a describe →
+// exec copy of an Atlas layout needs in order to keep its brand image
+// (mxcli-formula1 FINDINGS §142).
+func (ob *Builder) SetImage(propertyKey string, imageQN string) {
+	if imageQN == "" {
+		return
+	}
+	ob.object = updateWidgetPropertyValue(ob.object, ob.propertyTypeIDs, propertyKey, func(val bson.D) bson.D {
+		return setImageValue(val, imageQN)
+	})
+}
+
 func (ob *Builder) SetSelection(propertyKey string, value string) {
 	if value == "" {
 		return
@@ -1080,6 +1097,28 @@ func setPrimitiveValue(val bson.D, value string) bson.D {
 	return result
 }
 
+// setImageValue writes the image reference onto a WidgetValue's `Image` key.
+//
+// The key is REPLACED, never added: a value node that does not declare one
+// belongs to a property that is not image-typed, and a key the widget's
+// definition does not know about is the CE0463 shape. Measured on a Studio
+// Pro-authored widget, the stored form is the bare qualified name —
+// `MyFirstModule.Images._1` — with nothing else on the node changed.
+func setImageValue(val bson.D, imageQN string) bson.D {
+	if imageQN == "" {
+		return val
+	}
+	result := make(bson.D, 0, len(val))
+	for _, elem := range val {
+		if elem.Key == "Image" {
+			result = append(result, bson.E{Key: "Image", Value: imageQN})
+		} else {
+			result = append(result, elem)
+		}
+	}
+	return result
+}
+
 func setDataSource(val bson.D, ds pages.DataSource) bson.D {
 	result := make(bson.D, 0, len(val))
 	for _, elem := range val {
diff --git a/mdl/backend/widgetobj/builder_image_test.go b/mdl/backend/widgetobj/builder_image_test.go
new file mode 100644
index 0000000000..1f0e273ee6
--- /dev/null
+++ b/mdl/backend/widgetobj/builder_image_test.go
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package widgetobj
+
+import (
+	"testing"
+
+	"go.mongodb.org/mongo-driver/bson"
+)
+
+// mxcli-formula1 FINDINGS §142, and the gap MDL-WIDGET22 was named for: MDL
+// could not say WHICH image an image widget shows.
+//
+// The Image widget's `datasource` defaults to `image` — an entry from an image
+// collection — and the property holding that entry, `imageObject`, is of type
+// `image`. The widget engine had no operation for that type, so the property was
+// unreachable from MDL and every default-form image widget wrote a model mxbuild
+// refuses with "No image selected." It is also why a describe → exec copy of an
+// Atlas layout loses its brand image.
+//
+// The stored shape is a plain string on the WidgetValue, measured on a Studio
+// Pro-authored widget in a stock project:
+//
+//	/Object/Properties[2]/Value/Image = "MyFirstModule.Images._1"
+//
+// Three parts: Module.Collection.Image. Nothing else about the value node
+// changes, which is why this is the same shape as SetSelection rather than
+// anything structural.
+
+// imageValue is one WidgetValue as stored: the Image key sits beside the others
+// and is empty until something sets it.
+func imageValue() bson.D {
+	return bson.D{
+		{Key: "$Type", Value: "CustomWidgets$WidgetValue"},
+		{Key: "PrimitiveValue", Value: ""},
+		{Key: "Image", Value: ""},
+		{Key: "TextTemplate", Value: nil},
+	}
+}
+
+func get(d bson.D, key string) any {
+	for _, e := range d {
+		if e.Key == key {
+			return e.Value
+		}
+	}
+	return nil
+}
+
+func TestSetImageValue_SetsTheQualifiedName(t *testing.T) {
+	got := setImageValue(imageValue(), "MyFirstModule.Images._1")
+
+	if v := get(got, "Image"); v != "MyFirstModule.Images._1" {
+		t.Errorf("Image = %v, want the qualified name", v)
+	}
+}
+
+// Every other key must come through untouched and in order. A WidgetValue that
+// gained or lost a key is the CE0463 shape this whole area keeps producing.
+func TestSetImageValue_LeavesEverythingElseAlone(t *testing.T) {
+	in := imageValue()
+	got := setImageValue(in, "Mod.Coll.Img")
+
+	if len(got) != len(in) {
+		t.Fatalf("key count changed: %d -> %d", len(in), len(got))
+	}
+	for i := range in {
+		if got[i].Key != in[i].Key {
+			t.Errorf("key %d: %q -> %q — order changed", i, in[i].Key, got[i].Key)
+		}
+	}
+	if v := get(got, "PrimitiveValue"); v != "" {
+		t.Errorf("PrimitiveValue was disturbed: %v", v)
+	}
+	if v := get(got, "TextTemplate"); v != nil {
+		t.Errorf("TextTemplate was disturbed: %v", v)
+	}
+}
+
+// A value node with no Image key at all is left as it is rather than having one
+// invented. Adding a key the widget's definition does not declare is precisely
+// what mxbuild answers with CE0463.
+func TestSetImageValue_DoesNotInventTheKey(t *testing.T) {
+	in := bson.D{{Key: "$Type", Value: "CustomWidgets$WidgetValue"}, {Key: "PrimitiveValue", Value: ""}}
+	got := setImageValue(in, "Mod.Coll.Img")
+
+	if len(got) != len(in) {
+		t.Fatalf("a key was added to a value node that does not declare one: %v", got)
+	}
+}
+
+// An empty name is a no-op, like every other Set* on this builder: "the script
+// did not say" must not overwrite what the template holds. Without this, an
+// image widget authored without `Image:` would have its template default
+// blanked rather than left alone.
+func TestSetImageValue_EmptyNameLeavesTheValueAlone(t *testing.T) {
+	in := bson.D{
+		{Key: "$Type", Value: "CustomWidgets$WidgetValue"},
+		{Key: "Image", Value: "Mod.Coll.Existing"},
+	}
+	if got := get(setImageValue(in, ""), "Image"); got != "Mod.Coll.Existing" {
+		t.Errorf("Image = %v, want the existing value untouched", got)
+	}
+}
diff --git a/mdl/executor/cmd_microflows_aggregate_roundtrip_test.go b/mdl/executor/cmd_microflows_aggregate_roundtrip_test.go
new file mode 100644
index 0000000000..cc77c13878
--- /dev/null
+++ b/mdl/executor/cmd_microflows_aggregate_roundtrip_test.go
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"strings"
+	"testing"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+	"github.com/mendixlabs/mxcli/mdl/visitor"
+	"github.com/mendixlabs/mxcli/sdk/microflows"
+)
+
+// aggregateOperationName maps the AST's aggregate kind back to the Mendix
+// function it builds, so the round trip below can compare like with like.
+var aggregateOperationName = map[ast.AggregateListOperationType]microflows.AggregateFunction{
+	ast.AggregateCount:   microflows.AggregateFunctionCount,
+	ast.AggregateSum:     microflows.AggregateFunctionSum,
+	ast.AggregateAverage: microflows.AggregateFunctionAverage,
+	ast.AggregateMinimum: microflows.AggregateFunctionMin,
+	ast.AggregateMaximum: microflows.AggregateFunctionMax,
+	ast.AggregateReduce:  microflows.AggregateFunctionReduce,
+	ast.AggregateAll:     microflows.AggregateFunctionAll,
+	ast.AggregateAny:     microflows.AggregateFunctionAny,
+}
+
+// TestDescribedAggregateParsesBack is the test #1004 needed and did not have.
+//
+// DESCRIBE rendered an aggregate by lowercasing whatever Mendix had stored,
+// which silently assumed every value of the AggregateFunction enumeration was
+// also an MDL keyword. Five were; Reduce, All and Any were not, so a Studio
+// Pro-authored activity described as MDL that mxcli's own checker rejected
+// ("'reduce()' ... is not a Mendix expression function [MDL044]").
+//
+// Driving every function through describe and back through the parser is what
+// makes that class of gap impossible to reintroduce: a ninth function added to
+// Mendix fails here rather than in a user's script.
+func TestDescribedAggregateParsesBack(t *testing.T) {
+	for _, fn := range microflows.AllAggregateFunctions {
+		t.Run(string(fn), func(t *testing.T) {
+			action := &microflows.AggregateListAction{
+				InputVariable:  "ProductList",
+				OutputVariable: "Result",
+				Function:       fn,
+				UseExpression:  true,
+				Expression:     "$currentObject/Price",
+			}
+			// Reduce is the one function whose fold is not derivable, so a
+			// describe that omits it is lossy even if it parses.
+			if fn == microflows.AggregateFunctionReduce {
+				action.ReduceInitialValue = "0"
+				action.ReduceReturnType = &microflows.DecimalType{}
+			}
+
+			rendered := formatAction(nil, action, nil, nil)
+			if strings.HasPrefix(strings.TrimSpace(rendered), "//") {
+				t.Fatalf("%s has no MDL keyword — DESCRIBE cannot render it: %s", fn, rendered)
+			}
+
+			src := "create microflow M.A ($ProductList: list of M.Product)\nbegin\n  " + rendered + "\nend;"
+			prog, errs := visitor.Build(src)
+			if len(errs) > 0 {
+				t.Fatalf("DESCRIBE emitted MDL the parser rejects.\n  rendered: %s\n  errors:   %v", rendered, errs)
+			}
+
+			agg := findAggregate(t, prog, rendered)
+			if got := aggregateOperationName[agg.Operation]; got != fn {
+				t.Errorf("round trip changed the function: %s -> %s (rendered %q)", fn, got, rendered)
+			}
+			if fn == microflows.AggregateFunctionReduce {
+				if agg.InitialValue == nil || agg.ReturnType == nil {
+					t.Errorf("reduce lost its fold on the way back: initial=%v returns=%v (rendered %q)",
+						agg.InitialValue, agg.ReturnType, rendered)
+				}
+			}
+		})
+	}
+}
+
+// TestAggregateKeywordsCoverEveryFunction guards the mapping itself, so a
+// function added to microflows.AllAggregateFunctions without an MDL keyword
+// fails here with a clear reason rather than as a parse error above.
+func TestAggregateKeywordsCoverEveryFunction(t *testing.T) {
+	for _, fn := range microflows.AllAggregateFunctions {
+		if _, ok := mdlAggregateKeyword(fn); !ok {
+			t.Errorf("aggregate function %q has no MDL keyword — DESCRIBE would refuse to render it", fn)
+		}
+	}
+}
+
+// findAggregate returns the single aggregate in a parsed microflow, failing
+// with the statement kind that was produced instead. `reduce(...)` used to
+// parse as a Change Variable, which is exactly how #1004 presented.
+func findAggregate(t *testing.T, prog *ast.Program, rendered string) *ast.AggregateListStmt {
+	t.Helper()
+	for _, s := range prog.Statements {
+		cm, ok := s.(*ast.CreateMicroflowStmt)
+		if !ok {
+			continue
+		}
+		for _, st := range cm.Body {
+			if agg, ok := st.(*ast.AggregateListStmt); ok {
+				return agg
+			}
+			if set, ok := st.(*ast.MfSetStmt); ok {
+				t.Fatalf("%q parsed as a Change Variable of $%s, not an aggregate", rendered, set.Target)
+			}
+		}
+	}
+	t.Fatalf("no aggregate produced by %q", rendered)
+	return nil
+}
diff --git a/mdl/executor/cmd_microflows_builder_actions.go b/mdl/executor/cmd_microflows_builder_actions.go
index d74d49a835..294b930361 100644
--- a/mdl/executor/cmd_microflows_builder_actions.go
+++ b/mdl/executor/cmd_microflows_builder_actions.go
@@ -5,6 +5,7 @@ package executor
 
 import (
 	"fmt"
+	"regexp"
 	"strings"
 
 	"github.com/mendixlabs/mxcli/mdl/ast"
@@ -1191,7 +1192,7 @@ func (fb *flowBuilder) addListOperationAction(s *ast.ListOperationStmt) model.ID
 			operation = &microflows.FindOperation{
 				BaseElement:  model.BaseElement{ID: model.ID(types.GenerateID())},
 				ListVariable: s.InputVariable,
-				Expression:   fb.exprToString(s.Condition),
+				Expression:   fb.exprToString(fb.qualifyIteratorAttributes(s.Condition, s.InputVariable, "find")),
 			}
 		}
 	case ast.ListOpFilter:
@@ -1201,7 +1202,7 @@ func (fb *flowBuilder) addListOperationAction(s *ast.ListOperationStmt) model.ID
 			operation = &microflows.FilterOperation{
 				BaseElement:  model.BaseElement{ID: model.ID(types.GenerateID())},
 				ListVariable: s.InputVariable,
-				Expression:   fb.exprToString(s.Condition),
+				Expression:   fb.exprToString(fb.qualifyIteratorAttributes(s.Condition, s.InputVariable, "filter")),
 			}
 		}
 	case ast.ListOpSort:
@@ -1401,6 +1402,10 @@ func (fb *flowBuilder) addAggregateListAction(s *ast.AggregateListStmt) model.ID
 		function = microflows.AggregateFunctionMax
 	case ast.AggregateReduce:
 		function = microflows.AggregateFunctionReduce
+	case ast.AggregateAll:
+		function = microflows.AggregateFunctionAll
+	case ast.AggregateAny:
+		function = microflows.AggregateFunctionAny
 	default:
 		return ""
 	}
@@ -1412,6 +1417,21 @@ func (fb *flowBuilder) addAggregateListAction(s *ast.AggregateListStmt) model.ID
 		Function:       function,
 	}
 
+	// The fold Mendix stores beside the expression. REDUCE names both in MDL;
+	// ALL and ANY always fold a Boolean and never take a seed, which is what
+	// Studio Pro writes for them (empty initial value, Boolean return type).
+	switch s.Operation {
+	case ast.AggregateReduce:
+		if s.InitialValue != nil {
+			action.ReduceInitialValue = expressionToString(s.InitialValue)
+		}
+		if s.ReturnType != nil {
+			action.ReduceReturnType = convertASTToMicroflowDataType(*s.ReturnType, nil)
+		}
+	case ast.AggregateAll, ast.AggregateAny:
+		action.ReduceReturnType = &microflows.BooleanType{}
+	}
+
 	if s.IsExpression && s.Expression != nil {
 		action.UseExpression = true
 		action.Expression = expressionToString(s.Expression)
@@ -1870,3 +1890,212 @@ func (fb *flowBuilder) lookupAssociation(moduleName, assocName string) *assocLoo
 	}
 	return nil
 }
+
+// qualifyIteratorAttributes rewrites a bare attribute name in a FILTER/FIND
+// predicate into `$currentObject/<Attr>`.
+//
+// Mendix's "filter by expression" / "find by expression" evaluates the predicate
+// once per item with the item bound to `$currentObject`; a bare attribute name is
+// not a valid expression there and the build fails with CE0117. mxcli used to
+// store the authored text verbatim, so `filter($L, Amount > 0)` wrote
+// `"Amount > 0"` and produced a model that `mxcli check` accepted and mxbuild
+// rejected — measured identically on 11.11.0 and 11.13.0, so this is mxcli's
+// behaviour and not a Mendix version change (issue #1002).
+//
+// This is the other half of bug #343. That fix rerouted `filter($L, attr = value)`
+// to `Microflows$Filter` (filter BY ATTRIBUTE), which takes a member name rather
+// than an expression and so accepts the bare form. Everything else — a different
+// operator, a compound predicate — still fell through to the expression shape.
+// The split was on the operator and invisible to the author: `Status = 'x'` built
+// and `Status != 'x'` did not.
+//
+// Only a name that provably resolves to a member of the list's element entity is
+// qualified. A name that does NOT resolve, when the entity IS known, is a real
+// mistake and is reported here rather than left to surface as CE0117 at build
+// time. When the element entity cannot be determined nothing is proven either
+// way, so the expression is passed through unchanged.
+func (fb *flowBuilder) qualifyIteratorAttributes(cond ast.Expression, listVariable, opLabel string) ast.Expression {
+	if cond == nil {
+		return nil
+	}
+	entityQN := fb.listElementEntity(listVariable)
+	if entityQN == "" {
+		return cond
+	}
+
+	// name → the path segment to write after `$currentObject/`. An attribute is
+	// referenced by its bare name; an association carries its module qualifier.
+	renamed := map[string]string{}
+	var rewrite func(ast.Expression) ast.Expression
+	rewrite = func(e ast.Expression) ast.Expression {
+		switch n := e.(type) {
+		case nil:
+			return nil
+		case *ast.IdentifierExpr:
+			segment, ok := fb.iteratorMemberPath(entityQN, n.Name)
+			if !ok {
+				if !isMendixExpressionKeyword(n.Name) {
+					fb.addError("%s($%s, …): %q is not an attribute or association of %s — a %s predicate is evaluated once per item, so a bare name must be a member of the list's entity (mxbuild reports CE0117 otherwise)",
+						opLabel, listVariable, n.Name, entityQN, opLabel)
+				}
+				return n
+			}
+			renamed[n.Name] = segment
+			return &ast.AttributePathExpr{
+				Variable: "currentObject",
+				Path:     []string{segment},
+				Segments: []ast.PathSegment{{Name: segment, Separator: "/"}},
+			}
+		case *ast.BinaryExpr:
+			return &ast.BinaryExpr{Left: rewrite(n.Left), Operator: n.Operator, Right: rewrite(n.Right)}
+		case *ast.UnaryExpr:
+			return &ast.UnaryExpr{Operator: n.Operator, Operand: rewrite(n.Operand)}
+		case *ast.ParenExpr:
+			return &ast.ParenExpr{Inner: rewrite(n.Inner)}
+		case *ast.FunctionCallExpr:
+			args := make([]ast.Expression, len(n.Arguments))
+			for i, a := range n.Arguments {
+				args[i] = rewrite(a)
+			}
+			return &ast.FunctionCallExpr{Name: n.Name, Arguments: args}
+		case *ast.IfThenElseExpr:
+			return &ast.IfThenElseExpr{
+				Condition: rewrite(n.Condition),
+				ThenExpr:  rewrite(n.ThenExpr),
+				ElseExpr:  rewrite(n.ElseExpr),
+			}
+		case *ast.SourceExpr:
+			inner := rewrite(n.Expression)
+			if n.Source == "" {
+				return inner
+			}
+			// A non-empty Source is the exact text to write back (decimal and
+			// whitespace fidelity, #17-19), so patch the names inside it rather
+			// than re-rendering the tree — the same treatment association paths
+			// get in resolveAssociationPaths.
+			return &ast.SourceExpr{Expression: inner, Source: qualifyNamesInSource(n.Source, renamed)}
+		default:
+			// LiteralExpr, VariableExpr, AttributePathExpr, QualifiedNameExpr,
+			// ConstantRefExpr, TokenExpr, XPathPathExpr: nothing to qualify. An
+			// AttributePathExpr is already anchored to some variable, and naming
+			// the wrong one is MDL-LISTOP01's business, not this function's.
+			return e
+		}
+	}
+
+	return rewrite(cond)
+}
+
+// listElementEntity returns the qualified entity name of a list variable's
+// elements, or "" when the variable's type was never tracked.
+func (fb *flowBuilder) listElementEntity(listVariable string) string {
+	if fb == nil || fb.varTypes == nil || listVariable == "" {
+		return ""
+	}
+	entityQN, _ := strings.CutPrefix(fb.varTypes[listVariable], "List of ")
+	if entityQN == fb.varTypes[listVariable] {
+		return "" // not a list type
+	}
+	return entityQN
+}
+
+// iteratorMemberPath resolves a bare name against entityQN and returns the path
+// segment that references it from `$currentObject`. An attribute keeps its bare
+// name; an association is returned module-qualified, which is how Mendix spells
+// one in a path (`$currentObject/Sales.Order_Customer`).
+func (fb *flowBuilder) iteratorMemberPath(entityQN, name string) (string, bool) {
+	if name == "" || strings.Contains(name, ".") {
+		return "", false
+	}
+	if _, ok := fb.resolveAttributeInEntityHierarchy(entityQN, name); ok {
+		return name, true
+	}
+	if fb.backend == nil {
+		return "", false
+	}
+	module, _, found := strings.Cut(entityQN, ".")
+	if !found {
+		return "", false
+	}
+	mod, err := fb.backend.GetModuleByName(module)
+	if err != nil || mod == nil {
+		return "", false
+	}
+	dm, err := fb.backend.GetDomainModel(mod.ID)
+	if err != nil || dm == nil {
+		return "", false
+	}
+	for _, a := range dm.Associations {
+		if a.Name == name {
+			return module + "." + name, true
+		}
+	}
+	for _, a := range dm.CrossAssociations {
+		if a.Name == name {
+			return module + "." + name, true
+		}
+	}
+	return "", false
+}
+
+// isMendixExpressionKeyword reports whether name is a bare word Mendix defines
+// itself, so an unresolved one is not reported as a missing attribute.
+func isMendixExpressionKeyword(name string) bool {
+	switch strings.ToLower(name) {
+	case "true", "false", "empty", "nil", "null":
+		return true
+	}
+	return false
+}
+
+// bareNameInSourceRe matches a whole-word occurrence of a name that is not
+// already part of a path (`$currentObject/Amount`) or a qualified name
+// (`Module.Amount`). Go's regexp has no lookbehind, so the preceding character
+// is captured and put back.
+var bareNameInSourceRe = regexp.MustCompile(`(^|[^\w./$])([A-Za-z_]\w*)(\b)`)
+
+// qualifyNamesInSource rewrites each name in names to `$currentObject/<segment>`
+// within expression source text, leaving single-quoted string literals alone.
+func qualifyNamesInSource(source string, names map[string]string) string {
+	if len(names) == 0 {
+		return source
+	}
+	var out strings.Builder
+	for i := 0; i < len(source); {
+		if source[i] == '\'' {
+			// Copy the whole literal verbatim, including doubled-quote escapes.
+			j := i + 1
+			for j < len(source) {
+				if source[j] == '\'' {
+					if j+1 < len(source) && source[j+1] == '\'' {
+						j += 2
+						continue
+					}
+					j++
+					break
+				}
+				j++
+			}
+			out.WriteString(source[i:j])
+			i = j
+			continue
+		}
+		next := strings.IndexByte(source[i:], '\'')
+		end := len(source)
+		if next >= 0 {
+			end = i + next
+		}
+		segment := source[i:end]
+		out.WriteString(bareNameInSourceRe.ReplaceAllStringFunc(segment, func(m string) string {
+			sub := bareNameInSourceRe.FindStringSubmatch(m)
+			if len(sub) == 4 {
+				if segment, ok := names[sub[2]]; ok {
+					return sub[1] + "$currentObject/" + segment
+				}
+			}
+			return m
+		}))
+		i = end
+	}
+	return out.String()
+}
diff --git a/mdl/executor/cmd_microflows_builder_listop_predicate_test.go b/mdl/executor/cmd_microflows_builder_listop_predicate_test.go
new file mode 100644
index 0000000000..2863a5c925
--- /dev/null
+++ b/mdl/executor/cmd_microflows_builder_listop_predicate_test.go
@@ -0,0 +1,268 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"strings"
+	"testing"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+	"github.com/mendixlabs/mxcli/mdl/backend/mock"
+	"github.com/mendixlabs/mxcli/model"
+	"github.com/mendixlabs/mxcli/sdk/domainmodel"
+	"github.com/mendixlabs/mxcli/sdk/microflows"
+)
+
+// predicateBuilder wires a flow builder over a Shop.Order entity carrying
+// Status/Amount/Qty and an Order_Customer association, with $L typed as a list
+// of it — the shape every case in issue #1002 was measured on.
+func predicateBuilder(t *testing.T) *flowBuilder {
+	t.Helper()
+	mod := mkModule("Shop")
+	order := &domainmodel.Entity{
+		BaseElement: model.BaseElement{ID: nextID("ent")},
+		ContainerID: nextID("dm"),
+		Name:        "Order",
+		Persistable: true,
+		Attributes: []*domainmodel.Attribute{
+			{Name: "Status"}, {Name: "Amount"}, {Name: "Qty"},
+		},
+	}
+	dm := &domainmodel.DomainModel{
+		BaseElement:  model.BaseElement{ID: nextID("dm")},
+		ContainerID:  mod.ID,
+		Entities:     []*domainmodel.Entity{order},
+		Associations: []*domainmodel.Association{{Name: "Order_Customer"}},
+	}
+	mb := &mock.MockBackend{
+		IsConnectedFunc:      func() bool { return true },
+		ListModulesFunc:      func() ([]*model.Module, error) { return []*model.Module{mod}, nil },
+		GetModuleByNameFunc:  func(name string) (*model.Module, error) { return mod, nil },
+		ListDomainModelsFunc: func() ([]*domainmodel.DomainModel, error) { return []*domainmodel.DomainModel{dm}, nil },
+		GetDomainModelFunc:   func(id model.ID) (*domainmodel.DomainModel, error) { return dm, nil },
+	}
+	varTypes := map[string]string{"L": "List of Shop.Order"}
+	return &flowBuilder{
+		posX:         100,
+		posY:         100,
+		spacing:      HorizontalSpacing,
+		backend:      mb,
+		declaredVars: map[string]string{},
+		varTypes:     varTypes,
+		measurer:     &layoutMeasurer{varTypes: varTypes},
+	}
+}
+
+// filterExpression builds a FILTER over $L with the given predicate and returns
+// the expression the builder stored, plus any build errors.
+//
+// A nil source passes the condition as a bare tree, which is what the live
+// `$R = FILTER($L, …)` syntax produces (visitor_microflow_statements.go). A
+// non-empty source wraps it in the frozen SourceExpr the other visitor path
+// builds (visitor_microflow_actions.go, buildSourceExpression) — the builder has
+// to get both right, and only the second exercises the source-text rewrite.
+func filterExpression(t *testing.T, fb *flowBuilder, source string, cond ast.Expression) (string, []string) {
+	t.Helper()
+	predicate := cond
+	if source != "" {
+		predicate = &ast.SourceExpr{Expression: cond, Source: source}
+	}
+	stmt := &ast.ListOperationStmt{
+		Operation:      ast.ListOpFilter,
+		InputVariable:  "L",
+		OutputVariable: "R",
+		Condition:      predicate,
+	}
+	oc := fb.buildFlowGraph([]ast.MicroflowStatement{stmt},
+		&ast.MicroflowReturnType{Type: ast.DataType{Kind: ast.TypeBoolean}})
+	var expr string
+	for _, obj := range oc.Objects {
+		act, ok := obj.(*microflows.ActionActivity)
+		if !ok {
+			continue
+		}
+		lo, ok := act.Action.(*microflows.ListOperationAction)
+		if !ok {
+			continue
+		}
+		switch op := lo.Operation.(type) {
+		case *microflows.FilterOperation:
+			expr = op.Expression
+		case *microflows.FilterByAttributeOperation:
+			expr = "BY-ATTRIBUTE " + op.Attribute + " " + op.Expression
+		}
+	}
+	return expr, fb.GetErrors()
+}
+
+// bare builds `<name> <op> <literal>` the way the visitor does for a bare
+// attribute predicate: an IdentifierExpr on the left. A literal wrapped in
+// single quotes is a string, anything else an integer — enough to render the
+// right-hand side the way the real parser would.
+func bare(name, op, literal string) ast.Expression {
+	lit := &ast.LiteralExpr{Value: literal, Kind: ast.LiteralString}
+	switch {
+	case strings.HasPrefix(literal, "'"):
+		lit.Value = strings.Trim(literal, "'")
+	case literal == "empty":
+		lit.Kind = ast.LiteralEmpty
+	default:
+		lit.Kind = ast.LiteralInteger
+	}
+	return &ast.BinaryExpr{
+		Left:     &ast.IdentifierExpr{Name: name},
+		Operator: op,
+		Right:    lit,
+	}
+}
+
+// TestFilterPredicateQualifiesBareAttributes is issue #1002. A bare attribute in
+// a filter-by-expression predicate was stored verbatim, which mxbuild rejects
+// with CE0117 because the predicate is evaluated per item against
+// $currentObject. Measured identically on mxbuild 11.11.0 and 11.13.0, so the
+// issue's "Mendix 11.13 regression" diagnosis does not hold.
+func TestFilterPredicateQualifiesBareAttributes(t *testing.T) {
+	tests := []struct {
+		name   string
+		source string
+		cond   ast.Expression
+		want   string
+	}{
+		{
+			name:   "bare attribute with a comparison operator",
+			source: "Amount > 0",
+			cond:   bare("Amount", ">", "0"),
+			want:   "$currentObject/Amount > 0",
+		},
+		{
+			name:   "bare attribute with !=",
+			source: "Status != 'Pending'",
+			cond:   bare("Status", "!=", "'Pending'"),
+			want:   "$currentObject/Status != 'Pending'",
+		},
+		{
+			// The literal spells an attribute name and must survive untouched.
+			name:   "string literal is not rewritten",
+			source: "Qty > 0 and Status != 'Amount'",
+			cond: &ast.BinaryExpr{
+				Left:     bare("Qty", ">", "0"),
+				Operator: "and",
+				Right:    bare("Status", "!=", "'Amount'"),
+			},
+			want: "$currentObject/Qty > 0 and $currentObject/Status != 'Amount'",
+		},
+		{
+			name:   "an association carries its module qualifier",
+			source: "Order_Customer != empty",
+			cond:   bare("Order_Customer", "!=", "empty"),
+			want:   "$currentObject/Shop.Order_Customer != empty",
+		},
+		{
+			// The shape the live `$R = FILTER($L, …)` syntax produces.
+			name:   "bare attribute as a bare tree, no frozen source",
+			source: "",
+			cond:   bare("Amount", ">", "0"),
+			want:   "$currentObject/Amount > 0",
+		},
+		{
+			name:   "an already-qualified path is left alone",
+			source: "$currentObject/Amount > 0",
+			cond: &ast.BinaryExpr{
+				Left: &ast.AttributePathExpr{Variable: "currentObject", Path: []string{"Amount"},
+					Segments: []ast.PathSegment{{Name: "Amount", Separator: "/"}}},
+				Operator: ">",
+				Right:    &ast.LiteralExpr{Value: "0", Kind: ast.LiteralInteger},
+			},
+			want: "$currentObject/Amount > 0",
+		},
+	}
+
+	for _, tc := range tests {
+		t.Run(tc.name, func(t *testing.T) {
+			got, errs := filterExpression(t, predicateBuilder(t), tc.source, tc.cond)
+			if len(errs) > 0 {
+				t.Fatalf("unexpected build errors: %v", errs)
+			}
+			if got != tc.want {
+				t.Errorf("stored expression = %q, want %q", got, tc.want)
+			}
+		})
+	}
+}
+
+// TestFilterPredicateRefusesUnknownMember covers the other half: a bare name the
+// element entity does not have used to reach mxbuild as CE0117. Nothing can be
+// qualified, so it is refused here instead.
+func TestFilterPredicateRefusesUnknownMember(t *testing.T) {
+	_, errs := filterExpression(t, predicateBuilder(t), "Nonexistent > 0", bare("Nonexistent", ">", "0"))
+	if len(errs) == 0 {
+		t.Fatal("expected a build error for a name that is not a member of Shop.Order")
+	}
+	joined := strings.Join(errs, "\n")
+	for _, want := range []string{"Nonexistent", "Shop.Order", "CE0117"} {
+		if !strings.Contains(joined, want) {
+			t.Errorf("error %q does not mention %q", joined, want)
+		}
+	}
+}
+
+// TestFilterPredicateKeepsAttributeReroute is the bug #343 regression guard. The
+// `attr = value` form must stay on Microflows$Filter (filter BY ATTRIBUTE),
+// which takes a member name rather than an expression — qualifying it into an
+// expression would undo that fix.
+func TestFilterPredicateKeepsAttributeReroute(t *testing.T) {
+	got, errs := filterExpression(t, predicateBuilder(t), "", bare("Status", "=", "'Pending'"))
+	if len(errs) > 0 {
+		t.Fatalf("unexpected build errors: %v", errs)
+	}
+	if !strings.HasPrefix(got, "BY-ATTRIBUTE ") {
+		t.Fatalf("`Status = 'Pending'` built as %q, want the filter-by-attribute operation (bug #343)", got)
+	}
+	if !strings.Contains(got, "Shop.Order.Status") {
+		t.Errorf("filter-by-attribute names %q, want the Shop.Order.Status member", got)
+	}
+}
+
+// TestFilterPredicateUntouchedWithoutElementEntity: when the list's element type
+// was never tracked nothing is proven either way, so the predicate is passed
+// through rather than guessed at or refused.
+func TestFilterPredicateUntouchedWithoutElementEntity(t *testing.T) {
+	fb := predicateBuilder(t)
+	fb.varTypes = map[string]string{} // $L's type is unknown
+	fb.measurer = &layoutMeasurer{varTypes: fb.varTypes}
+	got, errs := filterExpression(t, fb, "Amount > 0", bare("Amount", ">", "0"))
+	if len(errs) > 0 {
+		t.Fatalf("unexpected build errors: %v", errs)
+	}
+	if got != "Amount > 0" {
+		t.Errorf("stored expression = %q, want it passed through unchanged", got)
+	}
+}
+
+// TestQualifyNamesInSource pins the source-text rewrite on its own. The
+// predicate reaches the builder as a frozen SourceExpr (buildSourceExpression),
+// so this is what actually decides the stored bytes.
+func TestQualifyNamesInSource(t *testing.T) {
+	names := map[string]string{"Amount": "Amount", "Assoc": "Shop.Assoc"}
+	tests := []struct{ in, want string }{
+		{"Amount > 0", "$currentObject/Amount > 0"},
+		{"(Amount > 0)", "($currentObject/Amount > 0)"},
+		{"Amount > 0 and Amount < 9", "$currentObject/Amount > 0 and $currentObject/Amount < 9"},
+		{"Assoc != empty", "$currentObject/Shop.Assoc != empty"},
+		// Already anchored to a variable, or qualified by a module: untouched.
+		{"$currentObject/Amount > 0", "$currentObject/Amount > 0"},
+		{"$other/Amount > 0", "$other/Amount > 0"},
+		{"Mod.Amount > 0", "Mod.Amount > 0"},
+		// Inside a string literal, including a doubled-quote escape.
+		{"Status != 'Amount'", "Status != 'Amount'"},
+		{"Status != 'it''s Amount' and Amount > 0",
+			"Status != 'it''s Amount' and $currentObject/Amount > 0"},
+		// A name that is not in the map is not touched.
+		{"Other > 0", "Other > 0"},
+	}
+	for _, tc := range tests {
+		if got := qualifyNamesInSource(tc.in, names); got != tc.want {
+			t.Errorf("qualifyNamesInSource(%q) = %q, want %q", tc.in, got, tc.want)
+		}
+	}
+}
diff --git a/mdl/executor/cmd_microflows_format_action.go b/mdl/executor/cmd_microflows_format_action.go
index 8c4bb1a4b9..e6ca3518b1 100644
--- a/mdl/executor/cmd_microflows_format_action.go
+++ b/mdl/executor/cmd_microflows_format_action.go
@@ -409,9 +409,12 @@ func formatAction(
 		if outputVar == "" {
 			outputVar = "Result"
 		}
-		fn := string(a.Function)
-		if fn == "" {
-			fn = "count"
+		fn, known := mdlAggregateKeyword(a.Function)
+		if !known {
+			// A function this build has no MDL keyword for. Rendering it by
+			// lowercasing the stored name is what produced unreadable MDL for
+			// Reduce/All/Any (#1004), so say so instead of emitting a lie.
+			return fmt.Sprintf("// unsupported aggregate function %q on $%s — mxcli cannot render this activity as MDL;", a.Function, outputVar)
 		}
 		// Extract attribute name (use last part of qualified name for readability)
 		attrName := a.AttributeQualifiedName
@@ -422,15 +425,27 @@ func formatAction(
 				attrName = parts[len(parts)-1]
 			}
 		}
+		// REDUCE carries the fold Mendix stores beside the expression. Both parts
+		// are required, so they are rendered even when empty rather than dropped —
+		// a reduce that describes without them cannot be executed back (#1004).
+		if a.Function == microflows.AggregateFunctionReduce {
+			initial := a.ReduceInitialValue
+			if initial == "" {
+				initial = "empty"
+			}
+			return fmt.Sprintf("$%s = reduce($%s, %s, initial: %s, returns: %s);",
+				outputVar, a.InputVariable, a.Expression, initial,
+				formatMicroflowDataType(ctx, a.ReduceReturnType, entityNames))
+		}
 		// Expression-based aggregate: SUM($list, $currentObject/Attr + 1)
 		if a.UseExpression && a.Expression != "" {
-			return fmt.Sprintf("$%s = %s($%s, %s);", outputVar, strings.ToLower(fn), a.InputVariable, a.Expression)
+			return fmt.Sprintf("$%s = %s($%s, %s);", outputVar, fn, a.InputVariable, a.Expression)
 		}
 		// Attribute-based aggregate: SUM($list.Attr)
 		if attrName != "" && a.Function != microflows.AggregateFunctionCount {
-			return fmt.Sprintf("$%s = %s($%s.%s);", outputVar, strings.ToLower(fn), a.InputVariable, attrName)
+			return fmt.Sprintf("$%s = %s($%s.%s);", outputVar, fn, a.InputVariable, attrName)
 		}
-		return fmt.Sprintf("$%s = %s($%s);", outputVar, strings.ToLower(fn), a.InputVariable)
+		return fmt.Sprintf("$%s = %s($%s);", outputVar, fn, a.InputVariable)
 
 	case *microflows.RetrieveAction:
 		outputVar := a.OutputVariable
@@ -2034,3 +2049,37 @@ func queueClauseMDL(qs *microflows.QueueSettings) string {
 	}
 	return " in queue " + qs.Queue
 }
+
+// mdlAggregateKeyword maps a Mendix aggregate function to the MDL keyword that
+// parses back to it, reporting false for one this build cannot express.
+//
+// DESCRIBE used to render an aggregate by lowercasing whatever was stored,
+// which silently assumed every value of Mendix's enumeration was also an MDL
+// keyword. It was not: Reduce, All and Any described as MDL that the grammar
+// then rejected (#1004). Mapping explicitly means a function added to Mendix
+// later fails TestAggregateKeywordsCoverEveryFunction rather than a user's
+// script.
+func mdlAggregateKeyword(fn microflows.AggregateFunction) (string, bool) {
+	switch fn {
+	case microflows.AggregateFunctionCount, "":
+		// Count is also the fallback for an activity with no function stored,
+		// which is what Mendix defaults a fresh aggregate to.
+		return "count", true
+	case microflows.AggregateFunctionSum:
+		return "sum", true
+	case microflows.AggregateFunctionAverage:
+		return "average", true
+	case microflows.AggregateFunctionMin:
+		return "minimum", true
+	case microflows.AggregateFunctionMax:
+		return "maximum", true
+	case microflows.AggregateFunctionReduce:
+		return "reduce", true
+	case microflows.AggregateFunctionAll:
+		return "all", true
+	case microflows.AggregateFunctionAny:
+		return "any", true
+	default:
+		return "", false
+	}
+}
diff --git a/mdl/executor/cmd_pages_describe.go b/mdl/executor/cmd_pages_describe.go
index b211a157cf..21e00be477 100644
--- a/mdl/executor/cmd_pages_describe.go
+++ b/mdl/executor/cmd_pages_describe.go
@@ -689,7 +689,12 @@ type rawWidget struct {
 	DisplayAs       string // "fullImage", "thumbnail"
 	Responsive      string // "true", "false"
 	ImageType       string // "image", "imageUrl", "icon"
-	OnClickType     string // "action", "enlarge"
+	// ImageObject is the image collection entry the widget shows, as the
+	// three-part qualified name Module.Collection.Image. Empty when the source
+	// is not an image collection, or when none is selected. Without it a
+	// describe -> exec copy loses the image (mxcli-formula1 FINDINGS §142).
+	ImageObject string
+	OnClickType string // "action", "enlarge"
 }
 
 // rawExplicitProp represents a non-default property extracted from a CustomWidget.
diff --git a/mdl/executor/cmd_pages_describe_image_test.go b/mdl/executor/cmd_pages_describe_image_test.go
new file mode 100644
index 0000000000..a25d096c1e
--- /dev/null
+++ b/mdl/executor/cmd_pages_describe_image_test.go
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"strings"
+	"testing"
+)
+
+// mxcli-formula1 FINDINGS §142: a describe → rename → exec copy of an Atlas
+// layout comes out with no brand image.
+//
+// `describe` emitted the Image widget as the built-in shorthand with no image
+// reference at all —
+//
+//	image staticImage1 (Responsive: false)
+//
+// — because MDL had no way to name an image collection entry, so there was
+// nothing to emit. Wiring the `image` operation gives the writer that
+// capability; without the READ half the round trip still loses it, and the copy
+// still renders blank.
+//
+// The stored form is a plain string on the WidgetValue, measured on a Studio
+// Pro-authored widget: `Image: "MyFirstModule.Images._1"`, three parts,
+// Module.Collection.Image.
+
+// imagePropWidget is one stored CustomWidget carrying an image-typed property.
+// The TypePointer indirection is the whole reason a dedicated extractor exists:
+// the property is found by resolving its pointer to a PropertyKey, not by
+// position.
+func imagePropWidget(propertyKey, stored string) map[string]any {
+	return map[string]any{
+		"Type": map[string]any{
+			"ObjectType": map[string]any{
+				"PropertyTypes": []any{
+					map[string]any{
+						"$ID":         "pt-1",
+						"$Type":       "CustomWidgets$WidgetPropertyType",
+						"PropertyKey": propertyKey,
+					},
+				},
+			},
+		},
+		"Object": map[string]any{
+			"Properties": []any{
+				map[string]any{
+					"$Type":       "CustomWidgets$WidgetProperty",
+					"TypePointer": "pt-1",
+					"Value": map[string]any{
+						"$Type":          "CustomWidgets$WidgetValue",
+						"PrimitiveValue": "",
+						"Image":          stored,
+					},
+				},
+			},
+		},
+	}
+}
+
+func TestExtractCustomWidgetPropertyImage_ReadsTheReference(t *testing.T) {
+	ctx, _ := newMockCtx(t)
+	got := extractCustomWidgetPropertyImage(ctx, imagePropWidget("imageObject", "MyFirstModule.Images._1"), "imageObject")
+	if got != "MyFirstModule.Images._1" {
+		t.Errorf("got %q, want the stored qualified name", got)
+	}
+}
+
+// CONTROL 1: an unset image reads as empty, so DESCRIBE emits nothing rather
+// than an `Image: ”` that would not re-execute.
+func TestExtractCustomWidgetPropertyImage_UnsetIsEmpty(t *testing.T) {
+	ctx, _ := newMockCtx(t)
+	if got := extractCustomWidgetPropertyImage(ctx, imagePropWidget("imageObject", ""), "imageObject"); got != "" {
+		t.Errorf("got %q, want empty", got)
+	}
+}
+
+// CONTROL 2: it must resolve the property by KEY, not take the first Image it
+// finds. The Image widget has two image-typed properties — `imageObject` and
+// `defaultImageDynamic` — so a positional read would return the wrong one.
+func TestExtractCustomWidgetPropertyImage_ResolvesByPropertyKey(t *testing.T) {
+	ctx, _ := newMockCtx(t)
+	w := imagePropWidget("defaultImageDynamic", "Mod.Coll.Fallback")
+	if got := extractCustomWidgetPropertyImage(ctx, w, "imageObject"); got != "" {
+		t.Errorf("got %q for imageObject, but only defaultImageDynamic is set", got)
+	}
+	if got := extractCustomWidgetPropertyImage(ctx, w, "defaultImageDynamic"); got != "Mod.Coll.Fallback" {
+		t.Errorf("got %q, want the fallback image", got)
+	}
+}
+
+// The end §142 is about: what DESCRIBE prints. An image widget with an entry
+// must emit `Image:` so describe → exec keeps it.
+func TestDescribeImageWidget_EmitsTheImageReference(t *testing.T) {
+	w := rawWidget{Name: "imgLogo"}
+	w.ImageObject = "MyFirstModule.Images._1"
+
+	out := describeImageWidgetProps(w)
+	if !strings.Contains(strings.Join(out, ", "), "Image: 'MyFirstModule.Images._1'") {
+		t.Errorf("describe did not emit the image reference: %v", out)
+	}
+}
+
+// CONTROL: a widget with no entry emits no `Image:` at all. An empty one would
+// re-execute into a reference to nothing.
+func TestDescribeImageWidget_OmitsAnAbsentReference(t *testing.T) {
+	w := rawWidget{Name: "imgLogo"}
+
+	for _, p := range describeImageWidgetProps(w) {
+		if strings.HasPrefix(p, "Image:") {
+			t.Errorf("emitted %q for a widget with no image", p)
+		}
+	}
+}
diff --git a/mdl/executor/cmd_pages_describe_output.go b/mdl/executor/cmd_pages_describe_output.go
index d164a47474..f96cab77b3 100644
--- a/mdl/executor/cmd_pages_describe_output.go
+++ b/mdl/executor/cmd_pages_describe_output.go
@@ -653,40 +653,7 @@ func outputWidgetMDLV3(ctx *ExecContext, w rawWidget, indent int) {
 			}
 		} else if widgetType == "image" {
 			header := fmt.Sprintf("image %s", mdlIdent(w.Name))
-			props := []string{}
-			if w.ImageType != "" && w.ImageType != "image" {
-				props = append(props, fmt.Sprintf("ImageType: %s", w.ImageType))
-			}
-			if w.ImageUrl != "" {
-				props = append(props, fmt.Sprintf("ImageUrl: %s", mdlQuote(w.ImageUrl)))
-			}
-			if w.AlternativeText != "" {
-				props = append(props, fmt.Sprintf("AlternativeText: %s", mdlQuote(w.AlternativeText)))
-			}
-			if w.WidthUnit != "" && w.WidthUnit != "auto" {
-				props = append(props, fmt.Sprintf("WidthUnit: %s", w.WidthUnit))
-			}
-			if w.ImageWidth != "" && w.ImageWidth != "100" {
-				props = append(props, fmt.Sprintf("Width: %s", w.ImageWidth))
-			}
-			if w.HeightUnit != "" && w.HeightUnit != "auto" {
-				props = append(props, fmt.Sprintf("HeightUnit: %s", w.HeightUnit))
-			}
-			if w.ImageHeight != "" && w.ImageHeight != "100" {
-				props = append(props, fmt.Sprintf("Height: %s", w.ImageHeight))
-			}
-			if w.DisplayAs != "" && w.DisplayAs != "fullImage" {
-				props = append(props, fmt.Sprintf("DisplayAs: %s", w.DisplayAs))
-			}
-			if w.Responsive != "" && w.Responsive != "true" {
-				props = append(props, fmt.Sprintf("Responsive: %s", w.Responsive))
-			}
-			if w.OnClickType == "enlarge" {
-				props = append(props, "OnClickType: enlarge")
-			}
-			if w.Action != "" {
-				props = append(props, fmt.Sprintf("OnClick: %s", w.Action))
-			}
+			props := describeImageWidgetProps(w)
 			props = appendConditionalProps(props, w)
 			props = appendAppearanceProps(props, w)
 			formatWidgetProps(ctx.Output, prefix, header, props, "\n")
@@ -1706,3 +1673,52 @@ func appendNamedActionProps(props []string, w rawWidget) []string {
 	}
 	return props
 }
+
+// describeImageWidgetProps renders an image widget's own properties, separated
+// from the output loop so the round trip can be asserted directly.
+//
+// `Image:` is the one §142 turns on: it names the image collection entry the
+// widget shows, and until the `image` operation existed there was nothing to
+// emit, so describe -> exec copied an Atlas layout and lost its brand image. An
+// ABSENT entry emits nothing rather than an empty `Image: ”`, which would
+// re-execute into a reference to nothing.
+func describeImageWidgetProps(w rawWidget) []string {
+	props := []string{}
+	if w.ImageType != "" && w.ImageType != "image" {
+		props = append(props, fmt.Sprintf("ImageType: %s", w.ImageType))
+	}
+	if w.ImageObject != "" {
+		props = append(props, fmt.Sprintf("Image: %s", mdlQuote(w.ImageObject)))
+	}
+	if w.ImageUrl != "" {
+		props = append(props, fmt.Sprintf("ImageUrl: %s", mdlQuote(w.ImageUrl)))
+	}
+	if w.AlternativeText != "" {
+		props = append(props, fmt.Sprintf("AlternativeText: %s", mdlQuote(w.AlternativeText)))
+	}
+	if w.WidthUnit != "" && w.WidthUnit != "auto" {
+		props = append(props, fmt.Sprintf("WidthUnit: %s", w.WidthUnit))
+	}
+	if w.ImageWidth != "" && w.ImageWidth != "100" {
+		props = append(props, fmt.Sprintf("Width: %s", w.ImageWidth))
+	}
+	if w.HeightUnit != "" && w.HeightUnit != "auto" {
+		props = append(props, fmt.Sprintf("HeightUnit: %s", w.HeightUnit))
+	}
+	if w.ImageHeight != "" && w.ImageHeight != "100" {
+		props = append(props, fmt.Sprintf("Height: %s", w.ImageHeight))
+	}
+	if w.DisplayAs != "" && w.DisplayAs != "fullImage" {
+		props = append(props, fmt.Sprintf("DisplayAs: %s", w.DisplayAs))
+	}
+	if w.Responsive != "" && w.Responsive != "true" {
+		props = append(props, fmt.Sprintf("Responsive: %s", w.Responsive))
+	}
+	if w.OnClickType == "enlarge" {
+		props = append(props, "OnClickType: enlarge")
+	}
+	if w.Action != "" {
+		props = append(props, fmt.Sprintf("OnClick: %s", w.Action))
+	}
+	return props
+}
diff --git a/mdl/executor/cmd_pages_describe_pluggable.go b/mdl/executor/cmd_pages_describe_pluggable.go
index ace68219af..28add25efa 100644
--- a/mdl/executor/cmd_pages_describe_pluggable.go
+++ b/mdl/executor/cmd_pages_describe_pluggable.go
@@ -941,6 +941,39 @@ func extractCustomWidgetPropertyAssociation(ctx *ExecContext, w map[string]any,
 }
 
 // extractCustomWidgetPropertyString extracts a string property value from a CustomWidget.
+// extractCustomWidgetPropertyImage reads an image-typed property's stored
+// reference — the WidgetValue's `Image` key, holding a three-part
+// Module.Collection.Image qualified name.
+//
+// It resolves the property through its TypePointer like every other extractor
+// here, rather than by position: the Image widget has TWO image-typed
+// properties (`imageObject` and `defaultImageDynamic`), so taking the first
+// Image found would return the wrong one.
+func extractCustomWidgetPropertyImage(ctx *ExecContext, w map[string]any, propertyKey string) string {
+	obj, ok := w["Object"].(map[string]any)
+	if !ok {
+		return ""
+	}
+	propTypeKeyMap := buildPropertyTypeKeyMap(w, false)
+	for _, prop := range getBsonArrayElements(obj["Properties"]) {
+		propMap, ok := prop.(map[string]any)
+		if !ok {
+			continue
+		}
+		if propTypeKeyMap[extractBinaryID(propMap["TypePointer"])] != propertyKey {
+			continue
+		}
+		value, ok := propMap["Value"].(map[string]any)
+		if !ok {
+			continue
+		}
+		if img, ok := value["Image"].(string); ok {
+			return img
+		}
+	}
+	return ""
+}
+
 func extractCustomWidgetPropertyString(ctx *ExecContext, w map[string]any, propertyKey string) string {
 	obj, ok := w["Object"].(map[string]any)
 	if !ok {
@@ -1124,6 +1157,7 @@ func extractExplicitProperties(ctx *ExecContext, w map[string]any) []rawExplicit
 // extractImageProperties extracts properties from a pluggable Image CustomWidget.
 func extractImageProperties(ctx *ExecContext, w map[string]any, widget *rawWidget) {
 	widget.ImageType = extractCustomWidgetPropertyString(ctx, w, "datasource")
+	widget.ImageObject = extractCustomWidgetPropertyImage(ctx, w, "imageObject")
 	widget.ImageUrl = extractCustomWidgetPropertyTextTemplate(ctx, w, "imageUrl")
 	widget.AlternativeText = extractCustomWidgetPropertyTextTemplate(ctx, w, "alternativeText")
 	widget.ImageWidth = extractCustomWidgetPropertyString(ctx, w, "width")
diff --git a/mdl/executor/cmd_workflows.go b/mdl/executor/cmd_workflows.go
index d9b1083f8d..2b48da69e4 100644
--- a/mdl/executor/cmd_workflows.go
+++ b/mdl/executor/cmd_workflows.go
@@ -197,14 +197,12 @@ func describeWorkflowToString(ctx *ExecContext, name ast.QualifiedName) (string,
 
 	// Display name
 	if targetWf.WorkflowName != "" {
-		escaped := strings.ReplaceAll(targetWf.WorkflowName, "'", "''")
-		lines = append(lines, fmt.Sprintf("  display '%s'", escaped))
+		lines = append(lines, fmt.Sprintf("  display %s", mdlQuoted(targetWf.WorkflowName)))
 	}
 
 	// Description
 	if targetWf.WorkflowDescription != "" {
-		escaped := strings.ReplaceAll(targetWf.WorkflowDescription, "'", "''")
-		lines = append(lines, fmt.Sprintf("  description '%s'", escaped))
+		lines = append(lines, fmt.Sprintf("  description %s", mdlQuoted(targetWf.WorkflowDescription)))
 	}
 
 	// Export level (only emit when non-empty)
@@ -219,7 +217,7 @@ func describeWorkflowToString(ctx *ExecContext, name ast.QualifiedName) (string,
 
 	// Due date
 	if targetWf.DueDate != "" {
-		lines = append(lines, fmt.Sprintf("  due date '%s'", targetWf.DueDate))
+		lines = append(lines, fmt.Sprintf("  due date %s", mdlQuoted(targetWf.DueDate)))
 	}
 
 	lines = append(lines, "")
@@ -237,14 +235,50 @@ func describeWorkflowToString(ctx *ExecContext, name ast.QualifiedName) (string,
 	return strings.Join(lines, "\n"), nil, nil
 }
 
-// formatAnnotation returns an ANNOTATION statement for a workflow activity annotation.
-// The annotation is emitted as a parseable MDL statement so it survives round-trips.
+// formatAnnotation renders an activity's annotation as MDL comment lines.
+//
+// It used to emit `annotation '<text>';`, and its own doc comment claimed that
+// statement "survives round-trips". It does not, and has not since MDL-WF04: a
+// standalone `annotation` in a workflow body is refused at check time AND by
+// execCreateWorkflow, because Mendix constructs every child of the activity flow
+// with a Flow parent and no annotation type takes one — the written unit cannot
+// be LOADED, so Studio Pro will not open the project. The describer was emitting
+// the one construct the writer refuses, and a 23-activity workflow produced 13
+// MDL-WF04 errors from unmodified DESCRIBE output (mendixlabs/mxcli#1007).
+//
+// A comment is the honest emit today, not a workaround. The annotation being
+// re-emitted here is ATTACHED to an activity, and although the write path stores
+// an attached annotation (addActivityBaseFields), no MDL input can produce one:
+// MDLWorkflow.g4 has only the standalone `workflowAnnotationStmt`. So the text is
+// unwritable either way, and carrying it as a comment at least keeps it in front
+// of whoever edits the script. The `annotation:` marker says what the line was.
+//
+// The microflow domain does have an attached form (`@annotation 'text'`, see
+// MDLMicroflow.g4) and it round-trips properly. Giving workflow activities the
+// same prefix is the fix that would preserve the annotation rather than
+// commenting it out; it is a grammar change, and deliberately not bundled here.
 func formatAnnotation(annotation string, indent string) string {
 	if annotation == "" {
 		return ""
 	}
-	escaped := strings.ReplaceAll(annotation, "'", "''")
-	return fmt.Sprintf("%sannotation '%s';", indent, escaped)
+	return annotationComment(annotation, indent)
+}
+
+// annotationComment renders text as one or more `-- annotation:` lines. An
+// annotation may contain newlines, and a `--` comment runs to end of line, so a
+// multi-line note has to be prefixed line by line or everything after the first
+// newline becomes stray tokens — the same failure the statement form had.
+func annotationComment(text, indent string) string {
+	lines := strings.Split(text, "\n")
+	for i, l := range lines {
+		l = strings.TrimRight(l, "\r")
+		if i == 0 {
+			lines[i] = indent + "-- annotation: " + l
+			continue
+		}
+		lines[i] = indent + "--   " + l
+	}
+	return strings.Join(lines, "\n")
 }
 
 // boundaryEventKeyword maps an EventType string to the MDL BOUNDARY EVENT keyword sequence.
@@ -269,8 +303,7 @@ func formatBoundaryEvents(events []*workflows.BoundaryEvent, indent string) []st
 	for _, event := range events {
 		keyword := boundaryEventKeyword(event.EventType)
 		if event.TimerDelay != "" {
-			escapedDelay := strings.ReplaceAll(event.TimerDelay, "'", "''")
-			lines = append(lines, fmt.Sprintf("%s%s '%s'", indent, keyword, escapedDelay))
+			lines = append(lines, fmt.Sprintf("%s%s %s", indent, keyword, mdlQuoted(event.TimerDelay)))
 		} else {
 			lines = append(lines, fmt.Sprintf("%s%s", indent, keyword))
 		}
@@ -323,8 +356,7 @@ func formatWorkflowActivities(flow *workflows.Flow, indent string) []string {
 			// (issuetracker #16). Re-applying the shorter form rebuilds the same
 			// Caption, so dropping it is lossless.
 			if caption := a.Caption; caption != "" && caption != target && caption != a.Name {
-				escapedCaption := strings.ReplaceAll(caption, "'", "''")
-				actLines = append(actLines, fmt.Sprintf("%sjump to %s comment '%s'", indent, mdlIdent(target), escapedCaption))
+				actLines = append(actLines, fmt.Sprintf("%sjump to %s comment %s", indent, mdlIdent(target), mdlQuoted(caption)))
 			} else {
 				actLines = append(actLines, fmt.Sprintf("%sjump to %s", indent, mdlIdent(target)))
 			}
@@ -337,12 +369,9 @@ func formatWorkflowActivities(flow *workflows.Flow, indent string) []string {
 				actLines = append(actLines, formatAnnotation(a.Annotation, indent))
 			}
 			if a.DelayExpression != "" {
-				escapedDelay := strings.ReplaceAll(a.DelayExpression, "'", "''")
-				escapedCaption := strings.ReplaceAll(caption, "'", "''")
-				actLines = append(actLines, fmt.Sprintf("%swait for timer '%s' comment '%s'", indent, escapedDelay, escapedCaption))
+				actLines = append(actLines, fmt.Sprintf("%swait for timer %s comment %s", indent, mdlQuoted(a.DelayExpression), mdlQuoted(caption)))
 			} else {
-				escapedCaption := strings.ReplaceAll(caption, "'", "''")
-				actLines = append(actLines, fmt.Sprintf("%swait for timer comment '%s'", indent, escapedCaption))
+				actLines = append(actLines, fmt.Sprintf("%swait for timer comment %s", indent, mdlQuoted(caption)))
 			}
 		case *workflows.WaitForNotificationActivity:
 			caption := a.Caption
@@ -368,13 +397,15 @@ func formatWorkflowActivities(flow *workflows.Flow, indent string) []string {
 			// Skip - auto-generated by Mendix, implicit in MDL syntax
 			continue
 		case *workflows.WorkflowAnnotationActivity:
-			// Standalone annotation (sticky note) - emit as ANNOTATION statement
-			if a.Description != "" {
-				escapedDesc := strings.ReplaceAll(a.Description, "'", "''")
-				actLines = []string{fmt.Sprintf("%sannotation '%s'", indent, escapedDesc)}
-			} else {
+			// A standalone annotation (sticky note) read back from the model. Emitted
+			// as a comment for the same reason as an attached one: the `annotation`
+			// statement it used to produce is refused by MDL-WF04 and by exec, so the
+			// describe output could not be re-run (mendixlabs/mxcli#1007).
+			if a.Description == "" {
 				continue
 			}
+			isComment = true
+			actLines = []string{annotationComment(a.Description, indent)}
 		case *workflows.GenericWorkflowActivity:
 			isComment = true
 			caption := a.Caption
@@ -424,7 +455,7 @@ func formatUserTask(a *workflows.UserTask, indent string) []string {
 	if a.IsMulti {
 		taskKeyword = "multi user task"
 	}
-	lines = append(lines, fmt.Sprintf("%s%s %s '%s'", indent, taskKeyword, mdlIdent(nameStr), caption))
+	lines = append(lines, fmt.Sprintf("%s%s %s %s", indent, taskKeyword, mdlIdent(nameStr), mdlQuoted(caption)))
 
 	if a.Page != "" {
 		lines = append(lines, fmt.Sprintf("%s  page %s", indent, a.Page))
@@ -439,7 +470,7 @@ func formatUserTask(a *workflows.UserTask, indent string) []string {
 			}
 		case *workflows.XPathBasedUserSource:
 			if us.XPath != "" {
-				lines = append(lines, fmt.Sprintf("%s  targeting users xpath '%s'", indent, us.XPath))
+				lines = append(lines, fmt.Sprintf("%s  targeting users xpath %s", indent, mdlQuoted(us.XPath)))
 			}
 		case *workflows.MicroflowGroupSource:
 			if us.Microflow != "" {
@@ -447,7 +478,7 @@ func formatUserTask(a *workflows.UserTask, indent string) []string {
 			}
 		case *workflows.XPathGroupSource:
 			if us.XPath != "" {
-				lines = append(lines, fmt.Sprintf("%s  targeting groups xpath '%s'", indent, us.XPath))
+				lines = append(lines, fmt.Sprintf("%s  targeting groups xpath %s", indent, mdlQuoted(us.XPath)))
 			}
 		}
 	}
@@ -458,14 +489,12 @@ func formatUserTask(a *workflows.UserTask, indent string) []string {
 
 	// Due date (task-level)
 	if a.DueDate != "" {
-		escapedDueDate := strings.ReplaceAll(a.DueDate, "'", "''")
-		lines = append(lines, fmt.Sprintf("%s  due date '%s'", indent, escapedDueDate))
+		lines = append(lines, fmt.Sprintf("%s  due date %s", indent, mdlQuoted(a.DueDate)))
 	}
 
 	// Task description
 	if a.TaskDescription != "" {
-		escaped := strings.ReplaceAll(a.TaskDescription, "'", "''")
-		lines = append(lines, fmt.Sprintf("%s  description '%s'", indent, escaped))
+		lines = append(lines, fmt.Sprintf("%s  description %s", indent, mdlQuoted(a.TaskDescription)))
 	}
 
 	// Outcomes
@@ -480,12 +509,12 @@ func formatUserTask(a *workflows.UserTask, indent string) []string {
 				outValue = outcome.Name
 			}
 			if outcome.Flow != nil && len(outcome.Flow.Activities) > 0 {
-				lines = append(lines, fmt.Sprintf("%s    '%s' {", indent, outValue))
+				lines = append(lines, fmt.Sprintf("%s    %s {", indent, mdlQuoted(outValue)))
 				subLines := formatWorkflowActivities(outcome.Flow, indent+"      ")
 				lines = append(lines, subLines...)
 				lines = append(lines, fmt.Sprintf("%s    }", indent))
 			} else {
-				lines = append(lines, fmt.Sprintf("%s    '%s' { }", indent, outValue))
+				lines = append(lines, fmt.Sprintf("%s    %s { }", indent, mdlQuoted(outValue)))
 			}
 		}
 	}
@@ -521,7 +550,7 @@ func formatCallMicroflowTask(a *workflows.CallMicroflowTask, indent string) []st
 			if idx := strings.LastIndex(paramName, "."); idx >= 0 {
 				paramName = paramName[idx+1:]
 			}
-			params = append(params, fmt.Sprintf("%s = '%s'", paramName, strings.ReplaceAll(pm.Expression, "'", "''")))
+			params = append(params, fmt.Sprintf("%s = %s", paramName, mdlQuoted(pm.Expression)))
 		}
 		lines = append(lines, fmt.Sprintf("%scall microflow %s with (%s) -- %s", indent, mf, strings.Join(params, ", "), caption))
 	} else {
@@ -583,7 +612,6 @@ func formatCallWorkflowActivity(a *workflows.CallWorkflowActivity, indent string
 		wf = "?"
 	}
 
-	escapedCaption := strings.ReplaceAll(caption, "'", "''")
 	if len(a.ParameterMappings) > 0 {
 		var params []string
 		for _, pm := range a.ParameterMappings {
@@ -591,11 +619,11 @@ func formatCallWorkflowActivity(a *workflows.CallWorkflowActivity, indent string
 			if idx := strings.LastIndex(paramName, "."); idx >= 0 {
 				paramName = paramName[idx+1:]
 			}
-			params = append(params, fmt.Sprintf("%s = '%s'", paramName, strings.ReplaceAll(pm.Expression, "'", "''")))
+			params = append(params, fmt.Sprintf("%s = %s", paramName, mdlQuoted(pm.Expression)))
 		}
-		lines = append(lines, fmt.Sprintf("%scall workflow %s comment '%s' with (%s)", indent, wf, escapedCaption, strings.Join(params, ", ")))
+		lines = append(lines, fmt.Sprintf("%scall workflow %s comment %s with (%s)", indent, wf, mdlQuoted(caption), strings.Join(params, ", ")))
 	} else {
-		lines = append(lines, fmt.Sprintf("%scall workflow %s comment '%s'", indent, wf, escapedCaption))
+		lines = append(lines, fmt.Sprintf("%scall workflow %s comment %s", indent, wf, mdlQuoted(caption)))
 	}
 
 	// BoundaryEvents
@@ -618,8 +646,7 @@ func formatExclusiveSplit(a *workflows.ExclusiveSplitActivity, indent string) []
 	}
 
 	if a.Expression != "" {
-		escapedExpr := strings.ReplaceAll(a.Expression, "'", "''")
-		lines = append(lines, fmt.Sprintf("%sdecision '%s' -- %s", indent, escapedExpr, caption))
+		lines = append(lines, fmt.Sprintf("%sdecision %s -- %s", indent, mdlQuoted(a.Expression), caption))
 	} else {
 		lines = append(lines, fmt.Sprintf("%sdecision -- %s", indent, caption))
 	}
diff --git a/mdl/executor/cmd_workflows_write.go b/mdl/executor/cmd_workflows_write.go
index afc53a8eaf..5313e8e612 100644
--- a/mdl/executor/cmd_workflows_write.go
+++ b/mdl/executor/cmd_workflows_write.go
@@ -36,6 +36,19 @@ func execCreateWorkflow(ctx *ExecContext, s *ast.CreateWorkflowStmt) error {
 				"remove it, or keep the note as an MDL comment (`-- ...`) [MDL-WF04]")
 	}
 
+	// Same for a jump whose target names no activity. A jump target is the only
+	// INTRA-document reference a workflow has, and validateWorkflowStatementRefs
+	// resolves only external ones (microflows, pages, entities), so nothing
+	// looked at it: the jump was written pointing at itself and surfaced under
+	// the native validator as CE6681, an error describing a different fault
+	// (mendixlabs/mxcli#1005). Refused with the check-time rule's own function so
+	// the two cannot drift, and here as well as at check time for the #833
+	// reason — exec is reachable without check.
+	if vs := ValidateWorkflowJumpTargets(s); len(vs) > 0 {
+		return mdlerrors.NewValidationf("workflow '%s': %s\n  → %s",
+			s.Name.String(), vs[0].Message, vs[0].Suggestion)
+	}
+
 	// Refuse a broken reference here as well as at check time. `check
 	// --references` reports these, but exec runs a different pass and wrote the
 	// workflow anyway, so a script that skipped check produced a model the build
@@ -494,15 +507,32 @@ func buildParallelSplit(n *ast.WorkflowParallelSplitNode) *workflows.ParallelSpl
 	return act
 }
 
+// jumpActivityName is the base name every jump activity gets; deduplication
+// appends a counter, giving JumpTo, JumpTo2, ...
+//
+// It used to be the TARGET's name, which made the jump a second activity
+// carrying that name. Mendix resolves TargetActivity by name, so the jump could
+// resolve to itself — the build then fails CE6681 ("not possible to jump to end
+// activities or jump-to activities"), an error naming a different fault
+// (mendixlabs/mxcli#1005). Whether it did depended on flow order, because
+// deduplication renames the SECOND activity it meets with a given name:
+//
+//	backward jump (target first)  jump becomes StepB2, target keeps StepB  — worked
+//	forward  jump (jump first)    jump KEEPS StepB, target becomes StepB2  — broke
+//
+// so a jump to a perfectly valid activity was also affected, which is why fixing
+// only the unresolved-target case would not have been enough.
+const jumpActivityName = "JumpTo"
+
 func buildJumpTo(n *ast.WorkflowJumpToNode) *workflows.JumpToActivity {
 	act := &workflows.JumpToActivity{}
 	act.ID = model.ID(generateWorkflowUUID())
-	act.Name = n.Target
+	act.Name = jumpActivityName
 	act.Caption = n.Caption
 	act.TargetActivity = n.Target
 
 	if act.Caption == "" {
-		act.Caption = act.Name
+		act.Caption = n.Target
 	}
 
 	return act
@@ -556,73 +586,102 @@ func buildEndWorkflow(n *ast.WorkflowEndNode) *workflows.EndWorkflowActivity {
 // Mendix Studio Pro requires unique activity names (CE0495).
 func deduplicateActivityNames(activities []workflows.WorkflowActivity) {
 	nameCount := make(map[string]int)
-	deduplicateActivityNamesInFlow(activities, nameCount)
+	// Two passes, jumps LAST.
+	//
+	// A jump is not a jump target (Mendix refuses that, CE6681), so it has no
+	// claim on a name a real activity wants. Letting it compete in flow order is
+	// how a FORWARD jump used to take its target's name and push the target to
+	// <name>2 — leaving the jump pointing at itself even though the target
+	// existed (mendixlabs/mxcli#1005). Naming jumps last means only jumps are
+	// ever suffixed, whatever they are called and wherever they appear.
+	deduplicateActivityNamesInFlow(activities, nameCount, false)
+	deduplicateActivityNamesInFlow(activities, nameCount, true)
 }
 
-// deduplicateActivityNamesInFlow recursively deduplicates activity names.
-func deduplicateActivityNamesInFlow(activities []workflows.WorkflowActivity, nameCount map[string]int) {
+// deduplicateActivityNamesInFlow recursively deduplicates activity names. Both
+// passes walk the whole tree; jumpPass selects which activities are renamed, so
+// a jump nested in an outcome flow is still reached in the second pass.
+func deduplicateActivityNamesInFlow(activities []workflows.WorkflowActivity, nameCount map[string]int, jumpPass bool) {
 	for _, act := range activities {
 		switch a := act.(type) {
 		case *workflows.UserTask:
-			a.Name = uniqueName(a.Name, nameCount)
+			if !jumpPass {
+				a.Name = uniqueName(a.Name, nameCount)
+			}
 			for _, outcome := range a.Outcomes {
 				if outcome.Flow != nil {
-					deduplicateActivityNamesInFlow(outcome.Flow.Activities, nameCount)
+					deduplicateActivityNamesInFlow(outcome.Flow.Activities, nameCount, jumpPass)
 				}
 			}
 		case *workflows.CallMicroflowTask:
-			a.Name = uniqueName(a.Name, nameCount)
+			if !jumpPass {
+				a.Name = uniqueName(a.Name, nameCount)
+			}
 			for _, outcome := range a.Outcomes {
 				switch o := outcome.(type) {
 				case *workflows.BooleanConditionOutcome:
 					if o.Flow != nil {
-						deduplicateActivityNamesInFlow(o.Flow.Activities, nameCount)
+						deduplicateActivityNamesInFlow(o.Flow.Activities, nameCount, jumpPass)
 					}
 				case *workflows.EnumerationValueConditionOutcome:
 					if o.Flow != nil {
-						deduplicateActivityNamesInFlow(o.Flow.Activities, nameCount)
+						deduplicateActivityNamesInFlow(o.Flow.Activities, nameCount, jumpPass)
 					}
 				case *workflows.VoidConditionOutcome:
 					if o.Flow != nil {
-						deduplicateActivityNamesInFlow(o.Flow.Activities, nameCount)
+						deduplicateActivityNamesInFlow(o.Flow.Activities, nameCount, jumpPass)
 					}
 				}
 			}
 		case *workflows.CallWorkflowActivity:
-			a.Name = uniqueName(a.Name, nameCount)
+			if !jumpPass {
+				a.Name = uniqueName(a.Name, nameCount)
+			}
 		case *workflows.ExclusiveSplitActivity:
-			a.Name = uniqueName(a.Name, nameCount)
+			if !jumpPass {
+				a.Name = uniqueName(a.Name, nameCount)
+			}
 			for _, outcome := range a.Outcomes {
 				switch o := outcome.(type) {
 				case *workflows.BooleanConditionOutcome:
 					if o.Flow != nil {
-						deduplicateActivityNamesInFlow(o.Flow.Activities, nameCount)
+						deduplicateActivityNamesInFlow(o.Flow.Activities, nameCount, jumpPass)
 					}
 				case *workflows.EnumerationValueConditionOutcome:
 					if o.Flow != nil {
-						deduplicateActivityNamesInFlow(o.Flow.Activities, nameCount)
+						deduplicateActivityNamesInFlow(o.Flow.Activities, nameCount, jumpPass)
 					}
 				case *workflows.VoidConditionOutcome:
 					if o.Flow != nil {
-						deduplicateActivityNamesInFlow(o.Flow.Activities, nameCount)
+						deduplicateActivityNamesInFlow(o.Flow.Activities, nameCount, jumpPass)
 					}
 				}
 			}
 		case *workflows.ParallelSplitActivity:
-			a.Name = uniqueName(a.Name, nameCount)
+			if !jumpPass {
+				a.Name = uniqueName(a.Name, nameCount)
+			}
 			for _, outcome := range a.Outcomes {
 				if outcome.Flow != nil {
-					deduplicateActivityNamesInFlow(outcome.Flow.Activities, nameCount)
+					deduplicateActivityNamesInFlow(outcome.Flow.Activities, nameCount, jumpPass)
 				}
 			}
 		case *workflows.JumpToActivity:
-			a.Name = uniqueName(a.Name, nameCount)
+			if jumpPass {
+				a.Name = uniqueName(a.Name, nameCount)
+			}
 		case *workflows.WaitForTimerActivity:
-			a.Name = uniqueName(a.Name, nameCount)
+			if !jumpPass {
+				a.Name = uniqueName(a.Name, nameCount)
+			}
 		case *workflows.WaitForNotificationActivity:
-			a.Name = uniqueName(a.Name, nameCount)
+			if !jumpPass {
+				a.Name = uniqueName(a.Name, nameCount)
+			}
 		case *workflows.EndWorkflowActivity:
-			a.Name = uniqueName(a.Name, nameCount)
+			if !jumpPass {
+				a.Name = uniqueName(a.Name, nameCount)
+			}
 		}
 	}
 }
diff --git a/mdl/executor/helpers.go b/mdl/executor/helpers.go
index 7a1c5b43f1..abba155a01 100644
--- a/mdl/executor/helpers.go
+++ b/mdl/executor/helpers.go
@@ -263,6 +263,13 @@ func validateWidgetReferences(ctx *ExecContext, widgets []*ast.WidgetV3, sc *scr
 		}
 	}
 
+	if len(refs.images) > 0 {
+		// No same-script exemption: MDL cannot create an image collection entry,
+		// so an image reference can only ever resolve against the project.
+		known, collections := buildImageQualifiedNames(ctx)
+		errors = append(errors, imageRefErrors(refs.images, known, collections)...)
+	}
+
 	return errors
 }
 
@@ -273,6 +280,7 @@ type widgetRefCollector struct {
 	pages      []string
 	snippets   []string
 	entities   []string
+	images     []string
 }
 
 // dedupe collapses repeated references within each category, preserving first
@@ -286,6 +294,7 @@ func (c *widgetRefCollector) dedupe() {
 	c.pages = uniqueStrings(c.pages)
 	c.snippets = uniqueStrings(c.snippets)
 	c.entities = uniqueStrings(c.entities)
+	c.images = uniqueStrings(c.images)
 }
 
 // uniqueStrings returns s with duplicate values removed, preserving order.
@@ -307,7 +316,8 @@ func uniqueStrings(s []string) []string {
 
 func (c *widgetRefCollector) empty() bool {
 	return len(c.microflows) == 0 && len(c.nanoflows) == 0 &&
-		len(c.pages) == 0 && len(c.snippets) == 0 && len(c.entities) == 0
+		len(c.pages) == 0 && len(c.snippets) == 0 && len(c.entities) == 0 &&
+		len(c.images) == 0
 }
 
 func (c *widgetRefCollector) collectFromWidgets(widgets []*ast.WidgetV3) {
@@ -345,6 +355,14 @@ func (c *widgetRefCollector) collectFromWidget(w *ast.WidgetV3) {
 		c.snippets = append(c.snippets, snippet)
 	}
 
+	// An image widget's Image collection entry. Only the image widget spells it
+	// this way; `Image` on any other widget type is not a collection reference.
+	if strings.EqualFold(w.Type, "image") {
+		if img := strings.TrimSpace(w.GetStringProp("Image")); img != "" {
+			c.images = append(c.images, img)
+		}
+	}
+
 	// Recurse into children
 	c.collectFromWidgets(w.Children)
 }
diff --git a/mdl/executor/identifier_quoting.go b/mdl/executor/identifier_quoting.go
index 4adc6cffc1..ed069a3c18 100644
--- a/mdl/executor/identifier_quoting.go
+++ b/mdl/executor/identifier_quoting.go
@@ -3,10 +3,32 @@
 package executor
 
 import (
+	"strings"
+
 	antlr "github.com/antlr4-go/antlr/v4"
 	"github.com/mendixlabs/mxcli/mdl/grammar/parser"
 )
 
+// mdlQuoted renders s as a complete MDL single-quoted string literal, doubling
+// every embedded quote — the escape the MDL lexer requires (`'it”s'`), and the
+// one Mendix Studio Pro's own expression syntax uses. Backslashes are NOT an
+// escape here.
+//
+// It returns the quotes as well as the escaped body, deliberately. The
+// describers used to write `fmt.Sprintf("... '%s'", escapeMe)` and escape the
+// argument separately at each site, which is one thing to remember per emit —
+// and six of twenty-three sites did not. The worst was a user task's
+// `targeting users xpath`, whose payload is an XPath containing quoted
+// constraints (`[System.UserRoles = '[%UserRole_Banker%]']`), so DESCRIBE
+// WORKFLOW output would not re-parse for any workflow using one
+// (mendixlabs/mxcli#1006). Keeping the quotes and the escaping in one function
+// makes an unescaped emit impossible to write by omission.
+//
+// A companion test asserts no `'%s'` remains in the describers.
+func mdlQuoted(s string) string {
+	return "'" + strings.ReplaceAll(s, "'", "''") + "'"
+}
+
 // mdlIdent renders name as an MDL identifier suitable for DESCRIBE output,
 // double-quoting it when it would not lex as a bare IDENTIFIER — e.g. when it
 // collides with a reserved keyword ("List", "Column", "Template", …). This keeps
diff --git a/mdl/executor/issue1005_jump_target_test.go b/mdl/executor/issue1005_jump_target_test.go
new file mode 100644
index 0000000000..ea13910bf1
--- /dev/null
+++ b/mdl/executor/issue1005_jump_target_test.go
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"strings"
+	"testing"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+	"github.com/mendixlabs/mxcli/mdl/visitor"
+	"github.com/mendixlabs/mxcli/sdk/workflows"
+)
+
+// mendixlabs/mxcli#1005 — a `jump to` whose target names no activity was
+// silently written as a jump to ITSELF, because buildJumpTo named the jump after
+// its target. Mendix resolves TargetActivity by name, so the only activity
+// carrying the missing name was the jump; the build then failed CE6681 ("not
+// possible to jump to end activities or jump-to activities"), naming a different
+// fault entirely.
+
+func buildWorkflowFrom(t *testing.T, src string) []workflows.WorkflowActivity {
+	t.Helper()
+	prog, errs := visitor.Build(src)
+	if len(errs) > 0 {
+		t.Fatalf("parse: %v", errs)
+	}
+	wf, ok := prog.Statements[0].(*ast.CreateWorkflowStmt)
+	if !ok {
+		t.Fatalf("statement is %T, want *ast.CreateWorkflowStmt", prog.Statements[0])
+	}
+	acts := buildWorkflowActivities(wf.Activities)
+	deduplicateActivityNames(acts)
+	return acts
+}
+
+// findJumpAndNames returns the single jump in the tree and every non-jump name.
+func findJumpAndNames(acts []workflows.WorkflowActivity) (*workflows.JumpToActivity, map[string]bool) {
+	names := map[string]bool{}
+	var jump *workflows.JumpToActivity
+	var walk func([]workflows.WorkflowActivity)
+	walk = func(list []workflows.WorkflowActivity) {
+		for _, a := range list {
+			switch v := a.(type) {
+			case *workflows.JumpToActivity:
+				jump = v
+			case *workflows.CallMicroflowTask:
+				names[v.Name] = true
+				for _, o := range v.Outcomes {
+					switch oo := o.(type) {
+					case *workflows.BooleanConditionOutcome:
+						if oo.Flow != nil {
+							walk(oo.Flow.Activities)
+						}
+					case *workflows.VoidConditionOutcome:
+						if oo.Flow != nil {
+							walk(oo.Flow.Activities)
+						}
+					}
+				}
+			case *workflows.UserTask:
+				names[v.Name] = true
+				for _, o := range v.Outcomes {
+					if o.Flow != nil {
+						walk(o.Flow.Activities)
+					}
+				}
+			}
+		}
+	}
+	walk(acts)
+	return jump, names
+}
+
+const jumpBackward = `create workflow M.WF
+  parameter $WorkflowContext: M.E
+begin
+  call microflow M.StepA with (P = '$WorkflowContext')
+    outcomes DEFAULT -> { };
+  call microflow M.StepB with (P = '$WorkflowContext')
+    outcomes
+      true -> { }
+      false -> { jump to StepB comment 'retry'; };
+end workflow;`
+
+// The jump appears BEFORE its target. This is the case the report does not
+// cover: its trigger table says a jump to a real activity is fine, and that
+// holds only for a backward jump. Deduplication renames the SECOND activity it
+// meets, so in flow order the jump took StepB and the real StepB became StepB2.
+const jumpForward = `create workflow M.WF
+  parameter $WorkflowContext: M.E
+begin
+  call microflow M.StepA with (P = '$WorkflowContext')
+    outcomes
+      true -> { }
+      false -> { jump to StepB comment 'skip ahead'; };
+  call microflow M.StepB with (P = '$WorkflowContext')
+    outcomes DEFAULT -> { };
+end workflow;`
+
+func TestJumpTo_NeverTakesTheTargetsName(t *testing.T) {
+	for name, src := range map[string]string{"backward": jumpBackward, "forward": jumpForward} {
+		t.Run(name, func(t *testing.T) {
+			jump, names := findJumpAndNames(buildWorkflowFrom(t, src))
+			if jump == nil {
+				t.Fatal("no jump activity was built")
+			}
+			if jump.Name == jump.TargetActivity {
+				t.Errorf("jump is named after its target (%q) — it targets itself", jump.Name)
+			}
+			if !names[jump.TargetActivity] {
+				t.Errorf("target %q is not the name of any activity; names present: %v",
+					jump.TargetActivity, names)
+			}
+			if jump.TargetActivity != "StepB" {
+				t.Errorf("TargetActivity = %q, want StepB", jump.TargetActivity)
+			}
+		})
+	}
+}
+
+// The caption a user wrote must survive the renaming — it is the only thing
+// distinguishing two jumps in Studio Pro.
+func TestJumpTo_KeepsTheAuthoredCaption(t *testing.T) {
+	jump, _ := findJumpAndNames(buildWorkflowFrom(t, jumpBackward))
+	if jump.Caption != "retry" {
+		t.Errorf("Caption = %q, want %q", jump.Caption, "retry")
+	}
+}
+
+// Two jumps in one workflow must still get distinct names.
+func TestJumpTo_TwoJumpsGetDistinctNames(t *testing.T) {
+	src := `create workflow M.WF
+  parameter $WorkflowContext: M.E
+begin
+  call microflow M.StepA with (P = '$WorkflowContext')
+    outcomes
+      true -> { jump to StepA comment 'again'; }
+      false -> { jump to StepA comment 'and again'; };
+end workflow;`
+	acts := buildWorkflowFrom(t, src)
+	seen := map[string]int{}
+	var walk func([]workflows.WorkflowActivity)
+	walk = func(list []workflows.WorkflowActivity) {
+		for _, a := range list {
+			switch v := a.(type) {
+			case *workflows.JumpToActivity:
+				seen[v.Name]++
+			case *workflows.CallMicroflowTask:
+				seen[v.Name]++
+				for _, o := range v.Outcomes {
+					if b, ok := o.(*workflows.BooleanConditionOutcome); ok && b.Flow != nil {
+						walk(b.Flow.Activities)
+					}
+				}
+			}
+		}
+	}
+	walk(acts)
+	for name, n := range seen {
+		if n > 1 {
+			t.Errorf("name %q used %d times — CE0495", name, n)
+		}
+	}
+}
+
+func workflowRuleIDs(t *testing.T, src string) []string {
+	t.Helper()
+	prog, errs := visitor.Build(src)
+	if len(errs) > 0 {
+		t.Fatalf("parse: %v", errs)
+	}
+	var out []string
+	for _, stmt := range prog.Statements {
+		if wf, ok := stmt.(*ast.CreateWorkflowStmt); ok {
+			for _, v := range ValidateWorkflow(wf) {
+				out = append(out, v.RuleID)
+			}
+		}
+	}
+	return out
+}
+
+// MDL-WF05 — the check that did not exist. A jump target is the only
+// intra-document reference a workflow has, and nothing resolved it.
+func TestMDLWF05_FlagsADanglingJumpTarget(t *testing.T) {
+	src := `create workflow M.WF
+  parameter $WorkflowContext: M.E
+begin
+  call microflow M.SUB_CheckPackageAvailability with (P = '$WorkflowContext')
+    outcomes
+      true -> { }
+      false -> { jump to callMicroflow2 comment 'back to StepB'; };
+end workflow;`
+	ids := workflowRuleIDs(t, src)
+	found := false
+	for _, id := range ids {
+		if id == "MDL-WF05" {
+			found = true
+		}
+	}
+	if !found {
+		t.Fatalf("no MDL-WF05 for an unresolved jump target; got %v", ids)
+	}
+
+	// The valid names are not obvious from the script — a `call microflow
+	// M.SUB_CheckPackageAvailability` activity is named SUB_CheckPackageAvailability,
+	// which is most of why the wrong name is easy to reach — so the rule must
+	// list them.
+	prog, _ := visitor.Build(src)
+	wf := prog.Statements[0].(*ast.CreateWorkflowStmt)
+	vs := ValidateWorkflowJumpTargets(wf)
+	if len(vs) != 1 {
+		t.Fatalf("got %d violations, want 1", len(vs))
+	}
+	if !strings.Contains(vs[0].Suggestion, "SUB_CheckPackageAvailability") {
+		t.Errorf("suggestion does not list the valid target: %q", vs[0].Suggestion)
+	}
+	if !strings.Contains(vs[0].Message, "CE6681") {
+		t.Errorf("message does not name the build error it prevents: %q", vs[0].Message)
+	}
+}
+
+// The control: a jump to a real activity must NOT be flagged, in both
+// directions. Without this the rule could pass by refusing every jump.
+func TestMDLWF05_AcceptsAValidJumpTarget(t *testing.T) {
+	for name, src := range map[string]string{"backward": jumpBackward, "forward": jumpForward} {
+		t.Run(name, func(t *testing.T) {
+			for _, id := range workflowRuleIDs(t, src) {
+				if id == "MDL-WF05" {
+					t.Errorf("MDL-WF05 fired on a valid %s jump", name)
+				}
+			}
+		})
+	}
+}
+
+// A target inside a nested outcome flow is still a valid target — the collector
+// has to recurse, or every jump into a branch would be refused.
+func TestMDLWF05_FindsATargetInsideANestedFlow(t *testing.T) {
+	src := `create workflow M.WF
+  parameter $WorkflowContext: M.E
+begin
+  call microflow M.Outer with (P = '$WorkflowContext')
+    outcomes
+      true -> {
+        call microflow M.InnerStep with (P = '$WorkflowContext')
+          outcomes DEFAULT -> { };
+      }
+      false -> { jump to InnerStep comment 'into the branch'; };
+end workflow;`
+	for _, id := range workflowRuleIDs(t, src) {
+		if id == "MDL-WF05" {
+			t.Errorf("MDL-WF05 fired on a jump to an activity nested in an outcome flow")
+		}
+	}
+}
+
+// A jump may not target another jump (CE6681), so a jump's own name must not be
+// offered as a valid target.
+func TestMDLWF05_AJumpIsNotAValidTarget(t *testing.T) {
+	src := `create workflow M.WF
+  parameter $WorkflowContext: M.E
+begin
+  call microflow M.StepA with (P = '$WorkflowContext')
+    outcomes
+      true -> { jump to StepA comment 'one'; }
+      false -> { jump to JumpTo comment 'two'; };
+end workflow;`
+	found := false
+	for _, id := range workflowRuleIDs(t, src) {
+		if id == "MDL-WF05" {
+			found = true
+		}
+	}
+	if !found {
+		t.Error("a jump targeting another jump was accepted — Mendix rejects it with CE6681")
+	}
+}
diff --git a/mdl/executor/issue1006_emitter_quoting_test.go b/mdl/executor/issue1006_emitter_quoting_test.go
new file mode 100644
index 0000000000..2ae01edd2b
--- /dev/null
+++ b/mdl/executor/issue1006_emitter_quoting_test.go
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"os"
+	"regexp"
+	"strings"
+	"testing"
+
+	"github.com/mendixlabs/mxcli/mdl/visitor"
+	"github.com/mendixlabs/mxcli/sdk/workflows"
+)
+
+// mendixlabs/mxcli#1006 — DESCRIBE WORKFLOW emitted single-quoted payloads
+// without doubling the quotes inside them, so its own output was a syntax error.
+//
+// The assertion is that the emitted MDL PARSES, not that it contains a
+// particular substring. A substring test would have to encode the escape it is
+// checking for, which is the thing under test; parsing is the property that
+// actually matters and it cannot be satisfied by the wrong escape.
+
+// parsesAsWorkflowBody emits the activities through the real describe path
+// (formatWorkflowActivities, which is what appends the statement terminator),
+// wraps them in the smallest workflow that can contain them, and reports the
+// parse errors if any.
+func parsesAsWorkflowBody(t *testing.T, acts ...workflows.WorkflowActivity) []string {
+	t.Helper()
+	lines := formatWorkflowActivities(&workflows.Flow{Activities: acts}, "  ")
+	src := "create workflow M.WF\n  parameter $WorkflowContext: M.E\nbegin\n" +
+		strings.Join(lines, "\n") + "\nend workflow;"
+	_, errs := visitor.Build(src)
+	if len(errs) == 0 {
+		return nil
+	}
+	out := make([]string, len(errs))
+	for i, e := range errs {
+		out[i] = e.Error()
+	}
+	t.Logf("emitted MDL that failed to parse:\n%s", src)
+	return out
+}
+
+// The reported case: an XPath payload is itself full of single-quoted
+// constraints, so this one is not an edge case — every XPath-targeted user task
+// hits it.
+func TestDescribeWorkflow_XPathUserSourceReparses(t *testing.T) {
+	task := &workflows.UserTask{}
+	task.Name = "Review"
+	task.Caption = "Review"
+	task.Page = "M.ReviewPage"
+	task.UserSource = &workflows.XPathBasedUserSource{
+		XPath: `[System.UserRoles = '[%UserRole_Banker%]']`,
+	}
+	if errs := parsesAsWorkflowBody(t, task); errs != nil {
+		t.Errorf("targeting users xpath does not re-parse: %v", errs)
+	}
+}
+
+// The same emitter, the group variant — unreported, and broken identically.
+func TestDescribeWorkflow_XPathGroupSourceReparses(t *testing.T) {
+	task := &workflows.UserTask{}
+	task.Name = "Review"
+	task.Caption = "Review"
+	task.Page = "M.ReviewPage"
+	task.UserSource = &workflows.XPathGroupSource{
+		XPath: `[System.UserRoles = '[%UserRole_Banker%]']`,
+	}
+	if errs := parsesAsWorkflowBody(t, task); errs != nil {
+		t.Errorf("targeting groups xpath does not re-parse: %v", errs)
+	}
+}
+
+// A caption or an outcome value carrying an ordinary apostrophe. Neither needs
+// an XPath to reach — "Manager's review" is a caption a person would type.
+func TestDescribeWorkflow_ApostropheInCaptionAndOutcomeReparses(t *testing.T) {
+	task := &workflows.UserTask{}
+	task.Name = "Approve"
+	task.Caption = "Manager's review"
+	task.Page = "M.ReviewPage"
+	task.TaskDescription = "Check the customer's limit"
+	task.DueDate = "[%CurrentDateTime%]"
+	task.Outcomes = []*workflows.UserTaskOutcome{
+		{Value: "Won't fix"},
+		{Value: "Approved"},
+	}
+	if errs := parsesAsWorkflowBody(t, task); errs != nil {
+		t.Errorf("apostrophes in caption/description/outcome do not re-parse: %v", errs)
+	}
+}
+
+// mdlQuoted is the whole fix; assert the escape directly so a failure upstream
+// is distinguishable from a failure in a caller.
+func TestMDLQuoted(t *testing.T) {
+	for in, want := range map[string]string{
+		"plain":             "'plain'",
+		"it's":              "'it''s'",
+		`[a = '[%X%]']`:     `'[a = ''[%X%]'']'`,
+		"":                  "''",
+		`already ''doubled`: `'already ''''doubled'`,
+		`back\slash`:        `'back\slash'`, // backslash is not an escape in MDL
+	} {
+		if got := mdlQuoted(in); got != want {
+			t.Errorf("mdlQuoted(%q) = %q, want %q", in, got, want)
+		}
+	}
+}
+
+// The guard against the next omission. Six of twenty-three emit sites in the
+// describers escaped nothing, and each was individually plausible — the pattern
+// `fmt.Sprintf("... '%s'", v)` puts the quotes and the escaping in different
+// places, so forgetting one is invisible at the call site.
+//
+// A source scan rather than more emit tests: a test can only cover the emit
+// positions it happens to construct, and the failure mode here is a NEW site
+// added later. `mdlQuoted` carries its own quotes, so a literal `'%s'` in these
+// files is by construction a site that is not using it.
+func TestDescribers_HaveNoHandRolledStringLiterals(t *testing.T) {
+	pattern := regexp.MustCompile(`'%s'`)
+	for _, f := range []string{"cmd_workflows.go"} {
+		src, err := os.ReadFile(f)
+		if err != nil {
+			t.Fatal(err)
+		}
+		for i, line := range strings.Split(string(src), "\n") {
+			if pattern.MatchString(line) {
+				t.Errorf("%s:%d emits a hand-rolled MDL string literal — use mdlQuoted:\n\t%s",
+					f, i+1, strings.TrimSpace(line))
+			}
+		}
+	}
+}
diff --git a/mdl/executor/issue1007_annotation_emit_test.go b/mdl/executor/issue1007_annotation_emit_test.go
new file mode 100644
index 0000000000..b01c8885c3
--- /dev/null
+++ b/mdl/executor/issue1007_annotation_emit_test.go
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"strings"
+	"testing"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+	"github.com/mendixlabs/mxcli/mdl/visitor"
+	"github.com/mendixlabs/mxcli/sdk/workflows"
+)
+
+// mendixlabs/mxcli#1007 — DESCRIBE WORKFLOW emitted `annotation '<text>';`, the
+// one construct MDL-WF04 exists to refuse. The describer and the validator
+// disagreed, each stating its position in a comment, and the describer's was the
+// stale one.
+//
+// The assertion is the full contract, not just "no annotation statement": the
+// emitted MDL must PARSE and must pass ValidateWorkflow. Checking only that the
+// keyword is gone would also pass for an emit that dropped the text entirely.
+
+// describeAndValidate emits the activities through the real describe path, wraps
+// them in the smallest containing workflow, and returns the parse errors and the
+// validator's rule IDs.
+func describeAndValidate(t *testing.T, acts ...workflows.WorkflowActivity) (src string, parseErrs []string, ruleIDs []string) {
+	t.Helper()
+	lines := formatWorkflowActivities(&workflows.Flow{Activities: acts}, "  ")
+	src = "create workflow M.WF\n  parameter $WorkflowContext: M.E\nbegin\n" +
+		strings.Join(lines, "\n") + "\nend workflow;"
+	prog, errs := visitor.Build(src)
+	for _, e := range errs {
+		parseErrs = append(parseErrs, e.Error())
+	}
+	if len(parseErrs) > 0 {
+		return src, parseErrs, nil
+	}
+	for _, stmt := range prog.Statements {
+		if wf, ok := stmt.(*ast.CreateWorkflowStmt); ok {
+			for _, v := range ValidateWorkflow(wf) {
+				ruleIDs = append(ruleIDs, v.RuleID)
+			}
+		}
+	}
+	return src, nil, ruleIDs
+}
+
+// An annotation ATTACHED to an activity — the reporter's case. 13 of these came
+// out of one 23-activity workflow.
+func TestDescribeWorkflow_AttachedAnnotationPassesOwnCheck(t *testing.T) {
+	jump := &workflows.JumpToActivity{TargetActivity: "Review"}
+	jump.Name = "j1"
+	jump.Annotation = "Source: Receive + Set busState = New Opening"
+
+	src, parseErrs, rules := describeAndValidate(t, jump)
+	if parseErrs != nil {
+		t.Fatalf("emitted MDL does not parse: %v\n%s", parseErrs, src)
+	}
+	for _, r := range rules {
+		if r == "MDL-WF04" {
+			t.Errorf("describe output still trips MDL-WF04:\n%s", src)
+		}
+	}
+	// The text must survive as something a reader can see — dropping it silently
+	// would satisfy the two checks above.
+	if !strings.Contains(src, "Source: Receive + Set busState = New Opening") {
+		t.Errorf("the annotation text was dropped:\n%s", src)
+	}
+	if strings.Contains(src, "annotation '") {
+		t.Errorf("still emitting an `annotation` statement:\n%s", src)
+	}
+}
+
+// A standalone annotation (a canvas sticky note) read back from the model, which
+// goes through a different branch of formatWorkflowActivities and had the same
+// bug. Note the terminator: the branch must mark itself a comment, or `;` gets
+// appended to the last line.
+func TestDescribeWorkflow_StandaloneAnnotationPassesOwnCheck(t *testing.T) {
+	ann := &workflows.WorkflowAnnotationActivity{Description: "sticky note on the canvas"}
+
+	src, parseErrs, rules := describeAndValidate(t, ann)
+	if parseErrs != nil {
+		t.Fatalf("emitted MDL does not parse: %v\n%s", parseErrs, src)
+	}
+	for _, r := range rules {
+		if r == "MDL-WF04" {
+			t.Errorf("describe output still trips MDL-WF04:\n%s", src)
+		}
+	}
+	if !strings.Contains(src, "sticky note on the canvas") {
+		t.Errorf("the annotation text was dropped:\n%s", src)
+	}
+	if strings.Contains(src, "; --") || strings.Contains(src, "note;") {
+		t.Errorf("a terminator was appended to a comment line:\n%s", src)
+	}
+}
+
+// An annotation may contain newlines, and `--` runs to end of line — so every
+// line needs its own prefix or the tail becomes stray tokens, which is the same
+// failure mode the statement form had.
+func TestDescribeWorkflow_MultiLineAnnotationCommentsEveryLine(t *testing.T) {
+	jump := &workflows.JumpToActivity{TargetActivity: "Review"}
+	jump.Name = "j1"
+	jump.Annotation = "first line\nsecond line\nthird line"
+
+	src, parseErrs, _ := describeAndValidate(t, jump)
+	if parseErrs != nil {
+		t.Fatalf("multi-line annotation does not parse: %v\n%s", parseErrs, src)
+	}
+	for _, want := range []string{"first line", "second line", "third line"} {
+		if !strings.Contains(src, want) {
+			t.Errorf("%q missing from:\n%s", want, src)
+		}
+	}
+	for _, line := range strings.Split(src, "\n") {
+		for _, part := range []string{"second line", "third line"} {
+			if strings.Contains(line, part) && !strings.Contains(line, "--") {
+				t.Errorf("continuation line is not commented: %q", line)
+			}
+		}
+	}
+}
+
+// The control for the whole change: an activity with no annotation must emit
+// exactly what it did before, with no stray comment line.
+//
+// The fixture carries the jump's target as a real activity. It did not, and the
+// test asserted "no violations at all" — which held until MDL-WF05 landed and
+// correctly reported the dangling target. Both PRs were green alone and red
+// together, because neither CI run saw the other's change; a fixture that is a
+// VALID workflow is what makes the assertion mean what it says.
+func TestDescribeWorkflow_NoAnnotationEmitsNoComment(t *testing.T) {
+	target := &workflows.UserTask{}
+	target.Name = "Review"
+	target.Caption = "Review"
+	target.Page = "M.ReviewPage"
+
+	jump := &workflows.JumpToActivity{TargetActivity: "Review"}
+	jump.Name = "j1"
+
+	src, parseErrs, rules := describeAndValidate(t, target, jump)
+	if parseErrs != nil {
+		t.Fatalf("parse: %v\n%s", parseErrs, src)
+	}
+	if len(rules) > 0 {
+		t.Errorf("unexpected violations %v for a valid workflow with no annotation:\n%s", rules, src)
+	}
+	if strings.Contains(src, "annotation") {
+		t.Errorf("emitted an annotation for an activity that has none:\n%s", src)
+	}
+}
diff --git a/mdl/executor/mapping_customhandler.go b/mdl/executor/mapping_customhandler.go
index ffb67a92f5..c29c5b0f2f 100644
--- a/mdl/executor/mapping_customhandler.go
+++ b/mdl/executor/mapping_customhandler.go
@@ -501,9 +501,10 @@ func resolveJsonStructureSource(b backend.FullBackend, ref ast.QualifiedName) (*
 //
 // FAIL OPEN when the project reports no XML schemas at all. There is no
 // `create xml schema` in MDL, so an XML schema can only ever have been put there
-// by a human — and, measured, NONE of the nine demo apps in the corpus contains
-// one. A project with an empty list is therefore the ordinary case, not evidence
-// that the name is wrong, and refusing on it would break every such mapping.
+// by a human, and it is rare: 3 documents in 1 of the 9 demo apps, against 36
+// message-definition collections and hundreds of JSON structures. A project with
+// an empty list is therefore the ordinary case, not evidence that the name is
+// wrong, and refusing on it would break every such mapping.
 func resolveXmlSchemaSource(b backend.FullBackend, ref ast.QualifiedName) error {
 	all, err := b.ListXmlSchemas()
 	if err != nil {
diff --git a/mdl/executor/mapping_source_resolution_test.go b/mdl/executor/mapping_source_resolution_test.go
index 088f799302..40631bbd86 100644
--- a/mdl/executor/mapping_source_resolution_test.go
+++ b/mdl/executor/mapping_source_resolution_test.go
@@ -196,10 +196,10 @@ func TestResolveXmlSchemaSourceIsModuleAware(t *testing.T) {
 // TestResolveXmlSchemaSourceFailsOpenOnEmptyProject pins the direction that
 // keeps this rule from being a regression.
 //
-// MDL cannot create an XML schema, and — measured — NONE of the nine demo apps
-// in the corpus contains one. A project with no XML schemas is therefore the
-// ordinary case, not evidence that the name is wrong; refusing on it would break
-// every such mapping in exchange for catching nothing.
+// MDL cannot create an XML schema, and they are rare: 3 documents in 1 of the 9
+// demo apps. A project with no XML schemas is therefore the ordinary case, not
+// evidence that the name is wrong; refusing on it would break every such mapping
+// in exchange for catching almost nothing.
 func TestResolveXmlSchemaSourceFailsOpenOnEmptyProject(t *testing.T) {
 	b := xmlBackend()
 
diff --git a/mdl/executor/validate_mapping_sources.go b/mdl/executor/validate_mapping_sources.go
index 30380182ef..5a84afa314 100644
--- a/mdl/executor/validate_mapping_sources.go
+++ b/mdl/executor/validate_mapping_sources.go
@@ -54,9 +54,9 @@ func validateMappingSources(ctx *ExecContext, prog *ast.Program) []error {
 //
 // A source family whose set is EMPTY disables itself. That is not defensiveness:
 // for XML schemas an empty set is the ordinary case (MDL cannot create one, and
-// none of the nine demo apps has any), and for JSON structures an empty set
-// means the project could not be read — in both, refusing would report every
-// mapping as broken on the strength of having learned nothing.
+// only 1 of the 9 demo apps has any), and for JSON structures an empty set means
+// the project could not be read — in both, refusing would report every mapping
+// as broken on the strength of having learned nothing.
 func mappingSourceViolations(refs []mappingSourceRef, jsonNames, xmlNames map[string]bool) []error {
 	var errs []error
 	for _, ref := range refs {
diff --git a/mdl/executor/validate_microflow.go b/mdl/executor/validate_microflow.go
index 9c53813468..26ee57eb94 100644
--- a/mdl/executor/validate_microflow.go
+++ b/mdl/executor/validate_microflow.go
@@ -100,6 +100,8 @@ func (v *microflowValidator) addViolation(ruleID string, severity linter.Severit
 
 // validate runs all checks on the microflow body.
 func (v *microflowValidator) validate(body []ast.MicroflowStatement) {
+	v.checkListOperationIterator(body)
+
 	// Walk the body for per-statement checks (validation feedback, return value checks)
 	v.emptyListVars = make(map[string]bool)
 	v.walkBody(body)
diff --git a/mdl/executor/validate_microflow_listop_iterator.go b/mdl/executor/validate_microflow_listop_iterator.go
new file mode 100644
index 0000000000..3fffa66f05
--- /dev/null
+++ b/mdl/executor/validate_microflow_listop_iterator.go
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"fmt"
+	"sort"
+	"strings"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+	"github.com/mendixlabs/mxcli/mdl/linter"
+)
+
+// checkListOperationIterator flags a FILTER/FIND predicate that navigates from a
+// variable which is not in scope — MDL-LISTOP01.
+//
+// Mendix binds the current item to `$currentObject` in a filter/find expression
+// and defines no other iterator name. `filter($L, $item/Amount > 0)` therefore
+// fails the build with CE0109 "Undefined variable 'item'", which mxcli used to
+// pass through silently (issue #1002).
+//
+// The rule keys on scope, not on the name: `$item` is perfectly valid in a
+// predicate when it is the enclosing loop's iterator, which is how the idiom in
+// CLAUDE.md ("use FIND for an O(N) lookup") is written —
+// `find($TargetList, key = $item/key)` navigates the OUTER loop's variable on the
+// right-hand side. Flagging the name would break that; flagging an unbound
+// variable does not. The variable set is collected flow-wide (branches and loop
+// bodies do not open a scope in Mendix — see MDL063), so a predicate may
+// reference anything the microflow binds anywhere.
+//
+// Unlike the executor's qualification of bare attribute names, this needs no
+// project: it is answered entirely from the statement's own body, so plain
+// `mxcli check` reports it.
+func (v *microflowValidator) checkListOperationIterator(body []ast.MicroflowStatement) {
+	inScope := map[string]bool{"currentObject": true}
+	for _, p := range v.params {
+		if p.Name != "" {
+			inScope[p.Name] = true
+		}
+	}
+	forEachMicroflowStatement(body, func(s ast.MicroflowStatement) {
+		for _, p := range statementProducedVars(s) {
+			inScope[p.name] = true
+		}
+	})
+
+	forEachMicroflowStatement(body, func(s ast.MicroflowStatement) {
+		lo, ok := s.(*ast.ListOperationStmt)
+		if !ok || lo.Condition == nil {
+			return
+		}
+		if lo.Operation != ast.ListOpFilter && lo.Operation != ast.ListOpFind {
+			return
+		}
+		op := strings.ToLower(lo.Operation.String())
+		unbound := map[string]bool{}
+		for _, name := range predicatePathVariables(lo.Condition) {
+			if !inScope[name] {
+				unbound[name] = true
+			}
+		}
+		names := make([]string, 0, len(unbound))
+		for n := range unbound {
+			names = append(names, n)
+		}
+		sort.Strings(names)
+		for _, name := range names {
+			v.addViolation("MDL-LISTOP01", linter.SeverityError,
+				fmt.Sprintf("%s($%s, …): '$%s' is not defined in this microflow. A %s predicate is "+
+					"evaluated once per item and Mendix binds the item to '$currentObject' — no other "+
+					"iterator name exists, so mxbuild rejects this with CE0109 \"Undefined variable '%s'\".",
+					op, lo.InputVariable, name, op, name),
+				fmt.Sprintf("Use '$currentObject/…' for the item being tested, e.g. "+
+					"%s($%s, $currentObject/Attribute > 0). A bare attribute name works too — mxcli "+
+					"qualifies it against the list's entity.", op, lo.InputVariable))
+		}
+	})
+}
+
+// predicatePathVariables returns the base variable of every path navigation in a
+// predicate ($x/Attr → "x"), deduplicated by the caller.
+func predicatePathVariables(expr ast.Expression) []string {
+	var out []string
+	var walk func(ast.Expression)
+	walk = func(e ast.Expression) {
+		switch n := e.(type) {
+		case nil:
+			return
+		case *ast.AttributePathExpr:
+			if n.Variable != "" {
+				out = append(out, n.Variable)
+			}
+		case *ast.BinaryExpr:
+			walk(n.Left)
+			walk(n.Right)
+		case *ast.UnaryExpr:
+			walk(n.Operand)
+		case *ast.ParenExpr:
+			walk(n.Inner)
+		case *ast.FunctionCallExpr:
+			for _, a := range n.Arguments {
+				walk(a)
+			}
+		case *ast.IfThenElseExpr:
+			walk(n.Condition)
+			walk(n.ThenExpr)
+			walk(n.ElseExpr)
+		case *ast.SourceExpr:
+			walk(n.Expression)
+		}
+	}
+	walk(expr)
+	return out
+}
+
+// forEachMicroflowStatement visits every statement in a body, descending into
+// the nested bodies of loops, branches and splits.
+func forEachMicroflowStatement(body []ast.MicroflowStatement, fn func(ast.MicroflowStatement)) {
+	for _, s := range body {
+		fn(s)
+		switch st := s.(type) {
+		case *ast.LoopStmt:
+			forEachMicroflowStatement(st.Body, fn)
+		case *ast.WhileStmt:
+			forEachMicroflowStatement(st.Body, fn)
+		case *ast.IfStmt:
+			forEachMicroflowStatement(st.ThenBody, fn)
+			forEachMicroflowStatement(st.ElseBody, fn)
+		case *ast.EnumSplitStmt:
+			for _, c := range st.Cases {
+				forEachMicroflowStatement(c.Body, fn)
+			}
+			forEachMicroflowStatement(st.ElseBody, fn)
+		case *ast.InheritanceSplitStmt:
+			for _, c := range st.Cases {
+				forEachMicroflowStatement(c.Body, fn)
+			}
+			forEachMicroflowStatement(st.ElseBody, fn)
+		}
+	}
+}
diff --git a/mdl/executor/validate_microflow_listop_iterator_test.go b/mdl/executor/validate_microflow_listop_iterator_test.go
new file mode 100644
index 0000000000..8ed5d18a3b
--- /dev/null
+++ b/mdl/executor/validate_microflow_listop_iterator_test.go
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"strings"
+	"testing"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+)
+
+// listopIteratorViolations runs the microflow validator and returns only the
+// MDL-LISTOP01 messages.
+func listopIteratorViolations(t *testing.T, stmt *ast.CreateMicroflowStmt) []string {
+	t.Helper()
+	var out []string
+	for _, v := range ValidateMicroflow(stmt) {
+		if v.RuleID == "MDL-LISTOP01" {
+			out = append(out, v.Message)
+		}
+	}
+	return out
+}
+
+// pathPredicate builds `$<variable>/<attr> > 0`.
+func pathPredicate(variable, attr string) ast.Expression {
+	return &ast.BinaryExpr{
+		Left: &ast.AttributePathExpr{
+			Variable: variable,
+			Path:     []string{attr},
+			Segments: []ast.PathSegment{{Name: attr, Separator: "/"}},
+		},
+		Operator: ">",
+		Right:    &ast.LiteralExpr{Value: "0", Kind: ast.LiteralInteger},
+	}
+}
+
+func filterStmt(input string, cond ast.Expression) *ast.ListOperationStmt {
+	return &ast.ListOperationStmt{
+		Operation:      ast.ListOpFilter,
+		InputVariable:  input,
+		OutputVariable: "R",
+		Condition:      cond,
+	}
+}
+
+// TestListOperationIteratorUndefinedVariable is issue #1002's CE0109 half.
+// Mendix binds the item to $currentObject and defines no other iterator, so
+// `filter($L, $item/Qty > 0)` fails the build — which mxcli used to pass
+// through silently.
+func TestListOperationIteratorUndefinedVariable(t *testing.T) {
+	stmt := &ast.CreateMicroflowStmt{
+		Name: ast.QualifiedName{Module: "Shop", Name: "BadIterator"},
+		Body: []ast.MicroflowStatement{
+			&ast.RetrieveStmt{Variable: "L"},
+			filterStmt("L", pathPredicate("item", "Qty")),
+		},
+	}
+	got := listopIteratorViolations(t, stmt)
+	if len(got) != 1 {
+		t.Fatalf("expected 1 MDL-LISTOP01 violation, got %d: %v", len(got), got)
+	}
+	for _, want := range []string{"$item", "$currentObject", "CE0109"} {
+		if !strings.Contains(got[0], want) {
+			t.Errorf("message %q does not mention %q", got[0], want)
+		}
+	}
+}
+
+// TestListOperationIteratorAcceptsCurrentObject is the control that stops the
+// rule from firing on the correct spelling.
+func TestListOperationIteratorAcceptsCurrentObject(t *testing.T) {
+	stmt := &ast.CreateMicroflowStmt{
+		Name: ast.QualifiedName{Module: "Shop", Name: "Good"},
+		Body: []ast.MicroflowStatement{
+			&ast.RetrieveStmt{Variable: "L"},
+			filterStmt("L", pathPredicate("currentObject", "Qty")),
+		},
+	}
+	if got := listopIteratorViolations(t, stmt); len(got) != 0 {
+		t.Errorf("$currentObject predicate flagged: %v", got)
+	}
+}
+
+// TestListOperationIteratorAcceptsEnclosingLoopVariable is the control that
+// matters most. The rule 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) lookup idiom is written —
+// `find($TargetList, key = $item/key)` inside `loop $item in $L`. Keying on the
+// name would break the documented pattern; this microflow builds at 0 errors on
+// mxbuild 11.13.0.
+func TestListOperationIteratorAcceptsEnclosingLoopVariable(t *testing.T) {
+	stmt := &ast.CreateMicroflowStmt{
+		Name:       ast.QualifiedName{Module: "Shop", Name: "LoopLookup"},
+		Parameters: []ast.MicroflowParam{{Name: "Others"}},
+		Body: []ast.MicroflowStatement{
+			&ast.RetrieveStmt{Variable: "L"},
+			&ast.LoopStmt{
+				LoopVariable: "item",
+				ListVariable: "L",
+				Body: []ast.MicroflowStatement{
+					filterStmt("Others", pathPredicate("item", "Qty")),
+				},
+			},
+		},
+	}
+	if got := listopIteratorViolations(t, stmt); len(got) != 0 {
+		t.Errorf("the enclosing loop's iterator was flagged: %v", got)
+	}
+}
+
+// TestListOperationIteratorAcceptsParameter: a microflow parameter is in scope
+// in a predicate just like any other variable.
+func TestListOperationIteratorAcceptsParameter(t *testing.T) {
+	stmt := &ast.CreateMicroflowStmt{
+		Name:       ast.QualifiedName{Module: "Shop", Name: "ParamRef"},
+		Parameters: []ast.MicroflowParam{{Name: "Wanted"}},
+		Body: []ast.MicroflowStatement{
+			&ast.RetrieveStmt{Variable: "L"},
+			filterStmt("L", pathPredicate("Wanted", "Qty")),
+		},
+	}
+	if got := listopIteratorViolations(t, stmt); len(got) != 0 {
+		t.Errorf("a parameter reference was flagged: %v", got)
+	}
+}
+
+// TestListOperationIteratorIgnoresSort: SORT carries no predicate expression
+// (it takes attribute names), so the rule must not reach into it.
+func TestListOperationIteratorIgnoresSort(t *testing.T) {
+	stmt := &ast.CreateMicroflowStmt{
+		Name: ast.QualifiedName{Module: "Shop", Name: "Sorted"},
+		Body: []ast.MicroflowStatement{
+			&ast.RetrieveStmt{Variable: "L"},
+			&ast.ListOperationStmt{
+				Operation:      ast.ListOpSort,
+				InputVariable:  "L",
+				OutputVariable: "R",
+				SortSpecs:      []ast.SortSpec{{Attribute: "Qty", Ascending: false}},
+			},
+		},
+	}
+	if got := listopIteratorViolations(t, stmt); len(got) != 0 {
+		t.Errorf("SORT was flagged: %v", got)
+	}
+}
diff --git a/mdl/executor/validate_widget_image.go b/mdl/executor/validate_widget_image.go
new file mode 100644
index 0000000000..8885af42ff
--- /dev/null
+++ b/mdl/executor/validate_widget_image.go
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"fmt"
+	"strings"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+	"github.com/mendixlabs/mxcli/mdl/linter"
+)
+
+// MDL-WIDGET22: an IMAGE widget with nothing to show.
+//
+// The Image widget's `datasource` property selects where the image comes from,
+// and it defaults to `image` — an entry from an image collection, named on the
+// widget's `imageObject` property. A widget with that source and no entry is a
+// model mxbuild refuses:
+//
+//	[error] "No image selected." at Image 'i'
+//
+// This was invisible until the CE0463 fix landed. Every mxcli-authored Image
+// failed the build with CE0463 "the definition of this widget has changed" —
+// which fired first, and which `mx update-widgets` cleared, leaving the real
+// error behind it (mxcli-formula1 FINDINGS §69/§142).
+//
+// When this rule was first written MDL could not name an image collection entry
+// at all, so its only advice was to switch source. `Image:` is now authorable
+// (see the `image` operation in widget_engine.go), so the rule reports a
+// genuinely incomplete widget rather than a missing capability — and the remedy
+// it offers is the one that keeps the author's intent.
+//
+// Reported at check time because that costs a second rather than a build. It is
+// an ERROR: the build does not pass, so accepting it would be mxcli waving
+// through a script it knows produces a broken app.
+const imageSourceRule = "MDL-WIDGET22"
+
+// imageSourceNeedsImage lists the `datasource` values that require an image
+// collection entry. Anything else — including a value this build does not
+// recognise — is left alone rather than guessed at.
+var imageSourceNeedsImage = map[string]bool{
+	"":      true, // absent: the widget's own default is "image"
+	"image": true,
+}
+
+// validateImageSource reports an IMAGE widget whose configured source has no
+// value to render.
+func validateImageSource(w *ast.WidgetV3, locationPrefix string) []linter.Violation {
+	if w == nil || !strings.EqualFold(w.Type, "image") {
+		return nil
+	}
+	source := strings.TrimSpace(w.GetStringProp("ImageType"))
+
+	switch {
+	case imageSourceNeedsImage[strings.ToLower(source)]:
+		if strings.TrimSpace(w.GetStringProp("Image")) != "" {
+			return nil // an entry is named — the widget is complete
+		}
+		return []linter.Violation{{
+			RuleID:   imageSourceRule,
+			Severity: linter.SeverityError,
+			Message: fmt.Sprintf(
+				"%s: widget `%s` (image) shows an image from an image collection "+
+					"(the default `ImageType: image`) but names no image — mxbuild rejects the "+
+					"build with \"No image selected.\"",
+				locationPrefix, w.Name),
+			Location: linter.Location{DocumentType: "page"},
+			Suggestion: fmt.Sprintf(
+				"Name the entry: `image %s (Image: 'Module.Collection.ImageName')` — "+
+					"`show image collections` lists them, and `describe image collection "+
+					"Module.Collection` lists the images inside one. Or switch source: "+
+					"`ImageType: imageUrl, ImageUrl: 'https://…'`, or `ImageType: icon`.",
+				w.Name),
+		}}
+	case strings.EqualFold(source, "imageUrl") && strings.TrimSpace(w.GetStringProp("ImageUrl")) == "":
+		return []linter.Violation{{
+			RuleID:   imageSourceRule,
+			Severity: linter.SeverityError,
+			Message: fmt.Sprintf(
+				"%s: widget `%s` (image) has `ImageType: imageUrl` and no `ImageUrl` — "+
+					"mxbuild rejects the build with \"No image selected.\"",
+				locationPrefix, w.Name),
+			Location:   linter.Location{DocumentType: "page"},
+			Suggestion: "Give it a URL: `ImageUrl: 'https://…'`.",
+		}}
+	}
+	return nil
+}
diff --git a/mdl/executor/validate_widget_image_ref.go b/mdl/executor/validate_widget_image_ref.go
new file mode 100644
index 0000000000..a2daa3f9a8
--- /dev/null
+++ b/mdl/executor/validate_widget_image_ref.go
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"fmt"
+	"sort"
+	"strings"
+)
+
+// Resolving the `Image:` reference an image widget now carries.
+//
+// Wiring the `image` operation gave MDL a new qualified name to get wrong, and
+// the first thing a typo did was slip past the reference check and fail the
+// build instead:
+//
+//	image imgTypo (Image: 'MyFirstModule.Images.NoSuchImage')
+//
+//	mxcli check --references -> Check passed!
+//	mx check                 -> [CE1613] "The selected image
+//	                            'MyFirstModule.Images.NoSuchImage' no longer exists."
+//
+// Every other name a widget can carry — microflow, nanoflow, page, snippet,
+// entity — is resolved by validateWidgetReferences. This is the same check for
+// the one reference that has THREE parts: Module.Collection.Image. Which half is
+// wrong decides where the author has to look, so the two mistakes get two
+// messages.
+
+// imageRefErrors reports the image references in refs that do not resolve.
+//
+// known holds every image as a lower-cased three-part qualified name;
+// collections holds every image collection as a lower-cased two-part one. A nil
+// map means the project's collections could not be listed — then nothing is
+// reported, because calling every image missing on a failed read is the wrong
+// direction to be wrong in. An empty non-nil map is a real answer: the project
+// has no image collections, so any reference to one is wrong.
+func imageRefErrors(refs []string, known map[string]bool, collections map[string]bool) []string {
+	var errors []string
+	for _, ref := range refs {
+		ref = strings.TrimSpace(ref)
+		if ref == "" {
+			continue
+		}
+		parts := strings.Split(ref, ".")
+		if len(parts) != 3 || parts[0] == "" || parts[1] == "" || parts[2] == "" {
+			errors = append(errors, fmt.Sprintf(
+				"invalid image reference: %s — an image is named "+
+					"Module.Collection.ImageName (three parts); `show image collections` "+
+					"lists the collections",
+				ref))
+			continue
+		}
+		if collections == nil || known == nil {
+			continue // nothing to resolve against
+		}
+
+		collection := parts[0] + "." + parts[1]
+		if !collections[strings.ToLower(collection)] {
+			errors = append(errors, fmt.Sprintf(
+				"image collection not found: %s (referenced as %s) — "+
+					"`show image collections` lists them",
+				collection, ref))
+			continue
+		}
+		if !known[strings.ToLower(ref)] {
+			msg := fmt.Sprintf("image not found: %s in image collection %s", parts[2], collection)
+			if inCollection := imagesInCollection(known, collection); len(inCollection) > 0 {
+				msg += fmt.Sprintf(" — it holds: %s", strings.Join(inCollection, ", "))
+			} else {
+				msg += fmt.Sprintf(" — `describe image collection %s` lists its images", collection)
+			}
+			errors = append(errors, msg)
+		}
+	}
+	return errors
+}
+
+// imagesInCollection returns the image names known for one collection, so the
+// diagnostic can show what is actually there instead of only what is not. The
+// names are lower-cased (that is how the set is keyed) and capped, since a
+// collection can hold hundreds.
+func imagesInCollection(known map[string]bool, collection string) []string {
+	prefix := strings.ToLower(collection) + "."
+	var names []string
+	for qn := range known {
+		if strings.HasPrefix(qn, prefix) {
+			names = append(names, strings.TrimPrefix(qn, prefix))
+		}
+	}
+	sort.Strings(names)
+	const max = 10
+	if len(names) > max {
+		names = append(names[:max:max], "…")
+	}
+	return names
+}
+
+// buildImageQualifiedNames returns the project's images as lower-cased
+// three-part qualified names, and its image collections as lower-cased two-part
+// ones. Both are nil when the collections could not be read at all — the caller
+// distinguishes that from "there are none".
+func buildImageQualifiedNames(ctx *ExecContext) (images map[string]bool, collections map[string]bool) {
+	h, err := getHierarchy(ctx)
+	if err != nil {
+		return nil, nil
+	}
+	ics, err := ctx.Backend.ListImageCollections()
+	if err != nil {
+		return nil, nil
+	}
+	images = make(map[string]bool)
+	collections = make(map[string]bool)
+	for _, ic := range ics {
+		qn := strings.ToLower(h.GetQualifiedName(ic.ContainerID, ic.Name))
+		collections[qn] = true
+		for _, img := range ic.Images {
+			images[qn+"."+strings.ToLower(img.Name)] = true
+		}
+	}
+	return images, collections
+}
diff --git a/mdl/executor/validate_widget_image_ref_test.go b/mdl/executor/validate_widget_image_ref_test.go
new file mode 100644
index 0000000000..8c8d60e1d7
--- /dev/null
+++ b/mdl/executor/validate_widget_image_ref_test.go
@@ -0,0 +1,94 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"strings"
+	"testing"
+)
+
+// Wiring `Image:` gave MDL a new reference to get wrong, and the first thing it
+// did was reproduce this session's recurring shape: a typo passed
+// `mxcli check --references` and failed the build.
+//
+//	image imgTypo (Image: 'MyFirstModule.Images.NoSuchImage')
+//
+//	mxcli check --references -> Check passed!
+//	mx check                 -> [CE1613] "The selected image
+//	                            'MyFirstModule.Images.NoSuchImage' no longer exists."
+//
+// Every other qualified name a widget can carry — microflow, nanoflow, page,
+// snippet, entity — is resolved by validateWidgetReferences. An image is now
+// one of them.
+//
+// The name has THREE parts, unlike the rest: Module.Collection.Image. So both
+// halves have to be checked, and the message has to say which one is wrong —
+// "collection not found" and "that collection has no such image" send the
+// reader to different places.
+
+func TestImageRefErrors_UnknownImageIsReported(t *testing.T) {
+	known := map[string]bool{"myfirstmodule.images._1": true}
+	collections := map[string]bool{"myfirstmodule.images": true}
+
+	errs := imageRefErrors([]string{"MyFirstModule.Images.NoSuchImage"}, known, collections)
+	if len(errs) != 1 {
+		t.Fatalf("got %d errors, want 1: %v", len(errs), errs)
+	}
+	if !strings.Contains(errs[0], "NoSuchImage") {
+		t.Errorf("the message should name the image: %s", errs[0])
+	}
+	// The collection exists, so the reader needs to know it is the image that is
+	// wrong — and what the collection does hold.
+	if !strings.Contains(errs[0], "MyFirstModule.Images") {
+		t.Errorf("the message should name the collection: %s", errs[0])
+	}
+}
+
+// A missing COLLECTION is a different mistake and gets a different message.
+func TestImageRefErrors_UnknownCollectionSaysSo(t *testing.T) {
+	errs := imageRefErrors([]string{"Nope.Missing.Img"}, map[string]bool{}, map[string]bool{})
+	if len(errs) != 1 {
+		t.Fatalf("got %d errors, want 1: %v", len(errs), errs)
+	}
+	if !strings.Contains(errs[0], "image collection") || !strings.Contains(errs[0], "Nope.Missing") {
+		t.Errorf("the message should name the missing collection: %s", errs[0])
+	}
+}
+
+// CONTROL: an image that exists is not reported. Without this the check just
+// forbids the feature.
+func TestImageRefErrors_KnownImageIsClean(t *testing.T) {
+	known := map[string]bool{"myfirstmodule.images._1": true}
+	collections := map[string]bool{"myfirstmodule.images": true}
+
+	if errs := imageRefErrors([]string{"MyFirstModule.Images._1"}, known, collections); len(errs) != 0 {
+		t.Errorf("an existing image was reported: %v", errs)
+	}
+	// Mendix resolves names case-insensitively, and so must this.
+	if errs := imageRefErrors([]string{"myfirstmodule.IMAGES._1"}, known, collections); len(errs) != 0 {
+		t.Errorf("a case difference was reported: %v", errs)
+	}
+}
+
+// A name that is not three parts cannot be resolved, and is reported as the
+// shape mistake it is rather than as a missing image.
+func TestImageRefErrors_MalformedNameIsReported(t *testing.T) {
+	for _, ref := range []string{"JustOne", "Module.Collection"} {
+		errs := imageRefErrors([]string{ref}, map[string]bool{}, map[string]bool{})
+		if len(errs) != 1 {
+			t.Fatalf("%q: got %d errors, want 1: %v", ref, len(errs), errs)
+		}
+		if !strings.Contains(errs[0], "Module.Collection.ImageName") {
+			t.Errorf("%q: the message should show the expected shape: %s", ref, errs[0])
+		}
+	}
+}
+
+// CONTROL: with no image collections readable at all, nothing is reported.
+// A project whose collections could not be listed must not have every image
+// called missing — that is the "guessing wrong rejects working input" direction.
+func TestImageRefErrors_NoCollectionsMeansNoOpinion(t *testing.T) {
+	if errs := imageRefErrors([]string{"Mod.Coll.Img"}, nil, nil); len(errs) != 0 {
+		t.Errorf("reported an image with nothing to resolve against: %v", errs)
+	}
+}
diff --git a/mdl/executor/validate_widget_image_test.go b/mdl/executor/validate_widget_image_test.go
new file mode 100644
index 0000000000..0674444950
--- /dev/null
+++ b/mdl/executor/validate_widget_image_test.go
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"strings"
+	"testing"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+	"github.com/mendixlabs/mxcli/mdl/linter"
+)
+
+// Found while fixing the Image CE0463 (mxcli-formula1 FINDINGS §69/§142): with
+// CE0463 out of the way, the bare form's real problem is visible.
+//
+//	image i (Responsive: false)
+//	  → [error] "No image selected." at Image 'i'
+//
+// The Image widget's `datasource` defaults to `image`, which shows an image from
+// an image collection, named on the widget's `imageObject` property.
+//
+// When this rule was written MDL could not name one at all, so the only advice
+// it could give was to switch source. `Image:` is authorable now, so the rule
+// reports a genuinely incomplete widget — and the case that must NOT fire is a
+// widget that names its entry.
+//
+// CE0463 was masking that, which is why it went unnoticed: the definition error
+// fired first and `mx update-widgets` "fixed" the page by clearing it, leaving
+// the real error behind. The same gap is what makes a describe → exec copy of an
+// Atlas layout lose its brand image (§142).
+//
+// Reporting it at check time is the whole value: mxbuild reports it at the far
+// end of a build, and `mxcli check` runs in a second.
+
+func imageWidget(props map[string]any) *ast.WidgetV3 {
+	return &ast.WidgetV3{Name: "img", Type: "image", Properties: props}
+}
+
+func imageViolations(vs []linter.Violation) []linter.Violation {
+	var out []linter.Violation
+	for _, v := range vs {
+		if v.RuleID == "MDL-WIDGET22" {
+			out = append(out, v)
+		}
+	}
+	return out
+}
+
+// The reported case: the default data source with no image to show.
+func TestImageWidget_DefaultSourceWithNoImageIsReported(t *testing.T) {
+	got := imageViolations(validateImageSource(imageWidget(map[string]any{"Responsive": "false"}), "page X"))
+	if len(got) != 1 {
+		t.Fatalf("got %d violations, want 1: %+v", len(got), got)
+	}
+	if got[0].Severity != linter.SeverityError {
+		t.Errorf("severity = %v, want error — mxbuild refuses the build", got[0].Severity)
+	}
+	if !strings.Contains(got[0].Message, "No image selected") {
+		t.Errorf("the message should quote what mxbuild says: %s", got[0].Message)
+	}
+	// The suggestion must lead with the remedy that keeps the author's intent —
+	// naming the entry — not only with "use a different source".
+	if !strings.Contains(got[0].Suggestion, "Image: 'Module.Collection.ImageName'") {
+		t.Errorf("the suggestion should show how to name the entry: %s", got[0].Suggestion)
+	}
+	if !strings.Contains(got[0].Suggestion, "imageUrl") {
+		t.Errorf("the suggestion should still offer the alternative sources: %s", got[0].Suggestion)
+	}
+}
+
+// …and with an explicit ImageType: image, which is the same model.
+func TestImageWidget_ExplicitImageTypeWithNoImageIsReported(t *testing.T) {
+	w := imageWidget(map[string]any{"ImageType": "image"})
+	if got := imageViolations(validateImageSource(w, "page X")); len(got) != 1 {
+		t.Fatalf("got %d violations, want 1: %+v", len(got), got)
+	}
+}
+
+// CONTROL 1: the URL form is complete and must pass. This is the shape the
+// CE0463 fix was verified on, at 0 errors.
+func TestImageWidget_UrlFormIsClean(t *testing.T) {
+	w := imageWidget(map[string]any{"ImageType": "imageUrl", "ImageUrl": "https://example.com/x.png"})
+	if got := imageViolations(validateImageSource(w, "page X")); len(got) != 0 {
+		t.Errorf("the URL form builds at 0 errors and must not be reported: %+v", got)
+	}
+}
+
+// CONTROL 2: an icon source needs no image either.
+func TestImageWidget_IconFormIsClean(t *testing.T) {
+	w := imageWidget(map[string]any{"ImageType": "icon"})
+	if got := imageViolations(validateImageSource(w, "page X")); len(got) != 0 {
+		t.Errorf("an icon source needs no image: %+v", got)
+	}
+}
+
+// CONTROL 3: the rule is about the IMAGE widget only. A different widget with a
+// stray ImageType property is none of its business.
+func TestImageWidget_OtherWidgetsAreNotTouched(t *testing.T) {
+	w := &ast.WidgetV3{Name: "dg", Type: "datagrid", Properties: map[string]any{}}
+	if got := imageViolations(validateImageSource(w, "page X")); len(got) != 0 {
+		t.Errorf("a datagrid was reported: %+v", got)
+	}
+}
+
+// CONTROL 4: an ImageType nobody recognises is left alone rather than guessed
+// at. Reporting on an unknown source would fire on a widget version this build
+// does not know about.
+func TestImageWidget_UnknownImageTypeIsLeftAlone(t *testing.T) {
+	w := imageWidget(map[string]any{"ImageType": "somethingNew"})
+	if got := imageViolations(validateImageSource(w, "page X")); len(got) != 0 {
+		t.Errorf("an unrecognised ImageType was reported: %+v", got)
+	}
+}
+
+// The URL form with an EMPTY url is the same incompleteness by the other route,
+// and mxbuild rejects it too.
+func TestImageWidget_EmptyUrlIsReported(t *testing.T) {
+	w := imageWidget(map[string]any{"ImageType": "imageUrl", "ImageUrl": ""})
+	if got := imageViolations(validateImageSource(w, "page X")); len(got) != 1 {
+		t.Fatalf("got %d violations, want 1: %+v", len(got), got)
+	}
+}
+
+// The capability this rule used to say did not exist: an image collection entry
+// named on the widget. It must not be reported.
+func TestImageWidget_NamedCollectionEntryIsClean(t *testing.T) {
+	for _, props := range []map[string]any{
+		{"Image": "MyFirstModule.Images._1"},                       // default source
+		{"ImageType": "image", "Image": "MyFirstModule.Images._1"}, // source spelled out
+	} {
+		if got := imageViolations(validateImageSource(imageWidget(props), "page X")); len(got) != 0 {
+			t.Errorf("a widget naming its image was reported: %+v", got)
+		}
+	}
+}
+
+// CONTROL: an empty Image is not an image. Whitespace is not either — the value
+// reaches the writer verbatim, so " " would store a reference to nothing.
+func TestImageWidget_EmptyOrBlankImageIsStillReported(t *testing.T) {
+	for _, v := range []string{"", "   "} {
+		got := imageViolations(validateImageSource(imageWidget(map[string]any{"Image": v}), "page X"))
+		if len(got) != 1 {
+			t.Errorf("Image=%q: got %d violations, want 1", v, len(got))
+		}
+	}
+}
diff --git a/mdl/executor/validate_widgets.go b/mdl/executor/validate_widgets.go
index e5a652d429..e3628d8d84 100644
--- a/mdl/executor/validate_widgets.go
+++ b/mdl/executor/validate_widgets.go
@@ -122,6 +122,9 @@ func validateWidgetTreeIn(widgets []*ast.WidgetV3, registry *WidgetRegistry, loc
 			out = append(out, validatePluggableContentParams(w, locationPrefix)...)
 		}
 		out = append(out, validateWidgetVisibility(w, registry, locationPrefix)...)
+		// An IMAGE with nothing to show — the default source needs an image
+		// reference MDL cannot author. See validate_widget_image.go.
+		out = append(out, validateImageSource(w, locationPrefix)...)
 		out = append(out, validateStaticWidget(w, locationPrefix)...)
 		out = append(out, validateDynamicTextFormatting(w, locationPrefix)...)
 		out = append(out, validateDatasourceXPathAssociationEmpty(w, locationPrefix)...)
diff --git a/mdl/executor/validate_workflow.go b/mdl/executor/validate_workflow.go
index 33d211c9c1..21a1abcf37 100644
--- a/mdl/executor/validate_workflow.go
+++ b/mdl/executor/validate_workflow.go
@@ -30,6 +30,7 @@ var wfOutcomeIdentRe = regexp.MustCompile(`^[A-Za-z_][A-Za-z0-9_]*$`)
 //   - MDL-WF03: decision / call-microflow outcome that is not a valid
 //     enumeration value identifier
 //   - MDL-WF04: standalone `annotation` in a workflow body (unloadable model)
+//   - MDL-WF05: `jump to` a target that names no activity (see validate_workflow_jump.go)
 func ValidateWorkflow(stmt *ast.CreateWorkflowStmt) []linter.Violation {
 	var out []linter.Violation
 	loc := linter.Location{
@@ -80,6 +81,7 @@ func ValidateWorkflow(stmt *ast.CreateWorkflowStmt) []linter.Violation {
 			})
 		}
 	})
+	out = append(out, ValidateWorkflowJumpTargets(stmt)...)
 	return out
 }
 
diff --git a/mdl/executor/validate_workflow_jump.go b/mdl/executor/validate_workflow_jump.go
new file mode 100644
index 0000000000..f4827f1925
--- /dev/null
+++ b/mdl/executor/validate_workflow_jump.go
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"fmt"
+	"sort"
+	"strings"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+	"github.com/mendixlabs/mxcli/mdl/linter"
+	"github.com/mendixlabs/mxcli/sdk/workflows"
+)
+
+// jumpTargetRule is MDL-WF05: `jump to <name>` must name an activity in the
+// same workflow.
+//
+// A jump target is the ONLY intra-document reference a workflow has. External
+// references — microflows, pages, entities — are resolved twice (check
+// --references, and again in execCreateWorkflow), but nothing looked at a jump,
+// so an unresolved target was written out and surfaced only under the native
+// validator as CE6681 "It is not possible to jump to end activities or jump-to
+// activities" — an error describing a different fault, because Mendix resolves
+// TargetActivity by NAME and the only activity carrying the missing name was the
+// jump itself. See mendixlabs/mxcli#1005.
+const jumpTargetRule = "MDL-WF05"
+
+// ValidateWorkflowJumpTargets reports every `jump to` whose target does not name
+// an activity in the workflow.
+//
+// The candidate names are computed by running the real builders over the AST and
+// reading the names off the result, not by re-deriving them here: a call
+// microflow activity is named after the microflow it calls, a user task after
+// its declared name, and a second copy of those rules would drift from the
+// writer and produce exactly the false refusals this rule exists to prevent.
+// None of it needs a project — every name comes from the script.
+func ValidateWorkflowJumpTargets(stmt *ast.CreateWorkflowStmt) []linter.Violation {
+	if stmt == nil {
+		return nil
+	}
+	built := buildWorkflowActivities(stmt.Activities)
+	targets := map[string]bool{}
+	collectJumpableNames(built, targets)
+
+	loc := linter.Location{
+		Module:       stmt.Name.Module,
+		DocumentType: "workflow",
+		DocumentName: stmt.Name.Name,
+	}
+
+	var out []linter.Violation
+	walkWorkflowActivities(stmt.Activities, func(a ast.WorkflowActivityNode) {
+		n, ok := a.(*ast.WorkflowJumpToNode)
+		if !ok || n.Target == "" {
+			return
+		}
+		if targets[n.Target] {
+			return
+		}
+		out = append(out, linter.Violation{
+			RuleID:   jumpTargetRule,
+			Severity: linter.SeverityError,
+			Location: loc,
+			Message: fmt.Sprintf("jump target %q does not match any activity in this workflow — "+
+				"Mendix resolves a jump by activity name, so this is written as a jump to itself and "+
+				"the build fails with CE6681 (\"not possible to jump to end activities or jump-to activities\")",
+				n.Target),
+			Suggestion: jumpTargetSuggestion(targets),
+		})
+	})
+	return out
+}
+
+// jumpTargetSuggestion lists what the author could have meant. The names are not
+// obvious from the script — a `call microflow M.SUB_Check` activity is named
+// SUB_Check, not by anything written at the call site — which is most of why the
+// wrong name is easy to reach in the first place.
+func jumpTargetSuggestion(targets map[string]bool) string {
+	if len(targets) == 0 {
+		return "This workflow has no activity a jump can target."
+	}
+	names := make([]string, 0, len(targets))
+	for n := range targets {
+		names = append(names, n)
+	}
+	sort.Strings(names)
+	return "Valid targets in this workflow: " + strings.Join(names, ", ") +
+		". A `call microflow` activity is named after the microflow it calls."
+}
+
+// collectJumpableNames gathers the names of every activity a jump may target,
+// recursing into outcome, path and boundary-event flows.
+//
+// Jump activities are deliberately excluded: Mendix refuses a jump to a jump
+// (CE6681), so accepting one here would let the rule bless the exact model it
+// exists to prevent.
+func collectJumpableNames(acts []workflows.WorkflowActivity, out map[string]bool) {
+	add := func(name string) {
+		if name != "" {
+			out[name] = true
+			// autoBindWorkflowParameters sanitises some names before they are
+			// stored, so a jump written against either spelling resolves.
+			out[sanitizeActivityName(name)] = true
+		}
+	}
+	for _, act := range acts {
+		switch a := act.(type) {
+		case *workflows.UserTask:
+			add(a.Name)
+			for _, o := range a.Outcomes {
+				if o.Flow != nil {
+					collectJumpableNames(o.Flow.Activities, out)
+				}
+			}
+			collectBoundaryEventNames(a.BoundaryEvents, out)
+		case *workflows.CallMicroflowTask:
+			add(a.Name)
+			collectConditionOutcomeNames(a.Outcomes, out)
+		case *workflows.SystemTask:
+			add(a.Name)
+		case *workflows.CallWorkflowActivity:
+			add(a.Name)
+		case *workflows.ExclusiveSplitActivity:
+			add(a.Name)
+			collectConditionOutcomeNames(a.Outcomes, out)
+		case *workflows.ParallelSplitActivity:
+			add(a.Name)
+			for _, o := range a.Outcomes {
+				if o.Flow != nil {
+					collectJumpableNames(o.Flow.Activities, out)
+				}
+			}
+		case *workflows.WaitForTimerActivity:
+			add(a.Name)
+		case *workflows.WaitForNotificationActivity:
+			add(a.Name)
+			collectBoundaryEventNames(a.BoundaryEvents, out)
+		}
+	}
+}
+
+func collectConditionOutcomeNames(outcomes []workflows.ConditionOutcome, out map[string]bool) {
+	for _, outcome := range outcomes {
+		switch o := outcome.(type) {
+		case *workflows.BooleanConditionOutcome:
+			if o.Flow != nil {
+				collectJumpableNames(o.Flow.Activities, out)
+			}
+		case *workflows.EnumerationValueConditionOutcome:
+			if o.Flow != nil {
+				collectJumpableNames(o.Flow.Activities, out)
+			}
+		case *workflows.VoidConditionOutcome:
+			if o.Flow != nil {
+				collectJumpableNames(o.Flow.Activities, out)
+			}
+		}
+	}
+}
+
+func collectBoundaryEventNames(events []*workflows.BoundaryEvent, out map[string]bool) {
+	for _, e := range events {
+		if e != nil && e.Flow != nil {
+			collectJumpableNames(e.Flow.Activities, out)
+		}
+	}
+}
diff --git a/mdl/executor/widget_defs.go b/mdl/executor/widget_defs.go
index a9958d24fc..7f838d14be 100644
--- a/mdl/executor/widget_defs.go
+++ b/mdl/executor/widget_defs.go
@@ -637,6 +637,8 @@ func operationForType(t string) string {
 		return "expression"
 	case "action":
 		return "action"
+	case "image":
+		return "image"
 	case "boolean", "integer", "decimal", "string", "enumeration":
 		return "primitive"
 	}
diff --git a/mdl/executor/widget_engine.go b/mdl/executor/widget_engine.go
index bc85fbedbf..c42695c59b 100644
--- a/mdl/executor/widget_engine.go
+++ b/mdl/executor/widget_engine.go
@@ -312,20 +312,30 @@ func (e *PluggableWidgetEngine) Build(def *WidgetDefinition, w *ast.WidgetV3) (*
 	// 3. Apply property mappings.
 	//
 	// A property the widget's editorConfig hides under the current configuration
-	// is SKIPPED, so the widget template's default survives into the stored
-	// object — which is what Studio Pro stores for it. Measured on a Studio
-	// Pro-authored File Uploader 2.5.0: all 34 declared properties are stored,
-	// the hidden ones at their default, so "hidden" means default-valued, not
-	// absent.
+	// is written at its DECLARED DEFAULT. Measured on a Studio Pro-authored File
+	// Uploader 2.5.0: all 34 declared properties are stored, the hidden ones at
+	// their default, so "hidden" means default-valued, not absent.
+	//
+	// Writing the default rather than merely skipping the mapping is the whole
+	// point: skipping leaves the widget TEMPLATE's captured value, and a template
+	// holds whatever the widget it was extracted from was set to. Image's is
+	// width/height 48 against a declared default of 100, which made every Image
+	// mxcli authored fail with CE0463 — see hiddenUnnamedProperties. Where no
+	// default can be looked up (a datasource has none) the mapping is skipped,
+	// exactly as before.
 	//
 	// This only ever fires for a property the script did NOT name — an MDL
 	// keyword shared by several properties (File Uploader routes both
 	// `associatedFiles` and `associatedImages` from `DataSource:`, gated on
 	// `uploadMode`). Naming a hidden property outright is still an error, raised
 	// by MDL-WIDGET10 at check time rather than silently dropped here (#956).
-	hiddenSkip := e.hiddenUnnamedProperties(def, w)
+	hiddenSkip := e.hiddenUnnamedProperties(def, w,
+		widgetPropertyDefaults(e.pageBuilder.getProjectPath(), def.WidgetID))
 	for _, mapping := range mappings {
-		if hiddenSkip[strings.ToLower(mapping.PropertyKey)] {
+		if reset, hidden := hiddenSkip[strings.ToLower(mapping.PropertyKey)]; hidden {
+			if reset != "" && mapping.Operation == "primitive" {
+				builder.SetPrimitive(mapping.PropertyKey, reset)
+			}
 			continue
 		}
 		ctx, err := e.resolveMapping(mapping, w)
@@ -337,6 +347,18 @@ func (e *PluggableWidgetEngine) Build(def *WidgetDefinition, w *ast.WidgetV3) (*
 			return nil, err
 		}
 	}
+	// A hidden property that MDL cannot name gets its declared default too. The
+	// loop above visits property MAPPINGS — which is what gives a property an MDL
+	// keyword — so it reached `width` and `height` and never `maxHeight`, whose
+	// value stayed at whatever the template captured. That single field is the
+	// whole of the CE0463 on a copied Atlas layout: one line differing in 1480,
+	// mxcli's 0 against the package's declared 250 (mxcli-ledger §142).
+	//
+	// The set of properties that must be default-valued is the widget's to decide,
+	// not mxcli's; making it a subset of what MDL has words for was the mistake.
+	for propKey, reset := range unmappedHiddenResets(def, e.visibilityRules(def), hiddenSkip) {
+		builder.SetPrimitive(propKey, reset)
+	}
 
 	// 4. Auto datasource: map AST DataSource to first DataSource-type property.
 	// This must run before child slots so that entityContext is available
@@ -601,18 +623,32 @@ func (e *PluggableWidgetEngine) isPrimaryAttributeMapping(mapping PropertyMappin
 // explicitly is reported by MDL-WIDGET10 instead, so it is deliberately not
 // included here.
 //
+// The KEY's presence means "hidden". The VALUE is the property's DECLARED
+// default, which the caller must write, or "" when no default could be looked
+// up — mxcli does not invent one.
+//
+// Skipping the property instead leaves the widget TEMPLATE's captured value in
+// place, and a template captures whatever the widget it was extracted from
+// happened to be set to. For the Image widget that is width/height 48 against a
+// declared default of 100, so every Image mxcli authored failed the build with
+// CE0463 — while mxcli's own MDL-WIDGET10 said, in as many words, that a hidden
+// `width` must be "100" (mxcli-formula1 FINDINGS §69/§142). The invariant is
+// default-VALUED, not skipped; the two only coincide when the template is
+// already at the default.
+//
+// defaults is the declared-default map from widgetPropertyDefaults — the same
+// source MDL-WIDGET10 reads, so the writer and the checker cannot disagree about
+// what a default is, which is how this shipped.
+//
 // Rules come from the .def.json, falling back to a live lift from the installed
 // .mpk (the same two sources the visibility application uses).
-func (e *PluggableWidgetEngine) hiddenUnnamedProperties(def *WidgetDefinition, w *ast.WidgetV3) map[string]bool {
-	rules := def.PropertyVisibility
-	if len(rules) == 0 {
-		rules = resolveWidgetVisibilityRules(e.pageBuilder.getProjectPath(), def.WidgetID)
-	}
+func (e *PluggableWidgetEngine) hiddenUnnamedProperties(def *WidgetDefinition, w *ast.WidgetV3, defaults map[string]string) map[string]string {
+	rules := e.visibilityRules(def)
 	if len(rules) == 0 {
 		return nil
 	}
 	values, explicit := widgetValueMap(w, def)
-	out := map[string]bool{}
+	out := map[string]string{}
 	for _, rule := range rules {
 		if rule.Nested() || rule.HiddenWhen == nil {
 			continue
@@ -621,13 +657,82 @@ func (e *PluggableWidgetEngine) hiddenUnnamedProperties(def *WidgetDefinition, w
 		if explicit[key] {
 			continue // named by the script — MDL-WIDGET10's business, not ours
 		}
-		condVal, known := values[strings.ToLower(rule.HiddenWhen.PropertyKey)]
+		condKey := strings.ToLower(rule.HiddenWhen.PropertyKey)
+		condVal, known := values[condKey]
 		if !known {
-			continue // condition indeterminable — never guess
+			// widgetValueMap only knows properties the definition MAPS, because a
+			// mapping is what gives a property an MDL keyword. A rule whose
+			// condition is an UNMAPPED property was therefore always
+			// indeterminable and never fired — which is how `maxHeight` (hidden
+			// when `maxHeightUnit` is "none") kept the template's value and
+			// produced the one differing field in 1480 on a copied Atlas layout
+			// (mxcli-ledger §142).
+			//
+			// The declared default is the right fallback for exactly the reason
+			// the rest of this function exists: MDL cannot name the property, so
+			// nothing has moved it off its default. It is a fallback and not a
+			// preference — a value the script set, or a mapping's own default,
+			// still wins above.
+			condVal, known = defaults[defaultsKey("", rule.HiddenWhen.PropertyKey)]
+			if !known || condVal == "" {
+				continue // still indeterminable — never guess
+			}
 		}
 		if rule.HiddenWhen.Hidden(map[string]string{rule.HiddenWhen.PropertyKey: condVal}) {
-			out[key] = true
+			out[key] = defaults[defaultsKey("", rule.PropertyKey)]
+		}
+	}
+	return out
+}
+
+// visibilityRules is the widget's editorConfig visibility rules: from the
+// .def.json when it carries them, otherwise a live lift from the installed .mpk.
+// Both consumers must use the same list — reading the .def.json field directly
+// gets an EMPTY one for every widget whose rules are lifted, which is most of
+// them, and a lookup keyed on it then silently finds nothing.
+func (e *PluggableWidgetEngine) visibilityRules(def *WidgetDefinition) []types.WidgetVisibilityRule {
+	if len(def.PropertyVisibility) > 0 {
+		return def.PropertyVisibility
+	}
+	return resolveWidgetVisibilityRules(e.pageBuilder.getProjectPath(), def.WidgetID)
+}
+
+// unmappedHiddenResets returns the hidden properties that the property-mapping
+// loop will not reach, keyed by the property key as the widget declares it (the
+// hidden map is lower-cased; a builder needs the real spelling, which is what
+// rules carries).
+//
+// Only properties with a declared default are returned — where none could be
+// looked up there is nothing to write, and mxcli does not invent one. That is
+// also what keeps #956's File Uploader datasource pruning unchanged: a
+// datasource has no default.
+//
+// The mapped ones are excluded rather than merged: the loop already writes them,
+// and writing a second value for one property is its own defect.
+func unmappedHiddenResets(def *WidgetDefinition, rules []types.WidgetVisibilityRule, hidden map[string]string) map[string]string {
+	if len(hidden) == 0 {
+		return nil
+	}
+	mapped := make(map[string]bool, len(def.PropertyMappings))
+	for _, m := range def.PropertyMappings {
+		mapped[strings.ToLower(m.PropertyKey)] = true
+	}
+	for _, mode := range def.Modes {
+		for _, m := range mode.PropertyMappings {
+			mapped[strings.ToLower(m.PropertyKey)] = true
+		}
+	}
+	out := map[string]string{}
+	for _, rule := range rules {
+		key := strings.ToLower(rule.PropertyKey)
+		if mapped[key] {
+			continue
+		}
+		reset, isHidden := hidden[key]
+		if !isHidden || reset == "" {
+			continue
 		}
+		out[rule.PropertyKey] = reset
 	}
 	return out
 }
@@ -648,6 +753,11 @@ func (e *PluggableWidgetEngine) applyOperation(builder backend.WidgetObjectBuild
 		builder.SetPrimitive(propKey, ctx.PrimitiveVal)
 	case "selection":
 		builder.SetSelection(propKey, ctx.PrimitiveVal)
+	case "image":
+		// An image collection entry, by its three-part qualified name. The
+		// value arrives through the generic source branch, so it is in
+		// PrimitiveVal like any other scalar — only the key it lands on differs.
+		builder.SetImage(propKey, ctx.PrimitiveVal)
 	case "expression":
 		builder.SetExpression(propKey, ctx.PrimitiveVal)
 	case "datasource":
diff --git a/mdl/executor/widget_hidden_reset_test.go b/mdl/executor/widget_hidden_reset_test.go
new file mode 100644
index 0000000000..1ad9d70a01
--- /dev/null
+++ b/mdl/executor/widget_hidden_reset_test.go
@@ -0,0 +1,185 @@
+// SPDX-License-Identifier: Apache-2.0
+
+// mxcli-formula1 FINDINGS §69/§142: every Image widget mxcli authored on Mendix
+// 11.13 failed the build with CE0463 "the definition of this widget has changed".
+//
+// Established first, because the skill says to and because it decides whose bug
+// it is (diagnose-ce0463.md, Step 0):
+//
+//	baseline blank project, mxcli never ran        -> 0 CE0463
+//	  …and it ships 10 Studio Pro-authored widgets of the SAME widget id, which pass
+//	the same project + one mxcli-authored Image     -> 1 CE0463, naming that widget
+//
+// So the tool is the variable: Case B, mxcli emits something the package does not
+// accept.
+//
+// The exhaustive path diff against those Studio Pro widgets came back with every
+// path present on both sides and four differing values, two of which were content
+// (the widget's Name, and the image it points at). What remained:
+//
+//	widthUnit   mine='auto'    reference='pixels'
+//	heightUnit  mine='auto'    reference='pixels'
+//
+// and a before/after diff of `mx update-widgets` (which clears the error) changed
+// exactly two values: width and height, 48 -> 100.
+//
+// Two hypotheses were tested and FALSIFIED, which is why they are written down:
+//
+//   - Key order. mxcli's widget node is not in the reference's alphabetical order.
+//     It is a documented CE0463 cause, and it is not this one: the same page's
+//     mxcli-authored Datagrid and Badge carry the identical key order and pass.
+//   - The width VALUE. Authoring Width: 48 explicitly passes, so 48 is not
+//     rejected. (Authoring it explicitly is also what makes the property visible.)
+//
+// The cause is the interaction. The Image widget hides `width` when `widthUnit`
+// is "auto", and a hidden property must hold its DECLARED DEFAULT — mxcli's own
+// MDL-WIDGET10 says so, in as many words:
+//
+//	property `width` is hidden when `widthUnit` is "auto" — a non-default value
+//	there fails the build with CE0463 (the default is "100")
+//
+// The engine skipped the mapping for a hidden property, which leaves the widget
+// TEMPLATE's captured value in place. For Image that value is 48, and the
+// declared default is 100. So `mxcli check` refused what `mxcli exec` emitted by
+// default — and the template alone is enough to see it: image.json's own
+// ValueType declares width's DefaultValue as "100" while its Object stores "48".
+//
+// Skipping was never the invariant. The engine's own comment states it correctly
+// — "all 34 declared properties are stored, the hidden ones AT THEIR DEFAULT, so
+// hidden means default-valued, not absent" — and then skips, which only coincides
+// with the default when the template happens to have captured it.
+
+package executor
+
+import (
+	"testing"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+	"github.com/mendixlabs/mxcli/mdl/types"
+)
+
+// imageDef is the Image widget reduced to the properties this is about: the unit
+// that does the hiding, and the dimension it hides.
+func imageDef() *WidgetDefinition {
+	return &WidgetDefinition{
+		WidgetID: "com.mendix.widget.web.image.Image",
+		MDLName:  "image",
+		PropertyMappings: []PropertyMapping{
+			{PropertyKey: "widthUnit", Source: "WidthUnit", Operation: "primitive", Value: "auto"},
+			{PropertyKey: "width", Source: "Width", Operation: "primitive"},
+			{PropertyKey: "heightUnit", Source: "HeightUnit", Operation: "primitive", Value: "auto"},
+			{PropertyKey: "height", Source: "Height", Operation: "primitive"},
+		},
+		PropertyVisibility: []types.WidgetVisibilityRule{
+			{PropertyKey: "width", HiddenWhen: &types.WidgetVisibilityCondition{
+				PropertyKey: "widthUnit", Operator: "eq", Value: "auto"}},
+			{PropertyKey: "height", HiddenWhen: &types.WidgetVisibilityCondition{
+				PropertyKey: "heightUnit", Operator: "eq", Value: "auto"}},
+		},
+	}
+}
+
+// The declared defaults, as widgetPropertyDefaults lifts them from the installed
+// .mpk. Measured on the 11.13 Image widget.
+func imageDefaults() map[string]string {
+	return map[string]string{"width": "100", "height": "100", "widthunit": "auto", "heightunit": "auto"}
+}
+
+// The reported case: `image img (...)` with no dimensions. Both hidden properties
+// must be RESET to their declared default, not left at whatever the template
+// captured.
+func TestHiddenProperties_ResetToTheirDeclaredDefault(t *testing.T) {
+	e := &PluggableWidgetEngine{pageBuilder: &pageBuilder{}}
+	hidden := e.hiddenUnnamedProperties(imageDef(), &ast.WidgetV3{Name: "img"}, imageDefaults())
+
+	for _, key := range []string{"width", "height"} {
+		reset, ok := hidden[key]
+		if !ok {
+			t.Fatalf("%s is hidden when its unit is auto and was not pruned at all", key)
+		}
+		if reset != "100" {
+			t.Errorf("%s reset value = %q, want %q — skipping leaves the template's 48, "+
+				"which is the CE0463", key, reset, "100")
+		}
+	}
+}
+
+// CONTROL 1: a property that is NOT hidden must not be touched. A reset applied
+// to a visible property would overwrite what the user asked for.
+func TestHiddenProperties_VisiblePropertyIsNotReset(t *testing.T) {
+	e := &PluggableWidgetEngine{pageBuilder: &pageBuilder{}}
+	w := &ast.WidgetV3{Name: "img", Properties: map[string]any{"WidthUnit": "pixels", "Width": "48"}}
+
+	hidden := e.hiddenUnnamedProperties(imageDef(), w, imageDefaults())
+	if _, ok := hidden["width"]; ok {
+		t.Error("width is visible when widthUnit is pixels — resetting it would discard Width: 48")
+	}
+	// …and the other axis is independent: heightUnit is still auto here.
+	if _, ok := hidden["height"]; !ok {
+		t.Error("height is still hidden (heightUnit defaults to auto) and must still be reset")
+	}
+}
+
+// CONTROL 2: a property the SCRIPT named is left to MDL-WIDGET10, which reports
+// it as an error at check time. Silently resetting it would discard the user's
+// value and turn a diagnosable mistake into a mystery.
+func TestHiddenProperties_ExplicitlyNamedIsLeftToTheChecker(t *testing.T) {
+	e := &PluggableWidgetEngine{pageBuilder: &pageBuilder{}}
+	w := &ast.WidgetV3{Name: "img", Properties: map[string]any{"Width": "48"}}
+
+	if _, ok := e.hiddenUnnamedProperties(imageDef(), w, imageDefaults())["width"]; ok {
+		t.Error("a hidden property the script named must not be silently reset — MDL-WIDGET10 reports it")
+	}
+}
+
+// CONTROL 3: with no declared default, the property is still pruned but carries
+// no reset. mxcli does not invent a value it could not look up; skipping is the
+// old behaviour and remains the fallback.
+func TestHiddenProperties_NoDeclaredDefaultMeansNoReset(t *testing.T) {
+	e := &PluggableWidgetEngine{pageBuilder: &pageBuilder{}}
+	hidden := e.hiddenUnnamedProperties(imageDef(), &ast.WidgetV3{Name: "img"}, nil)
+
+	reset, ok := hidden["width"]
+	if !ok {
+		t.Fatal("the property is hidden regardless of whether a default could be found")
+	}
+	if reset != "" {
+		t.Errorf("reset = %q, want empty — no default was available to reset to", reset)
+	}
+}
+
+// The File Uploader case this mechanism was built for (#956) must keep working:
+// there the pruned property is a DATASOURCE, which has no declared default, so it
+// is skipped exactly as before.
+func TestHiddenProperties_DataSourcePruningIsUnchanged(t *testing.T) {
+	e := &PluggableWidgetEngine{pageBuilder: &pageBuilder{}}
+	def := uploadModeDef()
+
+	filesMode := e.hiddenUnnamedProperties(def, &ast.WidgetV3{
+		Name: "fu", Properties: map[string]any{"DataSource": "assoc"}}, nil)
+	if _, ok := filesMode["associatedimages"]; !ok {
+		t.Error("associatedImages was not pruned under the default uploadMode — this is #956's CE0463")
+	}
+	if _, ok := filesMode["associatedfiles"]; ok {
+		t.Error("associatedFiles was pruned under uploadMode files — the widget would lose its data source")
+	}
+}
+
+// The writer and the checker must read the SAME declared defaults, or mxcli can
+// author what it then refuses. That is exactly what happened here: MDL-WIDGET10
+// knew the default was "100" while the writer emitted the template's 48.
+func TestHiddenProperties_WriterAndCheckerShareTheDefaultsSource(t *testing.T) {
+	// widgetPropertyDefaults is the checker's source (validate_widget_hidden.go).
+	// With no project it yields nothing, which is the "cannot look it up" case —
+	// the point here is that the writer calls the same function, so the two can
+	// never disagree about what a default is.
+	if got := widgetPropertyDefaults("", "com.mendix.widget.web.image.Image"); len(got) != 0 {
+		t.Fatalf("expected no defaults without a project, got %d", len(got))
+	}
+	e := &PluggableWidgetEngine{pageBuilder: &pageBuilder{}}
+	hidden := e.hiddenUnnamedProperties(imageDef(), &ast.WidgetV3{Name: "img"},
+		widgetPropertyDefaults("", "com.mendix.widget.web.image.Image"))
+	if reset := hidden["width"]; reset != "" {
+		t.Errorf("reset = %q, want empty when the defaults source has nothing", reset)
+	}
+}
diff --git a/mdl/executor/widget_hidden_reset_unmapped_test.go b/mdl/executor/widget_hidden_reset_unmapped_test.go
new file mode 100644
index 0000000000..ac5f451c6f
--- /dev/null
+++ b/mdl/executor/widget_hidden_reset_unmapped_test.go
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"testing"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+	"github.com/mendixlabs/mxcli/mdl/types"
+)
+
+// mxcli-ledger FINDINGS §142, which took the CE0463 on a copied Atlas layout
+// apart to one field. A full field-level diff of Atlas' own brand image against
+// a describe → rename → exec copy of it, GUIDs masked, differs in **one line of
+// 1480**:
+//
+//	=== ONLY IN ATLAS ===  Object/Properties/21/Value/PrimitiveValue = '250'
+//	=== ONLY IN MINE ===   Object/Properties/21/Value/PrimitiveValue = '0'
+//
+// Resolved through its TypePointer that property is `maxHeight`, whose declared
+// default in Image 1.6.0 is 250. mxcli writes 0. Setting it clears the build.
+//
+// This is the same class as §69 — a hidden property must hold its DECLARED
+// DEFAULT, or the package rejects the widget — and the fix for §69 did not cover
+// it, which is the interesting part. `hiddenUnnamedProperties` names maxHeight
+// correctly: it walks the widget's VISIBILITY RULES, and maxHeight has two
+// ("hidden when heightUnit ≠ auto", "hidden when maxHeightUnit = none").
+//
+// The reset was applied in a loop over the definition's PROPERTY MAPPINGS. A
+// mapping is what gives a property an MDL keyword, and `width`/`height` have one
+// (`Width:`, `Height:`) while `maxHeight` has none — MDL cannot spell it. So the
+// property was never visited and the widget TEMPLATE's captured value stood.
+//
+// The set of properties that must be default-valued is decided by the widget's
+// editorConfig, and the set MDL can name is decided by mxcli. Making one a subset
+// of the other was the mistake: every hidden property with a declared default is
+// written, whether or not MDL has a word for it.
+
+// imageDefWithMaxHeight is the Image widget reduced to the two properties this is
+// about — one hidden property WITH an MDL mapping, one WITHOUT.
+func imageDefWithMaxHeight() *WidgetDefinition {
+	def := imageDef()
+	def.PropertyVisibility = append(def.PropertyVisibility,
+		// maxHeight's real rules on Image 1.5.0/1.6.0, both of them.
+		types.WidgetVisibilityRule{PropertyKey: "maxHeight", HiddenWhen: &types.WidgetVisibilityCondition{
+			PropertyKey: "maxHeightUnit", Operator: "eq", Value: "none"}},
+	)
+	return def
+}
+
+func imageDefaultsWithMaxHeight() map[string]string {
+	d := imageDefaults()
+	d["maxheight"] = "250"
+	d["maxheightunit"] = "none"
+	return d
+}
+
+// The reset list must include a hidden property that has no MDL mapping. Before
+// this, the caller iterated mappings, so `maxHeight` could be named here and
+// still never written.
+func TestHiddenResets_IncludeAPropertyMDLCannotName(t *testing.T) {
+	e := &PluggableWidgetEngine{pageBuilder: &pageBuilder{}}
+	def := imageDefWithMaxHeight()
+	hidden := e.hiddenUnnamedProperties(def, &ast.WidgetV3{Name: "img"}, imageDefaultsWithMaxHeight())
+
+	resets := unmappedHiddenResets(def, def.PropertyVisibility, hidden)
+	got, ok := resets["maxHeight"]
+	if !ok {
+		t.Fatalf("maxHeight is hidden and has a declared default, but is not in the resets: %v", resets)
+	}
+	if got != "250" {
+		t.Errorf("maxHeight reset = %q, want %q — the template's 0 is the CE0463", got, "250")
+	}
+}
+
+// CONTROL 1: a hidden property that DOES have a mapping must not appear here.
+// The mapping loop already writes it, and writing it twice would be a second
+// value for one property.
+func TestHiddenResets_SkipWhatTheMappingLoopAlreadyWrites(t *testing.T) {
+	e := &PluggableWidgetEngine{pageBuilder: &pageBuilder{}}
+	def := imageDefWithMaxHeight()
+	hidden := e.hiddenUnnamedProperties(def, &ast.WidgetV3{Name: "img"}, imageDefaultsWithMaxHeight())
+
+	for _, mapped := range []string{"width", "height"} {
+		if _, ok := unmappedHiddenResets(def, def.PropertyVisibility, hidden)[mapped]; ok {
+			t.Errorf("%s has a property mapping and is written by that loop; "+
+				"it must not be written a second time here", mapped)
+		}
+	}
+}
+
+// CONTROL 2: no declared default, no reset. mxcli does not invent a value — the
+// rule is "hidden means default-valued", and with no default there is nothing to
+// say. This is what keeps #956's File Uploader datasource pruning unchanged.
+func TestHiddenResets_NoDeclaredDefaultWritesNothing(t *testing.T) {
+	e := &PluggableWidgetEngine{pageBuilder: &pageBuilder{}}
+	def := imageDefWithMaxHeight()
+	// Defaults for everything except maxHeight.
+	hidden := e.hiddenUnnamedProperties(def, &ast.WidgetV3{Name: "img"}, imageDefaults())
+
+	if v, ok := unmappedHiddenResets(def, def.PropertyVisibility, hidden)["maxHeight"]; ok {
+		t.Errorf("maxHeight was reset to %q with no declared default to reset it to", v)
+	}
+}
+
+// CONTROL 3: a VISIBLE unmapped property is not touched. The reset is about
+// hidden properties; applying it to a visible one would overwrite the template's
+// value where the template is right.
+func TestHiddenResets_VisibleUnmappedPropertyIsLeftAlone(t *testing.T) {
+	e := &PluggableWidgetEngine{pageBuilder: &pageBuilder{}}
+	def := imageDefWithMaxHeight()
+	// maxHeightUnit = "pixels" makes maxHeight visible, so nothing is hidden by
+	// that rule.
+	w := &ast.WidgetV3{Name: "img", Properties: map[string]any{"MaxHeightUnit": "pixels"}}
+	hidden := e.hiddenUnnamedProperties(def, w, imageDefaultsWithMaxHeight())
+
+	if _, ok := unmappedHiddenResets(def, def.PropertyVisibility, hidden)["maxHeight"]; ok {
+		t.Error("maxHeight is visible under this configuration and must keep its value")
+	}
+}
diff --git a/mdl/executor/widget_primitive_default_condition_test.go b/mdl/executor/widget_primitive_default_condition_test.go
index f53abf7794..e251cc0783 100644
--- a/mdl/executor/widget_primitive_default_condition_test.go
+++ b/mdl/executor/widget_primitive_default_condition_test.go
@@ -67,20 +67,20 @@ func TestHiddenUnnamedProperties_PrunesTheInactiveDataSource(t *testing.T) {
 	def := uploadModeDef()
 
 	filesMode := e.hiddenUnnamedProperties(def, &ast.WidgetV3{
-		Name: "fu", Properties: map[string]any{"DataSource": "assoc"}})
-	if !filesMode["associatedimages"] {
+		Name: "fu", Properties: map[string]any{"DataSource": "assoc"}}, nil)
+	if _, ok := filesMode["associatedimages"]; !ok {
 		t.Error("associatedImages was not pruned under the default uploadMode — this is the CE0463")
 	}
-	if filesMode["associatedfiles"] {
+	if _, ok := filesMode["associatedfiles"]; ok {
 		t.Error("associatedFiles was pruned under uploadMode files — the widget would lose its data source")
 	}
 
 	imagesMode := e.hiddenUnnamedProperties(def, &ast.WidgetV3{
-		Name: "fu", Properties: map[string]any{"uploadMode": "images", "DataSource": "assoc"}})
-	if !imagesMode["associatedfiles"] {
+		Name: "fu", Properties: map[string]any{"uploadMode": "images", "DataSource": "assoc"}}, nil)
+	if _, ok := imagesMode["associatedfiles"]; !ok {
 		t.Error("associatedFiles was not pruned under uploadMode images")
 	}
-	if imagesMode["associatedimages"] {
+	if _, ok := imagesMode["associatedimages"]; ok {
 		t.Error("associatedImages was pruned under uploadMode images — CE0642, the property is required there")
 	}
 }
diff --git a/mdl/executor/widget_registry.go b/mdl/executor/widget_registry.go
index fa2880b2e0..57ed8a5188 100644
--- a/mdl/executor/widget_registry.go
+++ b/mdl/executor/widget_registry.go
@@ -34,6 +34,10 @@ var defaultKnownOperations = map[string]bool{
 	"texttemplate":     true,
 	"action":           true,
 	"attributeObjects": true,
+	// An image collection entry on an image-typed property (the Image widget's
+	// `imageObject`). Without it the property is unreachable from MDL and the
+	// widget's default source has nothing to show — see setImageValue.
+	"image": true,
 }
 
 // knownOperations is the active set used for validation, initialized from
diff --git a/mdl/grammar/MDLLexer.g4 b/mdl/grammar/MDLLexer.g4
index e20d8af321..a135029834 100644
--- a/mdl/grammar/MDLLexer.g4
+++ b/mdl/grammar/MDLLexer.g4
@@ -217,6 +217,10 @@ CONTAINS: C O N T A I N S;
 AVERAGE: A V E R A G E;
 MINIMUM: M I N I M U M;
 MAXIMUM: M A X I M U M;
+// Mendix's three newer aggregate functions. ALL is already a token above.
+REDUCE: R E D U C E;
+ANY: A N Y;
+INITIAL: I N I T I A L;
 LIST: L I S T;
 REMOVE: R E M O V E;
 EQUALS_OP: E Q U A L S;
diff --git a/mdl/grammar/domains/MDLMicroflow.g4 b/mdl/grammar/domains/MDLMicroflow.g4
index bdaea6b153..54667f3992 100644
--- a/mdl/grammar/domains/MDLMicroflow.g4
+++ b/mdl/grammar/domains/MDLMicroflow.g4
@@ -828,6 +828,20 @@ listAggregateOperation
     | MINIMUM LPAREN attributePath RPAREN                                             // $min = MINIMUM($list.attr)
     | MAXIMUM LPAREN VARIABLE COMMA expression RPAREN                                 // $max = MAXIMUM($list, expr)
     | MAXIMUM LPAREN attributePath RPAREN                                             // $max = MAXIMUM($list.attr)
+    // REDUCE folds a list into one value. Both extra inputs are required and
+    // neither is derivable: `initial` seeds $currentResult, `returns` is the
+    // type Mendix stores alongside it (#1004).
+    | REDUCE LPAREN VARIABLE COMMA expression COMMA reduceFoldOptions RPAREN          // $total = REDUCE($list, expr, initial: 0, returns: Decimal)
+    // ALL / ANY test a Boolean expression over every item. Their return type is
+    // always Boolean, so it is derived rather than written.
+    | ALL LPAREN VARIABLE COMMA expression RPAREN                                     // $allMatch = ALL($list, expr)
+    | ANY LPAREN VARIABLE COMMA expression RPAREN                                     // $anyMatch = ANY($list, expr)
+    ;
+
+// REDUCE's seed and result type, in the ( key: value ) property style used
+// across MDL. Order is fixed so the statement reads the way it is written.
+reduceFoldOptions
+    : INITIAL COLON expression COMMA RETURNS COLON dataType
     ;
 
 /**
diff --git a/mdl/grammar/domains/MDLSettings.g4 b/mdl/grammar/domains/MDLSettings.g4
index 72c7068622..c71af8aa40 100644
--- a/mdl/grammar/domains/MDLSettings.g4
+++ b/mdl/grammar/domains/MDLSettings.g4
@@ -581,7 +581,7 @@ keyword
     | COUNT | SUM | AVG | MIN | MAX | DISTINCT | ALL
     | ASC | DESC | UNION | INTERSECT | SUBTRACT | EXISTS
     | CAST | COALESCE | TRIM | LENGTH | CONTAINS | MATCH
-    | AVERAGE | MINIMUM | MAXIMUM
+    | AVERAGE | MINIMUM | MAXIMUM | REDUCE | ANY | INITIAL
     | IS_NULL | IS_NOT_NULL | NOT_NULL
     | HEAD | TAIL | FIND | SORT | EMPTY
     | LIST_OF | LIST_KW | EQUALS_OP
diff --git a/mdl/visitor/annotation_height_hint_test.go b/mdl/visitor/annotation_height_hint_test.go
new file mode 100644
index 0000000000..25b9d8a650
--- /dev/null
+++ b/mdl/visitor/annotation_height_hint_test.go
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package visitor
+
+import (
+	"strings"
+	"testing"
+)
+
+// TestAnnotationHeightHint covers issue #1014. Mendix stores no annotation
+// height — DomainModels$Annotation has exactly Caption, ExportLevel, Location
+// and Width — so `Height: n` can never be accepted. The bare ANTLR error
+// ("expecting {POSITION, CAPTION, WIDTH}") reads like a missing mxcli feature,
+// which is what prompted the feature request; the hint says which it is and
+// names the two levers that do exist.
+func TestAnnotationHeightHint(t *testing.T) {
+	script := `create or modify annotation in M (
+  Caption: 'Section note',
+  Position: (100, 100),
+  Width: 420,
+  Height: 200
+);`
+	_, errs := Build(script)
+	if len(errs) == 0 {
+		t.Fatal("expected a parse error for Height on an annotation")
+	}
+	joined := errsText(errs)
+	for _, want := range []string{
+		"does not store an annotation height",
+		"auto-sizes",
+		"Width: 300",
+		"SET POSITION",
+	} {
+		if !strings.Contains(joined, want) {
+			t.Errorf("hint does not mention %q; got:\n%s", want, joined)
+		}
+	}
+}
+
+// TestAnnotationUnknownPropertyHint: any other unsupported property gets the
+// four-property statement without the height-specific advice.
+func TestAnnotationUnknownPropertyHint(t *testing.T) {
+	_, errs := Build("create annotation in M (\n  Caption: 'x',\n  Color: 'red'\n);")
+	if len(errs) == 0 {
+		t.Fatal("expected a parse error for Color on an annotation")
+	}
+	joined := errsText(errs)
+	if !strings.Contains(joined, "stores only Caption, Position and Width") {
+		t.Errorf("missing the four-property hint; got:\n%s", joined)
+	}
+	if strings.Contains(joined, "auto-sizes") {
+		t.Errorf("height-specific advice leaked onto a non-height property; got:\n%s", joined)
+	}
+}
+
+// TestWidgetHeightIsNotAnnotationHinted is the control that keeps the hint from
+// keying on the word "Height". A page widget's Height is valid MDL, and the
+// annotation expecting-set is what distinguishes the two.
+func TestWidgetHeightIsNotAnnotationHinted(t *testing.T) {
+	script := `create page M.P (Title: 'T', Layout: 'Atlas_Core.Atlas_Default') {
+  IMAGE img (Image: 'M.Coll.Pic', Width: 100, Height: 200)
+}`
+	_, errs := Build(script)
+	if len(errs) != 0 {
+		t.Fatalf("a widget Height should parse cleanly; got: %s", errsText(errs))
+	}
+}
diff --git a/mdl/visitor/visitor.go b/mdl/visitor/visitor.go
index d96a962d31..6b3f68ffd2 100644
--- a/mdl/visitor/visitor.go
+++ b/mdl/visitor/visitor.go
@@ -151,6 +151,29 @@ func enhanceErrorMessage(msg, offendingLine string) string {
 			"  On an existing entity, ALTER ENTITY Mod.E SET COMMENT '…' also works.", msg)
 	}
 
+	// `Height: n` on an annotation. Mendix stores no annotation height — the box
+	// auto-sizes to its caption — so the bare "expecting {POSITION, CAPTION,
+	// WIDTH}" reads like a missing mxcli feature when it is a missing Mendix
+	// property. Say which it is, and name the two levers that do exist. (#1014)
+	if looksLikeAnnotationProperty(msg) && annotationHeightRe.MatchString(offendingLine) {
+		return fmt.Sprintf("%s\n\n  Mendix does not store an annotation height. DomainModels$Annotation has\n"+
+			"  exactly four properties — Caption, ExportLevel, Location and Width — so the\n"+
+			"  note auto-sizes to its caption and there is nothing to write a height into.\n"+
+			"  Height follows from the wrapping, so WIDTH is the lever:\n"+
+			"    Width: 300   -- narrower wraps to more lines, so the note is TALLER\n"+
+			"    Width: 600   -- wider wraps to fewer lines, so the note is SHORTER\n"+
+			"  To stop a note overlapping what sits below it, move those down:\n"+
+			"    ALTER ENTITY Mod.Entity SET POSITION (x, y);", msg)
+	}
+
+	// Any other unknown property in an annotation's list — the same four-property
+	// limit, without the height-specific advice.
+	if looksLikeAnnotationProperty(msg) {
+		return fmt.Sprintf("%s\n\n  An annotation stores only Caption, Position and Width (Mendix keeps\n"+
+			"  Caption, ExportLevel, Location and Width, and nothing else — there is no\n"+
+			"  height, no colour and no name).", msg)
+	}
+
 	if looksLikeEnumEquals(msg) {
 		return fmt.Sprintf("%s\n\n  Enumeration values do not use '='. Write the value name (quoted or not)\n"+
 			"  followed by an optional quoted caption:\n"+
@@ -578,3 +601,24 @@ func hintedKeywords() []string {
 	sort.Strings(out)
 	return out
 }
+
+// annotationHeightRe matches a `Height:` property line.
+var annotationHeightRe = regexp.MustCompile(`(?i)^\s*height\s*:`)
+
+// looksLikeAnnotationProperty reports whether a parse error came from an
+// annotation's property list. The three-token expecting-set is unique to
+// `annotationProperty` in the grammar, and survives simplifyExpecting untouched
+// (three tokens, none of them statement-start keywords), so keying on it does
+// not misfire on a page widget's Height or any other property list.
+func looksLikeAnnotationProperty(msg string) bool {
+	i := strings.Index(msg, "expecting {")
+	if i < 0 {
+		return false
+	}
+	rel := strings.Index(msg[i:], "}")
+	if rel < 0 {
+		return false
+	}
+	set := msg[i : i+rel]
+	return strings.Contains(set, "CAPTION") && strings.Contains(set, "POSITION") && strings.Contains(set, "WIDTH")
+}
diff --git a/mdl/visitor/visitor_microflow_actions.go b/mdl/visitor/visitor_microflow_actions.go
index 2f8d4a6a86..63d81e40a6 100644
--- a/mdl/visitor/visitor_microflow_actions.go
+++ b/mdl/visitor/visitor_microflow_actions.go
@@ -983,6 +983,41 @@ func buildAggregateListStatement(ctx parser.IAggregateListStatementContext) *ast
 			} else if path := op.AttributePath(); path != nil {
 				stmt.InputVariable, stmt.Attribute = parseAttributePath(path.GetText())
 			}
+		} else if op.REDUCE() != nil {
+			// REDUCE($list, expr, initial: seed, returns: Type). Expression(0) is
+			// the fold body; the seed lives inside reduceFoldOptions, which the
+			// grammar makes mandatory, so a well-formed parse always has both.
+			stmt.Operation = ast.AggregateReduce
+			stmt.IsExpression = true
+			if v := op.VARIABLE(); v != nil {
+				stmt.InputVariable = strings.TrimPrefix(v.GetText(), "$")
+			}
+			if exprCtx := op.Expression(); exprCtx != nil {
+				stmt.Expression = buildSourceExpression(exprCtx)
+			}
+			if opts, ok := op.ReduceFoldOptions().(*parser.ReduceFoldOptionsContext); ok && opts != nil {
+				if seed := opts.Expression(); seed != nil {
+					stmt.InitialValue = buildSourceExpression(seed)
+				}
+				if dt := opts.DataType(); dt != nil {
+					t := buildDataType(dt)
+					stmt.ReturnType = &t
+				}
+			}
+		} else if op.ALL() != nil || op.ANY() != nil {
+			// Boolean predicates over the list. No seed, and the return type is
+			// always Boolean, so neither is written in MDL.
+			stmt.Operation = ast.AggregateAll
+			if op.ANY() != nil {
+				stmt.Operation = ast.AggregateAny
+			}
+			stmt.IsExpression = true
+			if v := op.VARIABLE(); v != nil {
+				stmt.InputVariable = strings.TrimPrefix(v.GetText(), "$")
+			}
+			if exprCtx := op.Expression(); exprCtx != nil {
+				stmt.Expression = buildSourceExpression(exprCtx)
+			}
 		}
 	}
 
diff --git a/mdl/visitor/visitor_microflow_aggregate_test.go b/mdl/visitor/visitor_microflow_aggregate_test.go
index 7787af2d6b..50f154f934 100644
--- a/mdl/visitor/visitor_microflow_aggregate_test.go
+++ b/mdl/visitor/visitor_microflow_aggregate_test.go
@@ -101,3 +101,76 @@ func parseSingleAggregate(t *testing.T, stmt string) *ast.AggregateListStmt {
 	t.Fatalf("no AggregateListStmt produced by %q", stmt)
 	return nil
 }
+
+// Mendix has eight aggregate functions; the grammar had five. DESCRIBE renders
+// an activity by name, so a stored Reduce/All/Any came back out as MDL the
+// parser could not read: `reduce(...)` fell through to a plain Change Variable
+// and MDL044 then reported `reduce()` as "not a Mendix expression function"
+// (#1004). Each of the three must reach an aggregate, not a SET.
+func TestAggregateAcceptsReduceAllAny(t *testing.T) {
+	cases := []struct {
+		name, src  string
+		wantOp     ast.AggregateListOperationType
+		wantInit   bool
+		wantReturn ast.DataTypeKind
+	}{
+		{
+			name:       "reduce carries its seed and result type",
+			src:        "$T = reduce($ProductList, $currentResult + $currentObject/Price, initial: 0, returns: Decimal);",
+			wantOp:     ast.AggregateReduce,
+			wantInit:   true,
+			wantReturn: ast.TypeDecimal,
+		},
+		{
+			name:   "all takes a bare boolean expression",
+			src:    "$T = all($ProductList, $currentObject/Price > 0);",
+			wantOp: ast.AggregateAll,
+		},
+		{
+			name:   "any takes a bare boolean expression",
+			src:    "$T = any($ProductList, $currentObject/Price > 0);",
+			wantOp: ast.AggregateAny,
+		},
+	}
+
+	for _, tc := range cases {
+		t.Run(tc.name, func(t *testing.T) {
+			got := parseSingleAggregate(t, tc.src)
+			if got.Operation != tc.wantOp {
+				t.Errorf("operation = %v, want %v", got.Operation, tc.wantOp)
+			}
+			if got.InputVariable != "ProductList" {
+				t.Errorf("input variable = %q, want %q", got.InputVariable, "ProductList")
+			}
+			if !got.IsExpression || got.Expression == nil {
+				t.Errorf("expression form not recognised: IsExpression=%v Expression=%v", got.IsExpression, got.Expression)
+			}
+			if tc.wantInit {
+				if got.InitialValue == nil {
+					t.Error("initial value missing — reduce would be stored with an empty fold")
+				}
+				if got.ReturnType == nil {
+					t.Fatal("return type missing — reduce would be stored with no result type")
+				}
+				if got.ReturnType.Kind != tc.wantReturn {
+					t.Errorf("return type kind = %v, want %v", got.ReturnType.Kind, tc.wantReturn)
+				}
+			} else if got.InitialValue != nil || got.ReturnType != nil {
+				// ALL/ANY have no seed and always fold to Boolean; writing either
+				// from MDL would let an author contradict Mendix.
+				t.Errorf("%v should carry no seed or declared type, got initial=%v returns=%v",
+					tc.wantOp, got.InitialValue, got.ReturnType)
+			}
+		})
+	}
+}
+
+// Adding REDUCE, ANY and INITIAL as lexer tokens takes those words out of
+// circulation as bare identifiers unless they are also listed in the `keyword`
+// rule. They are, and this is the check that says so.
+func TestReduceKeywordsStayUsableAsIdentifiers(t *testing.T) {
+	src := "create entity M.Thing (\n  reduce: string(10),\n  any: string(10),\n  initial: string(10)\n);"
+	if _, errs := Build(src); len(errs) > 0 {
+		t.Fatalf("new keywords are no longer usable as attribute names: %v", errs)
+	}
+}
diff --git a/mdl/visitor/xpath_format.go b/mdl/visitor/xpath_format.go
index daeecda02d..6442792ced 100644
--- a/mdl/visitor/xpath_format.go
+++ b/mdl/visitor/xpath_format.go
@@ -47,6 +47,12 @@ func FormatXPathConstraintWidth(constraint string, width int) string {
 	if strings.TrimSpace(constraint) == "" {
 		return constraint
 	}
+	// XPath's operator keywords are lower case only, and MDL accepts any case.
+	// This runs BEFORE the width test, because the short branch returns the
+	// caller's own bytes and an uppercase `AND` there is CE0161 at build time —
+	// which is exactly where it hid (mxcli-formula1 §80). See
+	// NormalizeXPathOperators.
+	constraint = NormalizeXPathOperators(constraint)
 	// Already short enough to read at a glance: leave it exactly as it is. This
 	// is the case for the overwhelming majority of constraints, and returning the
 	// caller's own bytes is what keeps this change from touching them.
diff --git a/mdl/visitor/xpath_operators.go b/mdl/visitor/xpath_operators.go
new file mode 100644
index 0000000000..5d6630a5dd
--- /dev/null
+++ b/mdl/visitor/xpath_operators.go
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package visitor
+
+import "strings"
+
+// XPath 1.0 spells its operator keywords in LOWER CASE only. MDL's lexer accepts
+// any case — `AND: A N D;` — so a constraint written `WHERE a = x AND b = y` is
+// perfectly good MDL and, stored verbatim, is XPath mxbuild rejects:
+//
+//	Retrieve object(s) activity 'Retrieve list of LiveForecast from database':
+//	  Error(s) in XPath constraint.                                   (CE0161)
+//
+// mxcli lowercased the operator already, on one of its two paths.
+// expressionToXPath does it while walking the parse tree; but
+// buildRetrieveWhereExpression freezes the RAW SOURCE whenever the clause
+// contains a `/`, which every variable path does, and expressionToXPath's
+// SourceExpr case hands that text straight back. So the casing survived exactly
+// when a path was present — which is why the reporting project's literal-only
+// reproducer built cleanly and looked like a non-bug (mxcli-formula1 §80).
+//
+// Normalising here rather than in the retrieve builder covers all three of
+// mxcli's constraint writers — retrieve, page data source, entity access rule —
+// since all three go through FormatXPathConstraint.
+
+// xpathOperatorKeywords are the operator names to fold to lower case. Only the
+// three MDL itself accepts in any case; `div` and `mod` are XPath keywords too
+// but nothing in MDL produces them, and a rewrite nothing needs is a rewrite
+// that can only be wrong.
+var xpathOperatorKeywords = map[string]string{
+	"and": "and",
+	"or":  "or",
+	"not": "not",
+}
+
+// NormalizeXPathOperators folds XPath's operator keywords to lower case,
+// leaving string literals and identifiers exactly as they are.
+//
+// The two things it must not touch are the reason this scans rather than
+// substitutes:
+//
+//   - Inside a STRING LITERAL the letters are data. Rewriting `'A AND B'`
+//     changes which rows the constraint matches — a silent wrong-answer bug,
+//     strictly worse than the build error being fixed.
+//   - An identifier that merely contains the letters (`Brand`, `Andrew`,
+//     `NOTES`, `Order_Andon`) is not an operator. Only a whole token counts.
+func NormalizeXPathOperators(constraint string) string {
+	if constraint == "" {
+		return constraint
+	}
+	var b strings.Builder
+	b.Grow(len(constraint))
+
+	for i := 0; i < len(constraint); {
+		c := constraint[i]
+
+		// A string literal runs to its closing quote; a doubled quote inside one
+		// is an escaped quote, not the end (the same rule the MDL expression
+		// scanner uses).
+		if c == '\'' {
+			j := i + 1
+			for j < len(constraint) {
+				if constraint[j] == '\'' {
+					if j+1 < len(constraint) && constraint[j+1] == '\'' {
+						j += 2
+						continue
+					}
+					j++
+					break
+				}
+				j++
+			}
+			b.WriteString(constraint[i:j])
+			i = j
+			continue
+		}
+
+		if !isXPathWordByte(c) {
+			b.WriteByte(c)
+			i++
+			continue
+		}
+
+		// A whole word. `not` is a function, so it is a keyword whether or not a
+		// `(` follows; `and`/`or` are infix. Either way the test is the token.
+		j := i
+		for j < len(constraint) && isXPathWordByte(constraint[j]) {
+			j++
+		}
+		word := constraint[i:j]
+		if lower, ok := xpathOperatorKeywords[strings.ToLower(word)]; ok && !partOfXPathName(constraint, i, j) {
+			b.WriteString(lower)
+		} else {
+			b.WriteString(word)
+		}
+		i = j
+	}
+	return b.String()
+}
+
+// isXPathWordByte reports whether c can appear inside an XPath name token.
+// `.`, `/` and `$` are deliberately excluded: they SEPARATE names, and
+// partOfXPathName uses them to tell a qualified name from a bare keyword.
+func isXPathWordByte(c byte) bool {
+	return c == '_' || c == '-' ||
+		(c >= 'a' && c <= 'z') || (c >= 'A' && c <= 'Z') || (c >= '0' && c <= '9')
+}
+
+// partOfXPathName reports whether the token at [start,end) is a segment of a
+// qualified or navigated name — `Module.Not`, `$v/And`, `And/Name` — where the
+// word is somebody's identifier and not an operator.
+func partOfXPathName(s string, start, end int) bool {
+	for i := start - 1; i >= 0; i-- {
+		switch s[i] {
+		case ' ', '\t', '\r', '\n':
+			continue
+		case '.', '/', '$', '@':
+			return true
+		}
+		break
+	}
+	for i := end; i < len(s); i++ {
+		switch s[i] {
+		case ' ', '\t', '\r', '\n':
+			continue
+		case '.', '/':
+			return true
+		}
+		break
+	}
+	return false
+}
diff --git a/mdl/visitor/xpath_operators_test.go b/mdl/visitor/xpath_operators_test.go
new file mode 100644
index 0000000000..739d0dd559
--- /dev/null
+++ b/mdl/visitor/xpath_operators_test.go
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package visitor
+
+import "testing"
+
+// mxcli-formula1 FINDINGS §80: `RETRIEVE … WHERE a = x AND b = y` stored an
+// uppercase `AND` in the XPath constraint, which mxbuild rejects:
+//
+//	ERROR at Formula1Backend, Microflow 'ZZ_AndProbe2',
+//	  Retrieve object(s) activity 'Retrieve list of LiveForecast from database':
+//	  Error(s) in XPath constraint.                                    (CE0161)
+//
+// XPath 1.0 spells its operators in lower case only, and MDL's lexer accepts
+// any case (`AND: A N D;`), so the two have to be reconciled on the way out.
+//
+// The finding is careful about something worth repeating: an earlier note
+// blamed the CASING alone, and a literal-only reproducer built cleanly. The
+// trigger is a VARIABLE reference on one side. Measured, and reproduced here on
+// 11.13 before the fix:
+//
+//	WHERE SessionKey = '1' AND AtLap = 2                  -> stored `and`, builds
+//	WHERE SessionKey = $N/SessionKey AND AtLap = $N/AtLap -> stored `AND`, CE0161
+//	…the same with lowercase `and`                        -> builds
+//
+// Two rendering paths, and only one normalises. `expressionToXPath` lowercases
+// the operator as it walks the parse tree; but `buildRetrieveWhereExpression`
+// freezes the RAW SOURCE whenever the clause contains a `/` — which every
+// variable path does — and `expressionToXPath`'s SourceExpr case hands that text
+// back verbatim. So the casing only survives when a path is present, which is
+// exactly the correlation the finding measured and could not explain.
+//
+// Normalising at FormatXPathConstraint fixes all three of mxcli's constraint
+// writers at once (retrieve, page data source, entity access rule), which is
+// why it goes there rather than in the retrieve builder.
+
+func TestNormalizeXPathOperators_LowercasesBooleanOperators(t *testing.T) {
+	cases := []struct{ in, want string }{
+		// The reported case: a variable path, so the raw source is preserved.
+		{"[SessionKey = $N/SessionKey AND AtLap = $N/AtLap]",
+			"[SessionKey = $N/SessionKey and AtLap = $N/AtLap]"},
+		{"[a = 1 OR b = 2]", "[a = 1 or b = 2]"},
+		{"[NOT(a = 1)]", "[not(a = 1)]"},
+		// Mixed case, which the lexer accepts just as readily.
+		{"[a = 1 And b = 2]", "[a = 1 and b = 2]"},
+		{"[a = 1 Or b = 2]", "[a = 1 or b = 2]"},
+		// Several in one constraint.
+		{"[a = 1 AND b = 2 OR c = 3]", "[a = 1 and b = 2 or c = 3]"},
+	}
+	for _, tc := range cases {
+		if got := NormalizeXPathOperators(tc.in); got != tc.want {
+			t.Errorf("NormalizeXPathOperators(%q)\n got %q\nwant %q", tc.in, got, tc.want)
+		}
+	}
+}
+
+// A STRING LITERAL is data, not syntax. Rewriting inside one changes what the
+// constraint matches — a silent wrong-rows bug, which is worse than the CE0161
+// this fixes.
+func TestNormalizeXPathOperators_LeavesStringLiteralsAlone(t *testing.T) {
+	cases := []string{
+		"[Name = 'A AND B']",
+		"[Name = 'AND']",
+		"[Name = 'NOT SET' AND Active = true()]",
+		// A doubled quote is an escaped quote inside the literal, not its end.
+		"[Name = 'it''s AND then' ]",
+	}
+	for _, in := range cases {
+		got := NormalizeXPathOperators(in)
+		want := in
+		if in == "[Name = 'NOT SET' AND Active = true()]" {
+			want = "[Name = 'NOT SET' and Active = true()]" // the operator OUTSIDE is normalised
+		}
+		if got != want {
+			t.Errorf("NormalizeXPathOperators(%q)\n got %q\nwant %q", in, got, want)
+		}
+	}
+}
+
+// An identifier that merely CONTAINS an operator's letters is not an operator.
+// This is the whole reason the replacement is token-based rather than a
+// string substitution.
+func TestNormalizeXPathOperators_LeavesIdentifiersAlone(t *testing.T) {
+	for _, in := range []string{
+		"[Brand = 'x']",
+		"[Andrew = 1]",
+		"[Module.Handover = 1]",
+		"[NOTES != empty]",
+		"[Sales.Order_Andon/Sales.Andon/Name = 'x']",
+		"[ORDERS = 1]",
+	} {
+		if got := NormalizeXPathOperators(in); got != in {
+			t.Errorf("NormalizeXPathOperators(%q) rewrote an identifier: %q", in, got)
+		}
+	}
+}
+
+// Idempotent, and a no-op on what already worked — the literal-only form the
+// finding measured as building cleanly must come through untouched.
+func TestNormalizeXPathOperators_IsANoOpOnCorrectInput(t *testing.T) {
+	for _, in := range []string{
+		"[SessionKey = '1' and AtLap = 2]",
+		"[a = 1 or not(b = 2)]",
+		"",
+		"[]",
+	} {
+		if got := NormalizeXPathOperators(in); got != in {
+			t.Errorf("NormalizeXPathOperators(%q) = %q, want it unchanged", in, got)
+		}
+	}
+	// Applying it twice changes nothing more.
+	once := NormalizeXPathOperators("[a = 1 AND b = 2]")
+	if twice := NormalizeXPathOperators(once); twice != once {
+		t.Errorf("not idempotent: %q then %q", once, twice)
+	}
+}
+
+// The end the finding is about: the constraint mxcli actually stores. Every
+// constraint writer goes through FormatXPathConstraint, so the normalisation
+// has to survive both its branches — the short one that returns the caller's
+// own bytes, and the wrapping one.
+func TestFormatXPathConstraint_NormalisesTheOperator(t *testing.T) {
+	short := "[SessionKey = $N/SessionKey AND AtLap = $N/AtLap]"
+	if got, want := FormatXPathConstraint(short), "[SessionKey = $N/SessionKey and AtLap = $N/AtLap]"; got != want {
+		t.Errorf("short constraint:\n got %q\nwant %q", got, want)
+	}
+
+	// Long enough to be wrapped: the operator must be lower case there too, and
+	// the wrapping (upstream #979) must still happen.
+	long := "[SessionKey = $Newest/SessionKey AND AtLap = $Newest/AtLap AND Status = 'Published' AND Archived = false()]"
+	got := FormatXPathConstraint(long)
+	if containsUpperOperator(got) {
+		t.Errorf("wrapped constraint kept an uppercase operator:\n%s", got)
+	}
+	if !hasNewline(got) {
+		t.Errorf("a constraint over the width budget should still be wrapped:\n%s", got)
+	}
+}
+
+func containsUpperOperator(s string) bool {
+	for _, op := range []string{" AND ", " OR ", "NOT("} {
+		if idx := indexOf(s, op); idx >= 0 {
+			return true
+		}
+	}
+	return false
+}
+
+func hasNewline(s string) bool { return indexOf(s, "\n") >= 0 }
+
+func indexOf(s, sub string) int {
+	for i := 0; i+len(sub) <= len(s); i++ {
+		if s[i:i+len(sub)] == sub {
+			return i
+		}
+	}
+	return -1
+}
diff --git a/modelsdk/widgets/definitions/image.def.json b/modelsdk/widgets/definitions/image.def.json
index 7aae9123c9..55e12e71f6 100644
--- a/modelsdk/widgets/definitions/image.def.json
+++ b/modelsdk/widgets/definitions/image.def.json
@@ -10,6 +10,11 @@
       "default": "image",
       "operation": "primitive"
     },
+    {
+      "propertyKey": "imageObject",
+      "source": "Image",
+      "operation": "image"
+    },
     {
       "propertyKey": "imageUrl",
       "source": "ImageUrl",
diff --git a/scripts/check-findings.sh b/scripts/check-findings.sh
new file mode 100755
index 0000000000..c6b9884657
--- /dev/null
+++ b/scripts/check-findings.sh
@@ -0,0 +1,65 @@
+#!/bin/bash
+# check-findings.sh — validate .claude/skills/fix-issue/findings/*.jsonl
+#
+# One JSON object per line, an `area`, and either the four structured fields or
+# a `raw` row. A malformed line is not cosmetic: the shards are read by grep and
+# by DuckDB, and DuckDB rejects the whole file on one bad line, so a typo in an
+# appended finding takes out every query over that area.
+
+set -euo pipefail
+
+dir="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)/.claude/skills/fix-issue/findings"
+
+if [ ! -d "$dir" ]; then
+    echo "findings directory not found: $dir" >&2
+    exit 1
+fi
+
+shopt -s nullglob
+files=("$dir"/*.jsonl)
+if [ ${#files[@]} -eq 0 ]; then
+    echo "no findings shards in $dir" >&2
+    exit 1
+fi
+
+python3 - "${files[@]}" <<'PY'
+import json, os, sys
+
+bad = 0
+total = 0
+for path in sys.argv[1:]:
+    with open(path) as f:
+        for n, line in enumerate(f, 1):
+            if not line.strip():
+                print("%s:%d: blank line" % (path, n)); bad += 1; continue
+            total += 1
+            try:
+                rec = json.loads(line)
+            except Exception as e:
+                print("%s:%d: not valid JSON: %s" % (path, n, e)); bad += 1; continue
+            if not isinstance(rec, dict):
+                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))
+                bad += 1
+
+if bad:
+    print("\n%d problem(s) across %d findings" % (bad, total), file=sys.stderr)
+    sys.exit(1)
+print("findings OK: %d records in %d shards" % (total, len(sys.argv) - 1))
+PY
+
+# The digest gap, one line, on every run. Advisory: a stale digest never fails
+# this check. It is printed HERE because this is the command the After-Every-Fix
+# checklist already runs — a report nobody invokes is how the digest fell three
+# months behind in the first place.
+"$(dirname "${BASH_SOURCE[0]}")/digest-status.sh" --brief || true
diff --git a/scripts/check-wiki-pages.sh b/scripts/check-wiki-pages.sh
new file mode 100755
index 0000000000..b6e3818c3c
--- /dev/null
+++ b/scripts/check-wiki-pages.sh
@@ -0,0 +1,34 @@
+#!/bin/bash
+# check-wiki-pages.sh — the wiki's page list must describe the wiki.
+#
+# .claude/skills/maintain-wiki/pages.md is the table of contents, and it is
+# hand-maintained: every sync is supposed to append a row. It drifted anyway —
+# architecture/mcp-backend.md and models/ped-mutation-constraints.md were added
+# in June 2026 and were still missing from it in September, which nothing
+# noticed because a table of contents has no failure mode of its own.
+#
+# Checks BOTH directions. A page absent from the list is invisible to anyone
+# choosing what to sync; a row naming no file is a page someone believes exists.
+
+set -euo pipefail
+cd "$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
+
+list=".claude/skills/maintain-wiki/pages.md"
+bad=0
+
+while IFS= read -r f; do
+    rel="${f#docs-wiki/}"
+    case "$rel" in README.md|SYNC_LOG.md) continue ;; esac
+    grep -q "\`$rel\`" "$list" || { echo "$rel exists but is not in $list"; bad=1; }
+done < <(find docs-wiki -name '*.md' | sort)
+
+while IFS= read -r rel; do
+    [ -e "docs-wiki/$rel" ] || { echo "$list names docs-wiki/$rel, which does not exist"; bad=1; }
+done < <(grep '^| `' "$list" | sed 's/^| `\([^`]*\)`.*/\1/')
+
+if [ "$bad" -ne 0 ]; then
+    echo
+    echo "The wiki page list and docs-wiki/ disagree. Add the row (or the page)." >&2
+    exit 1
+fi
+echo "wiki pages OK: $(grep -c '^| `' "$list") listed, all present"
diff --git a/scripts/digest-status.sh b/scripts/digest-status.sh
new file mode 100755
index 0000000000..a85e201dee
--- /dev/null
+++ b/scripts/digest-status.sh
@@ -0,0 +1,103 @@
+#!/bin/bash
+# digest-status.sh — how far the bug-pattern digest has fallen behind the findings.
+#
+# The findings under .claude/skills/fix-issue/findings/ are raw evidence; the
+# read layer is docs-wiki/bug-patterns/, which digests them into failure classes.
+# That digest is produced on demand by /mxcli-dev:wiki-sync, and nothing demanded
+# it: the After-Every-Fix checklist feeds the input and no step consumes it. The
+# result was three pattern pages, all synthesised on one day in May, against a
+# corpus that kept growing.
+#
+# 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.
+
+set -euo pipefail
+cd "$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
+
+python3 - "${1:-}" <<'PY'
+import glob, json, re, sys, collections
+
+brief = sys.argv[1] == "--brief" if len(sys.argv) > 1 else False
+
+# Last bug-pattern sync: SYNC_LOG.md is the audit trail and the authority.
+log = open("docs-wiki/SYNC_LOG.md").read()
+dates = re.findall(r"^\| (\d{4}-\d{2}-\d{2}) \| bug-patterns/", log, re.M)
+last = max(dates) if dates else "0000-00-00"
+pages = sorted(glob.glob("docs-wiki/bug-patterns/*.md"))
+
+areas = collections.Counter()
+since = collections.Counter()
+undated = 0
+for fn in glob.glob(".claude/skills/fix-issue/findings/*.jsonl"):
+    for line in open(fn):
+        r = json.loads(line)
+        a = r.get("area", "unfiled")
+        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
+
+total, new = sum(areas.values()), sum(since.values())
+
+if brief:
+    if new:
+        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)
+
+print("Bug-pattern digest status\n")
+print("  pattern pages      %d" % len(pages))
+print("  last sync          %s" % last)
+print("  findings           %d" % total)
+print("  not yet digested   %d  (%.0f%%)" % (new, 100.0 * new / total if total else 0))
+if 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
+# more thing to keep true and would silently rot the moment someone forgot it.
+text = "\n".join(open(p).read() for p in pages)
+def mentioned(a):
+    # Only ask the question for a real package path. A bare first segment like
+    # "model" or "scripts" matches as a substring of almost any prose and the
+    # answer would be a false yes.
+    if "/" not in a:
+        return "-"
+    return "yes" if a in text else "NO"
+
+CUT = 5
+head = [(a, n) for a, n in areas.most_common() if n >= CUT]
+tail = [(a, n) for a, n in areas.most_common() if n < CUT]
+print("\n  %-22s %9s %9s   %s" % ("area", "findings", "since", "in a page"))
+for a, n in head:
+    print("  %-22s %9d %9d   %s" % (a, n, since[a], mentioned(a)))
+if tail:
+    print("  %-22s %9d %9d   %s" % ("(%d areas < %d)" % (len(tail), CUT),
+                                    sum(n for _, n in tail),
+                                    sum(since[a] for a, _ in tail), "-"))
+
+print("\n  Pages: %s" % ", ".join(p.split("/")[-1] for p in pages))
+print("\n  This is advisory. Sync a page when its area has moved, or when a class of\n"
+      "  failure keeps recurring — not to drive a number to zero.")
+PY
diff --git a/sdk/microflows/microflows_actions.go b/sdk/microflows/microflows_actions.go
index c5ef900f22..b8517f8ff6 100644
--- a/sdk/microflows/microflows_actions.go
+++ b/sdk/microflows/microflows_actions.go
@@ -197,6 +197,16 @@ type AggregateListAction struct {
 	AttributeQualifiedName string            `json:"attributeQualifiedName,omitempty"` // BY_NAME_REFERENCE: Module.Entity.Attribute
 	UseExpression          bool              `json:"useExpression,omitempty"`          // true when Expression is used instead of Attribute
 	Expression             string            `json:"expression,omitempty"`             // Mendix expression string (when UseExpression=true)
+
+	// ReduceInitialValue and ReduceReturnType are what REDUCE folds from, and
+	// the type it folds to. Studio Pro writes both on *every* AggregateAction it
+	// stores, not only on Reduce: measured on the three reference activities in
+	// ako/TestApp (Reduce, All, Any), where All and Any carry an empty initial
+	// value and a Boolean return type even though Mendix's own reference guide
+	// says a return type is "not applicable" to them. Carrying both here is what
+	// keeps a stored Reduce from losing its fold on rewrite (#1004).
+	ReduceInitialValue string   `json:"reduceInitialValue,omitempty"`
+	ReduceReturnType   DataType `json:"reduceReturnType,omitempty"`
 }
 
 func (AggregateListAction) isMicroflowAction() {}
@@ -211,8 +221,43 @@ const (
 	AggregateFunctionMin     AggregateFunction = "Minimum"
 	AggregateFunctionMax     AggregateFunction = "Maximum"
 	AggregateFunctionReduce  AggregateFunction = "Reduce"
+	AggregateFunctionAll     AggregateFunction = "All"
+	AggregateFunctionAny     AggregateFunction = "Any"
 )
 
+// AllAggregateFunctions is every value Mendix's AggregateFunction enumeration
+// can hold. DESCRIBE used to render an aggregate by lowercasing whatever was
+// stored, so each function Mendix added came back out as MDL the grammar could
+// not read (#1004). Anything rendering or parsing these must cover this list.
+var AllAggregateFunctions = []AggregateFunction{
+	AggregateFunctionCount,
+	AggregateFunctionSum,
+	AggregateFunctionAverage,
+	AggregateFunctionMin,
+	AggregateFunctionMax,
+	AggregateFunctionReduce,
+	AggregateFunctionAll,
+	AggregateFunctionAny,
+}
+
+// WritesReduceProperties reports whether Mendix stores
+// ReduceInitialValueExpression and ReduceReturnDataType for this function.
+//
+// Measured true for Reduce, All and Any against Studio Pro reference documents
+// (ako/TestApp): All and Any carry an empty initial value and a Boolean return
+// type, so the two properties are not Reduce-only. No reference document exists
+// for the five older functions, so mxcli writes the pair for those only when a
+// stored document already carried it — inventing a key is the mistake that makes
+// a document mxbuild accepts and Studio Pro cannot open.
+func (f AggregateFunction) WritesReduceProperties() bool {
+	switch f {
+	case AggregateFunctionReduce, AggregateFunctionAll, AggregateFunctionAny:
+		return true
+	default:
+		return false
+	}
+}
+
 // ListOperationAction performs list operations.
 type ListOperationAction struct {
 	model.BaseElement
diff --git a/sdk/mpr/parser_microflow.go b/sdk/mpr/parser_microflow.go
index 9a580550af..c61edee650 100644
--- a/sdk/mpr/parser_microflow.go
+++ b/sdk/mpr/parser_microflow.go
@@ -987,6 +987,15 @@ func parseAggregateListAction(raw map[string]any) *microflows.AggregateListActio
 		action.Expression = extractString(raw["Expression"])
 	}
 
+	// Reduce's fold: what it starts from and what it folds to. Studio Pro writes
+	// both on every AggregateAction (empty initial value on All/Any), so read
+	// them unconditionally rather than only for Reduce — a rewrite that dropped
+	// them silently deleted the fold (#1004).
+	action.ReduceInitialValue = extractString(raw["ReduceInitialValueExpression"])
+	if rt, ok := raw["ReduceReturnDataType"].(map[string]any); ok {
+		action.ReduceReturnType = parseMicroflowDataType(rt)
+	}
+
 	return action
 }
 
diff --git a/sdk/mpr/writer_microflow_actions.go b/sdk/mpr/writer_microflow_actions.go
index 109baef52f..b06dccff97 100644
--- a/sdk/mpr/writer_microflow_actions.go
+++ b/sdk/mpr/writer_microflow_actions.go
@@ -380,9 +380,18 @@ func serializeMicroflowAction(action microflows.MicroflowAction) bson.D {
 		if a.UseExpression {
 			doc = append(doc, bson.E{Key: "UseExpression", Value: true})
 			doc = append(doc, bson.E{Key: "Expression", Value: a.Expression})
-		} else if a.AttributeQualifiedName != "" {
-			// Attribute is BY_NAME_REFERENCE
-			doc = append(doc, bson.E{Key: "Attribute", Value: a.AttributeQualifiedName})
+		}
+		// Attribute is BY_NAME_REFERENCE, and is written even when unused: every
+		// Studio Pro reference document carries it as "". Omitting it made a
+		// freshly described Studio Pro aggregate rewrite on its first execution
+		// for no semantic reason.
+		doc = append(doc, bson.E{Key: "Attribute", Value: a.AttributeQualifiedName})
+		// Reduce's fold. Written for the functions a reference document shows
+		// Mendix storing them on, and otherwise only to carry back what the
+		// stored document already had (#1004).
+		if a.Function.WritesReduceProperties() || a.ReduceInitialValue != "" || a.ReduceReturnType != nil {
+			doc = append(doc, bson.E{Key: "ReduceInitialValueExpression", Value: a.ReduceInitialValue})
+			doc = append(doc, bson.E{Key: "ReduceReturnDataType", Value: serializeMicroflowDataType(a.ReduceReturnType)})
 		}
 		doc = append(doc, bson.E{Key: "VariableName", Value: a.OutputVariable}) // storageName for outputVariableName
 		return doc
diff --git a/sdk/widgets/definitions/image.def.json b/sdk/widgets/definitions/image.def.json
index 7aae9123c9..55e12e71f6 100644
--- a/sdk/widgets/definitions/image.def.json
+++ b/sdk/widgets/definitions/image.def.json
@@ -10,6 +10,11 @@
       "default": "image",
       "operation": "primitive"
     },
+    {
+      "propertyKey": "imageObject",
+      "source": "Image",
+      "operation": "image"
+    },
     {
       "propertyKey": "imageUrl",
       "source": "ImageUrl",