Merge branch 'main' into fix/dset-silent-failure

Author: ako

.claude/skills/debug-bson.md

@@ -25,10 +25,10 @@ Use when encountering:
 ### Step 1: Reproduce the Error
 
 ```bash
-# Create a page via MDL
+# create a page via MDL
 ./bin/mxcli exec script.mdl -p /path/to/app.mpr
 
-# Run mx check to get the error
+# run mx check to get the error
 reference/mxbuild/modeler/mx check /path/to/app.mpr
 ```
 
@@ -58,8 +58,8 @@ import json
 conn = sqlite3.connect('/path/to/app.mpr')
 cursor = conn.cursor()
 
-# Find the document containing the widget
-cursor.execute("SELECT UnitData FROM Unit$ WHERE ContainmentName = 'Document' AND Name = ?", ('PageName',))
+# find the document containing the widget
+cursor.execute("select UnitData from Unit$ where ContainmentName = 'Document' and Name = ?", ('PageName',))
 row = cursor.fetchone()
 doc = bson.decode(row[0])
 
@@ -72,7 +72,7 @@ print(json.dumps(doc, indent=2, default=str))
 Extract the widget's mpk to understand its schema and mode-dependent rules:
 
 ```bash
-# Find the mpk in the project's widgets folder
+# find the mpk in the project's widgets folder
 ls /path/to/project/widgets/*.mpk
 
 # Extract (mpk is a ZIP archive)
@@ -81,8 +81,8 @@ cd /tmp/mpk-widget && unzip /path/to/project/widgets/com.mendix.widget.web.Datag
 ```
 
 Key files inside the mpk:
-- **`{Widget}.xml`** — Property schema: types, defaults, enumerations, nested objects
-- **`{Widget}.editorConfig.js`** — Mode-dependent visibility rules (which properties hide/show based on other values)
+- **`{widget}.xml`** — Property schema: types, defaults, enumerations, nested objects
+- **`{widget}.editorConfig.js`** — Mode-dependent visibility rules (which properties hide/show based on other values)
 - **`package.xml`** — Package version metadata
 
 ### Step 5: Read editorConfig.js for Mode Rules
@@ -108,18 +108,18 @@ Use binary search to find the exact property causing the error:
 # Mutation test: change a single property on a known-good widget
 import bson
 
-# Read the working widget BSON
+# read the working widget BSON
 with open('working-widget.bson', 'rb') as f:
     doc = bson.decode(f.read())
 
-# Change only one property value
+# change only one property value
 # ... modify the specific property ...
 
 # Re-encode and write back
 with open('test-widget.bson', 'wb') as f:
     f.write(bson.encode(doc))
 
-# Then insert back into the MPR and run mx check
+# then insert back into the MPR and run mx check
 ```
 
 ### Step 7: Extract Fresh Templates
@@ -131,7 +131,7 @@ If the widget template is outdated, extract a fresh one:
 reference/mxbuild/modeler/mx convert -p /path/to/app.mpr
 reference/mxbuild/modeler/mx update-widgets /path/to/app.mpr
 
-# Then extract using mxcli
+# then extract using mxcli
 ./bin/mxcli extract-templates -p /path/to/app.mpr -widget "com.mendix.widget.web.datagrid.DataGrid2" -o /tmp/template.json
 ```
 
@@ -159,20 +159,20 @@ Three Mendix tools parse the same BSON but with **different strictness levels**:
 ```bash
 # Self-diff: is the project's BSON clean?
 mx diff project.mpr project.mpr output.mpr
-# Success = all BSON matches schema. Crash = some mxunit has bad properties.
+# success = all BSON matches schema. Crash = some mxunit has bad properties.
 
-# Cross-diff: compare baseline vs modified
+# cross-diff: compare baseline vs modified
 # 1. Extract baseline from git
-mkdir /tmp/baseline && cd project-dir && git archive HEAD -- *.mpr mprcontents/ | tar -x -C /tmp/baseline/
-# 2. Run diff (file names must match!)
+mkdir /tmp/baseline && cd project-dir && git archive head -- *.mpr mprcontents/ | tar -x -C /tmp/baseline/
+# 2. run diff (file names must match!)
 mx diff /tmp/baseline/App.mpr ./App.mpr /tmp/diff-output.mpr
 ```
 
 ### Interpreting mx diff Output
 
 **Detailed error** (when both sides have same-ID objects):
 ```
-Objects with ID b6fc893f-... of type Settings$ServerConfiguration do not have the same properties.
+objects with ID b6fc893f-... of type settings$ServerConfiguration do not have the same properties.
 baseNames = ApplicationRootUrl, ConstantValues, CustomSettings, ..., Tracing;
 newNames = ApplicationRootUrl, ConstantValues, ...
 ```
