Problem
mxcli exec applies changes immediately and irreversibly. When iterating on a script (especially an LLM-generated one), there is no way to inspect what would be created/modified before committing to disk. A script that partially applies on error leaves the project in an inconsistent state.
Proposed feature
Add a --dry-run flag to mxcli exec that:
- Parses and validates the script (same as
mxcli check)
- Reports what would be created, modified, or dropped per statement — without writing to the MPR file
- Exits 0 if the script would apply cleanly, non-zero if any statement would fail
Example output:
[dry-run] CREATE ENTITY MyModule.Customer → would create (persistent entity, 4 attributes)
[dry-run] CREATE MICROFLOW MyModule.ACT_Save → would create
[dry-run] CREATE PAGE MyModule.Customer_Overview → would create
[dry-run] ALTER NAVIGATION Responsive → would update (add menu item)
---
4 statements would apply, 0 errors
Scope
- Does not require actual backend writes; the executor can report intent from the AST + current project state
- At minimum, a
--dry-run that runs check --references and reports the operation type per statement (create / modify / drop) is sufficient for a first version
- A
BEGIN SCRIPT … ROLLBACK transactional mode is a separate, harder problem (see discussion in issue about atomic execution); dry-run is the lightweight alternative that addresses the immediate need
Strategic context
This is one of the friction points identified during app generation testing. Referenced in the strategic positioning document (docs/01-project/MXCLI_STRATEGIC_POSITIONING.md) as part of the "validation before apply" loop:
agent writes MDL → check → [dry-run] → exec → test → iterate
Dry-run makes the pre-exec confidence step explicit and scriptable.
Problem
mxcli execapplies changes immediately and irreversibly. When iterating on a script (especially an LLM-generated one), there is no way to inspect what would be created/modified before committing to disk. A script that partially applies on error leaves the project in an inconsistent state.Proposed feature
Add a
--dry-runflag tomxcli execthat:mxcli check)Example output:
Scope
--dry-runthat runscheck --referencesand reports the operation type per statement (create / modify / drop) is sufficient for a first versionBEGIN SCRIPT … ROLLBACKtransactional mode is a separate, harder problem (see discussion in issue about atomic execution); dry-run is the lightweight alternative that addresses the immediate needStrategic context
This is one of the friction points identified during app generation testing. Referenced in the strategic positioning document (
docs/01-project/MXCLI_STRATEGIC_POSITIONING.md) as part of the "validation before apply" loop:Dry-run makes the pre-exec confidence step explicit and scriptable.