mxcli version: main at 643271e8 (Mendix 11.12.1, MPR v2, macOS)
Summary
Two of the bundled Starlark rules cannot report anything, on any project: ARCH002 (data_change_microflows.star) and ARCH003 (entity_business_key.star). Both are listed by --list-rules, both load and run without an error, and both return an empty result for every project, because their first guard skips every entity.
Repro
A blank project and one entity with no unique attribute — exactly what ARCH003 exists to report:
mx create-project --app-name Lint --output-dir ./Lint
cd Lint
mxcli init -p Lint.mpr
echo 'CREATE PERSISTENT ENTITY MyFirstModule."Order" ("Number": String(50));' > e.mdl
mxcli exec e.mdl -p Lint.mpr
mxcli lint -p Lint.mpr --rules ARCH003
Changing the one word in .claude/lint-rules/entity_business_key.star ("PERSISTENT" → "Persistent") and running the same command:
⚠ Entity 'Order' has no business key. Add a UNIQUE NOT NULL attribute for cross-system identification. [ARCH003]
1 issues: 0 errors, 1 warnings, 0 info
On a generated app of five persistent entities the same one-word change takes ARCH003 from 0 findings to 5.
Cause
Both rules guard with:
if entity.entity_type != "PERSISTENT":
continueThe catalog column stores PERSISTENT, but LintContext.Entities (mdl/linter/context.go) normalizes the kind before Starlark sees it:
CASE e.EntityType
WHEN 'PERSISTENT' THEN 'Persistent'
WHEN 'NON_PERSISTENT' THEN 'NonPersistent'
WHEN 'VIEW' THEN 'View'
...So the comparison is true for every entity and the body of each rule never runs. The other ten bundled rules that filter on the kind use "Persistent" and work.
The failure is silent by construction: no error, no output, and the rule still appears under --list-rules, so the result is indistinguishable from a project with nothing to report.
Why it was written that way
The write-lint-rules skill documents a third spelling. Its field table reads
| `entity_type` | string | `"persistent"`, `"NonPersistent"`, `"view"` |
and its worked example compares e.entity_type == "persistent", which matches nothing either. A rule written from that page reads as working and reports on no project at all.
Fix
I have a branch that corrects the two rules, corrects the field table and the example in the skill, and adds a test that loads the two shipped rule files themselves against a one-entity fixture — so a rule going back to the stored spelling fails there rather than going quiet. Reverting each fix in turn takes that rule's subtest to got 0 violations, want 1.
Full local run of push-test.yml is green (build, test, tunnel deps, check-mdl, skill pack JS, findings, wiki pages, MDL blocks in skills and docs-site, integration tests against mx 11.12.1, lint-go, govulncheck).
Happy to open the PR.
mxcli version: main at
643271e8(Mendix 11.12.1, MPR v2, macOS)Summary
Two of the bundled Starlark rules cannot report anything, on any project: ARCH002 (
data_change_microflows.star) and ARCH003 (entity_business_key.star). Both are listed by--list-rules, both load and run without an error, and both return an empty result for every project, because their first guard skips every entity.Repro
A blank project and one entity with no unique attribute — exactly what ARCH003 exists to report:
Changing the one word in
.claude/lint-rules/entity_business_key.star("PERSISTENT"→"Persistent") and running the same command:On a generated app of five persistent entities the same one-word change takes ARCH003 from 0 findings to 5.
Cause
Both rules guard with:
The catalog column stores
PERSISTENT, butLintContext.Entities(mdl/linter/context.go) normalizes the kind before Starlark sees it:So the comparison is true for every entity and the body of each rule never runs. The other ten bundled rules that filter on the kind use
"Persistent"and work.The failure is silent by construction: no error, no output, and the rule still appears under
--list-rules, so the result is indistinguishable from a project with nothing to report.Why it was written that way
The
write-lint-rulesskill documents a third spelling. Its field table readsand its worked example compares
e.entity_type == "persistent", which matches nothing either. A rule written from that page reads as working and reports on no project at all.Fix
I have a branch that corrects the two rules, corrects the field table and the example in the skill, and adds a test that loads the two shipped rule files themselves against a one-entity fixture — so a rule going back to the stored spelling fails there rather than going quiet. Reverting each fix in turn takes that rule's subtest to
got 0 violations, want 1.Full local run of
push-test.ymlis green (build, test, tunnel deps, check-mdl, skill pack JS, findings, wiki pages, MDL blocks in skills and docs-site, integration tests againstmx11.12.1, lint-go, govulncheck).Happy to open the PR.