@@ -186,15 +186,15 @@ Sequence contains no matching element
 
 ### Finding the Offending mxunit File
 
-Write a Go tool (or use the pattern below) to compare property keys of mxcli-written files against Studio Pro-native files of the same `$Type`:
+Write a Go tool (or use the pattern below) to compare property keys of mxcli-written files against Studio Pro-native files of the same `$type`:
 
 ```go
-// Walk mprcontents/, group files by $Type, compare key sets
+// Walk mprcontents/, group files by $type, compare key sets
 // Files with EXTRA keys (vs native files of same type) = the crash cause
 // Files with MISSING keys = also crash cause for mx diff
 ```
 
-The principle: for each `$Type`, ALL instances must have the **exact same set of non-$ property names**. Any deviation → crash.
+The principle: for each `$type`, ALL instances must have the **exact same set of non-$ property names**. Any deviation → crash.
 
 ### Version-Specific Properties
 
@@ -229,7 +229,7 @@ Some properties only exist in certain Mendix versions. Before adding a property
 
 **Symptom**: Studio Pro crashes when opening a project with `System.InvalidOperationException: Sequence contains no matching element` at `Mendix.Modeler.Storage.Mpr.MprProperty..ctor`.
 
-**Root cause**: A BSON document contains a property (field name) that does not exist in the Mendix type definition for its `$Type`. Studio Pro's `MprProperty` constructor uses `First()` to look up each BSON field in the type cache, and crashes on unrecognized fields.
+**Root cause**: A BSON document contains a property (field name) that does not exist in the Mendix type definition for its `$type`. Studio Pro's `MprProperty` constructor uses `First()` to look up each BSON field in the type cache, and crashes on unrecognized fields.
 
 **Diagnosis workflow**:
 
@@ -242,10 +242,10 @@ type_props = defaultdict(set)
 
 def walk_bson(obj, tp):
     if isinstance(obj, dict):
-        t = obj.get("$Type", "")
+        t = obj.get("$type", "")
         if t:
             for k in obj.keys():
-                if k not in ("$Type", "$ID"):
+                if k not in ("$type", "$ID"):
                     tp[t].add(k)
         for v in obj.values():
             walk_bson(v, tp)
@@ -272,7 +272,7 @@ for t, props in crash_props.items():
 
 3. **Extra properties = the crash cause**. The fix is to remove those fields from the writer function.
 
-**Example**: `DomainModels$CrossAssociation` had `ParentConnection` and `ChildConnection` copied from `DomainModels$Association`, but these fields don't exist on `CrossAssociation`. Removing them fixed the crash.
+**Example**: `DomainModels$CrossAssociation` had `ParentConnection` and `ChildConnection` copied from `DomainModels$association`, but these fields don't exist on `CrossAssociation`. Removing them fixed the crash.
 
 **Key principle**: When copying serialization code between similar types (e.g., Association → CrossAssociation), always verify which fields belong to each type by checking a baseline project's BSON.
 
@@ -282,7 +282,7 @@ for t, props in crash_props.items():
 
 **Root cause**: Two variants:
 
-1. **Association stored as Attribute**: In `ChangeActionItem` BSON, an association name was written to the `Attribute` field instead of the `Association` field. Check the executor code that builds `MemberChange` — it must query the domain model to distinguish associations from attributes.
+1. **Association stored as Attribute**: In `ChangeActionItem` BSON, an association name was written to the `attribute` field instead of the `association` field. Check the executor code that builds `MemberChange` — it must query the domain model to distinguish associations from attributes.
 
 2. **Entity treated as Enumeration**: In `CreateVariableAction` BSON, an entity qualified name was used as `DataTypes$EnumerationType` instead of `DataTypes$ObjectType`. Check `buildDataType()` in the visitor — bare qualified names default to `TypeEnumeration` and need catalog-based disambiguation.
 

