Microflow auto-layout: long flows never wrap, guards waste the main line, 4+ case splits draw crossing lines

[tgolembiewski]

mxcli version: v0.23.0 (Mendix 11.12.1, MPR v2, macOS)

Context

An agent builds a whole app from MDL and writes no @position — so every microflow is laid out by the builder's own auto-layout. On a generated B2B ordering app of 41 microflows, mx check is clean and nothing overlaps, but the more complex flows are hard to read on the Studio Pro canvas. Five separate things, each measured on that app:

1. The main line never wraps

Every top-level statement advances posX, nothing ever moves down. The widest flow came out 6930 × 160 px (43:1) — four screens of sideways scrolling for something 160 px tall.

2. A guard makes the main line wait for its own branch

if X then …; return; end if draws its branch in the lane below and ends it there, yet the next element on the main line is placed past the branch's far end: 370 px from the split, against 40 px between any two activities. Similarly a merge stands 120 px after its branch (a half pitch is added to a width that is already edge-to-edge), and a branch ending in return is measured without the end event it draws.

3. Enumeration splits with 4+ cases draw crossing lines

The anchor pair on each case flow stores the CASE order (splitCaseOrderAnchors, from 0e69243). From the fourth case on, that means sides no drawing would choose: case 4 leaves the split's left corner, cases 5–8 arrive on top of their activity, 9+ on its far side. A 7-case split is a tangle of lines crossing each other and the activities between them.

4. A note on a loop lands inside the loop

A note is placed 100 px above its element's centre. On a loop box several hundred px tall that is inside the box, on top of the body. The note's connector is also written top-to-top, so the line is attached to the top of the note rather than its bottom.

5. Loop boxes get no gap

An activity before or after a loop box touches it, because the cursor treats the box as an activity-width element.

Proposed fix

I have a branch that addresses all five, geometry and anchors only — no execution semantics, no MDL syntax change, @position-ed statements are never moved, and describe → exec still reports Unchanged microflow:

• wrap the main line onto rows past a width limit (rows placed under the real extent of the row above; the joining line runs bottom → top through the band between rows);
• let the main line resume right after a guard and track how far the lane below is taken, so only an element that reaches into that lane waits for it; tighten the merge gap; measure a returning branch with its end event;
• for 4+ cases, group case lines by side — upper third from the split's top corner, middle from the right, lower from the bottom, all arriving on the left — and have describe read the case order from side + canvas position (models written with the pair table are still read through it; ≤ 3 cases are unchanged);
• place notes above the element's top edge, connector bottom → top;
• give loop boxes the same 40 px gap as activities.

Same app after the change: widest flow 3220 px on one row, the 7-case flow has no crossing lines, 0 overlaps, mx check 0 errors. Unit tests for each item (each verified to fail with its fix reverted), make test, make lint-go, make check-mdl and the integration suite pass locally.

Related: #724 (opt-in beautify pass for one flow family — this is the default layout instead), #884, #990.

Happy to open the PR if this direction is OK — or to split it if you would rather take the items separately.

[github-actions]

Issue Triage

Summary:
The issue reports that mxcli’s auto‑layout for microflows produces overly wide, non‑wrapping flows, inefficient guard handling, crossing lines in multi‑case splits, misplaced notes, and missing gaps around loop boxes, and proposes a set of geometry‑only fixes.

Checklist (bug report)

Required info	Present?	Details
mxcli version	✅	v0.23.0 (shown)
Mendix version	✅	11.12.1 (shown)
Scenario (what the user was trying to do)	✅	Building an app from MDL with no @position, relying on auto‑layout, then running mx check
Expected output	✅	Flows should wrap, guards should not waste space, case splits should avoid crossing lines, notes placed above elements, loop boxes should have 40 px gaps
Experienced output	✅	Described the five specific layout problems (wide flows, guard waiting, crossing lines, notes inside loops, loop boxes touching)
AI bug report (mxcli diag --bundle or session log)	❌	Not provided

Missing information:
Could you please attach the output of mxcli diag --bundle (or at least the relevant session log) so we can reproduce the exact environment and see any additional diagnostics? Thanks!

---

Automated triage via OpenRouter — workflow source

[tgolembiewski]

Environment, from mxcli diag on the release binary:

Version:  v0.23.0 (2026-09-21T11:10:32Z)
Go:       go1.26.6 darwin/arm64
Mendix:   11.12.1, MPR v2

