layout flows introduces 4 MPR008 overlapping-activity warnings, all involving merge nodes

[ako]

Summary

mxcli layout flows is a large net win on a real project — it cleared 54 of 67 MPR011 loop-containment warnings here — but the layout it produces introduces 4 new MPR008 overlapping-activity warnings where there were none. All four involve a merge node placed within ~60–115px of its neighbour.

mxcli's own lint rule is what reports it.

Verified on main at c865b992, Mendix 11.13.0.

Reproduction

A project whose flows were authored from MDL without @position (so layout flows has real work to do):

$ mxcli lint -p App.mpr | grep -oE 'MPR008|MPR011' | sort | uniq -c
     67 MPR011

$ mxcli layout flows -p App.mpr --module Sudoku
30 flows laid out, 21 already laid out, 0 skipped.

$ mxcli lint -p App.mpr | grep -oE 'MPR008|MPR011' | sort | uniq -c
      4 MPR008          <- new
     13 MPR011

The four overlaps

'(merge)' (2360,80)   and '$isDiagonal and ($r = $c or $r + $c = 8)' (2475,80)   in ACT_DealGame
'(merge)' (2355,80)   and '(merge)' (2360,80)                                     in ACT_DealGame
'(merge)' (2815,1730) and '(unnamed)' (2740,1730)                                 in ACT_Refresh
'(merge)' (5635,330)  and '(merge)' (5580,330)                                    in ACT_Refresh

Every one has a merge node on at least one side, and two are merge-against-merge at a 5px and a 55px gap. Same y in all four cases, so it's horizontal spacing on the main path rather than a branch collision.

MPR008's own remedy text — "Each MDL statement that creates a canvas activity needs its own @position annotation" — is aimed at hand-written MDL and doesn't apply here: these positions were computed by layout flows, not authored.

Why I'd still recommend the command

Worth stating plainly, since this is a bug report against something good: I applied it to the project and committed the result. The trade is 54 MPR011 fixed against 4 MPR008 introduced, and MPR011 is the more serious rule — "renders wrong in Studio Pro; mx check does not detect this." Everything else checked out:

• 30 laid out, 0 skipped over 51 flows
• idempotent — a second run reports 0 flows would change, 51 already laid out
• mx check 0 errors, 44/44 microflow tests still pass
• "only positions change" holds: describing all 50 microflows before and after with coordinates normalised away leaves only 81 @anchor(to: …) lines, which the help documents as in scope

Two smaller observations from the same run

Splitting these out if you'd prefer separate issues — they're minor.

1. An annotation loses its explicit position. In ACT_SolveGrid:

@annotation(text: 'Propagate until neither rule can place another digit', position: (27160, 100))   -- before
@annotation 'Propagate until neither rule can place another digit'                                   -- after

Text intact, position dropped. On a canvas where everything else moved, a free-floating annotation with no position may not land near what it annotates. This was the only non-@anchor difference across all 50 flows.

2. 13 MPR011 survive the layout. Down from 67, so the rule is largely handled, but not fully — e.g.:

Activity '(unnamed)' at (630,80) lies outside the loop 'loop' that contains it
(box 1260x335) in microflow 'Sudoku.ACT_SolveGrid'.

Concentrated in the flows with nested loops: SUB_ValidateGrid (3), SUB_ShuffleSolution (3), ACT_SolveGrid (3), then one each in four others.

Suggested guard

Run mxcli lint before and after layout flows in the command's own test on a fixture with nested loops and merge nodes, and assert that MPR008 does not increase and MPR011 does not increase. Both rules already exist and both are computed from exactly the positions this command writes, so it's a cheap self-check — the layouter can be graded by the linter that ships beside it.