.claude/skills/design-mdl-syntax.md

@@ -18,9 +18,9 @@ When principles conflict, higher-priority ones win.
 
 MDL targets citizen developers and business analysts, not software engineers. Statements should read as natural English sentences.
 
-- Use keyword words (`FROM`, `WHERE`, `IN`), not symbols (`->`, `|>`, `=>`)
-- Spell out full words (`MICROFLOW`, `ASSOCIATION`), not abbreviations (`MF`, `ASSOC`)
-- Use prepositions to clarify relationships: `GRANT READ ON Entity TO Role`
+- Use keyword words (`from`, `where`, `in`), not symbols (`->`, `|>`, `=>`)
+- Spell out full words (`microflow`, `association`), not abbreviations (`MF`, `ASSOC`)
+- Use prepositions to clarify relationships: `grant read on entity to role`
 
 **Test**: Read it aloud. A business analyst should understand on first hearing.
 
@@ -30,34 +30,34 @@ Reuse existing patterns. Never create a second syntax for the same concept.
 
 | Operation | Pattern | Example |
 |-----------|---------|---------|
-| Create | `CREATE [MODIFIERS] <TYPE> Module.Name (...)` | `CREATE PERSISTENT ENTITY Shop.Product (...)` |
-| Modify | `ALTER <TYPE> Module.Name <OPERATION>` | `ALTER ENTITY Shop.Product ADD (...)` |
-| Remove | `DROP <TYPE> Module.Name` | `DROP ENTITY Shop.Product` |
-| List | `SHOW <TYPE>S [IN Module]` | `SHOW ENTITIES IN Shop` |
-| Inspect | `DESCRIBE <TYPE> Module.Name` | `DESCRIBE ENTITY Shop.Product` |
-| Security | `GRANT/REVOKE <perm> ON <target> TO/FROM <role>` | `GRANT READ ON Shop.Product TO Shop.User` |
+| Create | `create [MODIFIERS] <type> Module.Name (...)` | `create persistent entity Shop.Product (...)` |
+| Modify | `alter <type> Module.Name <operation>` | `alter entity Shop.Product add (...)` |
+| Remove | `drop <type> Module.Name` | `drop entity Shop.Product` |
+| List | `show <type>S [in module]` | `show entities in Shop` |
+| Inspect | `describe <type> Module.Name` | `describe entity Shop.Product` |
+| Security | `grant/revoke <perm> on <target> to/from <role>` | `grant read on Shop.Product to Shop.User` |
 
-Do NOT use alternative verbs: `ADD` instead of `CREATE`, `REMOVE` instead of `DROP`, `LIST` instead of `SHOW`, `VIEW` instead of `DESCRIBE`.
+Do NOT use alternative verbs: `add` instead of `create`, `remove` instead of `drop`, `list` instead of `show`, `view` instead of `describe`.
 
 ### 3. Optimize for LLMs
 
 - Keep patterns regular so one example is sufficient for generation
 - Statements must be self-contained (no implicit state from prior statements)
-- Use consistent keyword order: `<VERB> [MODIFIERS] <TYPE> <NAME> [CLAUSES] [BODY]`
+- Use consistent keyword order: `<VERB> [MODIFIERS] <type> <NAME> [CLAUSES] [body]`
 - Prefer flat statement sequences over deeply nested structures
 
 ### 4. Make Diffs Reviewable
 
 - One property per line in multi-property constructs
 - Allow trailing commas
-- `DESCRIBE` output uses deterministic property order
+- `describe` output uses deterministic property order
 - Default values omitted unless non-obvious
 
 ### 5. Token Efficiency (Without Sacrificing Clarity)
 
