`mxcli check` passes a commit-inside-a-loop that `lint` (CONV011) already knows; no script-scoped lint exists (feature request: check hints, `check --lint`, or `lint --document`)

[MendixMau]

Environment: mxcli v0.23.0 (2026-09-21T11:10:32Z) and nightly-20260916-ea9fa37d (2026-09-16), Mendix 11.12.2 project, macOS (Darwin 25.6). Same result on both binaries.

Summary (feature request, not a check/exec disagreement): mxcli check has no structural rules for the defects mxcli lint already detects with its built-in rules — commit inside a loop (CONV011), empty container (MPR006), empty microflow/nanoflow (MPR002). A script whose only body is a commit in a loop passes check with "Check passed!", is written by exec, builds clean with mxbuild, and the N+1 is only visible if someone later runs project-wide lint. lint in turn cannot be scoped to the documents a script just wrote (--modules and --rules exist, no --document), so a per-exec gate has to lint the whole project (~13 s on a 10k-finding project) and diff against a baseline.

Steps to reproduce

create or modify microflow UserGroups."ZZ_LoopCommitProbe" ($Groups: List of UserGroups.Group)
begin
  loop $G in $Groups begin
    change $G (Name = $G/Name);
    commit $G;
  end loop;
end;

$ mxcli check probe.mdl -p Marketplace.mpr
✓ Catalog cached to .mxcli/catalog.db
✓ Expression types OK

Check passed!

$ mxcli lint -p Marketplace.mpr --list-rules | grep CONV011
  CONV011 (NoCommitInLoop) - Commit actions should not be inside loops (N+1 performance issue)

After exec, mxcli lint -p Marketplace.mpr -r CONV011 reports the microflow. Nothing in the script-side path did.

For contrast, check on a larger real script of this shape did emit [MDL001] (nested loop) and [MDL067] (commit events) hints, so check already has a hint channel for loop-related shape; it just does not carry the commit-in-loop, empty-container or empty-flow rules.

Expected: one of

1. check emits the structural lint rules that can be evaluated from the script alone (CONV011, MPR006, MPR002 at least) as hints, in the same channel as MDL001/MDL067; or
2. check --lint (or exec --lint) runs the lint rule set against the documents the script creates/modifies and prints the findings; or
3. lint --document Module.Name (repeatable) so a caller can lint only what a script touched and a per-exec gate does not need a whole-project baseline diff.

Actual: check passes, exec writes, mxbuild is clean, and the defect is only found by a project-wide lint that nothing on the script path invokes.

Real-world impact (how this was found): a migration microflow authored by script shipped with three commits inside loops under an exec log row that said "mxbuild clean". The project's own lint gate (CONV011 baseline was 0) would have failed it on the day, but because check was the only script-side instrument that ran, and lint needs a project-wide run plus a baseline, nobody ran it. Six CONV011 findings accumulated across three microflows over a week.

Severity: low for correctness (nothing corrupt), medium for the workflow — check is what every script author runs, and it is silent on the class of defect lint is best at. Verified only on the two binaries above.

[github-actions]

Issue Triage

Summary:
The user requests that mxcli check (or a related flag) surface the structural lint rules that lint already detects (e.g., commit‑inside‑loop, empty container, empty flow) so that script authors can catch these issues without needing a full‑project lint run.

Checklist for feature request

Required info	Present?	Notes
Use case – why the feature is needed, what problem it solves	✅	Describes how commit‑inside‑loop defects slip through check and only appear later via project‑wide lint, causing workflow gaps.
Proposed syntax or behavior (if applicable)	✅	Lists three concrete options: (1) emit those lint rules as hints in check, (2) add check --lint / exec --lint, or (3) add lint --document to scope lint to touched documents.
Mendix version relevance (if version‑specific)	✅	Mentions the test project is Mendix 11.12.2; the request is relevant to that version (and likely others).

Conclusion:
The issue provides all the necessary information for a feature request. Thank you for the clear description and suggestions!

---

Automated triage via OpenRouter — workflow source