I have not attached the --bundle archive: it packs the whole log directory (16 MB, ~16k sessions across every project on this machine, most of them unrelated), and nothing here is an error — no command fails, no log line is written. The layout is deterministic, so a script reproduces it exactly. This one runs on any blank app and needs no @position:

repro.mdl

CREATE ENUMERATION MyFirstModule.LayoutStatus (
  NewOrder 'New', Confirmed 'Confirmed', InProgress 'In progress', Shipped 'Shipped',
  Delivered 'Delivered', Invoiced 'Invoiced'
);

CREATE MICROFLOW MyFirstModule.MF_LayoutLong ()
BEGIN
  LOG INFO 'step 1';
  LOG INFO 'step 2';
  LOG INFO 'step 3';
  LOG INFO 'step 4';
  LOG INFO 'step 5';
  LOG INFO 'step 6';
  LOG INFO 'step 7';
  LOG INFO 'step 8';
  LOG INFO 'step 9';
  LOG INFO 'step 10';
  LOG INFO 'step 11';
  LOG INFO 'step 12';
  LOG INFO 'step 13';
  LOG INFO 'step 14';
  LOG INFO 'step 15';
  LOG INFO 'step 16';
  LOG INFO 'step 17';
  LOG INFO 'step 18';
  LOG INFO 'step 19';
  LOG INFO 'step 20';
  LOG INFO 'step 21';
  LOG INFO 'step 22';
  LOG INFO 'step 23';
  LOG INFO 'step 24';
  LOG INFO 'step 25';
  LOG INFO 'step 26';
  LOG INFO 'step 27';
  LOG INFO 'step 28';
  LOG INFO 'step 29';
  LOG INFO 'step 30';
  LOG INFO 'step 31';
  LOG INFO 'step 32';
  LOG INFO 'step 33';
  LOG INFO 'step 34';
  LOG INFO 'step 35';
  LOG INFO 'step 36';
  LOG INFO 'step 37';
  LOG INFO 'step 38';
  LOG INFO 'step 39';
  LOG INFO 'step 40';
END;
/

CREATE MICROFLOW MyFirstModule.MF_LayoutGuards ($Amount: Integer, $Limit: Integer)
RETURNS Boolean AS $IsAccepted
BEGIN
  IF $Amount = 0 THEN
    LOG WARNING 'nothing to place';
    RETURN false;
  END IF;
  LOG INFO 'amount present';
  IF $Amount > $Limit THEN
    LOG WARNING 'over the limit';
    RETURN false;
  END IF;
  IF $Limit < 0 THEN
    LOG WARNING 'no credit at all';
    RETURN false;
  END IF;
  LOG INFO 'accepted';
  RETURN true;
END;
/

CREATE MICROFLOW MyFirstModule.MF_LayoutCases ($Status: MyFirstModule.LayoutStatus)
RETURNS String AS $Next
BEGIN
  DECLARE $Next String = '';
  CASE $Status
    WHEN NewOrder THEN
      SET $Next = 'Confirmed';
    WHEN Confirmed THEN
      SET $Next = 'InProgress';
    WHEN InProgress THEN
      SET $Next = 'Shipped';
    WHEN Shipped THEN
      SET $Next = 'Delivered';
    WHEN Delivered THEN
      SET $Next = 'Invoiced';
    WHEN Invoiced THEN
      SET $Next = 'Invoiced';
    WHEN (empty) THEN
      SET $Next = 'NewOrder';
  END CASE;
  RETURN $Next;
END;
/

mxcli exec repro.mdl -p App.mpr (3 microflows created, mx check 0 errors), then describe microflow gives, on v0.23.0:

Flow	What describe shows	Problem
MF_LayoutLong	40 activities at y=200, x from 360 to 6600	one row, never wraps (#1)
MF_LayoutGuards	split at 360 → its branch at (530,300), (690,300) → next main-line activity at 730; second split at 890 → third split at 1260	every guard pushes the next element 370px along the main line, past its own branch (#2)
MF_LayoutCases	7 branches at x=690, y=-100…500; cases 5, 6, 7 carry @anchor(to: top), and case 4 leaves the split's left corner (origin index 3, which describe does not print for a split)	the anchor pair is storing case order, not geometry (#3)

Items 4 and 5 show in Studio Pro on any loop with an @annotation and an activity before and after it.