-- Omit noise words: `CREATE ENTITY` not `CREATE A NEW ENTITY`
-- Support `OR MODIFY` to avoid check-then-create
-- Allow type inference for obvious cases: `DECLARE $Count = 0`
+- Omit noise words: `create entity` not `create A NEW entity`
+- Support `or modify` to avoid check-then-create
+- Allow type inference for obvious cases: `declare $count = 0`
 - Do NOT use symbols to save tokens at the cost of readability
 
 ## Design Workflow
@@ -72,37 +72,37 @@ Does an existing pattern cover this? If yes, extend it. Don't invent new syntax.
 
 ```
 New feature: "image collections"
-Existing pattern: CREATE/ALTER/DROP/SHOW/DESCRIBE
-Design: CREATE IMAGE COLLECTION Module.Name (...)
-        DESCRIBE IMAGE COLLECTION Module.Name
-        SHOW IMAGE COLLECTIONS [IN Module]
+Existing pattern: create/alter/drop/show/describe
+design: create image collection Module.Name (...)
+        describe image collection Module.Name
+        show image COLLECTIONS [in module]
 ```
 
 ### Step 2: Pick the Statement Shape
 
 Every MDL statement fits one of these shapes:
 
 ```
-DDL:   <VERB> [MODIFIERS] <TYPE> <QualifiedName> [CLAUSES] [BODY];
-DML:   <ACTION> <TARGET> [CLAUSES];
-DQL:   <QUERY-VERB> <TYPE>S [FILTERS];
+DDL:   <VERB> [MODIFIERS] <type> <QualifiedName> [CLAUSES] [body];
+DML:   <action> <TARGET> [CLAUSES];
+DQL:   <query-VERB> <type>S [FILTERS];
 ```
 
 If your feature doesn't fit any shape, it may belong as a CLI command (`mxcli <subcommand>`) rather than MDL syntax.
 
 ### Step 3: Choose Keywords
 
 1. Reuse existing keywords first (check reserved words in grammar)
-2. Use SQL/DDL verbs: `CREATE`, `ALTER`, `DROP`, `SHOW`, `DESCRIBE`, `GRANT`, `REVOKE`, `SET`
-3. Use Mendix terminology: `ENTITY` not `TABLE`, `MICROFLOW` not `FUNCTION`, `PAGE` not `VIEW`
-4. Prepositions clarify structure: `FROM`, `TO`, `IN`, `ON`, `BY`, `WITH`, `AS`, `WHERE`, `INTO`
+2. Use SQL/DDL verbs: `create`, `alter`, `drop`, `show`, `describe`, `grant`, `revoke`, `set`
+3. Use Mendix terminology: `entity` not `table`, `microflow` not `FUNCTION`, `page` not `view`
+4. Prepositions clarify structure: `from`, `to`, `in`, `on`, `by`, `with`, `as`, `where`, `into`
 
 ### Step 4: Write the Property List
 
 All property-bearing constructs use this format:
 
 ```mdl
-CREATE <TYPE> Module.Name (
+create <type> Module.Name (
     Property1: value,
     Property2: value,
 );
@@ -115,29 +115,29 @@ Rules:
 - Trailing comma allowed
 - One property per line (single line acceptable for 1-2 properties)
 
-#### Colon `:` vs `AS` — When to Use Each
+#### Colon `:` vs `as` — When to Use Each
 
 Use **colon** for property definitions (assigning a value to a named property):
 
 ```mdl
