style: convert MDL keywords to lowercase in docs and skill files

Applies the same lowercase convention to all code examples in
documentation and skill files. Code blocks and inline backtick spans
are converted; prose text is left unchanged. Keywords in qualified
names (e.g. Module.Entity) are preserved.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

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