-CREATE ENTITY Shop.Product (
-    Name: String(200),          -- property: type/value
-    Price: Decimal,
+create entity Shop.Product (
+    Name: string(200),          -- property: type/value
+    Price: decimal,
 );
-TEXTBOX txtName (Label: 'Name', Attribute: Title)
+textbox txtName (label: 'Name', attribute: title)
 ```
 
-Use **`AS`** for name-to-name mappings (renaming, aliasing, mapping one name to another):
+Use **`as`** for name-to-name mappings (renaming, aliasing, mapping one name to another):
 
 ```mdl
-CUSTOM NAME MAP (
-    'kvkNummer' AS 'ChamberOfCommerceNumber',   -- old name AS new name
-    'naam' AS 'CompanyName',
+CUSTOM NAME map (
+    'kvkNummer' as 'ChamberOfCommerceNumber',   -- old name AS new name
+    'naam' as 'CompanyName',
 )
-ALTER ENTITY Shop.Product RENAME Code AS ProductCode   -- old attr AS new attr
+alter entity Shop.Product rename Code as ProductCode   -- old attr AS new attr
 ```
 
-**Rule of thumb**: if the left side is a *fixed property key* defined by the syntax, use `:`. If the left side is a *user-provided name* being mapped to another name, use `AS`.
+**Rule of thumb**: if the left side is a *fixed property key* defined by the syntax, use `:`. If the left side is a *user-provided name* being mapped to another name, use `as`.
 
 ### Step 5: Validate
 
@@ -147,31 +147,31 @@ Run these checks before finalizing syntax design:
 2. **LLM generation test** — Give one example to an LLM, ask for a variant. Does it get it right?
 3. **Diff test** — Change one property. Is the diff exactly one line?
 4. **Pattern test** — Does it follow CREATE/ALTER/DROP/SHOW/DESCRIBE? If not, why?
-5. **Roundtrip test** — Can `DESCRIBE` output be fed back as input?
+5. **Roundtrip test** — Can `describe` output be fed back as input?
 
 ## Anti-Patterns (DO NOT)
 
 ### Custom Verbs for Standard Operations
 
 ```mdl
 -- WRONG: custom verb
-SCHEDULE EVENT Shop.Cleanup ...
+SCHEDULE event Shop.Cleanup ...
 REGISTER WEBHOOK Shop.OnOrder ...
 
 -- RIGHT: standard CREATE
-CREATE SCHEDULED EVENT Shop.Cleanup (...)
-CREATE WEBHOOK Shop.OnOrder (...)
+create SCHEDULED event Shop.Cleanup (...)
+create WEBHOOK Shop.OnOrder (...)
 ```
 
 ### Implicit Module Context
 
 ```mdl
 -- WRONG: implicit state
-USE MODULE Shop;
-CREATE ENTITY Customer (...);
+use module Shop;
+create entity Customer (...);
 
 -- RIGHT: explicit qualified name
-CREATE ENTITY Shop.Customer (...);
+create entity Shop.Customer (...);
 ```
 
 ### Symbolic Syntax
@@ -181,19 +181,19 @@ CREATE ENTITY Shop.Customer (...);
 $items |> filter($.active) |> map($.name)
 
 -- RIGHT: keyword-based
-FILTER $Items WHERE Active = true
+filter $Items where Active = true
 ```
 
 ### Positional Arguments
 
 ```mdl
 -- WRONG: meaning unclear without docs
-CREATE RULE Shop Process Order ACT_ProcessOrder
+create rule Shop Process Order ACT_ProcessOrder
 
 -- RIGHT: labeled properties
-CREATE RULE Shop.ProcessOrder (
-    Type: Validation,
-    Microflow: Shop.ACT_ProcessOrder,
+create rule Shop.ProcessOrder (
+    type: validation,
+    microflow: Shop.ACT_ProcessOrder,
 );
 ```
 
@@ -208,16 +208,16 @@ CREATE RULE Shop.ProcessOrder (
 
 Before merging any PR that adds new MDL syntax, verify:
 
-- [ ] Follows `CREATE`/`ALTER`/`DROP`/`SHOW`/`DESCRIBE` pattern
+- [ ] Follows `create`/`alter`/`drop`/`show`/`describe` pattern
 - [ ] Uses `Module.Element` qualified names (no bare names)
-- [ ] Property lists use `( Key: value, ... )` format
+- [ ] Property lists use `( key: value, ... )` format
 - [ ] Keywords are full English words (no abbreviations)
 - [ ] Statement reads as English (aloud test passed)
 - [ ] One example sufficient for LLM generation
 - [ ] Small change = one-line diff
 - [ ] No new keyword overloading
 - [ ] No implicit context dependency
-- [ ] `DESCRIBE` roundtrips to valid MDL
+- [ ] `describe` roundtrips to valid MDL
 - [ ] Grammar regenerated (`make grammar`)
 - [ ] Quick reference updated (`docs/01-project/MDL_QUICK_REFERENCE.md`)
 - [ ] Full-stack wired: grammar, AST, visitor, executor, DESCRIBE